<div class="gmail_quote"><div>David,</div><div><br></div><div>A few comments.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Naming Upstream<br>
---------------<br>
<br>
The intial clone from upstream results in a git remote reference with<br>
the rather unhelpful name of "origin."  As more remote sources get<br>
added, it is easy to forget what "origin" is.  Therefore, add a remote<br>
with a more descriptive name.<br>
<br>
git remote add llvm-upstream <a href="http://llvm.org/git/llvm.git" target="_blank">http://llvm.org/git/llvm.git</a> master<br>
<br></blockquote><div><br></div><div>If the intent is to rename origin, this can be done directly:</div><div>  git remote rename origin llvm-upstream</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Updating LLVM - no local changes<br>
--------------------------------<br>
<br></blockquote><div><br></div><div>Splitting this into "no local changes" / "with local changes" seems unnecessarily complicated. Why not just recommend doing 'git pull --rebase' all of the time?</div>
<div><br></div><div>I have to ask as well - is a linear history really desired? That seems to be the intent of your instructions.</div><div><br></div><div>I ask because for something like a reasonably sized feature that might have multiple commits, having the merge history in place can be useful, if only to separate the set of related changes from sets of unrelated changes. It also aids in reverting an entire feature composed of multiple commits.</div>
<div><br></div><div>One other comment - the way I use git (and from what I've read I am not alone), I end up committing multiple times per hour / many times per day, often into different branches. I then go back and use rebase to reorder and squash commits into logically related bite-sized chunks (e.g. combine some commits related to feature A into one or more commits, some related to feature B into one or more commits, and then there might be three bug fix commits for bugs C, D, and E.). It might be helpful to add some guidelines related to this that are in line with current LLVM review process - somewhat the reverse scenario of someone asking for commits to be split. In this case, they probably don't want to see 15 different commits that in total add 75 lines of code to feature A.</div>
<div><br></div><div>Mark</div><div><br></div></div>