87
Linus Torvalds on how and when to maintain a clean git history (2009) (www.mail-archive.com)
submitted 1 year ago* by to c/programming@programming.dev
18 comments fedilink hide all child comments
 

I want clean history, but that really means (a) clean and (b) history.

People can (and probably should) rebase their private trees (their own work). That's a cleanup. But never other peoples code. That's a "destroy history"

So the history part is fairly easy. There's only one major rule, and one minor clarification:

  • You must never EVER destroy other peoples history. You must not rebase commits other people did.

[...]

If you are working with git together with other people, it's worth a read.

you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 1 year ago

If ‘—first-parent’ was the default way that git log worked, I don’t think we’d even be having this argument over how to merge branches.

In my opinion, the best strategy is to always use a merge commit, and then when viewing master, always use —first-parent which will ONLY show commits on master. This gives you:

  • a very clean, linear history
  • the ability to let people work in their branches in their own way (it is ok to merge master into your branch multiple times without rebasing)
  • you can dig into the history of any branch if needed
  • it makes it easy to backport changes as you can cherry-pick out the merge commit which contains everything.

The problem is just the default log view of git and tools.

  • permalink
  • fedilink
  • source
  • parent