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

31–40 of 82 posts

Re: Git is Inconsistent

#31

Post by DennisP »

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…

Joel Spolsky describes mercurial as storing lists of changes, rather than a series of file snapshots.

"And so, when we want to merge our code together, Mercurial actually has a whole lot more information: it knows what each of us changed and can reapply those changes, rather than just looking at the final product and trying to guess how to put it together.

"For example, if I change a function a little bit, and then move it somewhere else, Subversion doesn’t really remember those steps, so when it comes time to merge, it might think that a new function just showed up out of the blue. Whereas Mercurial will remember those things separately: function changed, function moved, which means that if you also changed that function a little bit, it is much more likely that Mercurial will successfully merge our changes."

http://hginit.com/00.html

I'd assumed git and mercurial worked the same way.

Re: Git is Inconsistent

#32

Post by copper »

jerf wrote: post #28
Peaker wrote: post #23

Earlier quoted context omitted.

Here's a quote from the article explaining what would rely on this expectation: > There are still some people who still think nothing is wrong with git; that it is okay for the result of a merge to depend on how things are merged rather than on only what is merged; that is it okay for two git repositories that pull the same patches to have different contents depending on how they pulled those patches. I don’t know wh…

I think I kind of know what the author was getting at, but I'm not sure, and ending with the moral equivalent of "If you disagree with me, I guess you're just stupid" was a bit disappointing. I think the idea is the potential problems with this could emerge if you have two people simultaneously doing somewhat larger complicated merges that have this core problem perhaps more than once. I think that may be true, but t…

I thought the author was trying to get at the old Babbage quote on confusion of ideas.

FWIW, I use git-svn to handle complex merges in svn because git has a better merge algorithm. While this particular situation doesn't affect that use case - I think it could, but it should be rare with (svn) branch discipline - the fact that it might is something to keep in mind.

Re: Git is Inconsistent

#33

Post by bitwize »

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…

No, no, no.

History is EVERYTHING to a VCS. You ALWAYS want exact information of what changed at what time. This lets you do all sorts of cool things like examine the provenance of a file in detail, integrate a similar change across two different branches whose code may have diverged, etc.

Meticulous tracking of history as well as efficient handling of large binary blobs are why the pros almost always rely on Perforce for large projects.

Re: Git is Inconsistent

#34

Post by psykotic »

DennisP wrote: post #31
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…

Joel Spolsky describes mercurial as storing lists of changes, rather than a series of file snapshots. "And so, when we want to merge our code together, Mercurial actually has a whole lot more information: it knows what each of us changed and can reapply those changes, rather than just looking at the final product and trying to guess how to put it together. "For example, if I change a function a little bit, and then m…

The short of it is that Joel is wrong. Git and Mercurial use similar data structures and neither of them store changes in the way that Darcs stores changes. Maybe he knows that full well but is telling a white lie to get a teaching point across.

If you make a change to a file in Git and commit it, the new version will store the full updated contents of that file (delta compression is an orthogonal issue). Indeed, my use of the word "version" is revealing. That concept is secondary in Darcs; changes are what have primary ontological status.

Re: Git is Inconsistent

#36

Post by KirinDave »

Not to be grumpy about it, but git's shortcomings are well-known and most people don't run into them on a daily basis.

Some DVCS, like Darcs, might behave better, but they all seem almost comically slow even for medium-sized repos. If I have to sacrifice git's speed for certain types of correctness (that don't trouble me on a daily basis), I will be VERY reluctant to make that choice.

Re: Git is Inconsistent

#37

Post by nevinera »

Peaker wrote: post #23
nevinera wrote: post #21

>There are still some people who still think nothing is wrong with git; that it is okay for the result of a merge to depend on how things are merged rather than on only what is merged; that is it okay for two git repositories that pull the same patches to have different contents depending on how they pulled those patches. I don’t know what to say to those people. Such a view seems like insanity to me. Git merges file…

Here's a quote from the article explaining what would rely on this expectation: > There are still some people who still think nothing is wrong with git; that it is okay for the result of a merge to depend on how things are merged rather than on only what is merged; that is it okay for two git repositories that pull the same patches to have different contents depending on how they pulled those patches. I don’t know wh…

That quote by the author says 'I expect this behavior'. It does not give some use-case that would rely on it, aside from the use case of 'I use git, and incorrectly assume that merges are transitive.'

More specifically, if they pulled the same patches, the outcome would be identical. What he wants to be able to do is pull the same history by pulling different patches in that history. A patch is the diff between two repository states, and that's all it is. Sadly, diffs are intransitive.

Re: Git is Inconsistent

#38

Post by TillE »

Peaker wrote: post #24
hasenj wrote: post #20

Earlier quoted context omitted.

git's UI is great; as long as you understand how it works. The good thing is: "how it works" is really simple. You should treat it like a language (just like all system/unix tools), not an "app".

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.

Re: Git is Inconsistent

#39

Post by cookiecaper »

bitwize wrote: post #33
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…

No, no, no. History is EVERYTHING to a VCS. You ALWAYS want exact information of what changed at what time. This lets you do all sorts of cool things like examine the provenance of a file in detail, integrate a similar change across two different branches whose code may have diverged, etc. Meticulous tracking of history as well as efficient handling of large binary blobs are why the pros almost always rely on Perforc…

As far as I know, the history in git doesn't change unless you explicitly ask it to (rebase). So you should still always be able to tell exactly what changed and at what time it was changed. Perhaps git doesn't employ this information to the liking of others, but it should all be there.

Re: Git is Inconsistent

#40

Post by ob »

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…

No, you are totally wrong. Did you even try this in Git? Any sensible VC system will give you a conflict here. The article discusses auto-merge behaviour. You ABSOLUTELY can get auto-merge to work 100% of the time. When it doesn't you get a conflict that you need to manually resolve. BitKeeper does get this right (disclaimer: I am one of the developers of BitKeeper).
Post reply on HN