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

[Tim Pierce]

I had some bad experiences with trying to rebase my commits when I started
working with branches (OH HELLO ENDLESS GIT COMMIT LOOP FROM HELL), but I'm
willing to try again if someone can hold my hand during the scary parts. I
do like the idea of establishing a workflow that permits us to iterate
quickly but doesn't fill up our commit history with unnecessary merge
commits.


On Thu, Apr 17, 2014 at 11:12 AM, peter <peter.amstutz at curoverse.com> wrote:

> 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
>
>
>
> _______________________________________________
> Arvados-dev mailing list
> Arvados-dev at arvados.org
> http://lists.arvados.org/mailman/listinfo/arvados-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arvados.org/pipermail/arvados-dev/attachments/20140417/076e2e4f/attachment-0001.html>