Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thanks for your answer. I really was never aware of git's GC mechanisms before, that's why I was sure that commits still hold inside a tree. And you perfectly answered my question (well, at least parts that I understood all details about, I clearly see I'd need to read more some time later).

I still find mercurial's branching model "the right thing" in terms of tree showing development history inside a branch, or overall (multi-branch) history-review (where you clearly see which commit was made in which branch), but I now see that it's really nice from repository-cleanup perspective to have features git has, to deal with non-needed branches and commits (via different mechanisms).



Git's branching model is "the right thing" once you learn the idioms of git development.

For example, if you want to build a new feature, make a local branch so your changes are isolated. You can make work-in-progress commits that split up a large change into pieces, some of which may be experimental, contain debugging statements, or temporarily break things.

Then when you're satisfied your changes are bug-free, you can use an interactive rebase (git rebase -i) to turn the commits into clean patches that would be something you might e.g. send to the mailing list if you're working on the flagship Git project, the Linux kernel.

I like to keep my history clean, six months from now I won't be interested in all the bugs I wrote when I implemented a feature, and all the fixes that I came up with for them during initial testing. I won't want to see the implementation of that feature scattered over multiple commits. I just want to see one clean, bug-free patch that implements the feature.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: