Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Junio C Hamano <junkio@cox.net>]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> On Friday 12 January 2007 21:56, Junio C Hamano wrote:
>> This updates five commands (merge, pull, rebase, revert and cherry-pick)
>> so that they can be started from a subdirectory.
>> 
>> This may not actually be what we want to do.  These commands are
>> inherently whole-tree operations,...
>
> Why not add a general "--top" option to the "git" wrapper,
> to temporarily let git change to the toplevel while running
> the command?
>
> The wish to allow git-fetch from subdirectories is the
> inconvenience to have to cd up, and later down. This is
> avoided by running "git --top fetch", and theses people
> should be happy.

Well, git-fetch does not have anything to do with the working
tree, so it does not matter if you run from a subdirectory.  You
do not even need --top for it (and you don't with v1.5.0-rc1).

If we replace "git-fetch" in what you said with one of the
commands I listed in the message you quoted, what you said
becomes at least internally consistent.  But I do not
necessarily agree with it.

Adding --top and refusing to work without the option gives a
false impression that it is a bug that they do not work from the
top in the current implementation, and someday we might do these
commands limited to the current directory when the user is in a
subdirectory.  But for the above commands, it is definitely not
the case.  They are inherently whole-tree operations and it
ould actually be a bug to limit their operation to a single
subdirectory.

For example, what would a "merge" limited to the current
directory do?  It would probably do the usual 3-way merge for
the current directory and apply the 'ours' strategy for the rest
of the tree.

But that is obviously wrong.  The new commit claims that "I
considered the whole tree states these two commits record, and
came up with this another whole tree this commit records -- it
suits my purpose better than either of these other two trees".
Future merges that involve the resulting commit will take this
statement into account, and will revert the changes the other
branch would have brought in outside the current directory if
your merge result is later merged into somebody else's tree.

Rebasing a series of commits on top of some other branch, but
limiting only to the current directory does not make much sense,
either; it would lose the changes to the other parts of the
tree.  Losing the changes to the other parts of the tree might
sometimes be what the user would want, but for the most cases
that would not be true.  Also what the original log messages say
would not match the set of partial changes limited to the
current directory you are porting forward, so you would need to
reword the logs as well if you are limiting its operation to the
current directory.  In other words, it might be sometimes useful
but that is not a "rebase" anymore -- it is something else.  The
same discussion applies to the last two commands in the list
(revert and cherry-pick).

So for that reason, I think there are only two valid choices.
Either we insist these commands to be run from the top, or we
always automatically run these commands by cd'ing to the top
ourselves.