| 1 |
C Bergström wrote: |
| 2 |
> 1) Rebase doesn't obscure history, |
| 3 |
|
| 4 |
That's plain wrong. Rebasing changes the parent of your commit. That |
| 5 |
means that others can no longer see the history of your commit, |
| 6 |
specifically its original parent. Sometimes the parent is irrelevant, |
| 7 |
sometimes it is critical. |
| 8 |
|
| 9 |
|
| 10 |
> (Unless you flatten the commit - which makes things easier and then |
| 11 |
> yes does "lose" history, but that's a developer choice |
| 12 |
|
| 13 |
Whether flattening is acceptable or not depends on how crappy commits |
| 14 |
the developer has committed on the branch. A firm rule is not possible. |
| 15 |
|
| 16 |
|
| 17 |
> 2) I don't understand your comment about signatures. |
| 18 |
|
| 19 |
So you didn't know about PGP signed commits and now you do. |
| 20 |
|
| 21 |
|
| 22 |
> 3) Ever tried to make a patch of the *actual* merge commit? Can one of |
| 23 |
> the advocates of merge show me the git command to do that? (Sure you |
| 24 |
> can diff between 2 commits, but the "merge" commit likes to avoid |
| 25 |
> being seen) |
| 26 |
|
| 27 |
If there are no conflicts when merging then the merge commit does not |
| 28 |
contain any changes, so how could there be a patch? Do you actually |
| 29 |
know the Git data model? I wrote it down the other day. |
| 30 |
|
| 31 |
http://peter.stuge.se/git-data-model |
| 32 |
|
| 33 |
|
| 34 |
> 4) I disagree that even a very active repo will have a problem with |
| 35 |
> rebase - Why? |
| 36 |
> a. If devs aren't working in the same area there will be no conflicts |
| 37 |
> b. If |
| 38 |
|
| 39 |
It's not about conflicts. |
| 40 |
|
| 41 |
|
| 42 |
> and a "git pull --rebase" before push will be clean and fast (no |
| 43 |
> problems). |
| 44 |
|
| 45 |
Q: How do you deal with the two commits from other developers that |
| 46 |
were pushed while you were rebasing? |
| 47 |
|
| 48 |
A: You end up having to spin on the remote repo. That's really clumsy. |
| 49 |
|
| 50 |
|
| 51 |
> 5) More about linear commits and "history" - I need to double check, |
| 52 |
> but I don't think rebase changes the actual commit date (I could be |
| 53 |
> mistaken). |
| 54 |
|
| 55 |
You are mistaken, and should have double checked before you argued. |
| 56 |
|
| 57 |
Arguing without checking makes you look bad. |
| 58 |
|
| 59 |
|
| 60 |
> The only advantage to merge is you could see that the commit |
| 61 |
> happened on the "1st" ${DATE-TIME} of the month |
| 62 |
|
| 63 |
That's not correct. |
| 64 |
|
| 65 |
> I can't say I've ever cared to know the date of a commit, but I can |
| 66 |
> say I have cared a lot about knowing which commit came 1st. Rebase, |
| 67 |
> for better or worse, forces something to be 1st and it's clear and |
| 68 |
> easy to see. |
| 69 |
|
| 70 |
A rebase, like a cherry-pick, loses the very information you claim to |
| 71 |
care about; the original parent of the commit. |
| 72 |
|
| 73 |
|
| 74 |
> If I controlled the gentoo git server, I'd |
| 75 |
|
| 76 |
I think it's a good thing that you don't, since you seem to still |
| 77 |
need to study Git in more detail. |
| 78 |
|
| 79 |
|
| 80 |
//Peter |
Archives