<div dir="ltr">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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 11:12 AM, peter <span dir="ltr"><<a href="mailto:peter.amstutz@curoverse.com" target="_blank">peter.amstutz@curoverse.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, 2014-04-17 at 10:24 -0400, Brett Smith wrote:<br>
<br>
> I was just reviewing a branch for Tom. Since this was my second pass<br>
> on it, I went to the git log to see what changed since my last pass.<br>
> I’ve attached the log graph output magit showed me. The complicated<br>
> history tree made it challenging to find all the relevant revisions.<br>
> Tom described making several changes that I didn’t see at first, until<br>
> I found 1881da32 and friends near the bottom of the screen.<br>
<br>
</div>As I look at it, the problem you actually have here is that it is hard<br>
to identify which commits go with the feature branch you're trying to<br>
review, and which commits are merges from other places. Is that fair?<br>
<br>
If that is the case, perhaps we want something along the lines of named<br>
branches, similar to Mercurial branches. In hg, every commit has a<br>
"branch name" which is a permanent tag on the commit. When you look at<br>
history in Mercurial, it is very easy to a) see only the commits tagged<br>
with that branch and b) see where two branches forked or merged (since<br>
the left and right sides have distinct names.)<br>
<br>
For some reason, the git community is incredibly resistant to this idea,<br>
but I haven't seen a good reason why (git vs. hg religious wars don't<br>
count). Since git is so flexible, it seems like it would be pretty easy<br>
to achieve mercurial-like named branches (which are really just tags on<br>
commits), although we would need tool support when viewing history for<br>
this to actually be useful.<br>
<div class=""><br>
> There are at least two workflow changes we could make that would<br>
> improve our history-documentation:<br>
><br>
</div>> 1. Just stop merging the parent branch back into its parent so<br>
<div class="">> regularly. git diff master... would be the canonical way to<br>
> review. When the feature branch gets merged into master, the<br>
> merge would be larger, so we’d have to put in additional<br>
> effort to make sure that goes smoothly and doesn’t introduce<br>
> bugs.<br>
<br>
</div>I object to this on principal, all things being equal in my experience<br>
it is best to track master as closely as possible to minimize the<br>
disruption when you do merge. Keep in mind it is easy to introduce bugs<br>
if you are going through a big pile of merge conflicts, and the flip<br>
side of the context problem you describe above is that if you are<br>
manually resolving a three way merge conflict it's very helpful to know<br>
why the other change happened. That is more difficult when you have a<br>
pile of unrelated commits being merged, as opposed to a smaller<br>
incremental merge.<br>
<br>
> 1. If we don’t like big merges (very understandable!), where we<br>
<div class="">> currently merge the parent back into feature branches, instead<br>
> we could rebase the feature branch on top of its parent. To do<br>
> this, we’ll have to let ourselves rewrite history on<br>
> <a href="http://git.curoverse.com" target="_blank">git.curoverse.com</a>. This would require more discipline from us,<br>
> but I feel like we already have that, since our rule is that a<br>
> developer owns the branch they make. When you pull someone<br>
> else’s feature branch for review, you’d use git pull -f to get<br>
> the rewritten history. Our process for reviewing and merging<br>
> feature branches would remain the same, and those merges<br>
> should be as straightforward as they are today.<br>
<br>
</div>Rebasing and history rewriting scares me, but that's because I've never<br>
actually used it ;-) Perhaps an example of how this would work in<br>
practice is in order.<br>
<div class=""><br>
> There might be other options too, but I think these would require the<br>
> least disruption to our current workflow. Which is my goal, because I<br>
> generally like our current workflow. I just wish I could understand<br>
> the history better. :)<br>
<br>
</div>I think this is a fair point and we should definitely talk about it some<br>
more.<br>
<br>
- Peter<br>
<br>
<br>
<br>
_______________________________________________<br>
Arvados-dev mailing list<br>
<a href="mailto:Arvados-dev@arvados.org">Arvados-dev@arvados.org</a><br>
<a href="http://lists.arvados.org/mailman/listinfo/arvados-dev" target="_blank">http://lists.arvados.org/mailman/listinfo/arvados-dev</a><br>
</blockquote></div><br></div>