[LLVMdev] git Status

[David A. Greene]

Mark Lacey <641 at rudkx.com> writes:

>     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

Much better.  Thanks.

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

Actually git pull can sometimes get you into trouble.  Probably git
fetch / git rebase is the better combination for LLVM.  I agree my
distinction is artificial but for the users who simply want the most
up-to-date LLVM, git pull is simpler.  I certainly debated back a forth.
I have no problem reworking this.

> I have to ask as well - is a linear history really desired? That seems
> to be the intent of your instructions.

It is a stated requirement of the project.

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

Reverting is just as easy with linear history, I think.  Chris has
stated her wants reviews to be a simple as possible and linear history
gets us that.

There are some more interesting points made here:

http://randyfay.com/node/91

Here's an interesting article with a proposal on how to get the best of
both:

http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html

The follow-up linked at the bottom explains how it mgiht be implement.
It requires changes to git, however.  Personally, I kind of like the
ideas presented but I doubt it will happen any time soon.

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

That makes sense.  I briefly mentioned squashing in the rebase -i
explanation but I can expand on that.

Thanks for your feedback!

                         -Dave