34 ms·

The author concludes by saying: >I think I've written before that this profusion of solutions is the sign of a well-designed system. The tools and concepts are

by mcherm 10y ago

The author concludes by saying: >I think I've written before that this profusion of solutions is the sign of a well-designed system. The tools and concepts are powerful, and can be combined in many ways to solve many problems that the designers didn't foresee. I disagree. I consider this to be a failure of Git. The set of different options (normal merge, rebase, filter-branch, etc) is complex and not cleanly orthogonal which makes for a very messy "mental model". Even experienced experts would have difficulty finding the clear, simple way to solve this problem and those less experienced would have little chance of proceeding cleanly. I really wish some tool other than Git had "won" the version-control race; I honestly believe Git to be the worst of the contenders in the most recent generation of version control systems (albeit better than the previous generation in important ways).

stonecodegump 10y ago
I agree. I know there is a lot to Git and you can pretty much do everything. But whenever such discussions come up about how many options there are and how amazing it is, I just glaze over and completely fail to concentrate. I don't think I have the brain power to actually master Git. Luckily I work in a 2 man team, so rarely do I need to do anything particularly complex. I have my workflow and I do what I can not to stray from it.
ipioxu15 10y ago
Git is certainly the best of the version control systems to date, and I'm happy that it won. Experts have no problems with issues like this. The described failure mode also can occur in any existing version control system --- the user is essentially did cp -f ../mybranch/somefile-new.c somefile.c; hg commit somefile.c The history in mybranch touching somefile.c is now partly useless, since all the patches are already applied. Of course, the branch can still be merged, if the conflicts are resolved --- the conflict resolution is then pretty much doing the above command again.
- mtrn 10y ago
  > Git is certainly the best of the version control systems to date, and I'm happy that it won. Me too. What I found was that people do not recognize what tool git really is. People do not read the manuals and count on their world knowledge acquired from years of svn or other centralized systems. It's not the best sign, that you have to really dig git to be able to use it properly. But once you understood the core ideas, you can basically derive a lot of the workflows yourself, in a very principled and clear manner. Also: once you get a bit more familiar with the data model, one almost cannot not appreciate its beauty, I believe.
- warbiscuit 10y ago
  Honestly, I'm in the exact opposite camp - I'm glad mercurial is still alive and kicking, since I've found my experience with it (and tortoisehg) to be superior in a number of ways. Fewer cross platform issues, a much cleaner commandline interface, can hop over to a much more powerful gui if needed -- I generally use it even when I'm interacting with a git repo. That said, I'm far from an expert in git. What do you see as it's advantages? (outside of the larger mindshare, obviously :)
  - nine_k 10y ago
    The UI story of Hg is much better than Git's. The conceptual model of Git looks superior, though: it's more general and more orthogonal. I wish some well thought-out front-end to Git became hugely popular and eventually standard. I mean, including the CLI. Git even has a "plumbing mode" to interact with other programs more easily. But doing that is hard work.
    - rekado 10y ago
      Although I'm quite familiar with git on the command line, I'm using git mostly through magit[1] for Emacs. It's a very functional and discoverable user interface. [1]: https://magit.vc/ https://magit.vc/
      - nine_k 10y ago
        Same here! Magit is brilliant. Emacs is a somehow heavyweight frontend for a VCS, though. OTOH it can be considered a GUI client (and comes with a nice built-in editor).
  - Sir_Cmpwn 10y ago
    The fact that you use a Windows-only GUI for Hg is extremely telling. Git is fundamentally a Unix tool that follows Unix design expectations and integrates with the Unix ecosystem and expects the user to be a component command line user.
    - 10y ago
deanCommie 10y ago
Allow me to disagree with your disagreement. Git fails often for the "basic" use cases. I won't lie. The number of options is intimidating for a beginner and one can easily get themselves into trouble. This is why there are Git guides and tutorials and UIs and they are all ultimately unsatisfying when you're a beginner. However the use case discussed in this article is NOT a beginner use case. It is an advanced case and the fact that Git is an advanced tool that supports it (both natively with git-filter-branch, as the author found out, and ad-hoc-ly as was their original plan is a testament to the power of the system. Tell me how you would better achieve the requirements that were the premise for this article in a different VCS?
- jasoncchild 10y ago
  I agree with your disagreement. Furthermore, I'm curious how this edge case could have been mitigated using an alternative tool? most of my VCS experience is with git, and a very little SVN.
  - agentgt 10y ago
    As an experienced Hg user I will say what the author did would be about the same pain level in Hg (maybe even less if you use some extensions). Regardless it is probably less painful with whatever tool you are most familiar with. I would argue the author probably could have even used SVN (not that I would recommend that at all) given he did some pretty manual scripting stuff (looping through commit ids etc). Of course it his hard for me to tell with out seeing his exact repository (files).
    - AstralStorm 10y ago
      In SVN, this case would completely explode into manually applying a big patch.
    - Someone 10y ago
      "The easiest strategy in a case like this is usually to (go) back in time [...] That strategy wasn't available because X had already published the master with his back-end files, and a hundred other programmers had copies of them." "a hundred other programmers had copies of them." isn't a problem/cannot happen with svn because svn uses a single master repository. Fix it, and everybody can fetch it. That leaves the "going back in time" step. That isn't easy with svn. If you have a backup of your repository, you can create patches for the commits made after it, restore from backup, and replay those you want to keep. If you don't have a backup, the svn administrator can use svnadmin to dump and restore revisions and remove them (http://superuser.com/a/315138 http://superuser.com/a/315138). I think that will be a lengthy operation if your repository has lots of history. It also requires free space to create a copy of your reporpsitory. Disclaimer: I have never used this tool.
pawadu 10y ago
> I consider this to be a failure of Git. The set of different options (normal merge, rebase, filter-branch, etc) is complex and not cleanly orthogonal which makes for a very messy "mental model". Allow me to disagree... Does the CVS or SVN way of doing rebase and filter-branch work with your "mental model"? Well, there is your answer. > I really wish some tool other than Git had "won" the version-control race; I honestly believe Git to be the worst of the contenders in the most recent generation of version control systems Not to sound harsh, but why would I want to use an inferior tool just because you don't get git?
- irishsultan 10y ago
  I disagree with the person you're replying too, but CVS and SVN are not the current generation of version control systems (and CVS is perhaps not even the previous generation), so it's unclear why you bring them up. If you want to compare, compare to darcs, mercurial, bazaar, monotone, ... plenty of choice without going back to svn (let alone cvs).
  - pawadu 10y ago
    I agree with you on all accounts ;) The point I was half-jokingly making was that people don't understand what an extremely powerful tool they have been given and instead complain about shallow stuff that for them is simple to grasp edit: the way mg, bzr and the rest do the advanced stuff [when available] is basically a carbon copy of git.
    - laughinghan 10y ago
      > the way mg, bzr and the rest do the advanced stuff [when available] is basically a carbon copy of git. I'm a pretty big fan of git, but this is an unproductive stance. I don't know much about bzr, but my impression is that darcs pioneered the ideas that became git-rebase, and elsewhere in this thread people are having substantive discussions about hg (Mercurial; I assume that's what you meant by mg) bookmarks and branches vs git branches: https://news.ycombinator.com/item?id=13229582 https://news.ycombinator.com/item?id=13229582
nolemurs 10y ago
I see what you mean about the messy mental model, and I do 100% agree that in a well designed system most problems should have one obvious best solution. That said, I'm not sure that's a fair criticism of git. For instance, in this case, as mentioned below, the author of the article should have just reverted the commit where he checked out the files, then done a normal merge. If you're thinking of everything at the commit level, it's pretty much the obvious thing to do. The first obvious thought is to just backtrack (as mentioned in the article), then once you realize that's off the table (since the code is out in the wild) the very next obvious idea is to revert. Revert is what you do when you can't just undo. It's not even as if his commit involved any merges, so the revert is super easy. I guess I just don't agree that experts would have a hard time finding the simple solution - it was the first thought that popped into my head, and I read the article mostly looking for the explanation for why he didn't just do it. While git does provide near complete control, you almost never need to use more than the basics, and it doesn't have to be confusing. EDIT: Just to make very clear why I think the solution is obvious, the first thought that I think will occur to almost anyone is, "if I can just bring the master branch back to its prior state, then I can merge like usual". The beauty of git is if you can form a coherent idea like "bring the master branch back to its prior state" then you can probably do it, and it probably isn't hard. The mistake the author made was to have that thought, and then instead go off down a rabbit hole, and throw out the original simple idea.
- jdmichal 10y ago
  If you revert, how do you guarantee that the final result is identical to the previously deployed and tested version?
  - cyberpunk 10y ago
    He'd need to revert like 400 commits! Woah that's a real messy one. I hope everyone walks away with a feeling that merging 400 commits in what sounds like a CD env is asking for trouble... I'm probably not going to earn extra ninja points here, but in that situation I'd have turned off the deploy jenkins job, force pushed master back to sanity, squashed these commits into a sensible amount in a new branch, rebased it from master and gotten someone (several someones) to go over the pull rq which should be able to merge without conflict. (Fix conflicts in branch!) Maybe you'll have to get your devs to make a new branch locally and cherry pick their stuff back in, but urgh; I think the solution in the article would have taken me ages to RTFM enough to work it out... The lesson here is merge less, more often, or pay more attention when doing evil things like this should you get into that kind of situ...
stephenboyd 10y ago
I think there's an opportunity for a simpler-to-use alternative CLI Git client. Something more user-friendly than the /usr/bin/git program we're talking about and more developer-friendly than the existing Git GUI apps.
- VLM 10y ago
  Another parallel idea to consider is procedure and policy. The cleanup after the foot-shot was pretty gory, but I'm not sure with disciplined git-flow that its possible to replicate that foot-shot, and if you can't shoot yourself in the foot then the goriness of the cleanup is a non-issue. A third level up is you've got two devs carefully not coordinating and working together on code that closely related to each other, aside from the git-splosion that is not generally a recipe for success. Like, refactor the obviously independent multiple concepts (obviously independent because non-cooperating devs are working separately in parallel on them) in those files into multiple files and then there aren't merges to fight.
- Drdrdrq 10y ago
  There is gitless [0][1], haven't used it though. [0] http://gitless.com/ http://gitless.com/ [1] https://news.ycombinator.com/item?id=12621837 https://news.ycombinator.com/item?id=12621837
justinlaster 10y ago
> The set of different options (normal merge, rebase, filter-branch, etc) is complex and not cleanly orthogonal All of those commands you just listed are clearly defined and serve different purposes. In other cases, most commands or command flags simply help the user do something in an automated fashion that you could do by typing each specific command out (i.e., git pull --rebase). Git's core tooling is mainly centered around graph manipulation, everything else has been added due to convenience. And quite frankly I've never really understood the criticism people levy at git for being "complicated." It's stupidly simple at the end of the day, especially compared to the hodgepodge of features that other VC's provide, all of which don't really work together and are designed to cover some gap in what should be handled in the core design of the VC (I'm looking at you, Mercurial branches and bookmarks). All tools require you to be familiar with them. There's no getting around that. > Even experienced experts would have difficulty finding the clear, simple way to solve this problem I'm not sure how you can possibly say that, the answer is pretty obvious to a lot of us reading this article. This just feels like baseless whining. There is a litany of literature out there that could have easily pointed the author to a well defined, accepted, and documented solution.
- darkerside 10y ago
  > most commands or command flags simply help the user do something in an automated fashion that you could do by typing each specific command out (i.e., git pull --rebase) A tangent perhaps, but would you mind expanding on this? I use `git pull --rebase` frequently, and I'm not sure how this fits into what you described. Is it the specific command, or the automated shortcut? And what's the counterpart? Just trying to check my mental model.
  - mbrock 10y ago
    From the "git-pull" man page: > Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD. > More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With --rebase, it runs git rebase instead of git merge.
VLM 10y ago
Git is just getting in the way of the classic old philosophical discussion of there should only be one correct way to think vs a more multicultural the more ways there are to think and adapt and overcome, the better. The technical discussion of git innards and workflow just get in the way of the core philosophical discussion, and the innards would fall into place if the philosophical question were answered (as if philosophical questions are ever truly answered, LOL) A classic example of the philosophical argument is Perl vs Python. There's infinite ways to express yourself vs there is only one way that works. Now its very politically incorrect to say you like Perl in 2016 and I suspect Git is going to be in big trouble soon enough for the same philosophical reason. I would be interested in hearing what is the philosophical equivalent of Python for source code revision control. I mean... people can't be seriously suggesting going back to RCS/CVS/SVN/Hg, can they? Or I guess they can? Maybe some closed source silo I'm unfamiliar with? Maybe no revision control at all and go back to tgz files with dates embedded in the filename? A classic problem with limiting opportunity, limiting the range of thoughts and ideas, is finding a way to do it without impacting productivity or quality. In that way "use something simpler and enormously less capable" would be considered cheating the philosophical problem.
- bad_user 10y ago
  You're trying to find too much reasoning. Nowadays many people hate Python as well and I'm speaking as an ex-Python developer that now hates Python. And do you know what's ironic about Python? Because the language excluded certain features, it led to multiple non-orthogonal features that solve very specific use-cases and ways of doing things in its ecosystem, with hacks upon hacks meant to implement ideas from other ecosystems, most of them slightly broken. The problem with language simplicity is that it is misunderstood. Simplicity in the language implementation is often correlated with complexity for the developer, being what happens when you limit what can be expressed.
  - VLM 10y ago
    WRT the reasoning I have a gut level feeling its not technically solvable so I'm going for an abstract proof that its equivalent to a known existing unsolvable philosophical debate, therefore any mention of technical problems or feature list of git is bike shedding because its provably unsolvable at a higher level. So if the answer to the philosophical question is two opposing camps, and we have the source code revision control solution for one pole, then all we need to do is find the opposite pole and then ask the two never to merge (oh the extended pun..) groups, to realize the other side exists and please be civil with each other, etc. That could save a lot of wasted effort. Clearly the equivalent of methodically twisting Python into Perl one little bit at a time isn't going to make anyone on any side happy, or vice versa.
SixSigma 10y ago
> I consider this to be a failure of Git. Surely it's a failure of source code as streams of text. If each function was versioned with dependencies then this problem would be eliminated. Replaced by other problems.
theptip 10y ago
This is close to theological discussion territory, and I can see both sides of the argument, so I'm just going to mention that there is an interesting paper[1] from a couple years ago that uses a rigorous concept design process to attempt to simplify Git, and results in a VCS that does indeed require a simpler mental model (Gitless). Personally I'm not going to abandon Git and all the tooling and community it comes with just for a simpler mental model, given that I have a moderately good handle on the (mainline) features of git -- and therein lies the problem. (Although note, Gitless does work on top of Git, so you should be able to use it with Github by the looks of things [2]). I've linked Adrian Colyer's summary of the paper to make it easier to digest: [1]: https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-conceptual-design-analysis/ https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-c... [2]: http://gitless.com/#vs http://gitless.com/#vs
ASalazarMX 10y ago
I'll just leave this here http://xkcd.com/1597/ http://xkcd.com/1597/
- AstralStorm 10y ago
  This could be written about any tool. Especially bad with Perforce and Subversion - which do not really support branching. They say they do, but then the merging is a huge pain.
- deleted 10y ago
  [deleted]
Sir_Cmpwn 10y ago
Remember that git was written by and written for kernel hackers. Most of the people I've found having trouble with git are as far from kernel hackers as you can get and most who don't are quite a bit closer. As a kernel hacker myself, I think Git's interface is superb and intuitive.
- emmelaich 10y ago
  I don't think Junio Hamano (aka gitster) has done much kernel work at all. But point taken.
wilde 10y ago
Luckily there are a bunch of tools that wrap the git primitives to present more friendly UIs. I spend most of my source control time in SourceTree at this point.
agentgt 10y ago
I have to say I am fan of both Mercurial and Git particularly because I'm a crusty old developer who came from some god awful VCS/SCM like PVCS, CVS, RCS, Source safe. I remember first using Perforce for the first time and thinking dear god it is expensive but totally worth it (this was before git). Really what I think needs improvement is better diff/merging interfaces. There really isn't platform independent one that is opensource and free. Right now I use p4merge because it works fairly well on macOS but I still think it sucks (it doesn't have keybindings and yeah I have tried vim and emacs diff ... they are ok but not as easy to visualize diffing).
voidr 10y ago
I would be interested to know that in your view, which VCS would have solved this problem better assuming they would have done the same thing. It seems to me that they chose the worst possible option each time they hit a problem.

by mcherm 10y ago

stonecodegump 10y ago

I agree. I know there is a lot to Git and you can pretty much do everything. But whenever such discussions come up about how many options there are and how amazing it is, I just glaze over and completely fail to concentrate. I don't think I have the brain power to actually master Git. Luckily I work in a 2 man team, so rarely do I need to do anything particularly complex. I have my workflow and I do what I can not to stray from it.

ipioxu15 10y ago

Git is certainly the best of the version control systems to date, and I'm happy that it won. Experts have no problems with issues like this. The described failure mode also can occur in any existing version control system --- the user is essentially did cp -f ../mybranch/somefile-new.c somefile.c; hg commit somefile.c The history in mybranch touching somefile.c is now partly useless, since all the patches are already applied. Of course, the branch can still be merged, if the conflicts are resolved --- the conflict resolution is then pretty much doing the above command again.

mtrn 10y ago
> Git is certainly the best of the version control systems to date, and I'm happy that it won. Me too. What I found was that people do not recognize what tool git really is. People do not read the manuals and count on their world knowledge acquired from years of svn or other centralized systems. It's not the best sign, that you have to really dig git to be able to use it properly. But once you understood the core ideas, you can basically derive a lot of the workflows yourself, in a very principled and clear manner. Also: once you get a bit more familiar with the data model, one almost cannot not appreciate its beauty, I believe.
warbiscuit 10y ago
Honestly, I'm in the exact opposite camp - I'm glad mercurial is still alive and kicking, since I've found my experience with it (and tortoisehg) to be superior in a number of ways. Fewer cross platform issues, a much cleaner commandline interface, can hop over to a much more powerful gui if needed -- I generally use it even when I'm interacting with a git repo. That said, I'm far from an expert in git. What do you see as it's advantages? (outside of the larger mindshare, obviously :)
- nine_k 10y ago
  The UI story of Hg is much better than Git's. The conceptual model of Git looks superior, though: it's more general and more orthogonal. I wish some well thought-out front-end to Git became hugely popular and eventually standard. I mean, including the CLI. Git even has a "plumbing mode" to interact with other programs more easily. But doing that is hard work.
  - rekado 10y ago
    Although I'm quite familiar with git on the command line, I'm using git mostly through magit[1] for Emacs. It's a very functional and discoverable user interface. [1]: https://magit.vc/ https://magit.vc/
    - nine_k 10y ago
      Same here! Magit is brilliant. Emacs is a somehow heavyweight frontend for a VCS, though. OTOH it can be considered a GUI client (and comes with a nice built-in editor).
- Sir_Cmpwn 10y ago
  The fact that you use a Windows-only GUI for Hg is extremely telling. Git is fundamentally a Unix tool that follows Unix design expectations and integrates with the Unix ecosystem and expects the user to be a component command line user.
  - 10y ago

deanCommie 10y ago

Allow me to disagree with your disagreement. Git fails often for the "basic" use cases. I won't lie. The number of options is intimidating for a beginner and one can easily get themselves into trouble. This is why there are Git guides and tutorials and UIs and they are all ultimately unsatisfying when you're a beginner. However the use case discussed in this article is NOT a beginner use case. It is an advanced case and the fact that Git is an advanced tool that supports it (both natively with git-filter-branch, as the author found out, and ad-hoc-ly as was their original plan is a testament to the power of the system. Tell me how you would better achieve the requirements that were the premise for this article in a different VCS?

jasoncchild 10y ago
I agree with your disagreement. Furthermore, I'm curious how this edge case could have been mitigated using an alternative tool? most of my VCS experience is with git, and a very little SVN.
- agentgt 10y ago
  As an experienced Hg user I will say what the author did would be about the same pain level in Hg (maybe even less if you use some extensions). Regardless it is probably less painful with whatever tool you are most familiar with. I would argue the author probably could have even used SVN (not that I would recommend that at all) given he did some pretty manual scripting stuff (looping through commit ids etc). Of course it his hard for me to tell with out seeing his exact repository (files).
  - AstralStorm 10y ago
    In SVN, this case would completely explode into manually applying a big patch.
  - Someone 10y ago
    "The easiest strategy in a case like this is usually to (go) back in time [...] That strategy wasn't available because X had already published the master with his back-end files, and a hundred other programmers had copies of them." "a hundred other programmers had copies of them." isn't a problem/cannot happen with svn because svn uses a single master repository. Fix it, and everybody can fetch it. That leaves the "going back in time" step. That isn't easy with svn. If you have a backup of your repository, you can create patches for the commits made after it, restore from backup, and replay those you want to keep. If you don't have a backup, the svn administrator can use svnadmin to dump and restore revisions and remove them (http://superuser.com/a/315138 http://superuser.com/a/315138). I think that will be a lengthy operation if your repository has lots of history. It also requires free space to create a copy of your reporpsitory. Disclaimer: I have never used this tool.

pawadu 10y ago

> I consider this to be a failure of Git. The set of different options (normal merge, rebase, filter-branch, etc) is complex and not cleanly orthogonal which makes for a very messy "mental model". Allow me to disagree... Does the CVS or SVN way of doing rebase and filter-branch work with your "mental model"? Well, there is your answer. > I really wish some tool other than Git had "won" the version-control race; I honestly believe Git to be the worst of the contenders in the most recent generation of version control systems Not to sound harsh, but why would I want to use an inferior tool just because you don't get git?

irishsultan 10y ago
I disagree with the person you're replying too, but CVS and SVN are not the current generation of version control systems (and CVS is perhaps not even the previous generation), so it's unclear why you bring them up. If you want to compare, compare to darcs, mercurial, bazaar, monotone, ... plenty of choice without going back to svn (let alone cvs).
- pawadu 10y ago
  I agree with you on all accounts ;) The point I was half-jokingly making was that people don't understand what an extremely powerful tool they have been given and instead complain about shallow stuff that for them is simple to grasp edit: the way mg, bzr and the rest do the advanced stuff [when available] is basically a carbon copy of git.
  - laughinghan 10y ago
    > the way mg, bzr and the rest do the advanced stuff [when available] is basically a carbon copy of git. I'm a pretty big fan of git, but this is an unproductive stance. I don't know much about bzr, but my impression is that darcs pioneered the ideas that became git-rebase, and elsewhere in this thread people are having substantive discussions about hg (Mercurial; I assume that's what you meant by mg) bookmarks and branches vs git branches: https://news.ycombinator.com/item?id=13229582 https://news.ycombinator.com/item?id=13229582

nolemurs 10y ago

I see what you mean about the messy mental model, and I do 100% agree that in a well designed system most problems should have one obvious best solution. That said, I'm not sure that's a fair criticism of git. For instance, in this case, as mentioned below, the author of the article should have just reverted the commit where he checked out the files, then done a normal merge. If you're thinking of everything at the commit level, it's pretty much the obvious thing to do. The first obvious thought is to just backtrack (as mentioned in the article), then once you realize that's off the table (since the code is out in the wild) the very next obvious idea is to revert. Revert is what you do when you can't just undo. It's not even as if his commit involved any merges, so the revert is super easy. I guess I just don't agree that experts would have a hard time finding the simple solution - it was the first thought that popped into my head, and I read the article mostly looking for the explanation for why he didn't just do it. While git does provide near complete control, you almost never need to use more than the basics, and it doesn't have to be confusing. EDIT: Just to make very clear why I think the solution is obvious, the first thought that I think will occur to almost anyone is, "if I can just bring the master branch back to its prior state, then I can merge like usual". The beauty of git is if you can form a coherent idea like "bring the master branch back to its prior state" then you can probably do it, and it probably isn't hard. The mistake the author made was to have that thought, and then instead go off down a rabbit hole, and throw out the original simple idea.

jdmichal 10y ago
If you revert, how do you guarantee that the final result is identical to the previously deployed and tested version?
- cyberpunk 10y ago
  He'd need to revert like 400 commits! Woah that's a real messy one. I hope everyone walks away with a feeling that merging 400 commits in what sounds like a CD env is asking for trouble... I'm probably not going to earn extra ninja points here, but in that situation I'd have turned off the deploy jenkins job, force pushed master back to sanity, squashed these commits into a sensible amount in a new branch, rebased it from master and gotten someone (several someones) to go over the pull rq which should be able to merge without conflict. (Fix conflicts in branch!) Maybe you'll have to get your devs to make a new branch locally and cherry pick their stuff back in, but urgh; I think the solution in the article would have taken me ages to RTFM enough to work it out... The lesson here is merge less, more often, or pay more attention when doing evil things like this should you get into that kind of situ...

stephenboyd 10y ago

I think there's an opportunity for a simpler-to-use alternative CLI Git client. Something more user-friendly than the /usr/bin/git program we're talking about and more developer-friendly than the existing Git GUI apps.

VLM 10y ago
Another parallel idea to consider is procedure and policy. The cleanup after the foot-shot was pretty gory, but I'm not sure with disciplined git-flow that its possible to replicate that foot-shot, and if you can't shoot yourself in the foot then the goriness of the cleanup is a non-issue. A third level up is you've got two devs carefully not coordinating and working together on code that closely related to each other, aside from the git-splosion that is not generally a recipe for success. Like, refactor the obviously independent multiple concepts (obviously independent because non-cooperating devs are working separately in parallel on them) in those files into multiple files and then there aren't merges to fight.
Drdrdrq 10y ago
There is gitless [0][1], haven't used it though. [0] http://gitless.com/ http://gitless.com/ [1] https://news.ycombinator.com/item?id=12621837 https://news.ycombinator.com/item?id=12621837

justinlaster 10y ago

> The set of different options (normal merge, rebase, filter-branch, etc) is complex and not cleanly orthogonal All of those commands you just listed are clearly defined and serve different purposes. In other cases, most commands or command flags simply help the user do something in an automated fashion that you could do by typing each specific command out (i.e., git pull --rebase). Git's core tooling is mainly centered around graph manipulation, everything else has been added due to convenience. And quite frankly I've never really understood the criticism people levy at git for being "complicated." It's stupidly simple at the end of the day, especially compared to the hodgepodge of features that other VC's provide, all of which don't really work together and are designed to cover some gap in what should be handled in the core design of the VC (I'm looking at you, Mercurial branches and bookmarks). All tools require you to be familiar with them. There's no getting around that. > Even experienced experts would have difficulty finding the clear, simple way to solve this problem I'm not sure how you can possibly say that, the answer is pretty obvious to a lot of us reading this article. This just feels like baseless whining. There is a litany of literature out there that could have easily pointed the author to a well defined, accepted, and documented solution.

darkerside 10y ago
> most commands or command flags simply help the user do something in an automated fashion that you could do by typing each specific command out (i.e., git pull --rebase) A tangent perhaps, but would you mind expanding on this? I use `git pull --rebase` frequently, and I'm not sure how this fits into what you described. Is it the specific command, or the automated shortcut? And what's the counterpart? Just trying to check my mental model.
- mbrock 10y ago
  From the "git-pull" man page: > Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD. > More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With --rebase, it runs git rebase instead of git merge.

VLM 10y ago

Git is just getting in the way of the classic old philosophical discussion of there should only be one correct way to think vs a more multicultural the more ways there are to think and adapt and overcome, the better. The technical discussion of git innards and workflow just get in the way of the core philosophical discussion, and the innards would fall into place if the philosophical question were answered (as if philosophical questions are ever truly answered, LOL) A classic example of the philosophical argument is Perl vs Python. There's infinite ways to express yourself vs there is only one way that works. Now its very politically incorrect to say you like Perl in 2016 and I suspect Git is going to be in big trouble soon enough for the same philosophical reason. I would be interested in hearing what is the philosophical equivalent of Python for source code revision control. I mean... people can't be seriously suggesting going back to RCS/CVS/SVN/Hg, can they? Or I guess they can? Maybe some closed source silo I'm unfamiliar with? Maybe no revision control at all and go back to tgz files with dates embedded in the filename? A classic problem with limiting opportunity, limiting the range of thoughts and ideas, is finding a way to do it without impacting productivity or quality. In that way "use something simpler and enormously less capable" would be considered cheating the philosophical problem.

bad_user 10y ago
You're trying to find too much reasoning. Nowadays many people hate Python as well and I'm speaking as an ex-Python developer that now hates Python. And do you know what's ironic about Python? Because the language excluded certain features, it led to multiple non-orthogonal features that solve very specific use-cases and ways of doing things in its ecosystem, with hacks upon hacks meant to implement ideas from other ecosystems, most of them slightly broken. The problem with language simplicity is that it is misunderstood. Simplicity in the language implementation is often correlated with complexity for the developer, being what happens when you limit what can be expressed.
- VLM 10y ago
  WRT the reasoning I have a gut level feeling its not technically solvable so I'm going for an abstract proof that its equivalent to a known existing unsolvable philosophical debate, therefore any mention of technical problems or feature list of git is bike shedding because its provably unsolvable at a higher level. So if the answer to the philosophical question is two opposing camps, and we have the source code revision control solution for one pole, then all we need to do is find the opposite pole and then ask the two never to merge (oh the extended pun..) groups, to realize the other side exists and please be civil with each other, etc. That could save a lot of wasted effort. Clearly the equivalent of methodically twisting Python into Perl one little bit at a time isn't going to make anyone on any side happy, or vice versa.

SixSigma 10y ago

> I consider this to be a failure of Git. Surely it's a failure of source code as streams of text. If each function was versioned with dependencies then this problem would be eliminated. Replaced by other problems.

theptip 10y ago

This is close to theological discussion territory, and I can see both sides of the argument, so I'm just going to mention that there is an interesting paper[1] from a couple years ago that uses a rigorous concept design process to attempt to simplify Git, and results in a VCS that does indeed require a simpler mental model (Gitless). Personally I'm not going to abandon Git and all the tooling and community it comes with just for a simpler mental model, given that I have a moderately good handle on the (mainline) features of git -- and therein lies the problem. (Although note, Gitless does work on top of Git, so you should be able to use it with Github by the looks of things [2]). I've linked Adrian Colyer's summary of the paper to make it easier to digest: [1]: https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-conceptual-design-analysis/ https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-c... [2]: http://gitless.com/#vs http://gitless.com/#vs

ASalazarMX 10y ago

I'll just leave this here http://xkcd.com/1597/ http://xkcd.com/1597/

AstralStorm 10y ago
This could be written about any tool. Especially bad with Perforce and Subversion - which do not really support branching. They say they do, but then the merging is a huge pain.
deleted 10y ago
[deleted]

Sir_Cmpwn 10y ago

Remember that git was written by and written for kernel hackers. Most of the people I've found having trouble with git are as far from kernel hackers as you can get and most who don't are quite a bit closer. As a kernel hacker myself, I think Git's interface is superb and intuitive.

emmelaich 10y ago
I don't think Junio Hamano (aka gitster) has done much kernel work at all. But point taken.

wilde 10y ago

Luckily there are a bunch of tools that wrap the git primitives to present more friendly UIs. I spend most of my source control time in SourceTree at this point.

agentgt 10y ago

I have to say I am fan of both Mercurial and Git particularly because I'm a crusty old developer who came from some god awful VCS/SCM like PVCS, CVS, RCS, Source safe. I remember first using Perforce for the first time and thinking dear god it is expensive but totally worth it (this was before git). Really what I think needs improvement is better diff/merging interfaces. There really isn't platform independent one that is opensource and free. Right now I use p4merge because it works fairly well on macOS but I still think it sucks (it doesn't have keybindings and yeah I have tried vim and emacs diff ... they are ok but not as easy to visualize diffing).

voidr 10y ago

I would be interested to know that in your view, which VCS would have solved this problem better assuming they would have done the same thing. It seems to me that they chose the worst possible option each time they hit a problem.