<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 31, 2015 at 5:20 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Mark Adams <<a href="mailto:mfadams@lbl.gov">mfadams@lbl.gov</a>> writes:<br>
<br>
> I see, I forgot to pull.<br>
><br>
> These were trivial changes:  changed a variable name (that is a key word)<br>
> and fixed a test that did not compile anymore so I did it directly on<br>
> master.<br>
</span> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The commit messages says "demonstrates a bug".  Is there a bug?  </blockquote><div><br></div><div>There was and Barry fixed it (DMCompositeGetAccess on read only vector) <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What is<br>
it?<br>
<br>
<br>
As for non-fast-forward merges, Junio just published a blog post<br>
explaining the rationale for maintaining first-parent history and the<br>
way to gracefully retry in case of racy integration.  (His advice is the<br>
same as ours.)  He also mentions discussion of a "git rebase<br>
--first-parent" feature that would make this process easier.<br>
<br>
<a href="http://git-blame.blogspot.com/2015/03/fun-with-non-fast-forward.html" target="_blank">http://git-blame.blogspot.com/2015/03/fun-with-non-fast-forward.html</a><br>
</blockquote></div><br></div><div class="gmail_extra">Yes, I knew that my work was not going to conflict but I should pull to keep the history clean.<br><br></div><div class="gmail_extra"><br></div></div>