Re: [PATCH] Documentation: add a planning document for the next CLI revamp

From: Jeff King <peff@peff.net>
Date: Nov 3, 2008, 06:56 UTC
Message-ID: <20081103065636.GB10772@coredump.intra.peff.net>
In-Reply-To: <7v3ai9226q.fsf@gitster.siamese.dyndns.org>

On Sun, Nov 02, 2008 at 02:27:57PM -0800, Junio C Hamano wrote:

Show 9 quoted lines

> >> +  * '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.

Show 9 quoted lines

> 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