threads / discuss / 60573

Minor UX annoyance w/`git add --patch untracked/file`

Subject: Minor UX annoyance w/`git add --patch untracked/file`

## tl;dr

4 messages between Nov 30, 2023 and Dec 8, 2023.

replies: 3people: 4as markdown or json

Vito Caputo· Nov 30, 2023, 19:26 UTC · lore

Hello list,

Couldn't the following two steps be done automagically by --patch:

``` git add -N path/to/untracked/file/wishing/to/partially/add git add --patch path/to/untracked/file/wishing/to/partially/add ```

when one simply does:

`git add --patch path/to/untracked/file/wishing/to/partially/add`

Cheers, Vito Caputo

Jeff King· Dec 6, 2023, 19:54 UTC · re: Vito Caputo · lore

Re: Minor UX annoyance w/`git add --patch untracked/file`

On Thu, Nov 30, 2023 at 11:26:37AM -0800, Vito Caputo wrote:

Show 12 quoted lines

> Couldn't the following two steps be done automagically by --patch:
> 
> ```
> git add -N path/to/untracked/file/wishing/to/partially/add
> git add --patch path/to/untracked/file/wishing/to/partially/add
> ```
> 
> when one simply does:
> 
> `git add --patch path/to/untracked/file/wishing/to/partially/add`
> 
> ?

They _could_, but keep in mind that the argument is not strictly a path. It is a pathspec that may match multiple paths. So:

  git add -p path/to/

for example will pick up the tracked files in path/to/, but not your untracked one.

It would be possible to distinguish the two cases, and only auto-add files which are explicitly mentioned as full paths. But we usually shy away from too many special cases like this, as the resulting behavior can end up confusing and hard to explain.

-Peff

Junio C Hamano· Dec 8, 2023, 21:09 UTC · re: Jeff King · lore

Re: Minor UX annoyance w/`git add --patch untracked/file`

Jeff King <peff@peff.net> writes:

Show 7 quoted lines

> They _could_, but keep in mind that the argument is not strictly a path.
> It is a pathspec that may match multiple paths. So:
>
>   git add -p path/to/
>
> for example will pick up the tracked files in path/to/, but not your
> untracked one.

The corresponding command w/o "-p", i.e., "git add path/to/", will pick up both tracked and untracked ones from the named directory, while honoring the ignore settings. So I suspect it might feel more natural if "-p" followed suit.

Not that I feel strongly either way. The command has only worked with already tracked files since its inception and nobody complained in the past 15 years or so, probably because nobody cared that much for relatively rare event of creating a new file and adding it.

Thanks.

Taylor Blau· Dec 8, 2023, 22:29 UTC · re: Junio C Hamano · lore

Re: Minor UX annoyance w/`git add --patch untracked/file`

On Sat, Dec 09, 2023 at 06:09:46AM +0900, Junio C Hamano wrote:

Show 14 quoted lines

> Jeff King <peff@peff.net> writes:
>
> > They _could_, but keep in mind that the argument is not strictly a path.
> > It is a pathspec that may match multiple paths. So:
> >
> >   git add -p path/to/
> >
> > for example will pick up the tracked files in path/to/, but not your
> > untracked one.
>
> The corresponding command w/o "-p", i.e., "git add path/to/", will
> pick up both tracked and untracked ones from the named directory,
> while honoring the ignore settings.  So I suspect it might feel more
> natural if "-p" followed suit.

I tend to agree. I do think that the full specification of when "git add -p" implies "git add -N ... && git add -p" would be difficult to explain to users.

But I think it's a worthwhile trade-off in that it makes the UX more consistent in the common case (where the argument to add is a literal path, not a pathspec).

Thanks, Taylor