On Thu, Jan 26, 2012 at 04:35:59PM -0800, Junio C Hamano wrote:
> 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?
No, I meant it explicitly to be about this single user hating it. Note
how the resulting commits are never pushed. It is purely a local
override, but with the added bonus that history is tracked so you can
merge in further changes from upstream.
Of course, you could also share it with others, or do whatever. Once
it's tracked by git, you can be as flexible as you like.
> 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?
Yes, you _could_ just keep it in a branch, merge upstream's changes into
the branch, and then periodically copy it out to your .git directory.
But this removes that final step.
It also does allow "[include]ref = origin/meta:gitconfig" if you want to
live dangerously. I consider that a feature, because it lets the user
make the security tradeoff they deem appropriate. Yes, I want to have
git be secure by default, and yes I want to encourage awareness of the
issues in the documentation for the feature. But I suspect in practice
that many people fetch changes and run "make" without looking at them,
which is basically the exact same hole. If a user has already accepted
that risk, why deny them the convenience of accepting it somewhere else?
> 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.
I didn't think the read-from-blob code was very big or complex (most of
the refactoring was to support parsing an arbitrary buffer, but I think
that may be a good thing to have in the long run, anyway).
But I guess that is all a matter of opinion.
-Peff
--
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