[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Git: to merge or not to merge.

From: Francisco Vila
Subject: Re: Git: to merge or not to merge.
Date: Mon, 27 Oct 2008 12:03:49 +0100

2008/10/27 Trevor Daniels <address@hidden>:
>> Sometimes there is another commit in between and therefore I cannot
>> fast forward, but I deal with it by preparing a patch, resetting, and
>> applying it afterwards.
> I think cherry-pick will do this for you automatically, and
> with less effort if you use gitk.

Thank you Trevor, could you show me an example?
Suppose I'd have the two branches freshly pulled, and I wanted to
update a file after some changes in master.

I could: merge master, update my file, edit the committish of that
file to the merge commit, and push.
Or, I could first update my file, the merge master, then edit the
committish, then push. This makes the time in between shorter and
that's what I usually do. How does cherry-pick apply here?

Oh, I know this is not very lilypond-specific...
Francisco Vila. Badajoz (Spain)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]