{"thread":{"id":"48735","subject":"Re: want <reason> option to git-rebase","startedAt":"2018-06-19T01:07:22Z","lastAt":"2018-06-20T10:43:56Z","messageCount":5,"participants":["Jonathan Nieder","Ian Jackson","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"350449","messageId":"20180619010655.GA173168@aiede.svl.corp.google.com","threadId":"48735","inReplyTo":"23335.52730.475955.861241@chiark.greenend.org.uk","subject":"Re: want <reason> option to git-rebase","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-06-19T01:06:55Z","receivedAt":"2018-06-19T01:07:22Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nIan Jackson wrote[1]:\n\n> git-rebase leaves entries like this in the reflog:\n>\n>   c15f4d5391 HEAD@{33}: rebase: checkout c15f4d5391ff07a718431aca68a73e672fe8870e\n>\n> It would be nice if there were an option to control this message.\n> Particularly, when another tool invokes git-rebase, the other tool may\n> specify an interesting --onto, and there is no way to record any\n> information about that --onto commit.\n>\n> git-rebase already has a -m option, so I suggest\n>   --reason=<reason>\n>\n> It doesn't matter much exactly how the provided string is used.\n> Any of the following would be good IMO:\n>   <reason>\n>   rebase start: <reason>\n>\n> I think:\n>   rebase: checkout c15f4d5391ff07a718431aca68a73e672fe8870e <reason>\n> would be rather cumbersome.\n\nFrom git(1):\n\n GIT_REFLOG_ACTION\n\tWhen a ref is updated, reflog entries are created to keep\n\ttrack of the reason why the ref was updated (which is\n\ttypically the name of the high-level command that updated the\n\tref), in addition to the old and new values of the ref. A\n\tscripted Porcelain command can use set_reflog_action helper\n\tfunction in git-sh-setup to set its name to this variable when\n\tit is invoked as the top level command by the end user, to be\n\trecorded in the body of the reflog.\n\n\"git rebase\" sets this itself, so it doesn't solve your problem.\n\nCan you say more about what your tool does?  I'm wondering if it would\nmake sense for it to use lower-level commands where GIT_REFLOG_ACTION\napplies, instead of the more user-facing git rebase.\n\nThanks,\nJonathan\n\n[1] https://bugs.debian.org/901805\n"},{"id":"350465","messageId":"23336.55459.558413.723251@chiark.greenend.org.uk","threadId":"48735","inReplyTo":"20180619010655.GA173168@aiede.svl.corp.google.com","subject":"Re: want <reason> option to git-rebase","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2018-06-19T10:19:15Z","receivedAt":"2018-06-19T10:52:57Z","isPatch":false,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"Jonathan Nieder writes (\"Re: want <reason> option to git-rebase\"):\n> Ian Jackson wrote[1]:\n> > git-rebase leaves entries like this in the reflog:\n> >\n> >   c15f4d5391 HEAD@{33}: rebase: checkout c15f4d5391ff07a718431aca68a73e672fe8870e\n...\n>  GIT_REFLOG_ACTION\n> \tWhen a ref is updated, reflog entries are created to keep\n> \ttrack of the reason why the ref was updated (which is\n> \ttypically the name of the high-level command that updated the\n> \tref), in addition to the old and new values of the ref. A\n> \tscripted Porcelain command can use set_reflog_action helper\n> \tfunction in git-sh-setup to set its name to this variable when\n> \tit is invoked as the top level command by the end user, to be\n> \trecorded in the body of the reflog.\n> \n> \"git rebase\" sets this itself, so it doesn't solve your problem.\n\nHrm.\n\n> Can you say more about what your tool does?  I'm wondering if it would\n> make sense for it to use lower-level commands where GIT_REFLOG_ACTION\n> applies, instead of the more user-facing git rebase.\n\nSure.\n\nhttp://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git-manpage/dgit.git/git-debrebase.1\n\nSee the description of git-rebase new-upstream.  It does a lot of\ncomplicated work, synthesising a new pair of commits using plumbing\netc., and then does\n  git rebase --onto <thing it made> <user's previous base>\n\nIf the user says git rebase --abort, everything should be undone.\n\nAnother alternative solution would be to be able to make git reflog\nentries without actually updating any ref.\n\nIan.\n\n-- \nIan Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.\n\nIf I emailed you from an address @fyvzl.net or @evade.org.uk, that is\na private address which bypasses my fierce spamfilter.\n"},{"id":"350520","messageId":"c5fc1505-9847-25d8-02f3-c0e666afdd1d@kdbg.org","threadId":"48735","inReplyTo":"20180619010655.GA173168@aiede.svl.corp.google.com","subject":"Re: want <reason> option to git-rebase","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2018-06-19T18:31:39Z","receivedAt":"2018-06-19T18:31:44Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 19.06.2018 um 03:06 schrieb Jonathan Nieder:\n> Ian Jackson wrote[1]:\n>> git-rebase leaves entries like this in the reflog:\n>>\n>>    c15f4d5391 HEAD@{33}: rebase: checkout c15f4d5391ff07a718431aca68a73e672fe8870e\n>>\n>> It would be nice if there were an option to control this message.\n>> Particularly, when another tool invokes git-rebase, the other tool may\n>> specify an interesting --onto, and there is no way to record any\n>> information about that --onto commit.\n>>\n>> git-rebase already has a -m option, so I suggest\n>>    --reason=<reason>\n>>\n>> It doesn't matter much exactly how the provided string is used.\n>> Any of the following would be good IMO:\n>>    <reason>\n>>    rebase start: <reason>\n> \n>  From git(1):\n> \n>   GIT_REFLOG_ACTION\n> \tWhen a ref is updated, reflog entries are created to keep\n> \ttrack of the reason why the ref was updated (which is\n> \ttypically the name of the high-level command that updated the\n> \tref), in addition to the old and new values of the ref. A\n> \tscripted Porcelain command can use set_reflog_action helper\n> \tfunction in git-sh-setup to set its name to this variable when\n> \tit is invoked as the top level command by the end user, to be\n> \trecorded in the body of the reflog.\n> \n> \"git rebase\" sets this itself, so it doesn't solve your problem.\n\nIf it does so unconditionally, then that is a bug. If a script wants to \nset GIT_REFLOG_ACTION, but finds that it is already set, then it must \nnot change the value. set_reflog_action in git-sh-setup does the right \nthing.\n\nSo, if there is another script or application around git-rebase, then it \nshould just set GIT_REFLOG_ACTION (if it is not already set) and export \nthe environment variable to git-rebase.\n\n-- Hannes\n"},{"id":"350549","messageId":"20180620014940.GD122284@aiede.svl.corp.google.com","threadId":"48735","inReplyTo":"c5fc1505-9847-25d8-02f3-c0e666afdd1d@kdbg.org","subject":"Re: want <reason> option to git-rebase","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-06-20T01:49:40Z","receivedAt":"2018-06-20T01:49:46Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Johannes Sixt wrote:\n> Am 19.06.2018 um 03:06 schrieb Jonathan Nieder:\n>> Ian Jackson wrote[1]:\n\n>>> git-rebase leaves entries like this in the reflog:\n>>>\n>>>    c15f4d5391 HEAD@{33}: rebase: checkout c15f4d5391ff07a718431aca68a73e672fe8870e\n>>>\n>>> It would be nice if there were an option to control this message.\n>>> Particularly, when another tool invokes git-rebase,\n[...]\n>>  From git(1):\n>>\n>>   GIT_REFLOG_ACTION\n>> \tWhen a ref is updated, reflog entries are created to keep\n>> \ttrack of the reason why the ref was updated (which is\n>> \ttypically the name of the high-level command that updated the\n>> \tref), in addition to the old and new values of the ref. A\n>> \tscripted Porcelain command can use set_reflog_action helper\n>> \tfunction in git-sh-setup to set its name to this variable when\n>> \tit is invoked as the top level command by the end user, to be\n>> \trecorded in the body of the reflog.\n>>\n>> \"git rebase\" sets this itself, so it doesn't solve your problem.\n>\n> If it does so unconditionally, then that is a bug. If a script wants to set\n> GIT_REFLOG_ACTION, but finds that it is already set, then it must not change\n> the value. set_reflog_action in git-sh-setup does the right thing.\n>\n> So, if there is another script or application around git-rebase, then it\n> should just set GIT_REFLOG_ACTION (if it is not already set) and export the\n> environment variable to git-rebase.\n\nOh, good catch.  \"git rebase\" already generally does the right thing\nwhen GIT_REFLOG_ACTION is set (by only appending to it and never\nreplacing it).\n\nIan, does that work well for you?  If so, any ideas where it should go\nin the documentation to be more discoverable for next time?\n\nFootnotes:\n\n- git-rebase--interactive.sh has the following snippet:\n\n\tcase \"$orig_reflog_action\" in\n\t''|rebase*)\n\t\tGIT_REFLOG_ACTION=\"rebase -i ($1)\"\n\n  This is a little too aggressive, since it's possible for a\n  user-specified reflog action to start with \"rebase\" and\n  contain additional information that shouldn't be removed.\n\n- likewise in git-rebase--preserve-merges.sh.\n\nThanks,\nJonathan\n"},{"id":"350554","messageId":"23338.12262.631847.860230@chiark.greenend.org.uk","threadId":"48735","inReplyTo":"20180620014940.GD122284@aiede.svl.corp.google.com","subject":"Re: want <reason> option to git-rebase","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2018-06-20T10:43:50Z","receivedAt":"2018-06-20T10:43:56Z","isPatch":false,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"Jonathan Nieder writes (\"Re: want <reason> option to git-rebase\"):\n> Oh, good catch.  \"git rebase\" already generally does the right thing\n> when GIT_REFLOG_ACTION is set (by only appending to it and never\n> replacing it).\n\nGreat.  I indeed did not know about this.\n\n> Ian, does that work well for you?  If so, any ideas where it should go\n> in the documentation to be more discoverable for next time?\n\nThanks for asking exactly the right question :-).\n\nI didn't make a record of exactly where I looked but I'm pretty sure I\nlooked at the manpages for git-reflog and git-rebase.  I think I\nprobably also looked at git-update-ref; I have read git-update-ref a\nnumber of times.\n\nRight now in Debian unstable I see that none of these places document\nthis convention.\n\nI think git-reflog ought to mention it, so that it says where the\ninformation it provides comes from.\n\nIt also ought to be mentioned in git-update-ref, because all callers\nof git-update-ref need to implement it !\n\nIndeed, because I didn't know about this convention, dgit and\ngit-debrebase do not honour it.  At least in my case, if it had been\nin git-update-ref I would have implemented it myself and then I would\nobviously have thought of making use of it myself.\n\n\nAlso, I have to say, the documentation for GIT_REFLOG_ACTION\nin git(1) is very obscure.  It sort of generally waffles around what\nit is for, but it does not say:\n * what does this variable contain\n * who can and should set it\n * who should consume it\n * what the rules are for modifying it\n\nI don't think simply adding a cross-reference to GIT_REFLOG_ACTION in\ngit(1) would be sufficient, without also improving this part.\n\n\nThe explanations provided by you and Johannes, here in these emails,\nare much much better:\n\n> >> \"git rebase\" sets this itself, so it doesn't solve your problem.\n> >\n> > If it does so unconditionally, then that is a bug. If a script\n> > wants to set GIT_REFLOG_ACTION, but finds that it is already set,\n> > then it must not change the value. set_reflog_action in\n> > git-sh-setup does the right thing.\n> >\n> > So, if there is another script or application around git-rebase, then it\n> > should just set GIT_REFLOG_ACTION (if it is not already set) and export the\n> > environment variable to git-rebase.\n> \n> Oh, good catch.  \"git rebase\" already generally does the right thing\n> when GIT_REFLOG_ACTION is set (by only appending to it and never\n> replacing it).\n\nMaybe some of this prose, which explains things quite well, could be\nreworked into a form suitable for the git docs.  (Even though there\nseems to be disagreement about whether a subcommand may *append* to\nGIT_REFLOG_ACTION; which, ISTM, is a practice which ought to be\nencouraged rather than discouraged.)\n\n\nRegards,\nIan.\n\n-- \nIan Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.\n\nIf I emailed you from an address @fyvzl.net or @evade.org.uk, that is\na private address which bypasses my fierce spamfilter.\n"}]}