On Sun, Jul 5, 2015 at 1:42 AM, Rich Freeman <[email protected]> wrote:
> On Sat, Jul 4, 2015 at 2:17 PM, C Bergström <[email protected]> wrote:
>>
>> What I personally prefer is a rebase workflow.
>
> The recommendation is to rebase when practical.
>
> Rebasing makes the history look clean, but it sometimes does this by
> obscuring the real history. It also discards original author commits
> with their signatures and rewrites them without signatures (in theory
> it could add new signatures if the person doing the rebase is the
> author).
>
Without having this conversation - then no logical decision or points
will be brought up. Using git isn't magic. There are downsides to
different work-flows and not having some decision or plan on this will
lead to shit and confusion. Leaders should establish rules, guidelines
or some policy before the migration (!!!)
1) Rebase doesn't obscure history, but it may reorder things out of
chronological order. (Unless you flatten the commit - which makes
things easier and then yes does "lose" history, but that's a developer
choice
2) I don't understand your comment about signatures. I have never seen
author tags lost in a rebase. merge will skrew up git blame more than
rebase any day.
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)
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
and a "git pull --rebase" before push will be clean and fast (no
problems).
b. If multiple devs have a conflict - then it would be only the 1st
dev to push to have the easy job. The 2nd dev - regardless of merge or
rebase would have to resolve the conflicts. IF the conflicts can be
auto resolved - that would happen with a merge commit or rebase
anyway. Same amount of work - someone would still have to resolve
problems
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). The only advantage to merge is you could see that the
commit happened on the "1st" ${DATE-TIME} of the month - wouldn't have
to manually figure out if that commit was before or after another
commit in the graph. 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.
------------
If I controlled the gentoo git server, I'd set it to forbid merge
commits - at least to start. If that poses *real* problems (not just
random crying) then it could always be relaxed.
