Re: What's cooking in git.git (Mar 2011, #06; Thu, 31)

Jeff King [off-list ref] writes:

On Thu, Mar 31, 2011 at 03:26:31PM -0700, Junio C Hamano wrote:

(... parts that I do not disagree with are omitted ...)

quoted

* jc/add-u-migration (2011-03-22) 3 commits
 - add: make "add -u/-A" update full tree without pathspec (step 3)
 - add: make "add -u/-A" update full tree without pathspec (step 2)
  (merged to 'next' on 2011-03-31 at 962e058)
 + add: make "add -u/-A" update full tree without pathspec

The bottom one is a necessary first step toward the UI clean-up planned
for 1.8.0 which we discussed in length in the earlier part of the cycle;
the change is low impact, isolated, and has no risk of breaking the system
as a whole, but I would wait until the ":/" magic pathspec materializes,
as the advice message would have to become different, and the way to get
more stable semantics will become more direct.

I have been meaning to look closer at this. Were you wanting to get the
first stage of the transition into 1.7.5?

I was tempted to but I think it would be far more pleasant if the first
step were to add the warning against "add -u" without pathspec that is ran
from a subdirectory to advise "if you meant 'from here', say '.', if you
meant 'everywhere', say ':/'---for now we pretend you said '.' to match
the traditional behaviour."

It is adding even more confusion to add the "in this repository, 'add -u'
is tree-wide" configuration variable without giving people who need to
override that in unfamiliar repositories (read: scripts).

Right now, we don't have a good advice to force the tree-wide behaviour
other than "cd $(git rev-parse --show-cdup)/. && git add -u", which is
quite a mouthful.

We know how the magic "this pathspec is from the root" should work, and I
think we even saw "should look like this" patches, but haven't applied to
any branch so far yet.

quoted

* jk/progress-with-pager (2011-03-24) 4 commits
 - diff: turn on rename detection progress reporting
 - show: turn on rename detection progress reporting
 - progress: use pager's original_stderr if available
 - pager: save the original stderr when redirecting to pager

Will cook until 1.7.5 final.

I'm not sure if this whole thing should be scrapped. There are potential
problems with starting a pager that wants to grab the whole screen
(i.e., not less). Maybe it would be enough to have a pager.noprogress
option for people who use such a pager.

Perhaps.  With "Will cook until" I only meant "will not graduate until"; I
was not even making any prediction after 1.7.5 in the message.

Thanks.

On Fri, Apr 01, 2011 at 10:01:42AM -0700, Junio C Hamano wrote:

quoted

quoted

* jc/add-u-migration (2011-03-22) 3 commits
 - add: make "add -u/-A" update full tree without pathspec (step 3)
 - add: make "add -u/-A" update full tree without pathspec (step 2)
  (merged to 'next' on 2011-03-31 at 962e058)
 + add: make "add -u/-A" update full tree without pathspec

[...]

quoted

I have been meaning to look closer at this. Were you wanting to get the
first stage of the transition into 1.7.5?

I was tempted to but I think it would be far more pleasant if the first
step were to add the warning against "add -u" without pathspec that is ran
from a subdirectory to advise "if you meant 'from here', say '.', if you
meant 'everywhere', say ':/'---for now we pretend you said '.' to match
the traditional behaviour."

Yes, I think that is definitely the right first step.

It is adding even more confusion to add the "in this repository, 'add -u'
is tree-wide" configuration variable without giving people who need to
override that in unfamiliar repositories (read: scripts).

Right now, we don't have a good advice to force the tree-wide behaviour
other than "cd $(git rev-parse --show-cdup)/. && git add -u", which is
quite a mouthful.

We know how the magic "this pathspec is from the root" should work, and I
think we even saw "should look like this" patches, but haven't applied to
any branch so far yet.

That reasoning makes sense. Let's let the :/ patches develop and cook
for post-1.7.5, then, and worry about it in the next cycle when we can
build on top of them.

-Peff