[arvados-dev] Brett's opinions on git workflow

[peter]

On Thu, 2014-04-17 at 10:24 -0400, Brett Smith wrote:

> I was just reviewing a branch for Tom. Since this was my second pass
> on it, I went to the git log to see what changed since my last pass.
> I’ve attached the log graph output magit showed me. The complicated
> history tree made it challenging to find all the relevant revisions.
> Tom described making several changes that I didn’t see at first, until
> I found 1881da32 and friends near the bottom of the screen.

As I look at it, the problem you actually have here is that it is hard
to identify which commits go with the feature branch you're trying to
review, and which commits are merges from other places.  Is that fair?

If that is the case, perhaps we want something along the lines of named
branches, similar to Mercurial branches.  In hg, every commit has a
"branch name" which is a permanent tag on the commit.  When you look at
history in Mercurial, it is very easy to a) see only the commits tagged
with that branch and b) see where two branches forked or merged (since
the left and right sides have distinct names.)

For some reason, the git community is incredibly resistant to this idea,
but I haven't seen a good reason why (git vs. hg religious wars don't
count).  Since git is so flexible, it seems like it would be pretty easy
to achieve mercurial-like named branches (which are really just tags on
commits), although we would need tool support when viewing history for
this to actually be useful.

> There are at least two workflow changes we could make that would
> improve our history-documentation:
> 
>      1. Just stop merging the parent branch back into its parent so
>         regularly. git diff master... would be the canonical way to
>         review. When the feature branch gets merged into master, the
>         merge would be larger, so we’d have to put in additional
>         effort to make sure that goes smoothly and doesn’t introduce
>         bugs.

I object to this on principal, all things being equal in my experience
it is best to track master as closely as possible to minimize the
disruption when you do merge.  Keep in mind it is easy to introduce bugs
if you are going through a big pile of merge conflicts, and the flip
side of the context problem you describe above is that if you are
manually resolving a three way merge conflict it's very helpful to know
why the other change happened.  That is more difficult when you have a
pile of unrelated commits being merged, as opposed to a smaller
incremental merge.

>      1. If we don’t like big merges (very understandable!), where we
>         currently merge the parent back into feature branches, instead
>         we could rebase the feature branch on top of its parent. To do
>         this, we’ll have to let ourselves rewrite history on
>         git.curoverse.com. This would require more discipline from us,
>         but I feel like we already have that, since our rule is that a
>         developer owns the branch they make. When you pull someone
>         else’s feature branch for review, you’d use git pull -f to get
>         the rewritten history. Our process for reviewing and merging
>         feature branches would remain the same, and those merges
>         should be as straightforward as they are today.

Rebasing and history rewriting scares me, but that's because I've never
actually used it ;-)  Perhaps an example of how this would work in
practice is in order.

> There might be other options too, but I think these would require the
> least disruption to our current workflow. Which is my goal, because I
> generally like our current workflow. I just wish I could understand
> the history better. :)

I think this is a fair point and we should definitely talk about it some
more.

- Peter