Jeff King <peff@xxxxxxxx> writes:
> So yeah, if you are just going to copy it once, or even periodically, it
> is not that big an advantage. And the example I gave using "git tag" did
> just that. But I also wanted to allow more complex things, like this:
>
> # clone and inspect
> git clone git://example.com/project.git
> cd project
> git show origin:devtools/std_gitconfig
>
> # well, that looks pretty good. But I'd like to tweak something.
> git checkout -b config origin
> $EDITOR devtools/std_gitconfig
> git commit -a -m "drop the foo option, which I hate"
>
> # OK, let's use it now.
> git config include.ref config:devtools/std_gitconfig
>
> # Weeks pass. Somebody else updates the std_gitconfig.
> git fetch
> # let's inspect the changes
> git checkout config
> git diff @{u} -- devtools/std_gitconfig
> # looks good, let's merge (not copy!) them in
> git merge @{u}
>
> This is obviously an advanced thing to be doing.
The "which *I* hate" in the log message makes it sound as if it is a
personal preference, but in fact this is more about maintaining the
recommended configuration among participants, no? And if you have the
source of the configuration on a branch so that people can work on it
among themselves, then "config.path = ../devtools/std_gitconfig" should be
sufficient, no?
The pros-and-cons between the volume of the change to read include from
blobs and the benefit illustrated in the use case did not look too good to
me, at least from the messages in this thread so far.
--
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