1 |
On Sun, Jul 5, 2015 at 1:42 AM, Rich Freeman <rich0@g.o> wrote: |
2 |
> On Sat, Jul 4, 2015 at 2:17 PM, C Bergström <cbergstrom@×××××××××.com> wrote: |
3 |
>> |
4 |
>> What I personally prefer is a rebase workflow. |
5 |
> |
6 |
> The recommendation is to rebase when practical. |
7 |
> |
8 |
> Rebasing makes the history look clean, but it sometimes does this by |
9 |
> obscuring the real history. It also discards original author commits |
10 |
> with their signatures and rewrites them without signatures (in theory |
11 |
> it could add new signatures if the person doing the rebase is the |
12 |
> author). |
13 |
> |
14 |
|
15 |
Without having this conversation - then no logical decision or points |
16 |
will be brought up. Using git isn't magic. There are downsides to |
17 |
different work-flows and not having some decision or plan on this will |
18 |
lead to shit and confusion. Leaders should establish rules, guidelines |
19 |
or some policy before the migration (!!!) |
20 |
|
21 |
1) Rebase doesn't obscure history, but it may reorder things out of |
22 |
chronological order. (Unless you flatten the commit - which makes |
23 |
things easier and then yes does "lose" history, but that's a developer |
24 |
choice |
25 |
|
26 |
2) I don't understand your comment about signatures. I have never seen |
27 |
author tags lost in a rebase. merge will skrew up git blame more than |
28 |
rebase any day. |
29 |
|
30 |
3) Ever tried to make a patch of the *actual* merge commit? Can one of |
31 |
the advocates of merge show me the git command to do that? (Sure you |
32 |
can diff between 2 commits, but the "merge" commit likes to avoid |
33 |
being seen) |
34 |
|
35 |
4) I disagree that even a very active repo will have a problem with |
36 |
rebase - Why? |
37 |
a. If devs aren't working in the same area there will be no conflicts |
38 |
and a "git pull --rebase" before push will be clean and fast (no |
39 |
problems). |
40 |
b. If multiple devs have a conflict - then it would be only the 1st |
41 |
dev to push to have the easy job. The 2nd dev - regardless of merge or |
42 |
rebase would have to resolve the conflicts. IF the conflicts can be |
43 |
auto resolved - that would happen with a merge commit or rebase |
44 |
anyway. Same amount of work - someone would still have to resolve |
45 |
problems |
46 |
|
47 |
5) More about linear commits and "history" - I need to double check, |
48 |
but I don't think rebase changes the actual commit date (I could be |
49 |
mistaken). The only advantage to merge is you could see that the |
50 |
commit happened on the "1st" ${DATE-TIME} of the month - wouldn't have |
51 |
to manually figure out if that commit was before or after another |
52 |
commit in the graph. I can't say I've ever cared to know the date of a |
53 |
commit, but I can say I have cared a lot about knowing which commit |
54 |
came 1st. Rebase, for better or worse, forces something to be 1st and |
55 |
it's clear and easy to see. |
56 |
------------ |
57 |
If I controlled the gentoo git server, I'd set it to forbid merge |
58 |
commits - at least to start. If that poses *real* problems (not just |
59 |
random crying) then it could always be relaxed. |