threads / patch / 12888

patch, 2 partsadd--interactive: better mode change handling

Subject: [PATCH 0/2] add--interactive: better mode change handling

## tl;dr

2 messages between Mar 27, 2008 and Mar 27, 2008. Diffs are folded; open one to read it.

replies: 1people: 2as markdown or json

Jeff King· Mar 27, 2008, 07:29 UTC · lore

This was spawned by a bug report from Jörg about "git add -i"'s handling of mode changes. I don't think it's actually a bug, but rather a feature request, and as such should happen post-1.5.5.

The two patches are:
  [1/2] add--interactive: ignore mode change in 'p'atch command
  [2/2] add--interactive: allow user to choose mode update

Actually, you might argue that 1/2 _is_ a bugfix, though not quite the same one that was reported. I don't actually like the behavior after just 1/2 is applied, but I split the changes to be more readable.

There may potentially be a "[3/2] change the name of the 'p'atch command" since it is now not just about the patch (actually, since git patches _do_ include mode changes, it maybe is appropriate). Wincent suggested "pick" which I think is reasonable. I'm not planning on doing such a 3/2, but I'm sure some industrious soul can make arguments for or against changing the name. I will let them handle the ensuing bikeshed jamboree.

-Peff
Wincent Colaiuta· Mar 27, 2008, 08:34 UTC · re: Jeff King · lore

Re: [PATCH 0/2] add--interactive: better mode change handling

El 27/3/2008, a las 8:29, Jeff King escribió:
Show 9 quoted lines
> There may potentially be a "[3/2] change the name of the 'p'atch
> command" since it is now not just about the patch (actually, since git
> patches _do_ include mode changes, it maybe is appropriate). Wincent
> suggested "pick" which I think is reasonable. I'm not planning on  
> doing
> such a 3/2, but I'm sure some industrious soul can make arguments  
> for or
> against changing the name. I will let them handle the ensuing bikeshed
> jamboree.

I don't really want to participate in such a jamboree either, but I will add this one last comment that I should have mentioned in my previous email: one thing to bear in mind when considering changing the subcommand name is that "git add" itself has a "--patch" option since a couple of releases ago, and that means that changing the subcommand name either means introducing a mismatch between the option name and subcommand name, or going through a deprecate/rename cycle for the option name too, which we just introduced.

I don't really care either way. My muscle memory is trained for "patch" at this point, but changing wouldn't be a problem either.

In any case, your patches 1 and 2 look pretty sane to me.

Cheers, Wincent

← back to recent threads