[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)
http://www.paconet.org