9 ms·

Honest question - does git have to be as complicated as it is for most usages? The number of times I got stuck fixing (mine and other people's) git issues is wa

by vvpan 3y ago

Honest question - does git have to be as complicated as it is for most usages? The number of times I got stuck fixing (mine and other people's) git issues is way more than seems necessary. I have not used a merge at a workplace for so long that I forget how it works, because rebases make so much more sense. Git provides a thousand features and I find myself using only three. And yet mercurial (which I remember having a more streamlined UX) went the way of the dodo.

waynecochran 3y ago
There is a very simple workflow that uses a small subset of git commands -- I try to never stray from that. When I do, there is stackoverflow, ohshitgit.com, and I also know an expert who can help me untangle things if I am really unsure.
- dboreham 3y ago
  Also I've always found that cp working-tree broken-tree, then git clone <new-tree> then <manually fix up files I was working on> almost always beats trying to detailed the 10 suggested SO solutions.
  - Galanwe 3y ago
    That's basically what I did the first year working with git. Then I met a coworker that told me to stop doing this and come with him on a whiteboard to understand and solve the problem. That was painful the first month, but after some months of that treatment I had a strong mental model of exactly what happened, and how to fix it. I think overall the mental model is to 1) get knowledgeable enough to be able to actually draw the current graph of commits, branches and inheritance 2) clearly lay down the desired structure of the target graph 3) perform the steps necessary to transform the graph from 1) to 2).
  - mbork_pl 3y ago
    Also, Git has this weird feature called "workdirs" which may help with that, too.
  - coryrc 3y ago
    http://learngitbranching.js.org http://learngitbranching.js.org A couple hours and you'll never need to do that again. I promise!
  - samus 3y ago
    I've always found that a good Git user interface goes a long way to understand what is really going on. The commit graph and the conflict resolution UIs are most important. The right choice is very personal - I've found understanding the contents of a repo purely on the terminal to be torture, even though I issue most commands from there.
twosdai 3y ago
Funny enough. I only use merge because rebase makes no sense to me. As an aside, I think git complexity can arise for two reasons. One is legitimate, if you have hundreds or thousands of devs committing to the same repo regularly you need to have some order to the chaos otherwise it just will grind to a halt. The other is bullshit. Where some dev / management people believe that the git process needs to be complex for small teams due to the need to justify their place by "promoting safety". In small team environments, simple branching off of main and then committing prs directly to main is more than enough in my opinion. But git gives you the tools to go as crazy as you want, so some people do.
- dale_glass 3y ago
  Rebase is simple. It's "take these commits, and apply them one by one on top of another branch". So let's say your main development line is the "main" branch. You start working on "bugfix", so you branch-off from "main". You do this on November 1. So you make commits: "Fix bug". Then "Remove debug code", then "Rename X to Y". Now it's 10 days later. Say a coworker is doing some other work at the same time, and just merged this into "main". You want to make sure that after that, everything still works properly. Maybe somebody changed something that makes the code you wrote no longer work, because somebody happened to fix a typo in a function's name or something, and you wrote your code against the old name which just ceased to exist. So you do "git rebase main". What you're telling Git is "take the commits I made during the last 10 days, and apply them on top of the current main". It's like if you created a new branch then just applied the commits one by one by hand. You can do this as often as you want, so if you've got some experimental refactor that takes you a month you can keep on rebasing daily to make sure that if there's any conflicts you have to deal with, you deal with it a little at a time, instead of having to figure out how to square a month of your work with a month of the rest of the project's work once you're done. With this once you merge this into master, you get a "fast-forward" merge, which looks as if you were working on top of master all along. Instead of a single merge commit you see all 10 commits you made for the branch. You can also do an "interactive rebase", where instead of having the process automated you can make decisions about each commit individually. This allows you to rename, merge, or discard commits. Like you've got 10 embarrassing looking commits where you just poke stuff at random in hopes of that it'll finally work? You can make them disappear entirely, or merge them all into one commit.
seba_dos1 3y ago
Git is a data structure manipulation tool. LibreOffice also doesn't have to be so complicated as it is for most usages, it's just that everyone uses a different 5% of its functionality and considers it essential.
juped 3y ago
Instead of hijacking this post to start a flame war, why not promote mercurial without hijacking a post by drawing a parallel to mercurial's implementation of the same thing described in the article, highlighting commonalities and distinctions in the approaches?
- vvpan 3y ago
  I probably should not have mentioned mercurial. I do not really know it anymore, but it is somewhat more UX focused than git. I think my original argument stands, especially considering the comments - too many ways to use Git, while most people need only basics.
AlotOfReading 3y ago
Git could definitely have a simpler interface, but massively simplifying the mental burden would ultimately involve reducing its power as a tool. A significant part of the appeal is that the power users and the novices can both agree on the same tool and make it work for their needs. There's a huge "aftermarket" of frontends and scripts to simplify the experience in the way you want. Some of them, like jujutsu [0] are basically entirely new VCSs built on top of git (and influenced by mercurial). I didn't mind mercurial, but I think it's telling that even the tech behemoths championing it like Google and Facebook forked off into their own tools (fig/sapling). The latter even supports git directly. That battle is long over. [0] https://github.com/martinvonz/jj https://github.com/martinvonz/jj
- coryrc 3y ago
  Fig is an abstraction over top of Perforce. Before fig was a git-UI-based tool and it is gone. Mercurial's interface is way better than git. The fact that Mercurial does not scale to a Google-sized monorepo is not an indictment of Mercurial.
  - AlotOfReading 3y ago
    From what I understand, the local instance in fig is/was a full-on local mercurial repo, just not the entire monorepo (which doesn't leave Piper).
    - coryrc 3y ago
      I suppose it must be because you can create commits which don't exist in Perforce.
doctorpangloss 3y ago
When you experience no Git issues: - you know what you're doing, or - you are not working with other people, or - you are working with other people, but on different things Git is a dual of Conway's Law. Your Git repos tell the best story about your experience as a developer.
- yencabulator 3y ago
  That's just version control, nothing special about Git there. I guess a lot of kids running around these days never had this stuff happen, in worse forms, with CVS et al.
Tyr42 3y ago
I mean, this article is talking about how git works behind the scenes to make cherry pick work better and be less likely to fail to apple the patch. Yes there is complexity, but this is actually one of (rare) cases where git hides complexity successfully.
darklycan51 3y ago
Git seems extremely over complicated for no reason, half of the features seem to exist because the system is so easy to mess up.
- yencabulator 3y ago
  "I've only ever used a hammer so other tools should not exist." Supporting remote-use CVS for a distributed multi-team development group was pure hell, and regularly had me going to lunch while waiting for simple command to finish. I'm glad git's features exist.
bloopernova 3y ago
Try this tutorial: https://alexwlchan.net/a-plumbers-guide-to-git/ https://alexwlchan.net/a-plumbers-guide-to-git/ It helped me to more fully understand Git.
jkubicek 3y ago
> The number of times I got stuck fixing (mine and other people's) git issues is way more than seems necessary. I almost never have any issues with git, I wonder if you're working differently than I do? > I have not used a merge at a workplace for so long that I forget how it works, because rebases make so much more sense. Oh, that's the reason. I've been using git almost as long as github.com has been a thing and I'm convinced that if you find yourself rebasing, _especially_ if rebasing is a normal part of your workflow, you're using git wrong. Here's how I work: 1. All development is on a features branch 2. Feature branches are tight and focused 3. Frequent merges from `main` to stay up-to-date 4. Squash your branch into a single commit before merging This gets you everything you want from source control (linear history of well-structured atomic changes) without any of the gymnastic skills necessary to be a competent rebaser. Oh, and I never get stuck fixing weird issues, because it's impossible for me to generate weird issues. The worst thing I encounter is a merge conflict, and merge conflicts are the easiest possible conflicts to resolve.
- happytoexplain 3y ago
  I have to disagree with #4. If your branch's commit history is unnecessarily fragmented because it evolved as you worked, then yes, squash those commits - but "one commit per feature" as a rule doesn't work for many kinds of features which by their nature can be made only so "tight and focused". Sometimes it's an undue burden to have to view a feature's patch as a single diff, even if the feature is functionally as atomic as it can get.
  - jkubicek 3y ago
    First, my feature branch commit history is always fragmented and unusable. I commit extremely liberally, every few minutes if I'm actively making changes. Why not? If I always squash before I merge, nobody seems my junk, and being able to back up a few steps after coding down the wrong path is super useful. Second, if I do create a feature that should be multiple commits for clarity, I find it a lot easier to do all my work in a scratch feature branch, get everything working correctly, tests passing, etc., then do a `git merge --no-commit` onto my final feature branch for the PR. At that point I can break my work up into a few different commits, as necessary.
deleted 3y ago
[deleted]
- deleted 3y ago
  [deleted]
twic 3y ago
I still use Mercurial for personal projects! I do think it's superior to Git in many ways, and simpler than Git in many ways, but now i've got used to Git, i increasingly find myself getting stuck in Mercurial. For example, recently i included changes i didn't want in a commit, and found i had no good way out of the situation, whereas in Git i would just reset the branch to HEAD^ and try again.
- coryrc 3y ago
  hg histedit edit, commit hg add <smaller set of files> hg commit Possibly hg histedit, then reverse commit order (down commit).
  - naasking 3y ago
    Could also strip while keeping changes and then redo the commits.
andirk 3y ago
"With great power comes great responsibility" That's version control. You have every choice from straight forward to mind-blowingly time-manipulatingly complex. If you fear the unknown, then just do the out of the box stuff via a GUI like Sourcetree. If you're willing to sweat, then use Sourcetree but sometimes `git rebase HEAD~3` and rewrite history. And there's no shame in adding a `Fix: Change var to int` to be written into the annals of history forever. Don't worry about it.
speed_spread 3y ago
Git won because of Github and not much else. Git was conceived to manage the Linux source tree, which is a problem in a class of its own. Fully decentralized source management requires an extremely flexible system, which conversely precludes any kind of implicit workflow. While this goes against previous SCM (svn, etc.) it also leaves a serious void for regular organizations that just need to keep doing centralized, trunk-based development. Github provides that missing layer in a friendly, accessible manner. Ironically, by normalizing its usage, Github takes away a lot of the justification for git itself. You could achieve the same model with mercurial, bazaar, etc. which also have the advantage of a sane CLI.
- baq 3y ago
  Git was winning already and GitHub just made doubly sure it did. Git was winning before GitHub because it was fast. Like, everything else was dog slow in comparison. Yes, hg was slower, sometimes much slower. Alternatives were also hard to set up compared to git init and git push over ssh. (Ye olde svn, I’m looking at you.)
naasking 3y ago
> I have not used a merge at a workplace for so long that I forget how it works, because rebases make so much more sense. It boggles my mind that people think 1) rebase makes more sense than branching and merging, and 2) that someone would use rebase so much that they forget how to branch and merge.
- singingfish 3y ago
  I had a detailed discussion with a former colleague about this the other day. They're in the merge camp, and I'm in the "any code that actually makes it into the wild should have a linear history" (rebase) camp. Merge commits have multiple parents which makes visual inspection confusing, and it makes it much harder to use git bisect which is a tool that can save many hours of painstaking manual work. I clearly think that the rebase version is the correct approach, but I can see there are upsides and downsides for both. Sometimes for long lived branches I get merge commits in my feature / bugfix branches, but those are going to end up squash merged onto our release branch, so in the end the main thing I care about is the linearity of history in master/develop. Combination of linear history and appropriate use of annotated tags for releases makes it way easier to see what actually happened (i.e. the intentionality). A merge based approach shows you what people were actually doing though.
  - naasking 3y ago
    I'll leave this here for you to peruse: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md > Combination of linear history and appropriate use of annotated tags for releases makes it way easier to see what actually happened (i.e. the intentionality). I still haven't heard a good reason why linear history using git as an archaeological tool is the appropriate method to "infer intent". It seems like you would only have to infer intent this way if you have poor development practices, like not adding appropriate comments and not tying important changes to tickets that provide more background/context.
    - singingfish 3y ago
TexasMick 3y ago
I basically refuse to fix other people's git issues because 99% of the time they don't know how the basics.

by vvpan 3y ago

waynecochran 3y ago

There is a very simple workflow that uses a small subset of git commands -- I try to never stray from that. When I do, there is stackoverflow, ohshitgit.com, and I also know an expert who can help me untangle things if I am really unsure.

dboreham 3y ago
Also I've always found that cp working-tree broken-tree, then git clone <new-tree> then <manually fix up files I was working on> almost always beats trying to detailed the 10 suggested SO solutions.
- Galanwe 3y ago
  That's basically what I did the first year working with git. Then I met a coworker that told me to stop doing this and come with him on a whiteboard to understand and solve the problem. That was painful the first month, but after some months of that treatment I had a strong mental model of exactly what happened, and how to fix it. I think overall the mental model is to 1) get knowledgeable enough to be able to actually draw the current graph of commits, branches and inheritance 2) clearly lay down the desired structure of the target graph 3) perform the steps necessary to transform the graph from 1) to 2).
- mbork_pl 3y ago
  Also, Git has this weird feature called "workdirs" which may help with that, too.
- coryrc 3y ago
  http://learngitbranching.js.org http://learngitbranching.js.org A couple hours and you'll never need to do that again. I promise!
- samus 3y ago
  I've always found that a good Git user interface goes a long way to understand what is really going on. The commit graph and the conflict resolution UIs are most important. The right choice is very personal - I've found understanding the contents of a repo purely on the terminal to be torture, even though I issue most commands from there.

twosdai 3y ago

Funny enough. I only use merge because rebase makes no sense to me. As an aside, I think git complexity can arise for two reasons. One is legitimate, if you have hundreds or thousands of devs committing to the same repo regularly you need to have some order to the chaos otherwise it just will grind to a halt. The other is bullshit. Where some dev / management people believe that the git process needs to be complex for small teams due to the need to justify their place by "promoting safety". In small team environments, simple branching off of main and then committing prs directly to main is more than enough in my opinion. But git gives you the tools to go as crazy as you want, so some people do.

dale_glass 3y ago
Rebase is simple. It's "take these commits, and apply them one by one on top of another branch". So let's say your main development line is the "main" branch. You start working on "bugfix", so you branch-off from "main". You do this on November 1. So you make commits: "Fix bug". Then "Remove debug code", then "Rename X to Y". Now it's 10 days later. Say a coworker is doing some other work at the same time, and just merged this into "main". You want to make sure that after that, everything still works properly. Maybe somebody changed something that makes the code you wrote no longer work, because somebody happened to fix a typo in a function's name or something, and you wrote your code against the old name which just ceased to exist. So you do "git rebase main". What you're telling Git is "take the commits I made during the last 10 days, and apply them on top of the current main". It's like if you created a new branch then just applied the commits one by one by hand. You can do this as often as you want, so if you've got some experimental refactor that takes you a month you can keep on rebasing daily to make sure that if there's any conflicts you have to deal with, you deal with it a little at a time, instead of having to figure out how to square a month of your work with a month of the rest of the project's work once you're done. With this once you merge this into master, you get a "fast-forward" merge, which looks as if you were working on top of master all along. Instead of a single merge commit you see all 10 commits you made for the branch. You can also do an "interactive rebase", where instead of having the process automated you can make decisions about each commit individually. This allows you to rename, merge, or discard commits. Like you've got 10 embarrassing looking commits where you just poke stuff at random in hopes of that it'll finally work? You can make them disappear entirely, or merge them all into one commit.

seba_dos1 3y ago

Git is a data structure manipulation tool. LibreOffice also doesn't have to be so complicated as it is for most usages, it's just that everyone uses a different 5% of its functionality and considers it essential.

juped 3y ago

Instead of hijacking this post to start a flame war, why not promote mercurial without hijacking a post by drawing a parallel to mercurial's implementation of the same thing described in the article, highlighting commonalities and distinctions in the approaches?

vvpan 3y ago
I probably should not have mentioned mercurial. I do not really know it anymore, but it is somewhat more UX focused than git. I think my original argument stands, especially considering the comments - too many ways to use Git, while most people need only basics.

AlotOfReading 3y ago

Git could definitely have a simpler interface, but massively simplifying the mental burden would ultimately involve reducing its power as a tool. A significant part of the appeal is that the power users and the novices can both agree on the same tool and make it work for their needs. There's a huge "aftermarket" of frontends and scripts to simplify the experience in the way you want. Some of them, like jujutsu [0] are basically entirely new VCSs built on top of git (and influenced by mercurial). I didn't mind mercurial, but I think it's telling that even the tech behemoths championing it like Google and Facebook forked off into their own tools (fig/sapling). The latter even supports git directly. That battle is long over. [0] https://github.com/martinvonz/jj https://github.com/martinvonz/jj

coryrc 3y ago
Fig is an abstraction over top of Perforce. Before fig was a git-UI-based tool and it is gone. Mercurial's interface is way better than git. The fact that Mercurial does not scale to a Google-sized monorepo is not an indictment of Mercurial.
- AlotOfReading 3y ago
  From what I understand, the local instance in fig is/was a full-on local mercurial repo, just not the entire monorepo (which doesn't leave Piper).
  - coryrc 3y ago
    I suppose it must be because you can create commits which don't exist in Perforce.

doctorpangloss 3y ago

When you experience no Git issues: - you know what you're doing, or - you are not working with other people, or - you are working with other people, but on different things Git is a dual of Conway's Law. Your Git repos tell the best story about your experience as a developer.

yencabulator 3y ago
That's just version control, nothing special about Git there. I guess a lot of kids running around these days never had this stuff happen, in worse forms, with CVS et al.

Tyr42 3y ago

I mean, this article is talking about how git works behind the scenes to make cherry pick work better and be less likely to fail to apple the patch. Yes there is complexity, but this is actually one of (rare) cases where git hides complexity successfully.

darklycan51 3y ago

Git seems extremely over complicated for no reason, half of the features seem to exist because the system is so easy to mess up.

yencabulator 3y ago
"I've only ever used a hammer so other tools should not exist." Supporting remote-use CVS for a distributed multi-team development group was pure hell, and regularly had me going to lunch while waiting for simple command to finish. I'm glad git's features exist.

bloopernova 3y ago

Try this tutorial: https://alexwlchan.net/a-plumbers-guide-to-git/ https://alexwlchan.net/a-plumbers-guide-to-git/ It helped me to more fully understand Git.

jkubicek 3y ago

> The number of times I got stuck fixing (mine and other people's) git issues is way more than seems necessary. I almost never have any issues with git, I wonder if you're working differently than I do? > I have not used a merge at a workplace for so long that I forget how it works, because rebases make so much more sense. Oh, that's the reason. I've been using git almost as long as github.com has been a thing and I'm convinced that if you find yourself rebasing, _especially_ if rebasing is a normal part of your workflow, you're using git wrong. Here's how I work: 1. All development is on a features branch 2. Feature branches are tight and focused 3. Frequent merges from `main` to stay up-to-date 4. Squash your branch into a single commit before merging This gets you everything you want from source control (linear history of well-structured atomic changes) without any of the gymnastic skills necessary to be a competent rebaser. Oh, and I never get stuck fixing weird issues, because it's impossible for me to generate weird issues. The worst thing I encounter is a merge conflict, and merge conflicts are the easiest possible conflicts to resolve.

happytoexplain 3y ago
I have to disagree with #4. If your branch's commit history is unnecessarily fragmented because it evolved as you worked, then yes, squash those commits - but "one commit per feature" as a rule doesn't work for many kinds of features which by their nature can be made only so "tight and focused". Sometimes it's an undue burden to have to view a feature's patch as a single diff, even if the feature is functionally as atomic as it can get.
- jkubicek 3y ago
  First, my feature branch commit history is always fragmented and unusable. I commit extremely liberally, every few minutes if I'm actively making changes. Why not? If I always squash before I merge, nobody seems my junk, and being able to back up a few steps after coding down the wrong path is super useful. Second, if I do create a feature that should be multiple commits for clarity, I find it a lot easier to do all my work in a scratch feature branch, get everything working correctly, tests passing, etc., then do a `git merge --no-commit` onto my final feature branch for the PR. At that point I can break my work up into a few different commits, as necessary.

deleted 3y ago

[deleted]

deleted 3y ago
[deleted]

twic 3y ago

I still use Mercurial for personal projects! I do think it's superior to Git in many ways, and simpler than Git in many ways, but now i've got used to Git, i increasingly find myself getting stuck in Mercurial. For example, recently i included changes i didn't want in a commit, and found i had no good way out of the situation, whereas in Git i would just reset the branch to HEAD^ and try again.

coryrc 3y ago
hg histedit edit, commit hg add <smaller set of files> hg commit Possibly hg histedit, then reverse commit order (down commit).
- naasking 3y ago
  Could also strip while keeping changes and then redo the commits.

andirk 3y ago

"With great power comes great responsibility" That's version control. You have every choice from straight forward to mind-blowingly time-manipulatingly complex. If you fear the unknown, then just do the out of the box stuff via a GUI like Sourcetree. If you're willing to sweat, then use Sourcetree but sometimes `git rebase HEAD~3` and rewrite history. And there's no shame in adding a `Fix: Change var to int` to be written into the annals of history forever. Don't worry about it.

speed_spread 3y ago

Git won because of Github and not much else. Git was conceived to manage the Linux source tree, which is a problem in a class of its own. Fully decentralized source management requires an extremely flexible system, which conversely precludes any kind of implicit workflow. While this goes against previous SCM (svn, etc.) it also leaves a serious void for regular organizations that just need to keep doing centralized, trunk-based development. Github provides that missing layer in a friendly, accessible manner. Ironically, by normalizing its usage, Github takes away a lot of the justification for git itself. You could achieve the same model with mercurial, bazaar, etc. which also have the advantage of a sane CLI.

baq 3y ago
Git was winning already and GitHub just made doubly sure it did. Git was winning before GitHub because it was fast. Like, everything else was dog slow in comparison. Yes, hg was slower, sometimes much slower. Alternatives were also hard to set up compared to git init and git push over ssh. (Ye olde svn, I’m looking at you.)

naasking 3y ago

> I have not used a merge at a workplace for so long that I forget how it works, because rebases make so much more sense. It boggles my mind that people think 1) rebase makes more sense than branching and merging, and 2) that someone would use rebase so much that they forget how to branch and merge.

singingfish 3y ago
I had a detailed discussion with a former colleague about this the other day. They're in the merge camp, and I'm in the "any code that actually makes it into the wild should have a linear history" (rebase) camp. Merge commits have multiple parents which makes visual inspection confusing, and it makes it much harder to use git bisect which is a tool that can save many hours of painstaking manual work. I clearly think that the rebase version is the correct approach, but I can see there are upsides and downsides for both. Sometimes for long lived branches I get merge commits in my feature / bugfix branches, but those are going to end up squash merged onto our release branch, so in the end the main thing I care about is the linearity of history in master/develop. Combination of linear history and appropriate use of annotated tags for releases makes it way easier to see what actually happened (i.e. the intentionality). A merge based approach shows you what people were actually doing though.
- naasking 3y ago
  I'll leave this here for you to peruse: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md > Combination of linear history and appropriate use of annotated tags for releases makes it way easier to see what actually happened (i.e. the intentionality). I still haven't heard a good reason why linear history using git as an archaeological tool is the appropriate method to "infer intent". It seems like you would only have to infer intent this way if you have poor development practices, like not adding appropriate comments and not tying important changes to tickets that provide more background/context.
  - singingfish 3y ago

TexasMick 3y ago

I basically refuse to fix other people's git issues because 99% of the time they don't know how the basics.