On 08/22/2011 09:37 PM, David A. Greene wrote:> FlyLanguage<flylanguage at gmail.com> writes:
>
>> > 2) Nobody writing up how git should be used with the current llvm
>> > workflow (which is not going to adapt to an SCM, but the other
way
>> > around, which is understandable.)
> Here is a first cut at that. Other git users, please chime in with
> suggestions, edits, etc. Non-git users, please ask for clarification
> where needed. This is based on my notes on working with LLVM via
> git-svn, modified to assume native git. There are hundreds of ways to
> design a workflow that works with the current review process. This is
> but one.
>
> We should add this to the web page once it's polished if we make the
> transition to git.
>
> -Dave
Hi Dave,
thanks a lot. This already reads very nice. Two smaller
comments:> Sending Patches for Review
> --------------------------
>
> git includes a whole set of tools for managing the patch review
> process. We kick things off with git format-patch:
>
> git format-patch -o $HOME/patches/ifconvert --thread --src-prefix=old/ \
> --dst-prefix=new/ --cover-letter HEAD~1..HEAD
I personally dislike typing all the time such a long command line. Maybe
you can also point out, how to configure this in .git/config.
> This places three text files in $HOME/patches/ifconvert, one for each
> commit, plus a cover letter to send before each patch. These will get
> sent to the e-mail list with the subject "[PATCH n/2]<commit
> subject>" where "n" is the patch number (0 for the cover
letter) and
> <commit subject> is the first line of the commit message.
>
> Edit these files to add any commentary you desire.
>
> It is helpful for format-patch and send-email to have various bits of
> information pre-selected for e-mail interaction. For example, I put
> this in my .git/config file in the local repository:
>
> [format]
> numbered = auto
> to =llvm-commits at cs.uiuc.edu
> inline = "---------"
I believe the current policy is not to inline patches, but to attach
them. I believe we should keep following this policy to reduce the
changes of this transition.
> Updating Patches
> ----------------
>
> Your patches will probably require some editing. git rebase -i and
> git add -i are your friends.
>
> For the typical case of editing your patches a bit, use git rebase -i:
>
> git rebase -i HEAD~2
>
> This brings up an editor with a document that looks something like
> this:
>
> pick ef723 Start if conversion work
> pick 443de Middle of if conversion work, something interesting to commit
>
> This is a control file you edit to state how git-rebase should work.
> There are essentially three commands pick, edit and squash.
You missed the one I use most: 'fixup'. I use a different approach to
edit patches. Here the text, feel free to add parts of it or to ignore
it for the sake of simplicity.
-------------------
For the typical case of editing your patches a bit, use git rebase -i:
Let's assume you have the following two patches in your queue:
$ git log --oneline
ef723 Start if conversion work
443de Middle of if conversion work, something interesting to commit
To fix some problems with commit 'Start if conversion work', add your
fixes directly to the working copy and commit them as new changeset
'Fixes for: Start if conversion work'.
Now we call
$ git rebase -i HEAD~2
This gives us the following text file:
pick ef723 Start if conversion work
pick 443de Middle of if conversion work, something interesting to commit
pick 33ed3 Fixes for: Start if conversion work
Here, we move the fixup right after the commit to fix and replace the
default action 'pick' by the comment 'fixup'.
pick ef723 Start if conversion work
fixup 33ed3 Fixes for: Start if conversion work
pick 443de Middle of if conversion work, something interesting to commit
By saving and closing this file, the patches will be merged and
there will be a new history.
sdd24 Start if conversion work
eba32 Middle of if conversion work, something interesting to commit
Commit sdd24 now contains the changes of both ef723 and 443de. In case
you want to edit the commit message of the commit to fix, you can also
use 'squash' instead of 'fixup'.
---------------------------
Cheers
Tobi