Hacker News Reader

Comment by jheriko | Hacker News Reader

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

View on HN

> (...) 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....

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...

> 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.

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.

a few people have suggested this. disappointed that my initial google searches did not reveal this to me...

I appreciate the effort you have made in trying to educate me here - reflog does look like it might have helped to solve my problem although it is extremely non-obvious even after running it. (i.e. i know i need to google or read something else rather than how to solve the problem).

I have recreated the problem I originally had and documented precisely why it really is a usability problem. Now that I have done this I am pretty sure that my anti-git sentiment is warranted - even if my initial comment was massively too harsh.

http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html

I agree that git can be characterized as having some usability issues; I initially found the documentation obtuse in many places.

My favorite git joke, by far: "git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space."

If you're having trouble understanding git but you find yourself comfortable with basic CS terms, you might want to check out Git for Computer Scientists [0]. This really helped put it in perspective for me.

[0] http://eagain.net/articles/git-for-computer-scientists/

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.

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.

I'd recommend learning "git reset --keep" instead of --hard because of this reason.

Certainly. --hard should only be used if you actually want what --hard provides.

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/

My point is that git-reset --hard can remove data from the working tree filesystem that never hit the DAG in the first place:

  $ git init                                          
  Initialized empty Git repository in /home/john/tmp2/.git/                    
  $ echo "foo" > foo                                  
  $ git add foo                                       
  $ git commit -m 'init'                              
  [master (root-commit) 84fb5d1] init                                          
  ...                                                                          
  $ echo "bar" >>foo                                  
  $ cat foo                                           
  foo                                                                          
  bar                                                                          
  $ git reset --hard HEAD                             
  HEAD is now at 84fb5d1 init                                                  
  $ git reflog                                        
  84fb5d1 HEAD@{0}: commit (initial): init                                     
  $ git status                                        
  # On branch master                                                           
  nothing to commit (working directory clean)

Ok, yes, I agree with that clarification (and I missed that you specified in your original comment "uncommitted work", my mistake).

If you git reset --hard and you have a dirty working directory, you can absolutely blow work away. That's one of the main reasons to use git reset --hard, but I agree that it needs to be used with intention.

The easiest way to protect against it is to never use it if you have a dirty working directory, always commit first and then reset --hard after you've committed.

I guess maybe the counterargument is that perhaps this should happen invisibly and automatically.

You just ran a script that scattered production / sensitive information in your source files. You definitely don't want to get that into history and get the last head state back.. Yes, you can delete the working tree and check out head again, but than again, git reset --hard pretty much does that and it's welcome at times.

Well, there is to my knowledge no other vcs that does this. Mercurial will hapily blow your changes away if you do a hg update -C. If you want your changes to stick around, you do a git stash first.

This is true, but seems specious. By this definition (development tools that can irrecoverably destroy data in the working directory) you should be flaming against vim too, not to mention rm or the dreaded "clean" target to make.

It just seems silly, sorry. And while I know little about hg I suspect it's not even true: hg will never delete a file it doesn't understand? What about the equivalent of git clean (which I use daily -- it's loss would be a minor hardship and definitely not an advantage for mercurial)?

https://news.ycombinator.com/item?id=6752077

Understand that I am very pro-git. I'm just trying to be precise here.

i was too strong with 'unrecoverable'

'unrecoverable in acceptable timescale with acceptable resource' would be accurate.

specifically i found it difficult to undo a merge and found that i was in a team where people had decided to use tools they didn't know enough about to have been using at all.

I'd be surprised if mercurial didn't have a similar “feature”.

git reset --hard at least has the benefit of sounding like it's going to do something scary. "git checkout ." will also completely nuke your working directory without warning, and looks benign enough that you would never expect that problem.

Which really, at the end of the day, is the real problem with git. It's not that it's inherently more dangerous, it's that the CLI is so inconsistent it can be hard to remember what you're doing, what's safe and unsafe, etc. Sometimes you need to pass "--force" for dangerous stuff, sometimes you capitalize the argument (like force deleting a branch). Sometimes "--hard" indicates that you should do the dangerous version of something. Sometimes there's not even a safety switch.

> To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard.

Every version control system has a way to overwrite a dirty (modified) work directory, so git is hardly any more dangerous than any other tool.

It also won't help you get back uncommitted files that you destroy with `rm`. No other tool does, either.

To be clear, I think that the behaviour of git-reset --hard is absolutely appropriate. I am just correcting the overly strong statement: "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."

There are situations that reflog won't get you back from, but those situations are perfectly logical and appropriate exceptions.

You can actually get back files that you rm. I've seen it done. Apparently it has something to do with unmounting the drive, restarting in single-user mode, then finding/knowing where it is on the drive before the OS overwrites it (hence the unmount).

Doesn't generally work with modern FS's that use more "clever" allocation schemes.

Yeah there's not a lot of tooling for it. I recall writing my own to analyse a disk image to find traces of an intrusion, so its possible if you put in the leg work even for modern complex FS that do stuff like store small files inline in inodes.

I'm not sure what you mean. The 'clever' filesystems I'm aware of are copy-on-write, which makes it much easier to recover deleted files. Unclever filesystems, like NTFS, are also quite easy to recover files on. I've had to do so multiple times.

> No other tool does, either.

Darcs does: if you "darcs revert" to erase your local unrecorded changes you can actually "darcs unrevert" and get them back later. I guess it's a little like "git stash" but not quite, as you can only have 1 saved state and many darcs operations will nuke the unrevert save (loudly and with prompts, so it won't catch you off guard).

You're completely right, I should have clarified that I was only talking about committed data. My mistake.

Your definition of safe is not mine. I have no doubt the data is preserved - 'unrecoverable state' is too strong.

Its not safe in the sense that if i make a change on submission day and need to revert it then its more complicated than it needs to be. Granted I should not be using something I don't have sufficient mastery of in that kind of scenario, but its not always so simple.

My data being 'safe' is worthless if there is a steep learning curve to recovering it.

The learning curve is not that steep. Compare it to learning vim or emacs, for example, and it's no contest. The learning curve is basically: 1) read Pro Git, 2) play with git for a little while. That's about it. If you can't afford that learning curve for something that is a core part of your workflow, you're doing something wrong.

I appreciate the effort you have made in trying to educate me here.

I have recreated the problem I originally had and documented precisely why I think it really is a usability problem. Now that I have done this I am pretty sure that my anti-git sentiment is warranted - even if my initial comment was massively too harsh.

http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html

It looks like your troubles came purely from not understanding the concept of fast-forward merges. I completely agree with you that the documentation does not make this as clear as it ought to. However, the standard book on git (Pro Git, available free online) covers this (and most other git concepts) very well. This is simply a case of not understanding your tools (which you did acknowledge in the post). This is a widespread and deeply problematic situation, not just for version control systems but for almost all software, and it seems to only be getting worse. Takeaway lesson isn't that there's anything wrong with git, but rather that there's something wrong with an industry that seems to think we should be able to use tools without first learning how they work.

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.

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.

"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.

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 :)

The specific experience I have is being able to revert a merge painlessly with a single operation out of the box. This was unreasonably challenging with git. AFAIK there is no command for this out of the box and my research led me to believe I could only fix it for future commits by making other changes. That's not acceptable and utterly destroyed my confidence in every other feature. Why in as source control solution would you ever implement a feature which makes changes unrevertable by default? Its also a great example of the implementation impacts ng the user when it shouldn't - the only reason I need to know anything beyond what command to use here is poor design.

My problem is not from applying svn logic to git... Its from not knowing it well enough and expecting convenient defaults out of the box. Just using Mercurial solves this for me.

Oh, reverting merges! I've been there, and it is completely possible, out of the box, with git. But! It requires a relatively thorough understanding of how it works, or you will definitely mess it up. I wrote up this summary a while back for our company wiki:

Imagine this scenario:

- Team Sandy does a ton of work on branch foo.

- Team Sandy ensures the release manager that branch foo is perfect and bug free.

- Team Sandy merges branch foo into branch develop and pushes.

- Other developers continue committing to develop.

- Massive devastation and destruction start occurring due to massive bugs scattered throughout Sandy's code.

At this point, we want to get all of Sandy's code out of develop, as we can't post to production until develop is Sandy-free. What do we do?

- Revert the merge commit

The important thing to note here is that this basically undoes the effect of the merge, but NOT the history. If you were to try to merge branch foo back in at a later date, git would do nothing and tell you that everything is already merged in. This is technically correct, but confusing.

Let's imagine that Sandy goes back to branch foo and commits bug fixes to fix the devastation. Now, branch foo is ready to be merged back in. What do we do?

- Revert the revert commit (yes, really). This basically undoes the effect of our original undo. At this moment, develop has all of branch foo's code pre-bug fixes.

- Merge foo into develop. This merges the subsequent bug fix commits into develop.

A much more thorough discussion can be enjoyed here (I highly recommend the read): https://www.kernel.org/pub/software/scm/git/docs/howto/rever...

Basically, it can be done with one line on the commandline, but I wouldn't recommend anyone do it unless they've read the above (specifically, the discussion I've linked to).

'- Revert the merge commit' this is what i had problems with. i got an error message back from git that you can't revert a branch commit and when i googled it the conclusion i came to was i needed to go back in time and change our configuration to make this possible. its entirely possible that i ended up down the wrong path from google searching.

now, googling around i find some stack overflow answers and such i'm pretty sure i found at the time i had the issue. when i am next there (at work) i'll see if i can find a copy of that repo or recreate the same problem so that i can show what happened and why it is difficult to solve and dangerous in a production environment. actually... i might just try and repro it now, but my connection is so poor here (at home) that even installing git is likely to be painful.

however, ignoring that, the process you describe is horribly counter intuitive. well done for working it out in the first place, although i do see this suggested in a few of the stack overflow answers... :)

It's possible that when you were doing this things were different, because even in the last year or so it seems like git has become a lot less esoteric in its interface, but the man page for git revert currently explains a fair bit about how to use it to revert a merge commit. Basically you just need to specify which parent (of the merge commit's 2 parents) is the one that should survive the reversion with '--mainline'. This seems intuitive to me, with a maybe deeper than average understanding of git, though the rather more involved process of undoing the reversion is less so.

yeah, i feel like this is almost certainly the case. that man page was absolutely my first stop when i got the error message and looking at it now i can't imagine how distracted and stupid i must have been to have missed all of that information. its a weak argument, but i have never struggled to learn anything when provided sufficient information. usually much less than that is enough...

I completely agree that reverting a merge in git is painful (painful, that is, in figuring out the parameters to pass to git revert).

Let's say this is your scenario:

  d         Merge branch 'test'
  |\
  | c-test  Test Branch Commit 1
  b |       Master Commit 2
   \|
    a       Master Commit 1

And let's say you want to revert d, the merge commit. You would do this:

  git revert -m 1 HEAD

Now your history looks like this:

  e-master  Revert "Merge branch 'test'"
  |
  d         Merge branch 'test'
  |\
  | c-test  Test Branch Commit 1
  b |       Master Commit 2
   \|
    a       Master Commit 1

-m, or --mainline is the key here. Git needs to know which parent is the appropriate one to revert to.

As the d-b-a line is the leftmost one, its parent number is 1.

Let's say that, instead, for some reason you actually wanted to rely on the d-c-a line as the basis for the commit, effectively throwing away the changes presented in commit b. You would do:

  git revert -m 2 HEAD

That said, you almost always want -m 1. And that said, this is how I understand merge reverts to work, but I've only had to do this a few times, so take that with a grain of salt.

With all that said, I completely agree with you about the frustration in trying to figure it out, even with SO. This is exactly where some nice porcelain sitting on top of git could make things much simpler.

I appreciate the effort you have made in trying to educate me here.

http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html

Ah, and this is why I shun fast forward merges. You were using fast forward merges (and, honestly, I absolutely cannot blame you for doing so). A very, very simple graphic explaining the difference can be seen here:

http://stackoverflow.com/a/2850413/1397661

The fast forward merge loses any concept of where the branch was branched from and when it was merged back in. Many in the community find the fast forward version cleaner. Sure, it is cleaner, until you need to revert that merge.

After using git professionally for quite a while, my opinion is that one should almost always use --no-ff for merging (unless one really knows better). Sure, the history is a bit more complicated to view. But, if you want to easily revert that one merge, everything becomes much, much simpler. It adds a little complexity for the common case while significantly reducing the complexity for a number of slightly less common cases.

That said, this ties back into the learning curve of git. How were you to know that you should do non-fast-forward merges so as to make merge reverts easier? Git has probably the steepest learning curve of any current version control system. It takes time to figure out the proper workflow for a company, and I've seen many rather intelligent people fail at git.

By the way, you brought up valid points and questions, and I enjoyed this discussion.

This is precisely true. I don't know how to use git. That's a big part of the problem I have with it, I get much more bang for my buck in terms of time spent working things out if I don't use git.

I don't know how to operate a airplane, but that isn't a problem I have with airplanes. That is a problem I have with myself.

this is a terrible analogy, its more like 'i can't drive this car if i don't do an engine rebuild myself - maybe i'll drive this car that already works the way i want'

tbh, i started a place they used git, i started learning it but nobody already there knew a damned thing about it and they should have been using it at all. they used it because it was more popular, despite having history with mercurial. we now use mercurial.

no need to be condescending. i did just point out not knowing it was precisely my problem

Engine rebuild of git? You mean "learn how to use it". If you want to go with a car analogy, then it is more like you are going to keep on driving one car because you don't know how to drive the other.

Git isn't broken just because you don't know how to use it.

yes, but i also i mean configuring it. its not just that i don't know how to drive the other car, but to make it drive in a way which allows me to reach my destination i need to make changes to its configuration - rebuild the engine might be harsh, so lets say adjust the timing belt instead... or change my tires or something. analogies suck.

learning curve is important for tools. the biggest problem was that (before i was even there) someone decided to use a tool they didn't understand instead of a tool that they did. learning git as i went along turned out to be a dangerous path compared to learning svn, p4 or hg as i went along - especially in an environment where everyone else was learning as they went along.

i regret my initial harsh wording because it really isn't broken and in many respects its a fantastic tool, its just poorly designed - and this is very obvious if you look at any of the help pages - there are very few commands which perform common tasks without excessive options. i don't want to configure my tools that much when i don't need to (i.e. when other tools don't need that and provide the functionality i care about). implementation details shouldn't pollute my user experience.

so, how do you revert a branch commit? every answer i've seen required considerably more knowledge and effort than any other source control solution i've used.

Now that I have recreated my original scenario I am now firmly of the belief that the interface to the user, documentation and available reference are inadequate.

http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html

Hopefully I can claw back some of the respect that I have clearly lost from you. Or at least discourage you from being so offensively defensive about this. :)

> Git isn't broken just because you don't know how to use it.

That is a lame cop-out. Git has a terrible, terrible user interface. Its documentation is equally terrible. Git apologists are nearly as silly as Javascript apologists.

A distributed source control system does not intrinsically have to be as error-prone and obscure and arbitrary as git. The fact that git fanboys can't see this is either a lack of introspection or a lack of imagination, or both.

My favorite example is the fact that "checkout", arguably the single most common source control command, will irrevocably and silently destroy local changes. Those with more time and more hate on their hands have written volumes about this[1], but for me, I find that plenty of very talented devs I know really do not care for git, and suffer its numerous deficiencies because it is the flavor du jour (and because of Github).

[1] http://stevelosh.com/blog/2013/04/git-koans/

so, git reset was not able to solve my problem, nor was git revert, git gave me an error message explicitly stating that branch merges can not be reverted. when i researched it i came to the conclusion that the a configuration change was required to prevent this problem going forwards. i came to the conclusion that git had bad defaults for what i consider a critical function of source control - i consider this dangerous.

i was able to solve our problem at the time, but the amount of time i wasted investigating a 'correct' solution using git exceeded the amount of time it took me to later create an 'anti-merge' commit myself (the fix) and move over to hg (prevent recurrance). i also chastised everyone for using something they didn't understand instead of the familiar well known tool because it was more popular (curing the cause).

i am going to investigate reproing this since everyone is in such a state of disbelief and a good proportion seem to think i am completely inexperienced and stupid.

the branch disappearing is a small thing thats confusing, but it comes down to the implementation details of git - because its all just a pile of diffs with labels and such when i merge it seems like the 'branch' disappears, even though its exactly the same data that was there before, just organised into a different hierarchy of changes. this is quite confusing, but it also means that, e.g. producing the anti-merge change, required more effort than it should have.

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.

"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.

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.

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

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.

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.

> 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?

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

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.

Good point, the reflog should be mentioned earlier in tutorials.

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...)

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.

Doesn't the large number of people saying "use the reflog" indicate that amongst git users, they know that it exists?

Probably. It's one of those things you learn as a Git user sooner or later -- though in most cases, not before a few heart-stopping moments and probably a bit of an injection of FUD into your team.

Rather more worrying is the possibility of deleting history remotely with an injudicious git push --force. Some such remotes (coughGitHubcough) don't give you any access to the reflog on their end to sort things out.

Git really needs to set receive.denyNonFastForwards and receive.denyDeletes to true by default.

yes, tbh this is the first time i have heard of the reflog.

i extensively googled when i had the original problem which put me off using git

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.

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.

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

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.

Agreed... rewriting history is a powerful tool that power users will want to use. Nothing more. That of course applies to all tools :)

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.

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

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

Did they? Last I heard, they were having trouble with a few repos, because the hashes they got from github weren't quite right.

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.

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.

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

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.

> "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

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.

Please see this figure: 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

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?

> 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

> 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.

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.

Reply on news.ycombinator.com