2009/1/18 Graham Percival <gra...@percival-music.ca>:
> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
