Re: Is there a way to exclude user-specified files or directories from participating in merges?

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 18, 2009, 01:58 UTC
Message-ID: <7vfxic1p6m.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <e38bce640902171732j9b8801gca4223cdb96d2d34@mail.gmail.com>

Brent Goodrick <bgoodr@gmail.com> writes:

Show 9 quoted lines

> Thanks. Well, I should have said in my initial request: "Without
> manually forwarding changes from branch to branch and without having
> to remember special rules about what I can and cannot merge into which
> branch", since that is likely to get forgotten. :)
>
> The answer I am hearing you say is that git doesn't have a way to
> automatically exclude files akin to how rsync handles include/exclude.
>  Is that what you are saying? Or, could the hook mechanism be
> exploited to get this behavior?

A merge is defined as a whole tree operation simply because there is no sane way to support repeated merges (even a single direction merges) otherwise. What I explained was one (note that I am not saying "one true" here) workflow that naturally supports "common version and multiple variants" pattern that logically follows the definition of what a merge is.

I would imagine you could define a custom merge strategy that knows to ignore changes you made to work.sh file when you merge from work to common (and home.sh file when you merge from home to common) to implement what you would want, but for one thing the resulting history would not make sense (e.g. a merge from work to central would appear as if it reverts all the changes work made to certain files). It would be Ok if you were using git as a mere backup+sneakernet medium (in such a case you would not care what the history would show you), but that is not the intended target of git, so there is no such built-in support.

Also such a custom merge strategy would be very project specific and as your project grows and/or as you add more deployments, I suspect its rules will have to become a lot more complicated. I haven't even thought about what should happen in such a merge strategy when you try to merge work to home.

Compared to that, the two simple rules "commit chagnes to generic things only to the generic branch" and "merge only from generic to specific" will not grow as your project grows complexity.