David Turner <dturner@xxxxxxxxxxxxxxxx> writes: > On Tue, 2015-07-28 at 13:47 -0700, Junio C Hamano wrote: >> David Turner <dturner@xxxxxxxxxxxxxxxx> writes: >> >> > When we unpack trees into an existing index, we discard the old index >> > and replace it with the new, merged index. Ensure that this index has >> > its cache-tree populated. This will make subsequent git status and >> > commit commands faster. >> > >> > Signed-off-by: David Turner <dturner@xxxxxxxxxxxxxxxx> >> > Signed-off-by: Brian Degenhardt <bmd@xxxxxxxxxxxx> >> > --- >> > >> > This patch is by my colleague, Brian Degenhardt (as part of his work >> > on git at Twitter). I'm sending it with his and Twitter's approval. >> >> I'd need to tweak the From:/Author: line then, and flip the order of >> the sign-off, as Brian wrote and signed off then David relayed (as >> attached). > > Where do I put an Author: line? In the commit message above the > signoffs? As an email header? I didn't see an option to git send-email > that would do this. I don't want to use the From: header because I want > to be the point-of-contact for these patches. The message you are responding to would have been a good example of forcing the author, subject and author-date to be different from the e-mail headers. That is, if you did "git am -s -c" on my message you responded to, you would have seen a new commit authored by Brian; and anybody responding to the message would have sent that e-mail to me (and git@xxxxxxxxxxxxxxx). I think that is the arrangement you are looking for. Delete everything before and including the "-- >8 --" line from my message you responded to and then the person who applies does not have to say "-c" but just with "git am -s" the same thing would have happened. E-mail coming from (and reply going to) you, but resulting commit would be authored by Brian. "git send-email", if you are sending somebody else's commit, should automatically add the in-body header "From: Brian ..." as the first line of the body, with a blank line and the body of the commit log. >> By the way, I wonder if we can lose/revert aecf567c (cache-tree: >> create/update cache-tree on checkout, 2014-07-05), now the >> underlying unpack_trees() does the necessary cache_tree_update() >> when a branch is checked out. > > Well, the tests still pass, so I guess so. That is, we still need the > WRITE_TREE_REPAIR bit, but not the update check. > > Will re-roll once I hear back on the author line. Let's not do the "drop cache-tree generation from checkout" in the same patch. It can be done as a separate patch but I do not think it is a very high priority. With that understanding, what I have received from you (with a minor tweak shown in the message you are responding to) is already fine, I think. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html