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

[Junio C Hamano <gitster@pobox.com>]

Brent Goodrick <bgoodr@gmail.com> writes:

> Suppose I create a git repo called central.git on a machine I will
> call "central". In that central.git repo, I put these files:
>
>   work.sh
>   home.sh
>   generic.sh
>
> When I clone the central.git repo on to a different machine I will
> call "work", I want this fileset to be pulled:
>
>   work.sh
>   generic.sh
>
> But not the home.sh file.

You would have one common branch and one branch per deployment.

A common branch would host only common files (e.g. generic.sh file from
your example).  Per deployment branch, e.g. home, would branch from the
common branch (so it starts with some version of generic.sh) and may add
its own private files (e.g. home.sh).

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.