On Tue, Jun 2, 2009 at 7:50 PM, Peter Shenkin <[email protected]> wrote:
>
> On Tue, Jun 2, 2009 at 10:08 AM, Sitaram Chamarty <[email protected]> wrote:
>> your workarounds are possibly too complex. You might want to use "git
>> revert" instead, which would cover case 3 also.
>
> So in other words, in my Release branch, I would put the change that
> is not to be propagated into a commit of its own. This change could be
> the addition or deletion of a file, or a patch to a file.
correct so far
> Then I would merge this change (alone) into the master, then run "git revert".
The "alone" bit is not correct. There is no concept of "merging" a
single commit -- that is called a cherry-pick, which is used when you
really want only one change.
Your situation is that you have a lot of commits on the release branch
which you want to go to master, *except* just one. So you will do a
merge.
A "merge" has to, and will, get *all* the commits in the branch being
merged, which do not already exist in the destination (current)
branch.
This means the commit you *don't* want also will come in.
> Since "git revert" does a new commit after the reversion, the Release
> changes would not be propagated into the master even in future merges.
yes but the reason is not what you seem to think it is.
Let me try and illustrate.
Please make sure your mail reader show monospace fonts correctly, or
copy-paste the following into a plain text editor to view it properly.
You are at this stage:
---a---b---c---d---e <== master
\
\-i---j---k---l <== release
You want to merge release into master, except commit "k", so you
git checkout master
git merge release
and get a new merge commit called M.
---a---b---c---d---e---M
\ /
\-p---q---r---s-/
Now you add a revert for "r", to get "ri" (r-inverse):
git revert SHA_of_commit_r
---a---b---c---d---e---M---ri
\ /
\-p---q---r---s-/
Time passes...
---a---b---c---d---e---M---ri---f---g
\ /
\-p---q---r---s-/--t---u---v---w
Now you want to merge Release into master again, so you do exactly the same
thing again (git checkout master; git merge release) and get this:
---a---b---c---d---e---M---ri---f---g---N
\ / /
\-p---q---r---s-/--t---u---v---w--/
This is where git's "merge tracking" comes in. When you merge the release
branch into master, it will pick up *all* the commits which exist in release,
but do *not* exist in master.
This means t, u, v, w. It does *not* mean p/q/r/s, because they already exist
in master (due to commit M).
I hope that explains...
One caveat with this is that, should any future change in Release
depend on the commit "r" in some sense, then when *that* is merged
into master, you'll have a conflict which you will need to manually
resolve. For example, if commit "r" introduced a new function that
does not pertain to master (and that is why you don't want it in
master), and a few commit on the release branch introduces a change in
this function, then that commit will cause a conflict when applying.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"GitHub" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/github?hl=en
-~----------~----~----~----~------~----~------~--~---
