C Bergström wrote: > 1) Rebase doesn't obscure history, That's plain wrong. Rebasing changes the parent of your commit. That means that others can no longer see the history of your commit, specifically its original parent. Sometimes the parent is irrelevant, sometimes it is critical.
> (Unless you flatten the commit - which makes things easier and then > yes does "lose" history, but that's a developer choice Whether flattening is acceptable or not depends on how crappy commits the developer has committed on the branch. A firm rule is not possible. > 2) I don't understand your comment about signatures. So you didn't know about PGP signed commits and now you do. > 3) Ever tried to make a patch of the *actual* merge commit? Can one of > the advocates of merge show me the git command to do that? (Sure you > can diff between 2 commits, but the "merge" commit likes to avoid > being seen) If there are no conflicts when merging then the merge commit does not contain any changes, so how could there be a patch? Do you actually know the Git data model? I wrote it down the other day. http://peter.stuge.se/git-data-model > 4) I disagree that even a very active repo will have a problem with > rebase - Why? > a. If devs aren't working in the same area there will be no conflicts > b. If It's not about conflicts. > and a "git pull --rebase" before push will be clean and fast (no > problems). Q: How do you deal with the two commits from other developers that were pushed while you were rebasing? A: You end up having to spin on the remote repo. That's really clumsy. > 5) More about linear commits and "history" - I need to double check, > but I don't think rebase changes the actual commit date (I could be > mistaken). You are mistaken, and should have double checked before you argued. Arguing without checking makes you look bad. > The only advantage to merge is you could see that the commit > happened on the "1st" ${DATE-TIME} of the month That's not correct. > I can't say I've ever cared to know the date of a commit, but I can > say I have cared a lot about knowing which commit came 1st. Rebase, > for better or worse, forces something to be 1st and it's clear and > easy to see. A rebase, like a cherry-pick, loses the very information you claim to care about; the original parent of the commit. > If I controlled the gentoo git server, I'd I think it's a good thing that you don't, since you seem to still need to study Git in more detail. //Peter
