Mercurial developer responds to "Switch to git?" • Hacker News Board

Re: Mercurial developer responds to "Switch to git?"

#121

Post by jheriko » Mon, Nov 18, 2013, 5:40 AM UTC

rallison wrote: post #102

jheriko wrote: post #95

Earlier quoted context omitted.

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 solutio…

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 S…

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

Re: Mercurial developer responds to "Switch to git?"

#122

Post by cpeterso » Mon, Nov 18, 2013, 5:42 AM UTC

eddiegroves wrote: post #71

Mercurial's changeset evolution sounds really powerful and seems to address the 'git rebase and force push' problems that can occur.

Here's a video of a FOSDEM 2013 talk about Mercurial's changeset evolution:

https://air.mozilla.org/changesets-evolution-with-mercurial/

Re: Mercurial developer responds to "Switch to git?"

#123

Post by jheriko » Mon, Nov 18, 2013, 5:43 AM UTC

steveklabnik wrote: post #87

jxf wrote: post #23

Earlier quoted context omitted.

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

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

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

Re: Mercurial developer responds to "Switch to git?"

#124

Post by jheriko » Mon, Nov 18, 2013, 5:50 AM UTC

driverdan wrote: post #25

jheriko wrote: post #14

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,…

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…

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.

Re: Mercurial developer responds to "Switch to git?"

#125

Post by jheriko » Mon, Nov 18, 2013, 5:58 AM UTC

jeltz wrote: post #72

jammycakes wrote: post #68

Earlier quoted context omitted.

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 a…

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

Re: Mercurial developer responds to "Switch to git?"

#126

Post by jheriko » Mon, Nov 18, 2013, 6:00 AM UTC

ajross wrote: post #117

jlgreco wrote: post #45

Earlier quoted context omitted.

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 (i…

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…

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.

Re: Mercurial developer responds to "Switch to git?"

#127

Post by stormbrew » Mon, Nov 18, 2013, 6:04 AM UTC

jheriko wrote: post #121

rallison wrote: post #102

Earlier quoted context omitted.

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 S…

'- 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 pr…

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.

Re: Mercurial developer responds to "Switch to git?"

#128

Post by jheriko » Mon, Nov 18, 2013, 6:09 AM UTC

jlgreco wrote: post #115

jheriko wrote: post #108

Earlier quoted context omitted.

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 mer…

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.

Re: Mercurial developer responds to "Switch to git?"

#129

Post by jheriko » Mon, Nov 18, 2013, 6:12 AM UTC

stormbrew wrote: post #127

jheriko wrote: post #121

Earlier quoted context omitted.

'- 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 pr…

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 '--mainlin…

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

Re: Mercurial developer responds to "Switch to git?"

#130

Post by rallison » Mon, Nov 18, 2013, 6:15 AM UTC

jheriko wrote: post #121

rallison wrote: post #102

Earlier quoted context omitted.

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 S…

'- 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 pr…

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.