On Sun, Nov 02, 2008 at 02:27:57PM -0800, Junio C Hamano wrote:
> >> + * 'git push --matching' does what 'git push' does today (without
> >> + explicit configuration)
> >
> > I think this is reasonable even without other changes, just to override
> > any configuration.
>
> I don't. Can't you say "git push $there HEAD" these days? I vaguely
> recall that there is a way to configure push that way for people too lazy
> to type "origin HEAD" after "git push".
I think you are reading more into my statement than I intended. I meant
that adding an explicit --matching was reasonable, _even if it matches
the default_. I can think of two reasons:
1. Even if it is a no-op, it is more explicit for showing newbies what
is going on. And it also means that _if_ we wanted to introduce
new behavior or configurability, we will have already had
"--matching" for some time. So it will be safe(r) at that point to
immediately start saying "--matching" in your scripts to specify the
behavior you want, without as much worry about confusing an older
version.
2. Even today, the behavior of push can be modified with configuration
in remote.*.mirror. I would expect "git push --matching" to override
this. Though perhaps that is too confusing a behavior, as mirroring
does more than just ref selection, including force-updating.
So my statement was not anything about "git push $there HEAD", but just
that adding "--matching" was reasonable.
> I think I was neutral in the discussion that led to the removal of
> "git-export", but the rationale IIRC was exactly because "git-export" can
> be done by simply piping "git-tar" to tar. On the other hand, if all you
> had was "export" and you wanted to create a release tar/zip ball, you have
> to first create a (potentially huge) hierarchy in the filesystem only to
> archive it. This change needs to defend that the benefit of being able to
> create a new non-git checkout elsewhere on the filesystem far outweighs
> the downside of addition of another command (i.e. "eek, why does git have
> that many commands" from new people).
I think the complaint is just that it is awkward to have to pipe to tar
(and harder to check error status), when "export to directory" is a
reasonably common request.
If the concern is about another command, then perhaps rather than "git
export" it would be simpler to have "git archive --format=dir" as a
convenience (and it could even use the checkout-index optimization in
the local case, rather than generating a tar).
-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
