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

Git concepts simplified

gitolite.com

Post reply on HN
Print view View original

61–70 of 142 posts

Re: Git concepts simplified

#61

Post by jlgreco »

StavrosK wrote: post #54
tootie wrote: post #21

Earlier quoted context omitted.

That's not it. Following any reasonable workflow still requires a set of arcane commands and flags that only make the slightest bit of sense if you know how git is implemented. I was able to use SVN successfully without ever knowing a thing about the implementation. I've generally had the same experience with HG and even CVS and VSS back in the day. Git adds sophistication over a prodcut like SVN, but adds vastly mor…

It's that its porcelain is a clusterfuck. The staging area is a hack that greatly convolutes the UI, and it would have been better if it were left out and you just had a way to cherry-pick what you want to commit at commit time (if it wasn't everything). There's no symmetry in commands. The opposite of "git commit" is "git reset --soft HEAD^", not "git uncommit". "git reset" is three commands in one. I could go on an…

You're basically railing against orthogonality. I don't think anybody disagrees that some flags could be made more consistent, but creating a separate git-uncommit when that functionality is fundamentally encompassed by the purpose of the third invocation of git-reset is a mistake.

If you make a specific case for 'git reset --hard/--soft HEAD^' then you would either be left without the more general (and more useful) 'git reset --hard/--soft ', or you would have a situation where you have to use 'uncommit' to (for example) re-commit something, or you would be left with a git-uncommit command and still have git-reset for related operations. Why would any of that be better?

You could split the third invocation of git-reset off into its own command, but honestly I don't see the utility in doing that.

Re: Git concepts simplified

#62

Post by jimktrains2 »

StavrosK wrote: post #54
tootie wrote: post #21

Earlier quoted context omitted.

That's not it. Following any reasonable workflow still requires a set of arcane commands and flags that only make the slightest bit of sense if you know how git is implemented. I was able to use SVN successfully without ever knowing a thing about the implementation. I've generally had the same experience with HG and even CVS and VSS back in the day. Git adds sophistication over a prodcut like SVN, but adds vastly mor…

It's that its porcelain is a clusterfuck. The staging area is a hack that greatly convolutes the UI, and it would have been better if it were left out and you just had a way to cherry-pick what you want to commit at commit time (if it wasn't everything). There's no symmetry in commands. The opposite of "git commit" is "git reset --soft HEAD^", not "git uncommit". "git reset" is three commands in one. I could go on an…

git add -p

       -p, --patch
           Interactively choose hunks of patch between the index and the work
           tree and add them to the index. This gives the user a chance to
           review the difference before adding modified contents to the index.

           This effectively runs add --interactive, but bypasses the initial
           command menu and directly jumps to the patch subcommand. See
           “Interactive mode” for details.

Re: Git concepts simplified

#63

Post by Pxtl »

dcre wrote: post #59
Pxtl wrote: post #36

... that is not simple. But I'm figuring it out anyways. I commit my changes to my own repo and keep building changes under HEAD, committing as I go. If I get a branch from a buddy and I want to add it to my code, I either merge or rebase depending how I want his commits to be intertwingled. Because GIT is decentralized, there's no difference between merging in a buddy's branch, and import the latest changes from Ori…

One small point: on check-in, I don't think it's exactly that origin is also rebasing/merging just like you did. It's more like origin is just taking whatever you have and copying it exactly. The merging/rebasing process itself only happens locally. Regarding merge vs. rebase, here's my approach: rebase to keep history a straight line when it's just your changes and it's just a few commits. If it's too many commits y…

> One small point: on check-in, I don't think it's exactly that origin is also rebasing/merging just like you did. It's more like origin is just taking whatever you have and copying it exactly. The merging/rebasing process itself only happens locally.

But then what happens when I merge/rebase locally and publish at the same time as somebody else? I assume the origin doesn't keep a lock on the whole mess while I'm doing my local merge/rebase. That sounds like it would lead to a "last-one-wins" conflict-resolution or a complete reversion of the origin if I publish without rebasing on the origin's version first.

Re: Git concepts simplified

#64

Post by StavrosK »

leephillips wrote: post #60
StavrosK wrote: post #54

Earlier quoted context omitted.

It's that its porcelain is a clusterfuck. The staging area is a hack that greatly convolutes the UI, and it would have been better if it were left out and you just had a way to cherry-pick what you want to commit at commit time (if it wasn't everything). There's no symmetry in commands. The opposite of "git commit" is "git reset --soft HEAD^", not "git uncommit". "git reset" is three commands in one. I could go on an…

I might not [EDIT: in fact, was not: see reply below] be appreciating the way that the staging area convolutes the UI for you, but you can pretend it doesn't exist by always just doing commit -a. And, if you want to "cherry-pick what you want to commit at commit time", well, that's what the staging area is for, isn't it?

Pretending it doesn't exist won't unconvolute the UI. I'm talking about things like "git checkout -- ", and "Git reset" which could just be one command if they didn't have to manage getting things in and out of the staging area.

I much prefer bzr's porcelain, it's much better designed and more sane.

Re: Git concepts simplified

#65

Post by tootie »

damncabbage wrote: post #32
jlgreco wrote: post #11

Earlier quoted context omitted.

I don't get this attitude. The DAG is exceedingly simple and I think can be taught reasonably in only a few minutes. From there you really only need to teach a very minor amount of the UI, and teach the user how to perform "I want to do this to the DAG" => "This is what I type" translations on their own. I've seen all of this done well in sub-hour presentations. Mercurial on the other hand has a pain in the ass datam…

I agree with the model being great. The git command itself is abominably baroque in its user interface (inconsistencies and strange defaults abound), but I've gotten over that with more effort than I'd like to admit. I love Git's plumbing; I just hate its porcelain.

People who refuse to see the ugliness in git are the same people who think it's manly to live on the command line. Using git through Eclipse looks a lot like using SVN through Eclipse. If I right-click on a file and go Team > Replace With > Remote and select 'origin master' is saves me from trying to remember the obscure list of flags I need to pass to the command line to do the same thing.

Re: Git concepts simplified

#66

Post by ender7 »

stormbrew wrote: post #44

A suggestion for anyone hoping to write accessible tutorials: > Hg folks should read this section carefully. Among various crazy notions Hg has is one that encodes the branch name within the commit object in some way. Unfortunately, Hg's vaunted "ease of use" (a.k.a "we support Windows better than git", which in an ideal world would be a negative, but in this world sadly it is not) has caused enormous takeup, and doz…

There's also a bit of "people in glass houses..." to this comment. I don't think git really wants to start a fight when it comes to poor design decisions.

Re: Git concepts simplified

#68

Post by jlgreco »

tootie wrote: post #65
damncabbage wrote: post #32

Earlier quoted context omitted.

I agree with the model being great. The git command itself is abominably baroque in its user interface (inconsistencies and strange defaults abound), but I've gotten over that with more effort than I'd like to admit. I love Git's plumbing; I just hate its porcelain.

People who refuse to see the ugliness in git are the same people who think it's manly to live on the command line. Using git through Eclipse looks a lot like using SVN through Eclipse. If I right-click on a file and go Team > Replace With > Remote and select 'origin master' is saves me from trying to remember the obscure list of flags I need to pass to the command line to do the same thing.

Refuse to see the ugliness? No, I really don't see it. Sure, a few flags could be cleaned up, but the beauty of the rest of git more than offsets a few weirdly named flags.

Meanwhile git through eclipse causes nothing but trouble as far as I have seen. Making it seem like SVN is exactly the problem, git isn't like SVN so if it seems that way, something is going wrong. Pretending git is something that it isn't will bite you in the ass sooner rather than later. The disappointing part is that there isn't any technical reason why git integration in eclipse couldn't be good, it just isn't currently.

Re: Git concepts simplified

#69

Post by davvolun »

tootie wrote: post #8

There is an inverse relationship the number articles title "x explained simply" and the actual simplicity of x. I honestly don't understand why the developer community refuses to admit the obvious that git is unholy clusterfuck of a product. It has a nice data structure inside it? Name another end-user product for which you are even vaguely aware of what data structures were used.

That argument doesn't really make sense. If x were fundamentally simple, why would I need a simple explanation for it? Clearly git is, or can be, complex, and a simple, simpler or simplified explication would be helpful.

None of that implies that "git is [an] unholy clusterfuck of a product," it means that git is complicated. For 99% of the work you do with git, it isn't even that complicated and you don't need to be aware of the data structure. As for the last 1%, well, that's what separates git from other (D)VCSs. Git gives me the power to do a lot, and incidentally, it gives me the power to shoot my foot off too...I still prefer it over say svn or hg, my personal opinion.

Re: Git concepts simplified

#70

Post by dcre »

Pxtl wrote: post #63
dcre wrote: post #59

Earlier quoted context omitted.

One small point: on check-in, I don't think it's exactly that origin is also rebasing/merging just like you did. It's more like origin is just taking whatever you have and copying it exactly. The merging/rebasing process itself only happens locally. Regarding merge vs. rebase, here's my approach: rebase to keep history a straight line when it's just your changes and it's just a few commits. If it's too many commits y…

> One small point: on check-in, I don't think it's exactly that origin is also rebasing/merging just like you did. It's more like origin is just taking whatever you have and copying it exactly. The merging/rebasing process itself only happens locally. But then what happens when I merge/rebase locally and publish at the same time as somebody else? I assume the origin doesn't keep a lock on the whole mess while I'm doi…

It notices that origin has commits that you don't have and rejects your push. Then you pull the change that happened in the meantime, merge/rebase your change again on top of that, and push again.

If we're recommending books on Git, I recommend Pro Git. It's free online. http://git-scm.com/book

Post reply on HN