<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> I have to ask as well - is a linear history really desired? That seems<br>

> to be the intent of your instructions.<br>
<br>
</div>It is a stated requirement of the project.<br></blockquote><div><br></div><div>Thanks - I hadn't seen that stated explicitly. I understand the points you and others make wrt rebase vs. merging - I've seen many of the arguments before. I tend to rebase a lot since I tend to not be publishing and collaborating on feature branches (so I don't have the merges from mainline to feature branch, even if the feature branch stays around). </div>
<div><br></div><div>As for 'git pull' vs. 'git fetch / git merge' - since this advice really seems aimed at beginners, you might want to suggest 'git pull --ff-only' or perhaps even go as far as suggesting 'git config merge.ff only' to absolutely enforce linear history (setting the latter would be problematic of course for people who want to create feature branches and merge, etc. prior to doing some final rebase and submitting patches).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Reverting is just as easy with linear history, I think.  Chris has</div>
stated her wants reviews to be a simple as possible and linear history<br>
gets us that.<br></blockquote><div><br></div><div>Reverting using 'git revert' when you have a separate branch that is merged in requires a single revert of the merge commit, rather than reverting the individual commits that make up the feature.</div>
<div><br></div><div>I don't see how having branches increases complexity of reviews - as long as the submitted patches are rebased on top of the mainline, you still have the appearance of linear history from the reviewers POV, but maintain a separate branch that can be committed.</div>
<div><br></div><div>Mark</div></div>