Re: Contributor Guide "volunteers" needed

[Maximilian Albert]

2009/1/18 Graham Percival <address@hidden>:

> I've had problems with just "git pull"...
>
>> This only applies if there are no local changes, though.
>
> ... ah, for precisely for this reason.  :)
>
>> In case there are, then issuing
>> either command produces a merge commit so that the commit graph now
>> looks like this:
>>
>>   * master after merging
>>   |\
>>   | \
>>   |  \
>>   * * remotes/origin/master (on the right)
>>    \ |
>>     \|
>>      *
>>      |
>>
>> I'm not sure if this constellation can cause problems when producing
>> patches. It seems that the command "git-format-patch origin" works
>> fine, though (Rainer, thanks for pointing out that this should be the
>> correct command).
>
> See, I've been using git for a few years now, and I only barely
> understand what you're talking about.  (not because I'm an idiot;
> just because I've never been willing to put any time or effort
> towards learning any git theory.  If I can use it like cvs --
> checkout, add, commit, update -- then I'm happy)

Honestly, I feel like anything else than a git expert. Anyway,
probably my ASCII-arts above are not very clear. Perhaps this better
illustrates what I mean.

1) Start with a repository where master and remotes/origin/master are
identical (if they are not, you can say
     git-checkout -b test remotes/origin/master
to create a branch called 'test'; in this case, replace 'master' with
'test' everywhere in the following steps).
2)   git-reset --hard HEAD^
This discards the most recent commit on master so that master and
remotes/origin/master now differ by precisely one commit.
3) Do a simple change in one of the files (e.g., add a line or
something - doesn't really matter).
4)   git-commit -a -m "Test commit on master"
5)   git pull (or "git pull origin", I suppose they work identically)
--> this creates the merge commit
6) Fire up gitk and look at the commit graph; it should look similar
to what I tried to mimic in my ASCII arts.

On the other hand, if you do the following instead:

1) - 4) as above
5) git-checkout remotes/origin/master
6) git pull
7) git-rebase remotes/origin/master master

then you will see in gitk that master now sits nicely "on top of"
remotes/origin/master. That's what I meant when I said "linear
history".

But as mentioned, I don't suppose there is any difference between the
two methods as far as git-format-patch is concerned. However, I don't
know whether git-format-patch gets confused when the user makes
several commits with several pulls in between as in the first method
above.

Hmm, I just saw that that the second method gives a warning in step 5)
saying that remotes/origin/master is not a local branch (well,
obviously) and explaining how to create one if desired. I don't know
if this will confuse newcomers.

>>    git-checkout remotes/origin/master
>>    git-pull
>>    git-rebase remotes/origin/master master
>>
>> This produces a linear history, which I personally find "cleaner". :-)
>> But I suppose that "git-format-patch origin" does the right thing in
>> both situations. I don't know what you prefer to be included in the
>> CG.
>
> Mao.  I'm totally lost now.

See above. I hope it made things a bit clearer.

Max