[LLVMdev] git Status

Matthieu Moy Matthieu.Moy at grenoble-inp.fr
Tue Aug 23 00:44:07 PDT 2011


greened at obbligato.org (David A. Greene) writes:

> Updating LLVM - no local changes
> --------------------------------
>
> To update your clone to the latest LLVM sources, use git pull:
>
> git pull llvm-upstream

That should probably be either

  git pull

or

  git pull llvm-upstream master

since the first is shorter and works if llvm-upstream is the upstream
for the current branch, and "git pull llvm-upstream" will ask for a
branch name if it isn't.

> git cherry-pick 44ef3
> git cherry-pick afe3d
>
> The dag looks like this:
>
> ...-A---E-F{master}[HEAD]
>      \ / /
>       B-C-D{ifconvert}

Err, no. cherry-pick won't record B and C as parents.

A common convention would be to call E and F as B' and C' to reflect the
fact that they are different, but similar to B and C.

Also, if you are to draw DAGs in your explanations (which is good), you
should mention gitk and/or git log --oneline --graph so that users can
experiment by themselves.

> git rebase llvm-upstream/master
>
> There may be conflicts from this operation.  If so, resolve them in
> the usual way.

... and use "git rebase --continue" as needed.

Perhaps point to git-rebase(1) for more details.

> Now our history looks like this:
>
> ...-A-----G-H-I-E'-F'{master}[HEAD]
>      \   /
>       B-C-D{ifconvert}

I don't get it. B and C were local commits, and you didn't explain the
user how to push them, so they're still local. As I Understand It, G and
H are the remote commits you've just fetched, so G cannot have C as
parent.

You probably wanted to show this history after fetch

      G-H{llvm-uptream}
     /
...-A--E-F{master}[HEAD]

and this one after rebase

...-A-G-H-E'-F'{master}[HEAD]
    
> git format-patch -o $HOME/patches/ifconvert --thread --src-prefix=old/ \
>                  --dst-prefix=new/ --cover-letter HEAD~1..HEAD

I usually use git send-email right away, it can call format-patch in
modern Gits.

> Edit these files to add any commentary you desire.

... comments that are not meant to appear in the commit message should
be added after the --- and before the diffstat in the patches.

?

> [format]
>         numbered = auto
>         thread = shallow

these are the default, so better not annoy new users with them.

> git rebase -i HEAD~2

I usually do

git rebase -i origin/master

or in this case

git rebase -i llvm-upstream/master

which has the advantage of offering me to edit local commits, and only
them. I cannot rewrite upstream history by mistake (which would lead to
weird things afterwards).

> In this case, let's say that the second commit needs some work.  We
> edit the control file to do that:
>
>   pick ef723 Start if conversion work
>   edit 443de Middle of if conversion work, something interesting to commit

It's not the best example: rebase is not needed at all to edit the last
commit. You should edit the first to make the example more relevant.

> git reset --soft HEAD^

> git commit -a -c ORIG_HEAD

That seems to be a rather complex and potentially dangerous way of
saying

git commit --amend

> git reset --mixed HEAD^
>
> Your files are left in the "untracked files" 

... or "changed, but not staged for commit"

> state

> Now commit:
>
> git push llvm-upstream master

"Now commit" is confusing. If you talk to former SVN users, you can say
"now, do the equivalent of svn commit", and otherwise, "Now, send your
changes to the upstream repository".

My 2 (perhaps 3?) cents,

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/



More information about the llvm-dev mailing list