|
probably 99% of my time spent with git i just use it and it works fine. maybe more than 99%. i have also never stopped to seriously think about directed acyclic graphs while using git. however, i also know what they are, because i am familiar with more data structures than just an array
|
#
?
Jul 31, 2022 23:53
|
|
|
|
| # ? Apr 27, 2024 17:09 |
|
|
painful merges are rare for me unless some moron decides to rewrite everything
|
|
#
?
Aug 1, 2022 00:00
|
|
|
a lot of people deal with merge conflicts way more than they need to because they never bothered to learn what a rebase is or how to perform one i used to work at a place that used mercurial and the first thing they did was have me download a CompanyNameMercurialExtensions.dll and shove it in my mercurial folder which caused it to yell at me and refuse to create 2 tips on one branch, among other things feels like that's a feature where there's nothing wrong with it in theory but in practice nobody should ever want to do that on purpose
|
|
#
?
Aug 1, 2022 00:03
|
|
|
sb hermit posted:Mercurial is fine. We use it at work. Having multiple heads on the same branch is not ideal for people who can't, for some reason, get their heads around the concept. For this reason, git might be a bit more user friendly in that aspect. the biggest problem with mercurial and other dvcs solutions is that, like it or not, git won. these days, everything has git support built in (even perforce has a git compatibility layer), so if you use mercurial, the first thing new people have to do is learn how to use mercurial and then they will never stop complaining about how their favorite tool doesn't have it built in like it does git
|
|
#
?
Aug 1, 2022 00:19
|
|
|
raminasi posted:you can absolutely tell the cli tool to move a subtree. it's a fundamental operation. git's problem is that it's called "rebase," which is obvious to no one. you're dismissing the graph model in the same breath that you talk about "incantations" and "clusterfucks of rebases and cherry-picks," which is the #1 symptom of someone using git without thinking about the graph. thinking of git as a series of "incantations" that need to be executed in some magical, correct order to accomplish tasks is the deficient approach that causes people to hate git and be bad at it, and it is 100% caused by dismissing the graph. no, that's exactly my point. step (3a) is often one of the bigger hurdles in using git. even if you know the DAG model and what you want to do to it, you can't just will that change into being, and the actual UX around doing it is often rear end mystes posted:Probably because everyone is busy minmaxing their resume points by making everything as complicated as humanly possible? or just straight overengineering everything cause of delusions of possible future grandeur. idk how to persuade one of my coworkers that not everything needs to be a very extensible framework. we got: - a phone-home telemetry system. this used to work by just running a bunch of functions in sequence and concatenating their output to send it to a reporting server. we got a request to add a new metric. this request somehow turned into a complete overhaul of the system with the goal of somehow making it "extensible" (idk how, the simple-rear end interface of "generate a k=v string" was already sufficient to support anything the telemetry server can ingest) and something that other teams would also use (we are one of three golang teams in the org: one is not allowed to do phone-home metrics at all, and the other we did not consult with to see what they'd need in a shared library) - a new internal alpha project. coworker wants to add a "plugin" system. the proposal to do this does not indicate specific intended uses or even which systems you'd be able to manipulate (or rather, it kinda does the latter, but it mentions every major system): the motivation is essentially that "plugin systems are good" meanwhile the product we know _does_ need this treatment (it's a tool that we started using as a library, and we never worked to decouple the UI from the implementation or refactor its implementation to better support more than the one originally intended workflow) remains untouched, cause that's not greenfield
|
|
#
?
Aug 1, 2022 00:32
|
|
|
MrMoo posted:What confuses me the most, is that the many senior developers I see have no respect for making projects easy to work with. It always gets brushed off and ignored. i once attended a design review presented by two senior devs who needed to write a simple batch process and instead wrote a batch process that writes each item to kafka, processes the individual items, and then writes to a temp location for another batch process that then runs to complete the batch
|
|
#
?
Aug 1, 2022 00:43
|
|
|
12 rats tied together posted:a lot of people deal with merge conflicts way more than they need to because they never bothered to learn what a rebase is or how to perform one that doesn't really make sense to me; if you're the only one working on a branch rebasing makes no difference at all wrt merge conflicts, and if other people are working on it I guess you "don't deal" with the merge conflicts because the commit you're working off of suddenly disappears instead 12 rats tied together posted:i used to work at a place that used mercurial and the first thing they did was have me download a CompanyNameMercurialExtensions.dll and shove it in my mercurial folder which caused it to yell at me and refuse to create 2 tips on one branch, among other things seems like something that should be enforced at the central server (and iirc it's already a built-in feature that a non-force-push doesn't let you make multiple heads)
|
|
#
?
Aug 1, 2022 01:40
|
|
|
One of our repos has a tag named "list" that almost definitely got created because every command expects arguments differently like `-l`, `--list`, or `list`, depending on how the git devs were feeling at the time I guess.
|
|
#
?
Aug 1, 2022 02:10
|
|
|
has anyone tried adding a new layer on top of git that just renames commands and other stuff to not be dogshit?
|
|
#
?
Aug 1, 2022 02:20
|
|
|
many many times. they never last because they abstract too much, and when users of them land in a rough spot, they can no longer speak the the lingua franca of git misery
|
|
#
?
Aug 1, 2022 02:25
|
|
|
yeah that's about what i figured
|
|
#
?
Aug 1, 2022 02:34
|
|
|
cool av posted:that doesn't really make sense to me; if you're the only one working on a branch rebasing makes no difference at all wrt merge conflicts, the situation im thinking of is one where a shared base changes out from under you, people merge the base into their branch instead of rebasing on top of it, which results in repeatedly resolving the same or similar conflicts as git interleaves the new history of the base with the existing history of the branch. i assume that this + not enforcing a squash requirement on the base is what people mean when they talk about merge conflict hell etc in a trunk based feature branch workflow it should never matter to you the order of commits between your branch and its base, you should always strive to strictly be "the single next merge commit to base", so you should rebase your branch on an updated base and just be "the next commit to whatever file" which is a no conflict operation
|
|
#
?
Aug 1, 2022 02:42
|
|
|
It's always important to have a shared base, yes. I liked when a coworker came to me because they were trying to get the last thing out of SVN and into Github and said, "I found a page on something called Gitflow?" and I got to say, "Ignore all that. Just coordinate so the two of you don't edit the same poo poo at the same time."
|
|
#
?
Aug 1, 2022 02:49
|
|
|
brand engager posted:One of our repos has a tag named "list" that almost definitely got created because every command expects arguments differently like `-l`, `--list`, or `list`, depending on how the git devs were feeling at the time I guess. i have done this (might have been with branch names though) and it is infuriating
|
|
#
?
Aug 1, 2022 02:58
|
|
|
MrMoo posted:Coming up to a month having worked with a Googler refactoring a project, and I have a boat load of hot takes. hey yeah this is global ime and something i get into poo poo about constantly fight this fight folks, it needs to be done
|
|
#
?
Aug 1, 2022 03:04
|
|
|
qsvui posted:why should i? it'll have no impact on my work how do you know that something you've somehow never heard of will have no impact on your work? "anything i don't already know must not be useful to know" is a pretty dumb way to go through life.
|
|
#
?
Aug 1, 2022 03:37
|
|
|
redleader posted:i have done this (might have been with branch names though) and it is infuriating git tag rm something oops git tag -d rm (going by memory but intended story is "made a tag called 'rm'")
|
|
#
?
Aug 1, 2022 03:48
|
|
|
12 rats tied together posted:the situation im thinking of is one where a shared base changes out from under you, people merge the base into their branch instead of rebasing on top of it, which results in repeatedly resolving the same or similar conflicts as git interleaves the new history of the base with the existing history of the branch. i assume that this + not enforcing a squash requirement on the base is what people mean when they talk about merge conflict hell etc merging the latest base branch commit into your feature branch requires resolving conflicts up to that point, you don't have to do it again... exactly the same as rebasing on top of the latest base branch commit; there's really no functional difference except an extra edge in the DAG (extraneous edges can be problematic in situations with 3 or more criss-crossing branches, but Please Don't Do That and afaik you can't make that workflow work with rebasing either because you have to pick one of the other 2 branches to rebase off)
|
|
#
?
Aug 1, 2022 04:18
|
|
|
cool av posted:merging the latest base branch commit into your feature branch requires resolving conflicts up to that point, you don't have to do it again... exactly the same as rebasing on top of the latest base branch commit; there's really no functional difference except an extra edge in the DAG yes, these are the obvious ways to go about it if you understand what a commit graph is and how you want it to evolve, and it all works pretty smoothly. if you are someone who does not understand what a commit graph is, does not want to learn what one is, and just plows through rote-learning specific incantations that appear to do what you want them to do, it is possible to do very silly things with git that will cause you lots of merge pain. if you then try to fix it by looking up more incantations on stack overflow instead of actually trying to understand how things work, then you can easily gently caress things up even worse from there.
|
|
#
?
Aug 1, 2022 04:34
|
|
|
pokeyman posted:git tag rm something that's why I use a GUI for 95% of git stuff (fork, specifically) Jabor posted:if you are someone who does not understand what a commit graph is, does not want to learn what one is, and just plows through rote-learning specific incantations that appear to do what you want them to do, it is possible to do very silly things with git that will cause you lots of merge pain. if you then try to fix it by looking up more incantations on stack overflow instead of actually trying to understand how things work, then you can easily gently caress things up even worse from there. I had a co-worker do this in his first few weeks at the company last year; he must've just discovered rebasing or something. Ended up pushing 3 sets of the same 4 or 5 nearly identical commits with a couple of merges. he hasn't hosed it since then (afaik) so that's progress I guess. edit: I should add this place does not have PRs or code reviews, so that mess lives the onion wizard fucked around with this message at 06:27 on Aug 1, 2022 |
|
#
?
Aug 1, 2022 06:14
|
|
|
qsvui posted:no, no, no, no, no How have you never used dependencies?
|
|
#
?
Aug 1, 2022 07:11
|
|
|
embedded linux, they might literally just only have libc
|
|
#
?
Aug 1, 2022 07:14
|
|
|
bob dobbs is dead posted:embedded linux, they might literally just only have libc how someone contributes to buildroot but has never used make graph-depends is mind boggling to me tho
|
|
#
?
Aug 1, 2022 07:24
|
|
|
Xarn posted:How have you never used dependencies? I sidestep the issue of working with dags by making every function only reference itself.
|
|
#
?
Aug 1, 2022 07:57
|
|
|
graphs are everywhere and I work with them all the time but I dont particularly think of git as one tbh
|
|
#
?
Aug 1, 2022 11:02
|
|
|
akadajet posted:painful merges are rare for me unless some moron decides to rewrite everything the secret here is to be the guy that rewrites everything
|
|
#
?
Aug 1, 2022 12:50
|
|
|
one of the things I really like about using the MVC pattern is that it's easy to not overlap work between people, though if you do and you get a merge conflict on a cshtml view, god help you
|
|
#
?
Aug 1, 2022 12:57
|
|
|
Powerful Two-Hander posted:one of the things I really like about using the MVC pattern is that it's easy to not overlap work between people, though if you do and you get a merge conflict on a cshtml view, god help you  but for vuejs. "wait where did this thing go?" is too common a question
|
|
#
?
Aug 1, 2022 13:26
|
|
|
Oh that reminds me, almost everyone should change the git config so pull.rebase=true (will rebase instead of doing a merge commit if your local branch had changes not in the remote when you pull) and merge.conflictstyle=diff3 (shows what the conflicting section looked like in the common ancestor commit before yours and the other conflicting branch changed it). There's probably plenty more I don't know about, a bunch of the default git settings are terrible.
|
|
#
?
Aug 1, 2022 16:42
|
|
|
rebase looks way less messy than merge. if you gently caress up rebase materially you lose data whereas thats less a thing w merge diff3 is good tho bob dobbs is dead fucked around with this message at 21:37 on Aug 1, 2022 |
|
#
?
Aug 1, 2022 17:28
|
|
|
Just use lazygit and 95% of your git tasks are like, 3 keystrokes at most. Even makes squashing commits a seamless, one step process like it probably should be in the CLI.
|
|
#
?
Aug 1, 2022 17:42
|
|
|
InternetOfTwinks posted:Just use lazygit and 95% of your git tasks are like, 3 keystrokes at most. Even makes squashing commits a seamless, one step process like it probably should be in the CLI. i couldnt figure it out so: how do i squash more than one commit at a time?
|
|
#
?
Aug 1, 2022 18:37
|
|
|
I just go one at a time, then edit the commit message once I'm done. Lazy, but it works. I think you can tag the commits to squash as fixup commits with f then S on the next commit under them to autosquash all though.
InternetOfTwinks fucked around with this message at 20:57 on Aug 1, 2022 |
|
#
?
Aug 1, 2022 20:55
|
|
|
Plorkyeran posted:how do you know that something you've somehow never heard of will have no impact on your work? "anything i don't already know must not be useful to know" is a pretty dumb way to go through life. i've been doing the same embedded c poo poo for like a decade now. pretty sure this field won't catch up to the rest of the world before i'm dead. also, where'd this dumb projection about "anything" come from? we're talking about one thing that nobody besides computer touchers needs to know (and not even then)
|
|
#
?
Aug 1, 2022 21:23
|
|
|
Share Bear posted:i couldnt figure it out so: how do i squash more than one commit at a time? i use "git rebase -i HEAD^^^^^" and insert s'es
|
|
#
?
Aug 1, 2022 21:37
|
|
|
Xarn posted:How have you never used dependencies? it's me, i'm the terrible programmer
|
|
#
?
Aug 1, 2022 22:02
|
|
|
Share Bear posted:i couldnt figure it out so: how do i squash more than one commit at a time? right click how far back you wanna go and choose interactive rebase use the git-fork.com app, not the garbage cli
|
|
#
?
Aug 1, 2022 22:37
|
|
|
The_Franz posted:he didn't write that. it came to quake3 from someone who was at sgi where the constants were tweaked at some point during the 90s, but the actual origin is unknown. it was probably originally invented by some random person in a cubicle at sgi or sun or dec or wherever in the 80s https://www.youtube.com/watch?v=Fm0vygzVXeE this video by an ex-microsoft engineer places it as a collaboration at xerox parc with some okay sourcing.
|
|
#
?
Aug 1, 2022 23:25
|
|
|
Arivia posted:https://www.youtube.com/watch?v=Fm0vygzVXeE
|
|
#
?
Aug 1, 2022 23:52
|
|
|
|
| # ? Apr 27, 2024 17:09 |
|
|
brand engager posted:shows what the conflicting section looked like in the common ancestor commit omg i've been doing 3-way git diffs this whole time (because it is the default on my tool) and always wondered wtf the middle one was supposed to be. usually i just copy and paste either "mine" or "theirs" into the middle and work from there
|
|
#
?
Aug 2, 2022 01:18
|
|