Re: "git add -u" broken in git 1.7.4?

["SZEDER Gábor" <szeder@ira.uka.de>]

On Sun, Feb 06, 2011 at 10:46:20PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > Is "git add -p" broken, then? It takes pathspecs relative to the current
> > directory, but "git add -p" without arguments operates from the root,
> > not from the current subdirectory.
> 
> I would say so; "add -p" was an ill-executed afterthought.  The codepath
> was originally meant to be used from "-i" as the top-level interface that
> was a fully interactive way to prepare for the next commit, which is an
> operation that is inherently full-tree.
> 
> There are two schools of thought in previous threads discussing full-tree
> vs current-directory-relative.  I think each side has merits.
> 
> If we defaulted to the current directory (i.e. "git grep"), that would
> feel more natural as it is more consistent with how tools that are not git
> aware (e.g. "GNU grep" run in the same directory) behave.  A downside is
> when you are somewhere deep in a working tree, you have to know how deep
> you are and repeat "../" that many times, i.e. "git grep pattern ../../"
> 
> If we defaulted to the root-level (i.e. "git diff"), you do not have that
> downside (iow, "git diff" run from a deep directory is a full tree
> operation), and you can limit the scope to the current directory by a
> single dot, i.e. "git diff .".  A huge downside is that this may feel
> awkward for new people who do not yet breath git [*1*], as no other git
> aware tool would behave like this, limiting its scope to some directory
> that is higher above.
> 
> In the past, I have took the third position, saying that tools that
> semantically needs to be full-tree should be full-tree (i.e. ones that
> make or format commits), and others should be relative to the current
> directory (i.e. ones that are used to inspect your progress, such as
> grep), but that is not a very understandable guideline that people can
> easily follow.  If we have to choose between the two and make things
> consistent, my personal preference is to make everything relative to the
> current working directory.

_Everything_ relative to the current working directory?  I can't
imagine how would that work in practice.  Could you explain what would
the following commands do, for example, when they are relative to the
current working directory?

  $ cd t
  $ git checkout next
  $ git merge somebranch
  $ git reset HEAD^


Best,
Gábor