Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git is Inconsistent

r6.ca

Post reply on HN
Print view View original

61–70 of 82 posts

Re: Git is Inconsistent

#61

Post by ob »

davidmathers wrote: post #60
ob wrote: post #56

There are two things most commenters in this thread have missed: 1) The article talks about auto-merges. If the code is "too close" by some definition of close, you get a conflict that needs to be manually merged. The article does NOT talk about manual merges. 2) The article is titled "Git is Inconsistent", it doesn't claim Git is WRONG, it claims it is INCONSISTENT. It does different things depending on how you merg…

The article is titled "Git is Inconsistent", it doesn't claim Git is WRONG, it claims it is INCONSISTENT. Ok. The claim that git is inconsistent is wrong. From OP: The problem with git’s merging is that it doesn’t satisfy the “merge associativity law” which states that merging change A into a branch followed by merging change B into the branch gives the same results as merging both changes in together in one merge. T…

If you never merge, but only use "git pull --rebase", you will have a straight line history and thus lose all of the "distributed" nature of the history. That's fine, but limiting. Any system that allows distributed development has to deal with parallel work that gets merged in stages. Otherwise you are no better than diff/patch (FWIW, rebase merges before rebasing, so it is also vulnerable to this problem, rebasing just A, then rebasing B is NOT the same as rebasing A + B).

See: http://pastebin.com/SxmwpFkY

Re: Git is Inconsistent

#62

Post by saalweachter »

Groxx wrote: post #49
knowtheory wrote: post #42

Earlier quoted context omitted.

That's what i don't get. I don't understand where or how you could encounter a circumstance where this would matter. This complaint seems to be an abstract theoretical point (maybe to support git alternatives? dunno) that even esoteric usage of a DSCV would never come across. I dunno, maybe i'm not being creative enough in my use of histories. EDIT: Okay this explains everything in a considerably more concise fashion…

It would matter in this situation: In the beginning: function A(){ return 1; } Now commit this in one branch: function B(){ return 1; } function A(){ return 1; } then this: function A(){ return 1; } function B(){ return 1; } function A(){ return 1; } And then this in another branch off the base: function A(){ return 2; } Now merge the two end points. Which is correct? This, assuming a purely line-based diff: function…

You know, I suspect that in many production cases, neither merge is "correct". The example involves a lot code duplication, and a change to the block of code which was duplicated.

The probable case is something like:

  function foo(){
    do_something_complex_but_not_correct();
  }
with one person making the change to:

  function foo(){
    something_else();
    do_something_complex_but_not_correct();
  }
and then:

  function foo(){
    do_something_complex_but_not_correct();
    something_else();
    do_something_complex_but_not_correct();
  }
in the stated two-step change, while another author makes the change to:

  function foo(){
    do_something_complex_and_also_correct();
  }
The correct "merge" is going to be to apply the second change to both blocks of code, not just the first or the second:

  function foo(){
    do_something_complex_and_also_correct();
    something_else();
    do_something_complex_and_also_correct();
  }

Re: Git is Inconsistent

#63

Post by tonfa »

ob wrote: post #59
tonfa wrote: post #12

Earlier quoted context omitted.

Matt's point is that while some algorithms will fix this particular case, you can still come up with a different edge case which makes it break. The whole "prefect merge tool" was very popular five years ago (during git's and mercurial's infancy), but it didn't lead anywhere. Simple merges strategy are "good enough" in practice.

Matt's point is that they've chosen a system that makes it really hard to get that last 10%. "We have tried to draw spirals using cartesian coordinates, what we have gets us 90% there, but there are infinities and edge cases involved in getting a perfect spiral. The equations describing them would get so complicated it's just not worth it." What we have in BitKeeper is the equivalent of polar coordinates... it makes…

Do you have a page describing how that would differ? The bk website seems awfully outdated: there's no mention of the existence of other DVCS, there's a quote from MySQL being happy with bk -- they switched to bazaar two years ago --, etc..

I would be nice if you could give some examples where bk gets the merge right while git doesn't.

Re: Git is Inconsistent

#64

Post by davidmathers »

ob wrote: post #61
davidmathers wrote: post #60

Earlier quoted context omitted.

The article is titled "Git is Inconsistent", it doesn't claim Git is WRONG, it claims it is INCONSISTENT. Ok. The claim that git is inconsistent is wrong. From OP: The problem with git’s merging is that it doesn’t satisfy the “merge associativity law” which states that merging change A into a branch followed by merging change B into the branch gives the same results as merging both changes in together in one merge. T…

If you never merge, but only use "git pull --rebase", you will have a straight line history and thus lose all of the "distributed" nature of the history. That's fine, but limiting. Any system that allows distributed development has to deal with parallel work that gets merged in stages. Otherwise you are no better than diff/patch (FWIW, rebase merges before rebasing, so it is also vulnerable to this problem, rebasing…

OP is saying something like "when I cook things with my freezer they don't get hot." It's that non-sensical.

Git can't do (at all) what he wants to accuse it of doing wrong (because it has nothing to do with what git does). So I'm just pointing out the closest approximation to what he's aiming at is to use pull --rebase.

Personally I like to have a straight line history as a default and only merge when required. Rather than always merge by default.

Edit: Ok, I'm not sure I understand the point of the pastebin. Maybe. If you want the lower C to become X you need to git checkout master and then git rebase c. Not the other way around. Is that it?

Re: Git is Inconsistent

#65

Post by Groxx »

saalweachter wrote: post #62
Groxx wrote: post #49

Earlier quoted context omitted.

It would matter in this situation: In the beginning: function A(){ return 1; } Now commit this in one branch: function B(){ return 1; } function A(){ return 1; } then this: function A(){ return 1; } function B(){ return 1; } function A(){ return 1; } And then this in another branch off the base: function A(){ return 2; } Now merge the two end points. Which is correct? This, assuming a purely line-based diff: function…

You know, I suspect that in many production cases, neither merge is "correct". The example involves a lot code duplication, and a change to the block of code which was duplicated. The probable case is something like: function foo(){ do_something_complex_but_not_correct(); } with one person making the change to: function foo(){ something_else(); do_something_complex_but_not_correct(); } and then: function foo(){ do_so…

Which is why I side with explicit, patch-like behavior. Interpreting a `move-and-copy` as a `move` when there's a chunk of duplicate data that could mess things up means it's essentially doing a primitive semantic analysis of what you meant to do. It may be correct more of the time, but it can't be correct all of the time.

What I "meant to do" could have been as you stated, where both should have changed. Or I could have copied the internals of a function to a new one, and made minor changes around it, and actually do wish to use that new copy as the official version. There is no way to 100% accurately detect such intent without being explicit about it, so I'd prefer something dumb and therefore extremely predictable.

Re: Git is Inconsistent

#66

Post by tonfa »

gnosis wrote: post #35

Does anyone know how bazaar would handle this?

Just try or check the source. If they use patience or some kind of cdv merge, I expect they would get the same merge in both direction.

Re: Git is Inconsistent

#67

Post by tghw »

TillE wrote: post #38
Peaker wrote: post #24

Earlier quoted context omitted.

I think git is one of the best tools we have, but its UI is really bad: checkout and reset do completely different things when given files or when not given files. reset on files should really have been called unadd . reset on refspecs should really have been jumpto , moveto or something else indicative that the current branch ptr is moved to a new refspec. --soft and friends could have been --no-update-index or --no…

Sounds like you should be using Mercurial. The only thing it really lacks is the ability to change history, but this is more of a feature than a bug.

Mercurial has the same ability to change history as git, it just doesn't make it the default workflow. The mq extension (Mercurial Queues) lets you pull existing changesets into a temporary queue, fold them, reorder them, etc. The rebase extension lets you rebase and the histedit extension lets you edit history in slightly different ways.

All of these ship with Mercurial, but are turned off be default. Enabling them is just a matter of adding

    [extensions]
    mq =
to your .hgrc file.

Re: Git is Inconsistent

#68

Post by etherealG »

ob wrote: post #59
tonfa wrote: post #12

Earlier quoted context omitted.

Matt's point is that while some algorithms will fix this particular case, you can still come up with a different edge case which makes it break. The whole "prefect merge tool" was very popular five years ago (during git's and mercurial's infancy), but it didn't lead anywhere. Simple merges strategy are "good enough" in practice.

Matt's point is that they've chosen a system that makes it really hard to get that last 10%. "We have tried to draw spirals using cartesian coordinates, what we have gets us 90% there, but there are infinities and edge cases involved in getting a perfect spiral. The equations describing them would get so complicated it's just not worth it." What we have in BitKeeper is the equivalent of polar coordinates... it makes…

I'd appreciate an explanation of your approach too, it would be great to know how we could "adjust our coordinates" to take care of this issue without loosing speed, but gaining accuracy.

I suspect what you'll find is changing the base in this way, while fixing this problem would introduce other problems that occur much more regularly, but I hope I'm wrong.

Re: Git is Inconsistent

#69

Post by etherealG »

Peaker wrote: post #22
davidmathers wrote: post #14

Here's the short version: I am the original sentence. Alice commits a change in her repo: I am a different sentence. Bob commits a change in his repo: I am the original sentence. I am the original sentence. Now Alice pulls Bob's commit. What should happen? The argument is that in certain cases it can be known which of Bob's 2 sentences is the original and which is the copy (due to context provided by an intermediate…

> Git is consistent: a merge will always produce the same result for the same files I thought the point was that if you pull the exact same commits in different order the merge will produce a different result for the same files, meaning that in git the history does matter. Whereas darcs/etc will always produce the same result, such that history does not matter?

commits are not commutative in the general case. darcs algo is commutative for the merged commits, and gits is not, in this example.

the git people are arguing that the speed lost by gaining this commutative nature is just not worth it. i agree.

Post reply on HN