Andy Parkins <andyparkins@xxxxxxxxx> writes:
> On Wednesday 2007, June 13, David Watson wrote:
>> I've got a problem, or maybe annoyance is more the proper term, that
>> I haven't seen solved by any SCM system (at least not to my
>> knowledge). Basically, I may make some changes, e.g. to a Makefile or
>> somesuch, that I want to ignore when looking at what's changed from
>
> So you want to tell git to track a file and then have it not track
> changes to that file? Sounds crazy to me. Don't put files in the
> repository that you don't want tracking.
Actually, that is a sign that either the upstream project is
broken, and/or the user's workflow is broken.
Taking an example closer to home, if we tell tell users "in
config.mk file you can suit your local needs" and at the same
time add config.mk to the official repository, that would be
crazy. The changes to that file is _supposed_ to be local and
the other side will never be interested in getting updates to
that file. So if David is dealing with such a situation, then
the problem is in the project organization.
On the other hand, it is usual to see a comment in the Makefile
that says "# No user tweakable part below this line", with
expectations that users will muck with make variable definitions
in the earlier parts of the Makefile to suit the local
filesystem layout and such.
The changes users will make to such a file fall into one of two
categories:
(1) Local configuration changes to adjust to the user's
particular installation.
(2) Fixes, improvements and enhancements to the generic part
("below that line").
Other people, especially the "upstream" people, are never
interested in ever seeing patches of the former kind, while the
latter are of general use and you would want to feed themback.
You would need to separete out these two kinds at SOME stage
when you need to make changes of both kinds. You can do that at
patch submission time, cleaning up the series, if you are
feeding the changes via patches.
If you are communicating with the other side via pull/push, then
you would need to have two histories that cleanly separates the
two. Probably a good workflow is:
- The tracking branch remotes/origin/master; this holds what is
'pristine';
- Keep 'master' branch for only the changes for general
consumption.
- Have a separate 'local' branch, that is forked from 'master'
branch of yours. Local configuration changes will go to this
branch, never to 'master'.
You would never publish 'local' as it contains the local
configuration changes that are of no interest to others, but the
changes you may want to give back to outside will be readily
available in 'master'.
If I _were_ doing this, I would further use a topic branch that
forked from pristine to hold only the local changes, and use
'local' only as an integration branch between that local
configuration topic and 'master' (i.e. no commits will be made
to 'local' directly -- everything will come from either separate
topics or 'master').
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
