8 ms·

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset sever

by jheriko 13y ago

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use, and actually i consider the things that git does differently to hg to be demonstrably and measurably counter-intuitive and in some cases dangerous. the biggest problem by far is that git is dangerous out of the box - it can destroy your work very easily or leave you in an unrecoverable state. why can't i roll back a merge in one step if i didn't configure things to be able to do that? why does my branch disappear when i merge? how do the jenkins guys break their repo so casually and find themselves struggling to recover it? i believe this is the robustness mentioned here: "The changeset graph is in some sense more "robust" in that it's just there and doesn't change on its own initiative" mercurial seems loathe to alter history - which is pretty sane and common sensical seeming to me, git does it as part of how it is 'supposed to be used' which frankly sounds as mad as travelling back in time to shoot your grandfather. for these reasons - to me - using git is asking for trouble (it has caused me trouble and i switched to hg for precisely this reason). i cant reasonably recommend git to anyone... which is a shame. other than that flaw it is really quite rich and powerful and has other advantages over mercurial - including (perhaps foremost) its enormous popularity. EDIT: watch as this gets downvoted from hipster gut responses instead of thought :D

Pxtl 13y ago
Agreed. Honestly, I see the appeal of maintaining a clean history, but shouldn't that be done in some non-destructive fashion? Do we need source-control on our source-control? Or at least simply flag squashed commits instead of destroying them?
- Mindless2112 13y ago
  > Do we need source-control on our source-control? That's more or less what Mercurial's changeset evolution [1] is/will be (it's not enabled by default yet). [1] http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution
- jlgreco 13y ago
  > I see the appeal of maintaining a clean history, but shouldn't that be done in some non-destructive fashion? Don't rebase code that is public (few people recommend that you do) and there is nothing destructive about it. When I rebase my changes before making them public, I am not destroying history, I am deciding history.
emn13 13y ago
Yeah, I get the impression that in most meaningful ways hg is a better choice on a technical level. But git does have a few real advantaves. Git is faster, though the difference is small enough that I can't imagine this being a serious issue. Git repo's are smaller, particular in the face of (directory) renames. But the real advantage of git is its popularity. You present that as something worrying; but at the end of the day, hg and git aren't all that different, and popularity means pervasiveness means collaboration is easier - and that's worth something.
- jheriko 13y ago
  you are correct. its popularity is an advantage, and this is precisely why i would want to use git - so many people are familiar with it and it almost seems like the standard solution today for source control. but its still worrying to me for its popularity. either i am fantastically stupid or people are happily using a tool without any idea what they are doing or how to resolve what i consider to be a very standard source control problem. these are both things for me to worry about. if you are wondering what i had such a hard time with here is a trivialised example: http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html even if this problem is solvable and there is a solution this is a perfectly good way to approach problem solving - the problem is the lack of quality documentation and source materials to research a solution from.
- mrtngslr 13y ago
  Very sensible comment :) Having gained the most mind-share is Git's best feature, along with it's flexible branches and speed. Those features are super important and as a Mercurial developer, I'm very impressed with them.
jxf 13y ago
> (...) the biggest problem by far is that git is dangerous out of the box - it can destroy your work very easily or leave you in an unrecoverable state. It's almost impossible to leave git in "an unrecoverable state", short of actually deleting your ".git" directory. If you do wind up in a bad spot, that's what the ref-log is for [0]. If you've made an error that is difficult or complicated to unwind, no sweat: hit the reflog and go back in time to the point where things were the way you wanted. git is many things -- frequently useful, often complicated, sometimes obtuse. But it's almost always safe. [0]: https://www.kernel.org/pub/software/scm/git/docs/git-reflog.html https://www.kernel.org/pub/software/scm/git/docs/git-reflog....
- jheriko 13y ago
  I will concede that it might be safe in this sense - unrecoverable is too strong a word. My real world experience of this is that twice I've seen people frantically trying to work out this same problem of reverting a change and finding it difficult even to get a copy of the repo that matches the desired state. Granted it works easily in the most common case, but I've never seen thus problem arise with cvs, svn, hg or p4... Its sensible to use simpler tools if they are more practical, ie I have to learn less to get what I want from those tools. This seems to be a general problem with git currently - many commands need lots of switches or background knowledge to become useful and its really not necessary IMO. It would be nice to see that improve...
- steveklabnik 13y ago
  > git reflog This, a thousand times this. Unless you happen to randomly run `git gc` for some odd reason, you have a few months (with default settings) until your repo is in an unrecoverable state, unless you touch the .git directory directly.
  - JoshTriplett 13y ago
    Even if you do run git gc, by default git will still keep the reflog and all objects reachable from it around for 30 days.
  - jheriko 13y ago
driverdan 13y ago
I'm guessing the reason you're getting downvoted is because it sounds like you don't know how to use git. That may not be true, it just sounds that way. > the biggest problem by far is that git is dangerous out of the box - it can destroy your work very easily or leave you in an unrecoverable state. Please explain. How is it dangerous? How can it leave you in an unrecoverable state? > why can't i roll back a merge in one step if i didn't configure things to be able to do that? Depending on how many commits the merge had it'd be something like git reset HEAD^^ --hard > why does my branch disappear when i merge? What do you mean? That the branch you merged into doesn't indicate which commits were done on the other branch? Branches don't disappear.
- rallison 13y ago
  I think this gets to one of the issues people who have previous source control experience have with git. They apply the concepts from, say, subversion to git, and then have trouble. Take branches for example. In subversion, branches were heavyweight, scary things. In git, they are extremely lightweight, in that they are really nothing more than a pointer to a specific commit. They almost shouldn't even share the same name, they are so different. Basically, I found that I got much better once I stopped trying to apply my old understanding of subversion to git, and especially once I just started playing around with git commands on a dummy repo, to fully understand what was going on. Now that I've done that, I would never switch back to subversion. Perforce, maybe, but only for certain very specific scenarios.
  - jlgreco 13y ago
    "Perforce, maybe, but only for certain very specific scenarios." These days you can get a lot done using git as your perforce client but.... ick.
  - matwood 13y ago
    They apply the concepts from, say, subversion to git, and then have trouble. I have found this to be true. I helped a lot of people at work switch from svn to git. As I showed people what to do the biggest problem was trying to make git fit in with what they knew from svn. Now I start every conversation with forget svn :)
lotyrin 13y ago
As far as danger goes, I've never got into a state I couldn't back out of using the reflog - though the user experience surrounding getting there and back could definitely use some polishing. As far as having mutable histories, from the standpoint of someone who has to review and integrate lots of branches from a large distributed team, its amounts to a necessary evil. It's difficult to review and merge anything more than a concise set of changes that achieve their end goal and it's also difficult to have committed such a changeset on the first try. Not having the team rebase out experimental and exploratory commits would be a huge mess and while it's an option to just wait to commit until you're done, that risks losing things, and leads to giant one-shot patches that can still be tricky to review and ship. I'm not sure what workflows hg users that loathe to alter history adopt where they don't suffer from trying to integrate messy branches.
- kasey_junk 13y ago
  "from the standpoint of someone who has to review and integrate lots of branches from a large distributed team" I think this is a very telling point. I found git infuriating and inconsistent to an irresponsible degree, until I realized it wasn't built for me as a producer of code. It was built for people who have to integrate lots of code from lots of disparate producers. Once that lightbulb clicked a lot of things started to make more sense. I still find git infuriating as part of my daily development workflow, but at least I get it now. I still have a hard time recommending it for small teams that are doing on the fly integration, but for the big distributed team model, I could see it being the best choice.
MAGZine 13y ago
Nobody is saying you have to squash, it's just recommended to tidy changehistory. For all of your projects, you can simply not squash, and ask contributors to do the same. It's not like git rewrites history automatically... Just because git will let you shoot yourself in the foot, doesn't mean that it's a tool that should be avoided.
- jheriko 13y ago
  Actually it does rewrite history by default AFAIK. This is how the merges work from the end user perspective. I've never had trouble reverting a merge in any other context.
- jheriko 13y ago
  thanks for the suggestion, i did recreate my problem so that i could present a properly reasoned argument rather than a ragey comment: http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html i'm pretty sure that i need to do this particular shooting myself in the foot to be able to do work unfortunately. i might be lacking knowledge, but it was far too difficult to acquire said knowledge. as someone who self taught himself programming in many languages,classically hard stuff like functional calculus, quantum field theory and general relativity - as much as that is a weak argument - i'm inclined to think there is insufficient information, or at least extremely poor documentation here.
- mrtngslr 13y ago
  Agreed... rewriting history is a powerful tool that power users will want to use. Nothing more. That of course applies to all tools :)
nbouscal 13y ago
If your comment gets downvoted, it's much more likely to be because it is simply inaccurate. Git is remarkably safe out of the box. Git makes it damn near impossible to lose anything other than intentionally. No matter if you rebase, reset --hard, or any other "destructive" operation, you can always get back to your prior state with nothing but a quick look in the reflog. Even if you start doing the really dangerous stuff like filter-branch, there again Git goes to pains to prevent you from losing data, by creating a refs/original folder to preserve your old refs (though you can also just use git fsck). Git goes above and beyond the call of duty when it comes to preventing data loss. Short of intentionally running the garbage collector with --prune=all right after rebasing, you won't lose data. As for the core concepts being the same, you're talking about usage whereas the person you quoted was talking about the actual implementation-level object model. Git's model is remarkably simple, and that simplicity is the source of many of its benefits. Every other VCS out there is more complex.
- jlgreco 13y ago
  To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard. Of course --hard is not on by default so... there is no issue here with git's default behaviour. > "Git's model is remarkably simple, and that simplicity is the source of many of its benefits. Every other VCS out there is more complex." Yup, exactly. The simplicity of git's model is hugely important. It allows me to not only know what git will or will not allow me to do (knowledge that in other systems is acquired by studying the docs for each particular command to see what all the flags do) but also lets me figure out what sort of novel operations are possible if I am willing to write a little code of my own. Example: Update hook that only allows a push if two or more colleagues of the committer have pushed annotations for that commit already? With little more than my knowledge of git's data model, and what update hooks are in the first place, I know that can be done and I know how I could do it.
  - tednaleid 13y ago
    That's not correct, you can get back to any ref in the reflog, including those that you moved away from with git-reset --hard. Those commits are just dangling but are easy to get back to. I've got a presentation [1] that goes into how to use the reflog and how the various flags in reset work (among other things) that could explain more. [1]: http://tednaleid.github.io/showoff-git-core-concepts/ http://tednaleid.github.io/showoff-git-core-concepts/
andrevan 13y ago
You'll note that the Jenkins guys were able to recover all their work. They also use a non-standard branching and access model.
- jordigh 13y ago
  Did they? Last I heard, they were having trouble with a few repos, because the hashes they got from github weren't quite right.
- jheriko 13y ago
  yeah, but did you read about what they were doing? granted the breaker of it all did something he shouldn't have... but its still terrifying to hear of these things.
sampo 13y ago
> git is dangerous out of the box - it can destroy your work very easily I really wonder what do you mean by that? Yes, it's relatively easy to checkout some older commit and end up in a headless state, where an ordinary `git log` command won't show your more recent commits. And then panic and think that git has destroyed your work. But all your commits are still there. You need some more involved way (like the reflog) to get back to them, but git has not destroyed them. After 30 days or so, git may run garbage collection and remove dangling commits, thus really destroying your work then. But your words "can destroy your work very easily" are a bit strong if this is what you mean?
- jheriko 13y ago
  I chose words that were too strong. The core of my problem is the amount of learning and configuration required to revert a merge. Its too much. The poor choice of defaults and requirement that I fiddle with implementation details shakes my confidence in the whole of git. I'm sure its aslwasys eventually recoverable but that's far away from practical to me vs just using mercurial which I find easy to use and has sensible defaults
jammycakes 13y ago
I'd just like to respond to all the people who are saying "Use the reflog" here. Yes, you can recover lost commits using the reflog. But it is not well publicised that you can do this. Most tutorials do not mention it and most Git GUIs do not expose it. It is also not functionality that you expect to exist, so you are not likely to think to Google it. Unless you are an advanced Git user, your commits are indeed, to all intents and purposes, lost.
- jeltz 13y ago
  Good point, the reflog should be mentioned earlier in tutorials.
  - jheriko 13y ago
    i don't think thats a fix at all. i still think it should be possible to revert a merge with a single command and no flags. the volume of questions about this on stack overflow and co. and the variety of answers, some of which i'm sure i tried and found not suitable, suggests that this is a real user experience problem. alternatively their should be a decent ui solution to hide this stuff and it should be packaged with git in some friendly installer somewhere (not SourceTree which although the best of the bunch I've tried, was of no help to me when i had this problem and has a huge stack of usability problems vs. e.g. p4v which frankly everyone should rip off because i'm sure its why perforce is still even a thing aside from support contracts...)
    - jeltz 13y ago
      You do not use the reflog to revert a merge. You do it to undo a messed up rebase, and I am not sure if that is something which you want to fix automatically. I think using the reflog here might be better, maybe with a shortcut to make it easier to reset to a point in it.
- steveklabnik 13y ago
  Doesn't the large number of people saying "use the reflog" indicate that amongst git users, they know that it exists?
encoderer 13y ago
False. If you ever thought you lost work in Git, it's POSSIBLY because you overwrote your working copy. That is, code that hasn't been committed yet. But once you commit -- hell, once you just "git add" to the index -- your work is safe and won't be garbage collected off the disk for at least 30-45 days.
- jheriko 13y ago
  My choice of worded is quite poor. I know the problem I had was recoverable but the amount of learning involved and bad defaults standing my way put me off git. I get the same functionality from mercurial with a fraction of the effort
qznc 13y ago
Repeating my description: Git internally is just snapshots of the code connected with prev-version edges forming a directed acyclic graph and then some named pointers into this DAG. This is the simplicity of git. I do not use or know Mercurial, but from the article Mercurial seems to have multiple types of branches and commits. This makes it more complex.
- jheriko 13y ago
  everything is a changeset, and yes there are multiple types but for the end user they have no need to know about them - from there perspective everything is a changeset and they are all operated on equally. from the end user perspective git does have multiple types of change - and this was precisely my problem. i recreated the problem and documented it here: http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html to be fair, i completely took that quote that I used about simplicity out of context because I've heard similar said in a different context more than once and I jumped to a conclusion.
Mithaldu 13y ago
> "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " > > I find it hard to understand what this means The git model can be, to a sufficient degree of completeness, be demonstrated with child toys: http://www.youtube.com/watch?v=1ffBJ4sVUb4 http://www.youtube.com/watch?v=1ffBJ4sVUb4 I can't even imagine how a similar demonstration would look like with Mercurial. It would probably involve having a bunch of such trees on the table, and super-glue instead of sticking things together.
- mrtngslr 13y ago
  Please see this figure: http://www.aosabook.org/en/mercurial.html#fig.hg.revlog http://www.aosabook.org/en/mercurial.html#fig.hg.revlog I hope you see the similarities between the storage layers of Mercurial and of Git: Mercurial has a changeset graph with pointers into a manifest graph. The nodes in the manifest graph points to the files presents in that commit. It's (also) not very complicated. As for branches, they're very simple too, as I tried to explain here: https://news.ycombinator.com/item?id=6753477 https://news.ycombinator.com/item?id=6753477
jheriko 13y ago
as a note this seems to have +36 points, i assumed it was negative because my reputation seems to have taken a dive by roughly that same value. just noticed in my history that negatives are marked with a '-' and get greyed out. how strange... or perhaps i am again just being stupid.

by jheriko 13y ago

Pxtl 13y ago

Agreed. Honestly, I see the appeal of maintaining a clean history, but shouldn't that be done in some non-destructive fashion? Do we need source-control on our source-control? Or at least simply flag squashed commits instead of destroying them?

Mindless2112 13y ago
> Do we need source-control on our source-control? That's more or less what Mercurial's changeset evolution [1] is/will be (it's not enabled by default yet). [1] http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution
jlgreco 13y ago
> I see the appeal of maintaining a clean history, but shouldn't that be done in some non-destructive fashion? Don't rebase code that is public (few people recommend that you do) and there is nothing destructive about it. When I rebase my changes before making them public, I am not destroying history, I am deciding history.

emn13 13y ago

Yeah, I get the impression that in most meaningful ways hg is a better choice on a technical level. But git does have a few real advantaves. Git is faster, though the difference is small enough that I can't imagine this being a serious issue. Git repo's are smaller, particular in the face of (directory) renames. But the real advantage of git is its popularity. You present that as something worrying; but at the end of the day, hg and git aren't all that different, and popularity means pervasiveness means collaboration is easier - and that's worth something.

jheriko 13y ago
you are correct. its popularity is an advantage, and this is precisely why i would want to use git - so many people are familiar with it and it almost seems like the standard solution today for source control. but its still worrying to me for its popularity. either i am fantastically stupid or people are happily using a tool without any idea what they are doing or how to resolve what i consider to be a very standard source control problem. these are both things for me to worry about. if you are wondering what i had such a hard time with here is a trivialised example: http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html even if this problem is solvable and there is a solution this is a perfectly good way to approach problem solving - the problem is the lack of quality documentation and source materials to research a solution from.
mrtngslr 13y ago
Very sensible comment :) Having gained the most mind-share is Git's best feature, along with it's flexible branches and speed. Those features are super important and as a Mercurial developer, I'm very impressed with them.

jxf 13y ago

> (...) the biggest problem by far is that git is dangerous out of the box - it can destroy your work very easily or leave you in an unrecoverable state. It's almost impossible to leave git in "an unrecoverable state", short of actually deleting your ".git" directory. If you do wind up in a bad spot, that's what the ref-log is for [0]. If you've made an error that is difficult or complicated to unwind, no sweat: hit the reflog and go back in time to the point where things were the way you wanted. git is many things -- frequently useful, often complicated, sometimes obtuse. But it's almost always safe. [0]: https://www.kernel.org/pub/software/scm/git/docs/git-reflog.html https://www.kernel.org/pub/software/scm/git/docs/git-reflog....

jheriko 13y ago
I will concede that it might be safe in this sense - unrecoverable is too strong a word. My real world experience of this is that twice I've seen people frantically trying to work out this same problem of reverting a change and finding it difficult even to get a copy of the repo that matches the desired state. Granted it works easily in the most common case, but I've never seen thus problem arise with cvs, svn, hg or p4... Its sensible to use simpler tools if they are more practical, ie I have to learn less to get what I want from those tools. This seems to be a general problem with git currently - many commands need lots of switches or background knowledge to become useful and its really not necessary IMO. It would be nice to see that improve...
steveklabnik 13y ago
> git reflog This, a thousand times this. Unless you happen to randomly run `git gc` for some odd reason, you have a few months (with default settings) until your repo is in an unrecoverable state, unless you touch the .git directory directly.
- JoshTriplett 13y ago
  Even if you do run git gc, by default git will still keep the reflog and all objects reachable from it around for 30 days.
- jheriko 13y ago

driverdan 13y ago

I'm guessing the reason you're getting downvoted is because it sounds like you don't know how to use git. That may not be true, it just sounds that way. > the biggest problem by far is that git is dangerous out of the box - it can destroy your work very easily or leave you in an unrecoverable state. Please explain. How is it dangerous? How can it leave you in an unrecoverable state? > why can't i roll back a merge in one step if i didn't configure things to be able to do that? Depending on how many commits the merge had it'd be something like git reset HEAD^^ --hard > why does my branch disappear when i merge? What do you mean? That the branch you merged into doesn't indicate which commits were done on the other branch? Branches don't disappear.

rallison 13y ago
I think this gets to one of the issues people who have previous source control experience have with git. They apply the concepts from, say, subversion to git, and then have trouble. Take branches for example. In subversion, branches were heavyweight, scary things. In git, they are extremely lightweight, in that they are really nothing more than a pointer to a specific commit. They almost shouldn't even share the same name, they are so different. Basically, I found that I got much better once I stopped trying to apply my old understanding of subversion to git, and especially once I just started playing around with git commands on a dummy repo, to fully understand what was going on. Now that I've done that, I would never switch back to subversion. Perforce, maybe, but only for certain very specific scenarios.
- jlgreco 13y ago
  "Perforce, maybe, but only for certain very specific scenarios." These days you can get a lot done using git as your perforce client but.... ick.
- matwood 13y ago
  They apply the concepts from, say, subversion to git, and then have trouble. I have found this to be true. I helped a lot of people at work switch from svn to git. As I showed people what to do the biggest problem was trying to make git fit in with what they knew from svn. Now I start every conversation with forget svn :)

lotyrin 13y ago

As far as danger goes, I've never got into a state I couldn't back out of using the reflog - though the user experience surrounding getting there and back could definitely use some polishing. As far as having mutable histories, from the standpoint of someone who has to review and integrate lots of branches from a large distributed team, its amounts to a necessary evil. It's difficult to review and merge anything more than a concise set of changes that achieve their end goal and it's also difficult to have committed such a changeset on the first try. Not having the team rebase out experimental and exploratory commits would be a huge mess and while it's an option to just wait to commit until you're done, that risks losing things, and leads to giant one-shot patches that can still be tricky to review and ship. I'm not sure what workflows hg users that loathe to alter history adopt where they don't suffer from trying to integrate messy branches.

kasey_junk 13y ago
"from the standpoint of someone who has to review and integrate lots of branches from a large distributed team" I think this is a very telling point. I found git infuriating and inconsistent to an irresponsible degree, until I realized it wasn't built for me as a producer of code. It was built for people who have to integrate lots of code from lots of disparate producers. Once that lightbulb clicked a lot of things started to make more sense. I still find git infuriating as part of my daily development workflow, but at least I get it now. I still have a hard time recommending it for small teams that are doing on the fly integration, but for the big distributed team model, I could see it being the best choice.

MAGZine 13y ago

Nobody is saying you have to squash, it's just recommended to tidy changehistory. For all of your projects, you can simply not squash, and ask contributors to do the same. It's not like git rewrites history automatically... Just because git will let you shoot yourself in the foot, doesn't mean that it's a tool that should be avoided.

jheriko 13y ago
Actually it does rewrite history by default AFAIK. This is how the merges work from the end user perspective. I've never had trouble reverting a merge in any other context.
jheriko 13y ago
thanks for the suggestion, i did recreate my problem so that i could present a properly reasoned argument rather than a ragey comment: http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html i'm pretty sure that i need to do this particular shooting myself in the foot to be able to do work unfortunately. i might be lacking knowledge, but it was far too difficult to acquire said knowledge. as someone who self taught himself programming in many languages,classically hard stuff like functional calculus, quantum field theory and general relativity - as much as that is a weak argument - i'm inclined to think there is insufficient information, or at least extremely poor documentation here.
mrtngslr 13y ago
Agreed... rewriting history is a powerful tool that power users will want to use. Nothing more. That of course applies to all tools :)

nbouscal 13y ago

If your comment gets downvoted, it's much more likely to be because it is simply inaccurate. Git is remarkably safe out of the box. Git makes it damn near impossible to lose anything other than intentionally. No matter if you rebase, reset --hard, or any other "destructive" operation, you can always get back to your prior state with nothing but a quick look in the reflog. Even if you start doing the really dangerous stuff like filter-branch, there again Git goes to pains to prevent you from losing data, by creating a refs/original folder to preserve your old refs (though you can also just use git fsck). Git goes above and beyond the call of duty when it comes to preventing data loss. Short of intentionally running the garbage collector with --prune=all right after rebasing, you won't lose data. As for the core concepts being the same, you're talking about usage whereas the person you quoted was talking about the actual implementation-level object model. Git's model is remarkably simple, and that simplicity is the source of many of its benefits. Every other VCS out there is more complex.

jlgreco 13y ago
To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard. Of course --hard is not on by default so... there is no issue here with git's default behaviour. > "Git's model is remarkably simple, and that simplicity is the source of many of its benefits. Every other VCS out there is more complex." Yup, exactly. The simplicity of git's model is hugely important. It allows me to not only know what git will or will not allow me to do (knowledge that in other systems is acquired by studying the docs for each particular command to see what all the flags do) but also lets me figure out what sort of novel operations are possible if I am willing to write a little code of my own. Example: Update hook that only allows a push if two or more colleagues of the committer have pushed annotations for that commit already? With little more than my knowledge of git's data model, and what update hooks are in the first place, I know that can be done and I know how I could do it.
- tednaleid 13y ago
  That's not correct, you can get back to any ref in the reflog, including those that you moved away from with git-reset --hard. Those commits are just dangling but are easy to get back to. I've got a presentation [1] that goes into how to use the reflog and how the various flags in reset work (among other things) that could explain more. [1]: http://tednaleid.github.io/showoff-git-core-concepts/ http://tednaleid.github.io/showoff-git-core-concepts/

andrevan 13y ago

You'll note that the Jenkins guys were able to recover all their work. They also use a non-standard branching and access model.

jordigh 13y ago
Did they? Last I heard, they were having trouble with a few repos, because the hashes they got from github weren't quite right.
jheriko 13y ago
yeah, but did you read about what they were doing? granted the breaker of it all did something he shouldn't have... but its still terrifying to hear of these things.

sampo 13y ago

> git is dangerous out of the box - it can destroy your work very easily I really wonder what do you mean by that? Yes, it's relatively easy to checkout some older commit and end up in a headless state, where an ordinary `git log` command won't show your more recent commits. And then panic and think that git has destroyed your work. But all your commits are still there. You need some more involved way (like the reflog) to get back to them, but git has not destroyed them. After 30 days or so, git may run garbage collection and remove dangling commits, thus really destroying your work then. But your words "can destroy your work very easily" are a bit strong if this is what you mean?

jheriko 13y ago
I chose words that were too strong. The core of my problem is the amount of learning and configuration required to revert a merge. Its too much. The poor choice of defaults and requirement that I fiddle with implementation details shakes my confidence in the whole of git. I'm sure its aslwasys eventually recoverable but that's far away from practical to me vs just using mercurial which I find easy to use and has sensible defaults

jammycakes 13y ago

I'd just like to respond to all the people who are saying "Use the reflog" here. Yes, you can recover lost commits using the reflog. But it is not well publicised that you can do this. Most tutorials do not mention it and most Git GUIs do not expose it. It is also not functionality that you expect to exist, so you are not likely to think to Google it. Unless you are an advanced Git user, your commits are indeed, to all intents and purposes, lost.

jeltz 13y ago
Good point, the reflog should be mentioned earlier in tutorials.
- jheriko 13y ago
  i don't think thats a fix at all. i still think it should be possible to revert a merge with a single command and no flags. the volume of questions about this on stack overflow and co. and the variety of answers, some of which i'm sure i tried and found not suitable, suggests that this is a real user experience problem. alternatively their should be a decent ui solution to hide this stuff and it should be packaged with git in some friendly installer somewhere (not SourceTree which although the best of the bunch I've tried, was of no help to me when i had this problem and has a huge stack of usability problems vs. e.g. p4v which frankly everyone should rip off because i'm sure its why perforce is still even a thing aside from support contracts...)
  - jeltz 13y ago
    You do not use the reflog to revert a merge. You do it to undo a messed up rebase, and I am not sure if that is something which you want to fix automatically. I think using the reflog here might be better, maybe with a shortcut to make it easier to reset to a point in it.
steveklabnik 13y ago
Doesn't the large number of people saying "use the reflog" indicate that amongst git users, they know that it exists?

encoderer 13y ago

False. If you ever thought you lost work in Git, it's POSSIBLY because you overwrote your working copy. That is, code that hasn't been committed yet. But once you commit -- hell, once you just "git add" to the index -- your work is safe and won't be garbage collected off the disk for at least 30-45 days.

jheriko 13y ago
My choice of worded is quite poor. I know the problem I had was recoverable but the amount of learning involved and bad defaults standing my way put me off git. I get the same functionality from mercurial with a fraction of the effort

qznc 13y ago

Repeating my description: Git internally is just snapshots of the code connected with prev-version edges forming a directed acyclic graph and then some named pointers into this DAG. This is the simplicity of git. I do not use or know Mercurial, but from the article Mercurial seems to have multiple types of branches and commits. This makes it more complex.

jheriko 13y ago
everything is a changeset, and yes there are multiple types but for the end user they have no need to know about them - from there perspective everything is a changeset and they are all operated on equally. from the end user perspective git does have multiple types of change - and this was precisely my problem. i recreated the problem and documented it here: http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html to be fair, i completely took that quote that I used about simplicity out of context because I've heard similar said in a different context more than once and I jumped to a conclusion.

Mithaldu 13y ago

> "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " > > I find it hard to understand what this means The git model can be, to a sufficient degree of completeness, be demonstrated with child toys: http://www.youtube.com/watch?v=1ffBJ4sVUb4 http://www.youtube.com/watch?v=1ffBJ4sVUb4 I can't even imagine how a similar demonstration would look like with Mercurial. It would probably involve having a bunch of such trees on the table, and super-glue instead of sticking things together.

mrtngslr 13y ago
Please see this figure: http://www.aosabook.org/en/mercurial.html#fig.hg.revlog http://www.aosabook.org/en/mercurial.html#fig.hg.revlog I hope you see the similarities between the storage layers of Mercurial and of Git: Mercurial has a changeset graph with pointers into a manifest graph. The nodes in the manifest graph points to the files presents in that commit. It's (also) not very complicated. As for branches, they're very simple too, as I tried to explain here: https://news.ycombinator.com/item?id=6753477 https://news.ycombinator.com/item?id=6753477

jheriko 13y ago

as a note this seems to have +36 points, i assumed it was negative because my reputation seems to have taken a dive by roughly that same value. just noticed in my history that negatives are marked with a '-' and get greyed out. how strange... or perhaps i am again just being stupid.