[LLVMdev] git Status

[Matthieu Moy]

Mark Lacey <641 at rudkx.com> writes:

> David,
>
> A few comments.
>  
>
>     Naming Upstream
>     ---------------
>    
>     The intial clone from upstream results in a git remote reference with
>     the rather unhelpful name of "origin."  As more remote sources get
>     added, it is easy to forget what "origin" is.  Therefore, add a remote
>     with a more descriptive name.
>    
>     git remote add llvm-upstream http://llvm.org/git/llvm.git master
>
> If the intent is to rename origin, this can be done directly:
>   git remote rename origin llvm-upstream

or simpler, do it at clone time:

  git clone --origin llvm-upstream

Note that git clone does not only set a remote, it also sets it as
"upstream" for the master branch, i.e. "git pull" without argument will
fetch from origin. Adding a new remote will not do that (but one can use
the --set-upstream option of various commands to fix that later).

That said, I don't think it's a good idea to ask users to rename their
upstream in a guideline document. Naming upstream is personnal
preference, and keeping the default seems sane for most users. If you
don't remember what "origin" is, then .git/config can remind you.

>     Updating LLVM - no local changes
>     --------------------------------
>
> Splitting this into "no local changes" / "with local changes" seems
> unnecessarily complicated. Why not just recommend doing 'git pull
> --rebase' all of the time?

I'd also recommand "git pull --rebase" if the goal is to keep history
linear. Note that this has to go with a big, fat, warning, telling the
user that rebasing published history is bad. Rebase is a very good tool
to work with private history, but as soon as you've pushed it to some
place visible by other people, you should stop using it.

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

Rebase is exactly meant to do this separation, and avoid history looking
like

- start working on feature
- merge from upstream
- continue working on feature
- merge again from upstream
...

and remove the useless "merge from upstream" commits, that would just
distract reviewers. Keeping merge history when merging several clean,
published branches is good though.

If you look at how Git itself is developped, people use rebase a lot to
send clean patch series, and the maintainer uses merge a lot to merge
multiple patch series together.

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