mirror of
https://github.com/git/git
synced 2024-07-02 15:48:44 +00:00
fa82cf43b1
The notes/amlog database is used to annotate individual commits that result from "git am" application. A note is attached to the commit object and record s the Message-ID of the incoming e-mailed patch that resulted in the commit, so "git show --notes=amlog" would easily show where the commit came from. The rewrite-hook mechanism can be used to maintain the notes across rebasing and amending (but cherry-pick does not preserve the note by design---the maintainer has to be careful to avoid using cherry-pick). One message can and does result in multiple commits, and the mapping worked naturally in this direction. Originally it felt like a good idea to create a blob object that has a Message-ID in it, and annotate the blob object with a note message that has the name of the commit object that results by running "git am" on the message, and mix such records in the notes database. When you have a message, from the Message-ID, you can manufacture a blob that has the Message-ID in it and ask the notes database about the note attached to it, effectively giving you a reverse mapping. This was ugly, unnecessary and unworkable at the same time. - These blobs with message-ID in them are not anchored by any ref; the reverse mapping entries in the notes tree were subject to be gc'ed any time. - "git grep -e '<message-id>' notes/amlog" essentially gives a mechanism that is quick enough to find what commits resulted from a message. - There is no machinery that helps these reverse mapping notes to be maintained across rebases and amends. Because a single "git am" session is often far from enough for an e-mailed patch, these "reverse" entries that were created upon the first application quickly became stale pointing at commits that have been amended away. There often are more than one commit that result from the same message on topic branches while the right base is being selected, so "the last one wins" rule, if it were even possible to implement, wouldn't have been sufficient. Since grepping for the Message-ID in the notes database, i.e. using the forward mapping, gives an access to the necessary piece of information reliably and quicly enough, let's retire the failed attempt to throw reverse mapping entries in to the "amlog" notes.
54 lines
1.2 KiB
Bash
Executable File
54 lines
1.2 KiB
Bash
Executable File
#!/bin/sh
|
|
|
|
GIT_DIR=.git
|
|
dotest="$GIT_DIR/rebase-apply"
|
|
|
|
prec=4 &&
|
|
this=$(cat 2>/dev/null "$dotest/next") &&
|
|
msgnum=$(printf "%0${prec}d" $this) &&
|
|
test -f "$dotest/$msgnum" &&
|
|
message_id=$(sed -ne '
|
|
/^[ ]/{
|
|
# Append continuation line to hold space
|
|
H
|
|
# Swap hold and pattern
|
|
x
|
|
# Remove the LF, making it a single line
|
|
s/\n//
|
|
# Swap hold and pattern back
|
|
x
|
|
# Discard the pattern and go on
|
|
n
|
|
}
|
|
# Hold this new line, and look at what is in the hold space
|
|
x
|
|
# Is it the Message-ID line? If so, spit it out and finish.
|
|
/^[Mm][Ee][Ss][Ss][Aa][Gg][Ee]-[Ii][Dd]:[ ]*/{
|
|
s///p
|
|
q
|
|
}
|
|
# Otherwise, check if this new line is empty
|
|
x
|
|
# Is it? Then we are done with the header
|
|
/^$/b end
|
|
# Otherwise we need to hold onto this header line
|
|
x
|
|
# And start the next cycle
|
|
b
|
|
: end
|
|
# ??? do we want to check if we held onto the last message-id line
|
|
# and process it here if we did???
|
|
q
|
|
' "$dotest/$msgnum") &&
|
|
|
|
if test -n "$message_id" &&
|
|
head=$(git rev-parse --verify HEAD 2>/dev/null)
|
|
then
|
|
echo "$head $message_id" >>"$GIT_DIR"/am.log &&
|
|
(
|
|
GIT_NOTES_REF=refs/notes/amlog
|
|
export GIT_NOTES_REF
|
|
git notes add -f -m "Message-Id: $message_id" "$head"
|
|
)
|
|
fi
|