If you don’t understand how to safely use a chainsaw, then don’t touch it. If you don’t understand how to safely rebase, then don’t do it on any codebase you care a lot about.

If you don’t think the man page is clear enough, there are plenty of good git books and online resources to help you. Read them and learn, or ask a more experienced git user to help you.

Even when working with other developers at my job we work for a while, then we clean up the commits via rebasing and start working on a new branch, keeping the old one just in case. It works great. Before we push to production we also rebase in order to clean everything up and make our jobs easier when we have to look through history later.

Actually, I like to use rebase – all the time to reorganize my commits by splitting, squashing and fixing comment etc. It’s part of my dev process for partitioning and composing code. But once it’s published, it’s documented history and should not be changed to avoid confusion.

I’ve always cringe when I see cvs/p4/svn people pushing huge and sometimes broken stuff into a central repository, simply because they want a “checkpoint”, due to large un-versioned changes already built up in their trees, simply because they have tools like git rebase -i or git add -p to pick and choose patches within files. Ugh

In the end just look at your commit message, if you need to write a whole page of changes you probably should break it into smaller steps.

The point is that even ‘atomic’ feature can be broken into logical steps, which are much easier to review. But anyway git is no forcing you to do anything.

Rebase is a wonderful tool, and bisect works really nice with it. I wouldn’t want to bisect merges only as that would be limited in nature. I like the paradigm of making each commit a complete patch. It makes following the history much easier.

This is like “we have to do this to support the broken tool”. The right thing here is to only count the merge revision when bisecting.

> Second, you want to ensure that you order patches so that every version builds; hence, when submitting a new driver to Linux, you put the patch with the Makefile last.

Similarly, the key is to only count revisions committed directly to the mainline, including merges.

I’m not quite following you as to why this would be a bad thing. If a bug was fixed before it makes into the official tree, why would the public care about it? IOW, what’s so important for the rest of the world to see:

commit a: the big shining feature!
commit b: oops, fixed a typo in the big shining feature.

instead of:

commit a’: the big shining feature!

?

I doubt even a maintainer needs/wants to see all the noises in the patch series.

I’m glad to have come across your post via the google query ‘git merge rebase’ precisely because I didn’t know when either was more appropriate. Despite the grilling responses, I’ve found the entire thread very informative.

I am using git locally to sidestep the finer ‘features’ of clearcase. I use git-rebase between my various branches and master where I perform clearcase rebase/deliveries. For me, master is the central repository and cc-rebases are indeed modifications in history.

Cheers,
Alex

All in all, I could not disagree more with your final conclusion that git-rebase should be removed because it encouraged bad practices. Just because it isn’t useful to you, it doesn’t mean that there’s no use for it at all (see above). Git gives you the tools for both philosophies, it’s your decision whether to rebase or to merge.

Personally, I like to use rebase -i all the time to reorganize my commits by splitting, squashing and fixing comment etc. It’s part of my dev process for partitioning and composing code. But once it’s published, it’s documented history and should not be changed to avoid confusion.

I’ve always cringe when I see cvs/p4/svn people pushing huge and sometimes broken stuff into a central repository, simply because they want a “checkpoint”, due to large un-versioned changes already built up in their trees, simply because they have tools like git rebase -i or git add -p to pick and choose patches within files. Ugh.

I’ve been using Darcs since 2005. I switched to Darcs, in fact, 10 days after the simultaneous founding announcements of git and Mercurial.

Overall, I have been happy. I

I agree with you that git-rebase doesn’t make sense on shared repositories.
Any repository with more than one user should certainly not use git-rebase. A
“copy-rebase” technique works fine, though; make a new branch at the same
location, and rebase the *new* branch.