Re: [PATCH] ls-tree: add --full-tree option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Sixt <j6t@xxxxxxxx> writes:

> I'm saying that if a script has to be fixed to use --full-tree, then
> it can be fixed just as well by appending the colon to the ${rev}.

I do not agree with your "just as well"; an existing script that feeds a
tree object to the plumbing would be broken by such a change.

But I think perhaps you were responding to the first paragraph of the
commit log message that you omitted from your quote?

JC> The established behaviour of "git ls-tree $commit" run from a
JC> subdirectory "sub/dir" in a work tree is to...

If that is the case, I understand what you meant.

The patch is about the behaviour of the command for not just $commit but
any $tree_ish, so "git ls-tree ${commit}:" shares the exact same issue
(i.e. historical background that forbids us from changing the behaviour
without an explicit option, and that --full-tree can be a way to help new
scripts without breaking existing scripts' expectations).

I've updated the commit log message with s/$commit/$tree_ish/;

> OTOH, you had yourself argued somewhat in favor of the current ls-tree
> behavior:
>
> http://thread.gmane.org/gmane.comp.version-control.git/46232/focus=46400

That's not really "somewhat in favor".  I can be (and am more often than
not) sympathetic without agreeing to the end result. My sympathy extends
from "I can sort-of-kind-of imagine that it may hurt, and even though I do
not think your approach is a way to properly address it at all, I'd agree
it might be nice to have some solution to the issue" to "I do not think it
is feasible to change this anymore, but I wish we could, too."

In any case, the quoted message was from May 2007, way before v1.6.0 when
we learned the hard way that people do not want any change.

I really hate "take it or leave it", especially when it is not my itch to
scratch, but in this case, I think I've spent enough time making myself
clear that I think (1) that the current behaviour is a result of misguided
attempt for interactive user expectation, which shouldn't have made to the
plumbing, (2) that we cannot change the default behaviour now even (1) is
true; and (3) that the only possible approach to help new scripts would be
a new option.
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux