stash: add 'rename' subcommand#2180
Conversation
Welcome to GitGitGadgetHi @ozemin, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests. Please make sure that either:
You can CC potential reviewers by adding a footer to the PR description with the following syntax: NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description, Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:
It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code. Contributing the patchesBefore you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form Both the person who commented An alternative is the channel Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment If you want to see what email(s) would be sent for a After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail). If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the curl -g --user "<EMailAddress>:<Password>" \
--url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txtTo iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description): To send a new iteration, just add another PR comment with the contents: Need help?New contributors who want advice are encouraged to join git-mentoring@googlegroups.com, where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join. You may also be able to find help in real time in the developer IRC channel, |
There is no way to change the message of a stash entry after the
fact. The only option is dropping the entry and re-storing it by
hand, which moves it to the top of the stash list and gets fiddly
for deeper entries.
Add 'git stash rename <message> [<stash>]', defaulting to the
latest entry like the other subcommands do. It reads the object id
and reflog message of the target entry and of the entries above it,
drops them all like 'git stash drop' would, and stores them back in
the same order, with the new message going to the target. Position,
contents and the reflog chain stay as they were.
The command checks every entry it is about to rewrite and refuses
to start if one of them does not look like a stash commit, which
can only happen when refs/stash was written to by hand. Finding
that out halfway through the sequence would lose entries. Should a
write-back fail anyway, the entry's object id is reported so it can
be recovered with 'git stash store', and the command only reports
success when the reflog ended up in the requested state.
This was proposed before: in 2010, as a "git reflog update" command
that edited reflog entries in place [1]. When it came up again in
2013 [2], Junio rejected it on the grounds that reflogs are
append-only recovery logs, and that whoever really cares about a
stash message can pop and re-stash [3]. Michael Haggerty pointed
out in that thread that refs/stash does not fit the description:
its reflog is the primary data store for stash entries, and 'git
stash drop' rewrites it all the time [4]. So this patch stays away
from the reflog machinery entirely and does the suggested
pop-and-re-stash workaround mechanically, without the detour
through the working tree.
The sequence only works if entry positions hold still while it
runs, so the command takes index-based selectors (stash@{1}) and
rejects time-based ones. It also refreshes the reflog timestamps
of the rewritten entries, and renaming stash@{n} costs n+1 reflog
deletions and ref updates.
[1] https://lore.kernel.org/git/20100620093142.GF24805@occam.hewgill.net/
[2] https://lore.kernel.org/git/loom.20130104T192132-16@post.gmane.org/
[3] https://lore.kernel.org/git/7vbod4tynt.fsf@alter.siamese.dyndns.org/
[4] https://lore.kernel.org/git/50ED2C78.1030300@alum.mit.edu/
Signed-off-by: Emin Özata <eminozata@proton.me>
1 participant
eo/stash-rename
"git stash rename" learned to change the message of an existing stash
entry without changing its position or its contents.
This came up in 2010 and again in 2013, and was rejected back then
because the proposed implementation rewrote reflog entries in place.
This version doesn't: it does the drop-and-re-store dance that was
suggested as the manual workaround, with the machinery stash already
uses for drop and store, and touches nothing but refs/stash. Details
and links to the old threads are in the commit message.
Costs, so nobody has to dig for them: rewritten entries get fresh
reflog timestamps (hence index-only selectors), and renaming
stash@{n} does n+1 reflog deletions, each of them a locked rewrite
of the whole reflog. The sequence is not atomic either: a failure
halfway is handled by writing the collected entries back
best-effort, whatever cannot be written back is reported with its
object id so "git stash store" can recover it, and a process killed
between the drop and store phases loses the collected entries (git
fsck still finds them). A single refs_reflog_expire() pass would
cut both the I/O and that window down, and closing the window for
real needs a new refs API operation; I'd rather do either as a
follow-up if the feature is wanted at all.
I picked a positional over "-m " ("stash store"
style); no strong opinion, happy to switch.
t3903 passes with GIT_TEST_DEFAULT_REF_FORMAT=files and reftable.
cc: Junio C Hamano gitster@pobox.com
cc: Greg Hewgill greg@hewgill.com
cc: Micheil Smith micheil@brandedcode.com
cc: Michael Haggerty mhagger@alum.mit.edu
cc: Ævar Arnfjörð Bjarmason avarab@gmail.com