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

Tim Pierce twp at curoverse.com
Thu Apr 17 13:56:18 EDT 2014


I don't mind dealing with rebase conflicts if I can figure out a workflow
that doesn't screw up my repository. This seems to be mostly related to the
fact that I spend a lot of time developing on two machines -- my office
workstation and my laptop -- before merging to master, so I have to push
commits back and forth between them, and pushing to a branch on origin is
the easiest way to do that reliably.

If I can rewrite commit history on a branch that I've pushed to origin
without screwing things up, I'm happy to try a rebase-oriented workflow
again.

(I've also tried cloning my workstation repository onto a thumb drive and
using that to move data back and forth between machines, but that only
seems to pose the same problems in a different way.)

Alternatively, it may make more sense for me to just use my laptop for
development exclusively, and make a habit of not committing back to master
until my branch is rebased and ready for review. The multiple-machine setup
turns out not to give me a lot of value beyond a relatively small amount of
convenience.


On Thu, Apr 17, 2014 at 1:43 PM, Brett Smith <brett at curoverse.com> wrote:

>  (I know we talked about this at lunch, but I wanted to post too for
> others’ benefit.)
>
> On 04/17/2014 11:12 AM, peter 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?
>
>   That is the problem I had this morning. And as people have pointed out
> since then, git log can help solve this problem with specs like
> --first-parent and ^master.
>
> I think a merge-heavy history can make other problems too, though. In
> particular, when you’re reviewing history on master itself. Trying to
> understand where something came from, either manually or using a tool like
> git bisect, is more difficult with a complicated tree.
>  --
> Brett Smith
>
> _______________________________________________
> 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/8cb9a1dd/attachment.html>


More information about the Arvados-dev mailing list