From: Patrick Steinhardt <ps@pks.im>
To: Alexander Shpilkin <ashpilkin@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: A cross between 'git stash create' and 'git stash push --include-untracked'?
Date: Mon, 31 Mar 2025 09:47:56 +0200 [thread overview]
Message-ID: <Z-pIrCp6ZewWuPI0@pks.im> (raw)
In-Reply-To: <d8f596cfac9b001350b8b5e408067bb4caa073a7.camel@gmail.com>
On Sun, Mar 30, 2025 at 05:37:42PM +0300, Alexander Shpilkin wrote:
> Hi,
>
> I'm trying to write a script for my use that would run before every
> invocation of 'make' and record the working tree state at that point.
> Stripping out the boring parts, it is basically just
>
> git update-ref --create-reflog refs/build $(git stash create)
>
> but the problem is that what I want is less like 'git stash create' and
> more like 'git stash create --include-untracked', in case there are any
> new and as yet untracked source files that are nevertheless picked up
> by the build system.
>
> Of course, that does not exist and, because of the syntax of 'git stash
> create', cannot exist. I've looked at the code in builtin/stash.c and
> it looks like there are only two callers of do_create_stash(): one is
> create_stash() and hardcodes the include_untracked argument to zero,
> the other is do_push_stash() and (assuming I try to undo its effects
> with 'git stash pop' afterwards) will potentially destroy my working
> tree's mtimes and cause more rebuilding than necessary. So it seems
> like I'm stuck here.
Indeed.
> Any suggestions?
I guess the obvious answer here is to extend `git stash create` so that
it knows to handle "--include-untracked".
Unfortunately, it wouldn't be quite as simple as just wiring up the
command line option and passing the flag to `do_create_stash()` because
`save_untracked_files()` saves untracked files by modifying the
repository's index. Consequentially, we would still end up modifying the
repository, even though the checked out files would ultimately remain
unmodified.
I think we'd have to teach `save_untracked_files()` to do the changes on
an in-memory index instead of invoking git-update-index(1). And if it
knew to do that we could easily wire it up for `git stash create` and
thus implement your usecase.
I won't be working on this myself as I'm short on time, but I assume
that patches would very much be welcome.
Thanks!
Patrick
prev parent reply other threads:[~2025-03-31 7:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-30 14:37 A cross between 'git stash create' and 'git stash push --include-untracked'? Alexander Shpilkin
2025-03-31 7:47 ` Patrick Steinhardt [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z-pIrCp6ZewWuPI0@pks.im \
--to=ps@pks.im \
--cc=ashpilkin@gmail.com \
--cc=git@vger.kernel.org \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.