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

71–80 of 82 posts

Re: Git is Inconsistent

#71

Post by irons »

__david__ wrote: post #51
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…

None of that says "really bad UI". Quirky, sure. Not as straightforward as others. Could definitely be improved. But not "really bad". Though I will add that the index is a horribly named concept and it really bugs me that different commands use different names for it ("--cached", but sometimes "--index"). They need to rename it to "staging" and change all the command line options to --staging (keeping the old ones a…

None of that says "really bad UI". Quirky, sure. Not as straightforward as others.

I wouldn't call strychnine a poison. It's just a quirky food additive.

Re: Git is Inconsistent

#72

Post by ob »

etherealG wrote: post #68
ob wrote: post #59

Earlier quoted context omitted.

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.

You're wrong, but unfortunately I'm not at liberty to describe how bk does merges... it's part of the "secret sauce". i am truley sorry for your lots...

Re: Git is Inconsistent

#73

Post by ob »

tonfa wrote: post #63
ob wrote: post #59

Earlier quoted context omitted.

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.

Yeah, the website is awfully outdated and information free. BitMover is working on it.

One example that bk gets right and git doesn't is precisely the one explained in the article.

Re: Git is Inconsistent

#74

Post by ob »

davidmathers wrote: post #64
ob wrote: post #61

Earlier quoted context omitted.

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

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

No, OP is saying "when I cook my food in the microwave for 3 minutes, I get it to a very different temperature than if I cook it for 1.5 minutes first and then another 1.5 minutes"

Re: Git is Inconsistent

#75

Post by [deleted] »

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…

[deleted]

Re: Git is Inconsistent

#76

Post by etherealG »

ob wrote: post #72
etherealG wrote: post #68

Earlier quoted context omitted.

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.

You're wrong, but unfortunately I'm not at liberty to describe how bk does merges... it's part of the "secret sauce". i am truley sorry for your lots...

hehe, fair play. :) just kidding.

Re: Git is Inconsistent

#77

Post by Peaker »

cmurphycode wrote: post #58
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…

"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-update-files." I can understand your confusion, given the seemingly sepa…

Even after your explanation, the name "reset" and "--mixed" make no sense to me. "reset" is not indicative of what's being reset. "--mixed" is almost meaningless. "--soft" and "--hard" are also mostly meaningless.

I'm OK with having a low-level primitive like "reset" that doesn't have a simple meaning so cannot have a meaningful name. But then, it should be wrapped with meaningful commands such as "moveto" with flags to avoid touching index or working tree, and "unadd" on top of "reset". Then, I don't think anyone would ever use reset directly, so it would probably be phased out :-)

Re: Git is Inconsistent

#78

Post by nevinera »

JoeAltmaier wrote: post #25
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…

There are so many theories of "source control" that none of them are "simple clear and easy". They take study, and if you start from a different place, a new paradigm will be hard to learn and internalize. That said: An elegant property? Are you kidding? That is intrinsic to most tools that dare call themselves "source control". Git requires extraordinary explanation if it behaves in an extraordinary fashion.

>That is intrinsic to most tools that dare call themselves "source control".

Bullshit. 'Merge' is one of the most complicated operations in every versioning system. I'm pretty confident svn is 'inconsistent'. Or is that too niche?

Re: Git is Inconsistent

#79

Post by jongraehl »

tytso wrote: post #13

I've contributed a tiny amount to git (the high-level "git mergetool") so I can't speak for all of the git developers, but I've spent enough time hanging around for them to say that the general feeling they have is that git's algorithm which is "3-way merge, and then look at the intervening commits to fix any merge conflicts" is good enough. You can always try to spend more time trying to use more data, or deducing m…

Why are you sure that this ambiguity can't be efficiently detected? If it can be, it's worth doing.

Re: Git is Inconsistent

#80

Post by JoeAltmaier »

nevinera wrote: post #78
JoeAltmaier wrote: post #25

Earlier quoted context omitted.

There are so many theories of "source control" that none of them are "simple clear and easy". They take study, and if you start from a different place, a new paradigm will be hard to learn and internalize. That said: An elegant property? Are you kidding? That is intrinsic to most tools that dare call themselves "source control". Git requires extraordinary explanation if it behaves in an extraordinary fashion.

>That is intrinsic to most tools that dare call themselves "source control". Bullshit. 'Merge' is one of the most complicated operations in every versioning system. I'm pretty confident svn is 'inconsistent'. Or is that too niche?

Merge is a tool. The issue is, can you reproduce source accurately, from a variety of starting points, and be sure you have some canonical thing (release x.y).

Do I understand you right? This is not the expectation for a source control tool?

Post reply on HN