From: Boaz Harrosh <bharrosh@panasas.com>
To: skillzero@gmail.com
Cc: git@vger.kernel.org
Subject: Re: git merge and cherry-pick and duplicated commits?
Date: Wed, 14 Jan 2009 10:38:40 +0200 [thread overview]
Message-ID: <496DA490.5020708@panasas.com> (raw)
In-Reply-To: <2729632a0901140008r59e429aeq3ce367e1bc7df71@mail.gmail.com>
skillzero@gmail.com wrote:
> On Tue, Jan 13, 2009 at 11:34 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>
>> Well, the way to do it is "careful planning".
>>
>> If you have a *slight* suspicion that some change *might* be needed on a
>> different branch, then:
>>
>> 1. you commit the change on a branch of its own that forks off of the
>> merge-base of *all* the branches that *might* need it;
>>
>> 2. next, you merge this fix-up branch into the branch where you need it
>> first, which is very likely your current topic-under-development.
>>
>> 3. Later you can merge the branch into the other branches if you find that
>> it is really needed.
>
> If I create a separate bug-fix-only branch X that forks from the
> latest common commit of all the branches that might need it and some
> of those branches already have commits after that merge base (e.g.
> branch Z is 5 commits after the common merge base by the time I fix
> the bug), will git be able to merge the new branch X into Z in a way
> that will allow me to also merge branch X into my original feature
> branch A and then later merge A into Z without duplicating the commit
> that is now in both branch X and Z?
>
> It seems like I'd run into my original duplicate commit problem
> because even though branch X was originally based off the same parent
> commit, it will have a different parent when it is merged into Z
> because Z is no longer at that common merge commit (it's 5 commits
> beyond it).
> --
No, if you use merges it will not duplicate. It will know exactly what
to do because it is the same commit in all branches.
Only git-cherry-pick will duplicate the same patch, but as a different
new commit. Then when merging the merge sees a merge conflict but since
it is exactly the same change it will accept it. The same happens if
two different patches have exact same hunk, the merge is smart to accept
the same change from two sources. What happen with cherry-pick is that all
the hunks match.
Boaz
next prev parent reply other threads:[~2009-01-14 8:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-14 2:40 git merge and cherry-pick and duplicated commits? skillzero
2009-01-14 5:31 ` Brian Gernhardt
2009-01-14 6:21 ` skillzero
2009-01-14 7:34 ` Johannes Sixt
2009-01-14 8:08 ` skillzero
2009-01-14 8:34 ` Johannes Sixt
2009-01-14 18:33 ` skillzero
2009-01-14 19:40 ` Peter Baumann
2009-01-14 20:16 ` Junio C Hamano
2009-01-15 23:09 ` Markus Heidelberg
2009-01-14 8:38 ` Boaz Harrosh [this message]
2009-01-14 8:41 ` Thomas Rast
2009-01-14 13:47 ` Alex Riesen
2009-01-14 7:33 ` skillzero
2009-01-14 15:53 ` Sitaram Chamarty
2009-01-14 8:31 ` Nanako Shiraishi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=496DA490.5020708@panasas.com \
--to=bharrosh@panasas.com \
--cc=git@vger.kernel.org \
--cc=skillzero@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).