From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Wed, 18 Feb 2009 13:33:45 GMT
Subject: Re: Is there a way to exclude user-specified files or directories from participating in merges?
Message-ID: <slrngpo3hp.boq.sitaramc@sitaramc.homelinux.net>
In-Reply-To: <7v1vtw367w.fsf@gitster.siamese.dyndns.org>

On 2009-02-18, Junio C Hamano <gitster@pobox.com> wrote:
> And stick to the following two rules:
>
>  - You make edits to common files only on the common branch.
>  - You merge from common to deployment, never the other way.
>
> So at work, you would have a checkout of your work "deployment branch",
> and find needs to change things.  It is Ok to edit both work.sh and
> generic.sh (without being able to edit both, it would be hard to verify if
> the changes would work together) at this time, but don't commit the result
> in the work branch.
>
> Save the changes to work.sh away (e.g. "git diff work.sh >P.diff" and then
> "git checkout HEAD work.sh"), switch to the common branch, and commit the
> changes to the generic file.  Switch back to the deployment branch, merge
> the common branch (to pick up the changes to home.sh), reapply the changes
> specific to the deployment you saved earlier (e.g. "git apply P.diff"),
> tne commit the result.

[I did read your followup also; my question applies to both
versions of the technique]

Let me explain where I'm coming from: this is very often
needed when you maintain customer specific branches, and the
workflows in both your posts in this thread so far are too
complex for, err, me <sheepish grin> :-)

Would it not be easier to do something like this?  (I suck
at 2-d drawing, even line... but this should still be
understandable)

(W = work, T = temporary, C = common)

  - make granular commits and test etc, from W to T

        O---a---b+1---c---2---d---3
        W is pointing at commit O
        T is pointing at commit 3
        b+1 is a commit that contains both types of changes

  - use rebase -i (including split commits if needed, as
    described in 'git help rebase') to put all the changes
    that go to master before the ones that only go to work.

        O---a---b---c---d---1---2---3

  - (retest if needed)

  - cherry pick the first set of changes to common (in this
    example, a, b, c, d will become a', etc on common)

  - merge from common to work (x, y, etc are some other
    changes that went into common since the last time you
    merged)

        O---x---y---a'---b'---c'---d'
        W is now pointing at d'

  - cherry pick the stuff that remains

        O---x---y---a'---b'---c'---d'---1'---2'---3'
        W is now pointing at 3'