From: Igor Djordjevic <igor.d.djordjevic@gmail.com>
To: Thomas Gummerer <t.gummerer@gmail.com>
Cc: Reid Price <reid.price@gmail.com>, git@vger.kernel.org
Subject: Re: Apparent bug in 'git stash push <subdir>' loses untracked files
Date: Thu, 14 Dec 2017 00:46:21 +0100 [thread overview]
Message-ID: <ee9e6b8b-278e-0b86-cd35-c5d490ed7700@gmail.com> (raw)
In-Reply-To: <20171213231414.GD24597@hank>
Hi Thomas,
On 14/12/2017 00:14, Thomas Gummerer wrote:
>
> > For what it`s worth, using `git stash save <subdir>` instead seems
> > to (still) work as expected...
>
> I think that depends on what you expect ;) 'git stash save <subdir>'
> will create a stash of the whole working directory with the message
> "<subdir>". So while it would indeed work for the presumably
> simplified example Reid provided, it would not do what you'd expect
> if there are any tracked and modified files outside of the <subdir>.
>
> In that case 'git stash save <subdir>' would include the tracked
> files outside of <subdir>, while what I assume Reid wanted is to keep
> them in place, and only stash the files in <subdir>.
Indeed, I didn`t pay enough attention to the fact that even `git
stash save\push` produced different output messages, the difference
being exactly automatic (push) versus provided (save) stash message.
And I did use `git stash save <message>` in the past... :$ Not too
often, I guess.
> > but on the other hand, `git-stash`[1] manpage seems not to mention
> > this usage ("save" with "pathspec")?
>
> "stash save" with "pathspec" doesn't exist, and it will probably
> never exist. We decided to introduce a new "push" verb for 'git
> stash' because the command line for 'git stash save' takes a message
> as its last argument, instead of taking the message with a -m flag
> like other commands do. Introducing a pathspec argument for "git
> stash save" would have either broken backward compatibility, or it
> would have had some syntax that's very inconsistent with other git
> commands.
Yeah, I`m aware of the "transition", thus teaching myself to use `git
stash push` lately. That`s also what made me curious to try out the
"old" `git stash save` behavior, but obviously in a bit hasty manner.
Sorry for the confusion, and thanks, for both clarification
and your work.
Regards, Buga
next prev parent reply other threads:[~2017-12-13 23:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-13 17:32 Apparent bug in 'git stash push <subdir>' loses untracked files Reid Price
2017-12-13 21:20 ` Igor Djordjevic
2017-12-13 23:14 ` Thomas Gummerer
2017-12-13 23:46 ` Igor Djordjevic [this message]
2017-12-13 23:05 ` Thomas Gummerer
2017-12-16 18:33 ` Junio C Hamano
2017-12-17 18:05 ` Thomas Gummerer
2017-12-18 18:24 ` Junio C Hamano
2018-01-05 20:03 ` Thomas Gummerer
2018-01-06 0:24 ` [PATCH v2] stash: don't delete untracked files that match pathspec Thomas Gummerer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ee9e6b8b-278e-0b86-cd35-c5d490ed7700@gmail.com \
--to=igor.d.djordjevic@gmail.com \
--cc=git@vger.kernel.org \
--cc=reid.price@gmail.com \
--cc=t.gummerer@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).