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

Linus on keeping a clean git history (2009)

mail-archive.com

Post reply on HN
Print view View original

81–86 of 86 posts

Re: Linus on keeping a clean git history (2009)

#81

Post by karategeek6 »

lukev wrote: post #3

This highlights the only thing I don't like about Git. It's an immensely capable tool, but it gives no guidance regarding the right way to do things. Our own teams have a set of practices which are similar but different from what Linus outlines here. And different projects on my company use different practices from those. The worst thing is that there's no way of enforcing these workflows or practices other than out-…

While I personally don't subscribe to the "one true way" philosophy, if you do (absolutely nothing wrong with that), you might be better off with mercurial than git.

Re: Linus on keeping a clean git history (2009)

#82

Post by klj613-- »

jebblue wrote: post #71

I have tried to get git, some people say one project per repo (which seems crazy but I did it), many projects are ok, you do need a main master repo, you don't need one, then there's the half dozen commands where with SVN it's one. Now the most valuable thing to me in source control, history, I'm supposed to keep clean? That's like a sacred cow, you _don't_ mess with history. >> That's fairly straightforward, no? No…

Best way to learn git is in the command line (get away from any GUI). And then play with repositories to see what the commands actually do.

"Don't mess with history"? I don't have to commit to my commits as long as my commits ain't public.

Rewriting history is a lie? Well, if you want to keep everything you do in history, maybe commit on each keystroke? That's insane.

Don't commit unless your ready to commit? Then that be hard to keep track of. Come time to commit you've got 50+ files modified good luck at doing decent commit messages.

Re: Linus on keeping a clean git history (2009)

#83

Post by klj613-- »

mibbitier wrote: post #26
aidenn0 wrote: post #22

Earlier quoted context omitted.

In my experience, git is more complex than svn, but not needlessly so. In any sufficiently long-running project, I've wanted features that git has and svn doesn't.

As a relative newbie to git, Why do I get prompted to enter a commit message when I'm just doing a git pull? Why do I have to explicitly add every file I want to commit each time? Why can't it just default to "everything under the current dir" like svn does?

1. `git pull` = fetch + merge If the merge has conflicts, then you got to solve the conflicts and do the commit manually (entering the commit message) If the merge doesn't have conflicts, then the merge commit is automatic.

2. `git commit -m "foobar"` will commit the files from the stage/index `git commit -am "foobar"` will commit all the modified files (it will ignore untracked files)

Re: Linus on keeping a clean git history (2009)

#84

Post by jebblue »

klj613-- wrote: post #82
jebblue wrote: post #71

I have tried to get git, some people say one project per repo (which seems crazy but I did it), many projects are ok, you do need a main master repo, you don't need one, then there's the half dozen commands where with SVN it's one. Now the most valuable thing to me in source control, history, I'm supposed to keep clean? That's like a sacred cow, you _don't_ mess with history. >> That's fairly straightforward, no? No…

Best way to learn git is in the command line (get away from any GUI). And then play with repositories to see what the commands actually do. "Don't mess with history"? I don't have to commit to my commits as long as my commits ain't public. Rewriting history is a lie? Well, if you want to keep everything you do in history, maybe commit on each keystroke? That's insane. Don't commit unless your ready to commit? Then th…

>> Best way to learn git is in the command line (get away from any GUI).

I've used a lot of source control systems and the best always have a GUI and so guess what? I want a GUI unless the CLI for such system is inherently intuitive which if you read my comments I do not think git is intuitive at all.

>> I don't have to commit to my commits as long as my commits ain't public.

Huh?!?! I don't get that, it like makes no sense to me whatsoever. Why do you think I should even try to comprehend it?

>> Don't commit unless your ready to commit?

Are you suggesting I said or asked that??? Are you advising me? Seriously what?

>> Then that be hard to keep track of. Come time to commit you've got 50+ files modified good luck at doing decent commit messages.

Huh? I'm sorry is that English because it doesn't even make sense at all to me? Is it 50 lines changed all clearly related? Is it 50 totally different changes?

Re: Linus on keeping a clean git history (2009)

#85

Post by lmm »

smithzvk wrote: post #72
lmm wrote: post #66

Earlier quoted context omitted.

Switching branches is cheap, I'd say the "right" way to get a tree like you want is to have two or even five branches all the time you're working. But I suspect you could make two branches and cherry-pick different sets of commits onto them to get the result you're after. To my mind it wouldn't be worth the effort though; how often do you really care whether the code worked with only 1 and 4 applied?

Right, I would say that it isn't worth the effort. Also, I probably never care about the code with only 1 and 4 applied. So perhaps branches aren't the right way to do what I am describing. I always saw VC as a systematic way to keep a log of my development so that I could figure out where I may have broken my code. For this purpose, having some sort of meta-data where commits can be grouped would be nice. It would a…

git-bisect is the standard tool for figuring out where you broke something. I don't know what it does with branching histories though, I tend to effectively linearise my history by rebasing each branch on the trunk head before merging it.

Re: Linus on keeping a clean git history (2009)

#86

Post by klj613-- »

jebblue wrote: post #84
klj613-- wrote: post #82

Earlier quoted context omitted.

Best way to learn git is in the command line (get away from any GUI). And then play with repositories to see what the commands actually do. "Don't mess with history"? I don't have to commit to my commits as long as my commits ain't public. Rewriting history is a lie? Well, if you want to keep everything you do in history, maybe commit on each keystroke? That's insane. Don't commit unless your ready to commit? Then th…

>> Best way to learn git is in the command line (get away from any GUI). I've used a lot of source control systems and the best always have a GUI and so guess what? I want a GUI unless the CLI for such system is inherently intuitive which if you read my comments I do not think git is intuitive at all. >> I don't have to commit to my commits as long as my commits ain't public. Huh?!?! I don't get that, it like makes n…

Personally I think its better using the CLI for git.

I commit very often however I rewrite the commits. In other words, I mess with my history and it is a good thing (My commits ain't final, in other words... "I do not commit to my commits").

In SVN I try not to commit too often because I do not want to commit (publish) changes which I may not want to keep.

With git I commit very often in stages. Then I can remove them or change them at a later stage. If I do not do this I will end up with a load of files (e.g. 50+) which has been modified and either I commit them all in one (bad) go or try and separate out each step I've taken the past 12 hours and do decent commit messages (good).

Of course you could commit very often, create new commits to fix errors you've done in recent commits (rather than rewriting history). You could also merge master into feature-x everyday (rather than rebasing), but then you'd have history which looks like chaos and hard to follow.

-

Honestly, when I started git I was lost (first VCS I learnt). Until one day I figured out how simple git is to use.

Post reply on HN