[LLVMdev] git Status

[David A. Greene]

Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes:

> 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.

Good catch.

>> 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.

Ok.  This was all written on-the-fly.

> 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.

Ok.

> 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.

Good idea.

>> 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.

Ok.  I made the assumption that man pages would be a resource.  I'll
make that explicit.

>> 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.

Yep.  That was a graph rewrite error.

> 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]

Ah.  Good idea!

>> 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.

Yeah, I debated about that.  I like to look at the e-mail files before I
send them.  I think send-email will let you do that and it's less
confusing.  I'll rewrite this part.

>> 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.
>
> ?

Ok, I'll note that.

>> [format]
>>         numbered = auto
>>         thread = shallow
>
> these are the default, so better not annoy new users with them.

Ok.

>> 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).

Ah, good idea.  I'll change this.

>> 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.

Ok.

>> 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

Yep.

>> git reset --mixed HEAD^
>>
>> Your files are left in the "untracked files" 
>
> ... or "changed, but not staged for commit"

Fixed.

>> 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".

Ah, good catch.

Thanks!

                            -Dave