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

From: Junio C Hamano <junkio@cox.net>
Date: Jan 14, 2007, 01:37 UTC
Message-ID: <7virfaie1m.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <45A97EC5.10401@midwinter.com>

Steven Grimm <koreth@midwinter.com> writes:

Show 15 quoted lines

> Josef Weidendorfer wrote:
>> Why not add a general "--top" option to the "git" wrapper,
>> to temporarily let git change to the toplevel while running
>> the command?
>>
>
> If I can add a config entry so --top is the default, then that's
> acceptable, but IMO it should be the default and we should, at most,
> spit out a warning if a command is run in a subdirectory and there's a
> chance of confusion.
>
> When I run one of the commands that currently can't run in a
> subdirectory and it spits out its error message, I NEVER react to that
> by saying, "Oops, forgot I was in a subdirectory, guess I didn't want
> to run that after all." (Have any of you said that, even once?)

I agree with you 90% -- the other 10% are:

 - when these whole-tree operations fail in conflicts, I need to
   cd to the top to deal with "the other parts" of the tree
   anyway.

 - the result of merging other tree may make the current
   directory disappear (say, I haven't changed anything in the
   current directory and the other branch moved it to somewhere
   else, so it cleanly merged but now the current directory
   should not be there).

These worries are only small percentage because most of the merges (or merge-like operations) are clean and directory removal is rare.

I would understand why somebody might want to fetch from others while working in subdirectory -- to see what other people might be doing in the same area as you are currently working on.

I consider that being in a subdirectory means the user is in the middle of actively working on something in that area. Honestly I do not understand why anybody would want to run the five whole-tree commands under discussion (merge, pull, rebase, revert and cherry-pick) in the middle of doing something, so from the theoretical point of view I would agree that it makes sense for the commands to internally cd-up to do their work, I am not sure how much practical value it would add.

Show 7 quoted lines

> ... I
> react by grimacing and typing "cd" so the command will do what I told
> it to do. I have done that every single time I've gotten the
> in-a-subdirectory error. And muttering under my breath something along
> the lines of, "The code knows everything it needs to know to do what I
> just told it to, but it's making me take seconds to do by hand what it
> could have done on its own in nanoseconds."

I do understand that you would want to cuss --- I probably would if that happened to me, too.

However, I am somewhat doubtful to put me in that situation in the first place, because running these five commands would be something I would do when my work-in-progress is somewhat in a stable state (perhaps after creating a temporary commit with "git-commit -a -m WIP" on the current topic branch), and am switching my attention to do something else. Doing one of these five commands (say "rebase") would be the first action of the next stage of my work, but that would most likely be preceded by cd'ing to the top; I am unlikely to stay in the "current subdirectory" when running the "rebase".

I most likely am missing something, some obvious thing in your workflow that is not mine.