aaargh! for i-j-k-l read p-q-r-s in the first diagram below! And the commit you don't want is "r" not "k".
Sorry :) On Tue, Jun 2, 2009 at 10:17 PM, Sitaram Chamarty <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
