{"thread":{"id":"13855","subject":"[RFC] git-sequencer.txt","startedAt":"2008-06-07T22:01:01Z","lastAt":"2008-06-13T19:24:38Z","messageCount":41,"participants":["Stephan Beyer","Johannes Schindelin","Paolo Bonzini","Jakub Narebski","Junio C Hamano","Jeff King","Christian Couder","Daniel Barkalow","Olivier Marin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"79071","messageId":"20080607220101.GM31040@leksak.fem-net","threadId":"13855","inReplyTo":null,"subject":"[RFC] git-sequencer.txt","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-07T22:01:01Z","receivedAt":"2008-06-07T22:01:01Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nI inline-attached the documentation (and somehow specification)\nfor git-sequencer (my GSoC'08 project) for you to comment on.\n\ngit-sequencer wants to become the common backend for git-am and \ngit-rebase(--interactive) and perhaps some other git commands.\nBut, if git-sequencer.txt is good enough, you should be able to figure\nout yourself, what it can actually be used for :-)\n\nSome background on the project status:\nThere is already a working (shell) implementation of the following \nspecification (90% finished), but we thought that it is useful to \nfirst give you only a spec without implementation details to comment on.\n\nNote, that there is also a git-am and git-rebase--interactive that use\ngit-sequencer directly and ... all test cases of the test suite (in \"next\")\nare passed.  So imho a first reality-check is passed, too.\n\nBut the second (and perhaps much harder) stage to pass is your \npoint of view.\nSo I hope you will have some good ideas and strong opinions ;-)\n\nRegards,\n  Stephan\n\n------------------------------ git-sequencer.txt ------------------------------\ngit-sequencer(1)\n================\n\nNAME\n----\ngit-sequencer - Execute a sequence of git instructions\n\nSYNOPSIS\n--------\n[verse]\n'git-sequencer' [-v | --verbose] <file> [<branch>]\n'git-sequencer' --continue | --skip | --abort | --edit\n\n\nDESCRIPTION\n-----------\nExecutes a sequence of git instructions to HEAD or `<branch>`.\nThe sequence is given by `<file>` or standard input.\nAlso see 'TODO FILE FORMAT' below.\n\nBefore doing anything, the TODO file is checked for correct syntax \nand sanity.\n\nIn case of a conflict or request in the TODO file, git-sequencer will\npause. On conflict you can use git-diff to locate the markers (`<<<<<<`) \nand make edits to resolve the conflict.\n\nFor each file you edit, you need to tell git the changes by doing\n\n    git add <file>\n\nAfter resolving the conflict manually and updating the index with the\ndesired resolution, you can continue the sequencing process with\n\n    git sequencer --continue\n\nAlternatively, you can undo the git-sequencer progress with\n\n    git sequencer --abort\n\nor skip the current instruction with\n\n    git sequencer --skip\n\nor correct the TODO file with\n\n    git sequencer --edit\n\nDuring pauses or when finished with the sequencing task, the current\nHEAD will always be the result of the last processed instruction.\n\n\nOPTIONS\n-------\n<file>::\n\tFilename of the TODO file.  Use `-` to read from standard input.\n\tSee 'TODO FILE FORMAT' below.\n\n<branch>::\n\tWorking branch; defaults to HEAD.\n\n--continue::\n\tRestart the sequencing process after having resolved a merge conflict.\n\n--abort::\n\tRestore the original branch and abort the sequence operation.\n\n--skip::\n\tRestart the sequencing process by skipping the current patch.\n\n--edit::\n\tInvoke editor to edit the undone rest of the TODO file.\n+\nThe file is syntax- and sanity-checked afterwards, so that you can \nsafely run `git sequencer --skip` or `--continue` after editing.\nIf you nonetheless noticed that you made a mistake, you can \noverwrite `.git/sequencer/todo` with `.git/sequencer/todo.old` and\nrerun `git sequencer --edit`.\n+\nIf the check fails you are prompted if you want to correct your \nchanges, edit again, cancel editing or really want to save.\n\n-v, \\--verbose::\n\tBe more verbose. [XXX: to be defined more accurately, i.e. print diffstat]\n\n\nNOTES\n-----\n\nWhen sequencing, it is possible, that you are changing the history of\na branch in a way that can cause problems for anyone who already has \na copy of the branch in their repository and tries to pull updates from\nyou.  You should understand the implications of using git-sequencer on\na repository that you share.\n\ngit-sequencer will usually be called by another git porcelain, like\nlinkgit:git-am[1] or linkgit:git-rebase[1].\n\n\nTODO FILE FORMAT\n----------------\n\nThe TODO file contains basically one instruction per line.\n\nBlank lines will be ignored. \nAll characters after a `#` character will be ignored until the end of a line.\n\nThe following instructions can be used:\n\n\nedit <commit>::\n\tPicks a commit and pauses the sequencer process to let you\n\tmake changes.\n+\nAfter you have finished your changes, invoke `git-sequencer --continue`.\nIf you only want to edit the commit message with an editor,\nrun `git-commit --amend` (see linkgit:git-commit[1]) before.\n+\nNote, that `edit <commit>` is a short form for `pick --edit <commit>`.\n\n\nfile [<options>] <file>::\n\tIf file `<file>` is a pure (diff) patch, then apply the patch.\n\tIf no `--message` option is given, an editor will\n\tbe invoked to enter a commit message.\n+\nIf `<file>` is a linkgit:git-format-patch[1]-formatted patch,\nthen the patch will be commited.\n+\nSee the following list and 'GENERAL OPTIONS' for values of `<option>`:\n\n\t-3, --3way;;\n\t\tWhen the patch does not apply cleanly, fall back on\n\t\t3-way merge, if the patch records the identity of blobs\n\t\tit is supposed to apply to, and we have those blobs\n\t\tavailable locally.\n\n\t-k;;\n\t\tPass `-k` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).\n\n\t-n;;\n\t\tPass `-n` flag to `git-mailinfo` (see\n\t\tlinkgit:git-mailinfo[1]).\n\n\t-u;;\n\t\tPass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).\n\t\tThe proposed commit log message taken from the e-mail\n\t\tis re-coded into UTF-8 encoding (configuration variable\n\t\t`i18n.commitencoding` can be used to specify project's\n\t\tpreferred encoding if it is not UTF-8).\n+\nThis was optional in prior versions of git, but now it is the\ndefault. You could use `-n` to override this.\n\n\t-*;;\n\t\tAny other dash-prefixed option is passed to\n\t\tlinkgit:git-apply[1].\n\t\tThis is especially useful for flags like\n\t\t`--reverse`, `-C<n>`, `-p<n>` or `--whitespace=<action>`.\n\n\nmark <mark>::\n\tSet a symbolic mark for the last commit.\n\t`<mark>` is an unsigned integer starting at 1 and\n\tprefixed with a colon, e.g. `:1`.\n+\nThe marks can help if you want to refer to commits that you\ncreated during the sequencer process, e.g. if you want to\nmerge such a commit.\n+\nThe set marks are removed after the sequencer has completed.\n\n\nmerge [<options>] <commit-ish1> <commit-ish2> ... <commit-ishN>::\n\tMerge commits into HEAD.\n+\nA commit can also be given by a mark, if prefixed with a colon.\n+\nIf you do not provide a commit message (using `-F`, `-m`, `--reference` \nor `--standard`), an editor will be invoked.\n+\nSee the following list and 'GENERAL OPTIONS' for values of `<option>`:\n\n\t--reference=<commit-ish>;;\n\t\tTake author and commit message of <commit-ish>.\n\t\n\t--standard;;\n\t\tGenerates a commit message like 'Merge ... into HEAD'.\n\t\tSee also linkgit:git-fmt-merge-msg[1].\n\t\n\t-s <strategy>;;\n\t--strategy=<strategy>;;\n\t\tUse the given merge strategy.\n\t\tSee also linkgit:git-merge[1].\n\n\npick [<options>] <commit>::\n\tPick (see linkgit:git-cherry-pick[1]) a commit.\n\tSequencer will pause on conflicts.\n+\nSee 'GENERAL OPTIONS' for values of `<option>`.\n\n\nreset <commit-ish>::\n\tGo back (see linkgit:git-reset[1] `--hard`) to commit `<commit-ish>`.\n\t`<commit-ish>` can also be given by a mark, if prefixed with a colon.\n\n\nsquash [<options>] <commit>::\n\tAdd the changes introduced by `<commit>` to the last commit.\n+\nSee 'GENERAL OPTIONS' for values of `<option>`.\n\n\ntag <tag>::\n\tSet tag `<tag>` to the current HEAD,\n\tsee also linkgit:git-tag[1].\n\tIf another commit is tagged `<tag>`, it will lose this tag,\n\ti.e. the tag will be reset to HEAD.\n\n\n\nGENERAL OPTIONS\n---------------\n\nBesides some special options, the instructions\n`file`, `merge`, `pick`, `squash` take the following general options:\n\n--edit::\n\tAllows you to re-edit the done commit. For example, you can change\n\tthe commit message in an editor, or fix even bugs or typos.\n\tLets you also manually make further commits on top of the\n\tcurrent commit before continuing.\n+\nYou will have to invoke `git-sequencer --continue` (or `--edit` or `--abort`),\nwhen finished.\n\n--author=<author>::\n\tOverride the author name and e-mail address used in the commit.\n\tUse `A U Thor <author@example.com>` format.\n\n-F <file>::\n--file=<file>::\n\tTake the commit message from the given file.\n\n-m <msg>::\n--message=<msg>::\n\tUse the given `<msg>` as the commit message.\n\n-s::\n--signoff::\n\tAdd `Signed-off-by:` line to the commit message (if not yet there),\n\tusing the committer identity of yourself.\n\n\nRETURN VALUES\n-------------\n\ngit-sequencer returns:\n\n* `0`, if git-sequencer successfully completed all the instructions\n       in the TODO file or successfully aborted after\n       `git-sequencer --abort`,\n* `2`, on user-requested pausing, e.g.\n       when using the `edit` instruction.\n* `3`, on pauses that are not requested, e.g.\n       when there are conflicts to resolve.\n* any other value on error, e.g.\n  syntax errors in the TODO file or\n  running git-sequencer on a bare repository.\n\n\nEXAMPLES\n--------\n\nXXX [Here the usage of all commands should become clear,\nbut it's braindamaged to write this section as long as the file format\nis in discussion.]\n\n\nSEE ALSO\n--------\nlinkgit:git-add[1],\nlinkgit:git-am[1],\nlinkgit:git-cherry-pick[1],\nlinkgit:git-commit[1],\nlinkgit:git-format-patch[1],\nlinkgit:git-rebase[1],\nlinkgit:git-reset[1],\nlinkgit:git-tag[1]\n\n\nAuthors\n-------\nXXX\n\nDocumentation\n-------------\nDocumentation by Stephan Beyer and the git-list <git@vger.kernel.org>.\n\nGIT\n---\nPart of the linkgit:git[1] suite\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79218","messageId":"20080609114550.GA8079@leksak.fem-net","threadId":"13855","inReplyTo":"20080607220101.GM31040@leksak.fem-net","subject":"squashing patches (was: Re: [RFC] git-sequencer.txt)","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-09T11:45:50Z","receivedAt":"2008-06-09T11:45:50Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Wow,\n\nI didn't expect *that much* feedback :-)\nI think I begin slowly to comment some things, and/or tell you\nsome things that are still open.\nThen, maybe, someone of you swoops in :)\n\n> TODO FILE FORMAT\n> ----------------\n\nFirst to say, I tried to be (backwards-)compatible to the \nrebase--interactive TODO file format in \"master\".\nIt became incompatible to the one in \"next\" in one point \nonly (-> merge). But if I understood \"next\" right, this is\nnot bad, since Joerg Sommers rebase-i patchset is still\nopen for discussion (i.e. mark).\n\nWell, now I come to the subject's topic.\n\n\nI've noticed that one thing is *obviously* missing:\n\nThere's a slight asymmetry between\n> file [<options>] <file>::\nand\n> pick [<options>] <commit>::\n> edit <commit>::\n> squash [<options>] <commit>::\n\n\"edit\" is kept for backwards compatibility. It's a short form for and\ninternally `expanded' to \"pick --edit\".\nAs --edit is a general option, there is also \"file --edit\".\nSo there's no functional asymmetry in this case.\n\nIf you want to pick several commits and squash them together, there is\n\"squash\".  BUT there is no equivalent for \"file\" currently.\nThe only way to squash several patches together is with an external tool\nlike your favourite text editor, which is not fun but error-prone.\nAnd there is no way to squash a commit (in the repo) and a patch (as file)\ntogether (in exactly this order). The only thing is that you could run\nsequencer twice and squash in the second move.\n\nSo I wonder if file --squash is useful, too, or even --squash as an\ngeneral option. The latter means that you could squash merge commits\ninto other commits, too.\n\nWe've also discussed the non-atomic approach of doing something like\n\tpick ( a b c d )\t# or another syntax for that\nfor picking multiple commits into one.\nIn my current point of view, this does not seem right, as it:\n - is not atomic ;), and...\n - Well, the approach could be used for \"file ( a b c d )\", too,\n   but it doesn't help for squashing commits AND patches.\n\nComments? Opinions? Ideas?\n\nA first try to prod,\n  Stephan.\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79225","messageId":"alpine.DEB.1.00.0806091503360.1783@racer","threadId":"13855","inReplyTo":"20080609114550.GA8079@leksak.fem-net","subject":"Re: squashing patches (was: Re: [RFC] git-sequencer.txt)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-09T14:04:02Z","receivedAt":"2008-06-09T14:04:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 9 Jun 2008, Stephan Beyer wrote:\n\n> Wow,\n> \n> I didn't expect *that much* feedback :-)\n\nHey, that's a real long document, and some of us have a real job! ;-)\n\nCiao,\nDscho\n"},{"id":"79232","messageId":"484D47C9.9050509@gnu.org","threadId":"13855","inReplyTo":"20080609114550.GA8079@leksak.fem-net","subject":"Re: squashing patches","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-06-09T15:10:01Z","receivedAt":"2008-06-09T15:10:01Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> If you want to pick several commits and squash them together, there is\n> \"squash\".  BUT there is no equivalent for \"file\" currently.\n> The only way to squash several patches together is with an external tool\n> like your favourite text editor, which is not fun but error-prone.\n> And there is no way to squash a commit (in the repo) and a patch (as file)\n> together (in exactly this order). The only thing is that you could run\n> sequencer twice and squash in the second move.\n\nMy feedback is in the message from the \"-s theirs\" thread that I CCed \nyou on.\n\nBasic points:\n\n1) I would like a \"--strategy\" option for cherry-pick and for the \nsequencer's \"pick\";\n\n2) What about\n\n   mark :1\n   pick a\n   file b\n   pick c\n   squash --up-to :1\n\nor, to specify a commit message\n\n   mark :1\n   file a\n   pick b\n   squash --up-to :1 -C HEAD^\n\nor also\n\n   mark :1\n   file a\n   pick b\n   squash --up-to :1 -C HEAD^ -s\n\nto merge all signoffs.  This could be done by providing a stand-alone \ngit-squash command; or alternatively, it could be done in the sequencer \nand the git-squash command would simply do\n\n   (echo 'mark :1'\n    git-rev-list --reverse $1.. | sed 's,^,pick '\n    echo \"squash --up-to :1 $*\") | git-sequencer\n\nafter some option parsing.\n\n3) I would like a totally batch mode-of-operation, which would fail if \nuser intervention was needed (the user could choose whether to not edit \nthe editor, or whether to use a no-op for GIT_EDITOR).\n\n4) I think the sequencer is an opportunity to improve some commands, \ne.g. git-cherry-pick should grow more or less the same options as \ngit-sequencer's pick.\n\nPaolo\n"},{"id":"79235","messageId":"484D4F8C.7030600@gnu.org","threadId":"13855","inReplyTo":"484D47C9.9050509@gnu.org","subject":"Re: squashing patches","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-06-09T15:43:08Z","receivedAt":"2008-06-09T15:43:08Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Paolo Bonzini wrote:\n> the git-squash command would simply do\n> \n>   (echo 'mark :1'\n>    git-rev-list --reverse $1.. | sed 's,^,pick '\n>    echo \"squash --up-to :1 $*\") | git-sequencer\n\nNah this makes no sense, sorry.\n\nPaolo\n"},{"id":"79239","messageId":"20080609162909.GC8079@leksak.fem-net","threadId":"13855","inReplyTo":"484D47C9.9050509@gnu.org","subject":"Re: squashing patches","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-09T16:29:09Z","receivedAt":"2008-06-09T16:29:09Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\n> My feedback is in the message from the \"-s theirs\" thread that I CCed  \n> you on.\n\nWell, I've noticed and read it, but haven't knowm what I wanted to \nreply. :)\n\n> Basic points:\n>\n> 1) I would like a \"--strategy\" option for cherry-pick and for the  \n> sequencer's \"pick\";\n\nIf somebody adds a --strategy option to cherry-pick and it gets\ninto \"next\", I have no problem to let sequencer pass the option to\ncherry-pick ;)\n\nBtw, I like the idea of cherry-pick --strategy=theirs (though I don't\nknow if I'd ever use it), but this is currently beyond my task ;-)\n\n> 2) What about\n>\n>   mark :1\n>   pick a\n>   file b\n>   pick c\n>   squash --up-to :1\n\nI like the idea.  And the others?\n\n--- a/Documentation/git-sequencer.txt\n+++ b/Documentation/git-sequencer.txt\n@@ -212,6 +216,12 @@ squash [<options>] <commit>::\n +\n See 'GENERAL OPTIONS' for values of `<option>`.\n \n+squash [<options>] --up-to <mark>::\n+\tSquash all commits up to the given mark into one commit.\n+\tThere must not be any merge commits in between.\n++\n+See 'GENERAL OPTIONS' for values of `<option>`.\n+\n \n tag <tag>::\n \tSet tag `<tag>` to the current HEAD,\n\n> or, to specify a commit message\n>\n>   mark :1\n>   file a\n>   pick b\n>   squash --up-to :1 -C HEAD^\n\nReusing the commit message may be useful, too, agreed.\nI think that this is something that can be put to the \n\"GENERAL OPTIONS\" section:\n\n--- a/Documentation/git-sequencer.txt\n+++ b/Documentation/git-sequencer.txt\n@@ -240,6 +250,12 @@ when finished.\n \tOverride the author name and e-mail address used in the commit.\n \tUse `A U Thor <author@example.com>` format.\n \n+-C <commit-ish>::\n+--reuse-message=<commit-ish>::\n+\tReuse message from specified commit.\n+\tNote, that only the commit message is reused\n+\tand not the authorship information.\n+\n -F <file>::\n --file=<file>::\n \tTake the commit message from the given file.\n--\n\nOk?\n\n\nIf you want also the authorship information, there's the --reference\nwhich is atm only available for the \"merge\" insn.\nCurrently I also wonder, why only merge has this option ;-)\n\nShould this be a General Option, too?\n\n--- a/Documentation/git-sequencer.txt\n+++ b/Documentation/git-sequencer.txt\n@@ -182,9 +189,6 @@ or `--standard`), an editor will be invoked.\n +\n See the following list and 'GENERAL OPTIONS' for values of `<option>`:\n \n-\t--reference=<commit-ish>;;\n-\t\tTake author and commit message of <commit-ish>.\n-\t\n \t--standard;;\n \t\tGenerates a commit message like 'Merge ... into HEAD'.\n \t\tSee also linkgit:git-fmt-merge-msg[1].\n@@ -247,6 +263,10 @@ when finished.\n -m <msg>::\n --message=<msg>::\n \tUse the given `<msg>` as the commit message.\n+\t\n+--reference=<commit-ish>::\n+\tTake author and commit message of <commit-ish>.\n+\t\n \n -s::\n --signoff::\n--\n\n> or also\n>\n>   mark :1\n>   file a\n>   pick b\n>   squash --up-to :1 -C HEAD^ -s\n>\n> to merge all signoffs.\n\nHm, this is a bit too specific I think.\nDo I interpret your example right, that you want to \nsquash \"a\" and \"b\", reuse the commit message of the\nnewly commited patch \"a\", but also add the signoff of\n\"b\"? (And perhaps, if not set, the own signoff?)\n\nIf I put this into sequencer, I'd like to name\nthat --squash-signoffs (or --merge-signoffs) or something,\nbecause -s/--signoff is a general option atm, that adds\nyour signoff.\n\nWhat do the others think? (Sorry for my questions to \"the others\", \nbut I need some input. *grin*)\n\n> This could be done by providing a stand-alone  \n> git-squash command; or alternatively, it could be done in the sequencer  \n\nThe git-squash approach looks clean to me.\n\n>   (echo 'mark :1'\n>    git-rev-list --reverse $1.. | sed 's,^,pick '\n>    echo \"squash --up-to :1 $*\") | git-sequencer\n\nI notice that you indirectly changed the synopsis, intuitively.\nThis shows me, that we should change it ;-)\nAccording to the current SYNOPSIS you have to do \"git-sequencer -\"\nto read from stdin.\n\n> 3) I would like a totally batch mode-of-operation, which would fail if  \n> user intervention was needed\n\nI like the idea.\n\n--- a/Documentation/git-sequencer.txt\n+++ b/Documentation/git-sequencer.txt\n@@ -8,7 +8,7 @@ git-sequencer - Execute a sequence of git instructions\n SYNOPSIS\n --------\n [verse]\n-'git-sequencer' [-v | --verbose] <file> [<branch>]\n+'git-sequencer' [--batch] [-v | --verbose] <file> [<branch>]\n 'git-sequencer' --continue | --skip | --abort | --edit\n\n@@ -59,6 +59,13 @@ OPTIONS\n <branch>::\n \tWorking branch; defaults to HEAD.\n \n+--batch::\n+\tRun in batch mode. If unexpected user intervention is needed\n+\t(e.g. a conflict or the need to run an editor), git-sequencer fails.\n++\n+Note that the sanity check fails, if you use this option\n+and an instruction like `edit` or the `--edit` option.\n+\n --continue::\n \tRestart the sequencing process after having resolved a merge conflict.\n \n--\n\nOk?\n\n> (the user could choose whether to not edit the editor,\n> or whether to use a no-op for GIT_EDITOR).\n\nI don't understand ;-)\n\n> 4) I think the sequencer is an opportunity to improve some commands,  \n> e.g. git-cherry-pick should grow more or less the same options as  \n> git-sequencer's pick.\n\nHmmmmm, basically I like this approach.\nLet's for example take the \"merge --reference=<commit>\" option.\nIt fetches the information from a former commit, and then does\ngit merge with different authorship information and -m \"message bla\".\nSo the basics are there, they just have to be put together.\nDo you think it's useful to add something like --reference (or -C,\nor however it is called) to git-merge?\n\nThanks and regards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79242","messageId":"484D5C5B.9090804@gnu.org","threadId":"13855","inReplyTo":"20080609162909.GC8079@leksak.fem-net","subject":"Re: squashing patches","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-06-09T16:37:47Z","receivedAt":"2008-06-09T16:37:47Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n>> (the user could choose whether to not edit the editor,\n>> or whether to use a no-op for GIT_EDITOR).\n\nRight now, doing\n\npick a\nsquash b\n\nwill always invoke the editor.  It could be possible to have two \noperation modes.  One in which the sanity check fails, one in which the \nautomatic concatenation of two commit messages is used.\n\n> Do you think it's useful to add something like --reference (or -C,\n> or however it is called) to git-merge?\n\nMaybe it's not useful, but I think it's cleaner than adding the option \nonly to git-sequencer.\n\nPaolo\n\nps: sure you should ask \"the others\" (who are more knowledgeable than me \nBTW) for opinions about what I proposed.\n"},{"id":"79243","messageId":"m3d4mqwnxh.fsf@localhost.localdomain","threadId":"13855","inReplyTo":"20080607220101.GM31040@leksak.fem-net","subject":"Re: [RFC] git-sequencer.txt","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-09T16:49:44Z","receivedAt":"2008-06-09T16:49:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Stephan Beyer <s-beyer@gmx.net> writes:\n\n> ------------------------------ git-sequencer.txt ------------------------------\n> git-sequencer(1)\n> ================\n> \n> NAME\n> ----\n> git-sequencer - Execute a sequence of git instructions\n> \n> SYNOPSIS\n> --------\n> [verse]\n> 'git-sequencer' [-v | --verbose] <file> [<branch>]\n\nI think that you should think carefully if there would be no troubles\nwith this way of specifying options.  Perhaps explicit file option\n(-F/--file=<file>), or optional '--' separating revisions.  But\nperhaps my fears are for nothing, and current proposal is good\nsolution.\n\n> 'git-sequencer' --continue | --skip | --abort | --edit\n\nThe common '--continue | --skip | --abort' infrastructure is, I think,\none of the most important things about this.  I'd like to have\n'--what' (or '--status') option to tell us if we are in the middle of\nsequence of oprations, and what this sequence is (rebase, rebase -i,\nam, revert, cherry-pick, sequencer <file>,...).\n\n> TODO FILE FORMAT\n> ----------------\n> edit <commit>::\n> file [<options>] <file>::\n> mark <mark>::\n> merge [<options>] <commit-ish1> <commit-ish2> ... <commit-ishN>::\n\n> pick [<options>] <commit>::\n> \tPick (see linkgit:git-cherry-pick[1]) a commit.\n> \tSequencer will pause on conflicts.\n\nTwo comments (as I don't use \"git rebase -i\", preferring to work with\nStGIT, Quilt-like patch management interface).\n\nFirst, if git-sequencer is to become backbone for cherry-pick,\nallowing for example long requested cherry-picking multiple commits\n(squasing them or not into single commit), is should be able to use it\nalso for git-revert.  Thus I'd like to have either \"pick -R\" or\n\"revert\" command.\n\nSecond, about \"pick\" accepring (I guess) git-cherry-pick options: I\nwould like to have documentation on '--mainline <parent-number>'\noption in git-sequencer manpage, or at lest explicitely mentioned that\nit can be used to pick merge commits.  BTW, is \"pick --no-commit\"\nsymmetric equivalent^W alternative to \"squash\"?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"79252","messageId":"7vprqqh06j.fsf@gitster.siamese.dyndns.org","threadId":"13855","inReplyTo":"20080609114550.GA8079@leksak.fem-net","subject":"Re: squashing patches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-09T19:34:44Z","receivedAt":"2008-06-09T19:34:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephan Beyer <s-beyer@gmx.net> writes:\n\n> So I wonder if file --squash is useful, too, or even --squash as an\n> general option. The latter means that you could squash merge commits\n> into other commits, too.\n>\n> We've also discussed the non-atomic approach of doing something like\n> \tpick ( a b c d )\t# or another syntax for that\n> for picking multiple commits into one.\n> In my current point of view, this does not seem right, as it:\n>  - is not atomic ;), and...\n>  - Well, the approach could be used for \"file ( a b c d )\", too,\n>    but it doesn't help for squashing commits AND patches.\n>\n> Comments? Opinions? Ideas?\n\nI actually expected that the primitive command sequence the backward\ncompatible \"edit\" would expand to would be a pair, \"pick\" followed by\n\"pause\".  Whenever the sequencer sees \"pause\", it does not do anything but\nreports the current HEAD and gives the control back to the user, so that\nthe user can do amend or whatever before telling you to --continue.\n\nSimilarly, I expected the backward-compatible \"squash\" to expand to a\npair, \"pick\" followed by \"zucchini 2\".  Whenever the sequencer sees\n\"zucchini <n>\", it prepares a commit log to describe the top <n> commits,\nresets HEAD back by <n> commits, and gives control to your editor.\n\nAbout the other parts in your original message:\n\n - The \"tag\" command looked a little out of place;\n\n - I would have called your \"file\" command \"patch\" (we might want to have\n   another file related operation later).\n\n - The --author option presumably would be to lie about the authorship but\n   without taking it from an existing commit.  (1) Don't you need to have\n   an option similar to -C option of \"git-commit\"?  (2) Don't you need to\n   also be able to lie about the author timestamp?\n"},{"id":"79261","messageId":"1213043398-30524-1-git-send-email-s-beyer@gmx.net","threadId":"13855","inReplyTo":"484D47C9.9050509@gnu.org","subject":"[RFC/PATCH] Add git-squash tool and tests","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-09T20:29:58Z","receivedAt":"2008-06-09T20:29:58Z","isPatch":true,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"git-squash is a simple command that, given the parent commit of X,\nsquashes the commits X..HEAD into one.\n\nSigned-off-by: Stephan Beyer <s-beyer@gmx.net>\n---\nHi,\n\nperhaps this is a little surprising, but because of:\n> This could be done by providing a stand-alone git-squash command;\nI thought it could be right to quickly write this as a script.\n\nHere it is as RFC, yet without documentation.\n\nJunio, this could be a backend for the zucchini instruction, by just\n zucchini <n>  =>  git-squash \"HEAD~$(expr $n + 1)\"   ;-)\n\n Makefile          |    1 +\n command-list.txt  |    1 +\n git-squash.sh     |   77 +++++++++++++++++++++++++++++++++++++++++++++++++++++\n t/t3150-squash.sh |   66 +++++++++++++++++++++++++++++++++++++++++++++\n 4 files changed, 145 insertions(+), 0 deletions(-)\n create mode 100755 git-squash.sh\n create mode 100755 t/t3150-squash.sh\n\ndiff --git a/Makefile b/Makefile\nindex 1937507..863004b 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -251,6 +251,7 @@ SCRIPT_SH += git-rebase.sh\n SCRIPT_SH += git-repack.sh\n SCRIPT_SH += git-request-pull.sh\n SCRIPT_SH += git-sh-setup.sh\n+SCRIPT_SH += git-squash.sh\n SCRIPT_SH += git-stash.sh\n SCRIPT_SH += git-submodule.sh\n SCRIPT_SH += git-web--browse.sh\ndiff --git a/command-list.txt b/command-list.txt\nindex 3583a33..e342da3 100644\n--- a/command-list.txt\n+++ b/command-list.txt\n@@ -108,6 +108,7 @@ git-show-branch                         ancillaryinterrogators\n git-show-index                          plumbinginterrogators\n git-show-ref                            plumbinginterrogators\n git-sh-setup                            purehelpers\n+git-squash                              mainporcelain\n git-stash                               mainporcelain\n git-status                              mainporcelain common\n git-stripspace                          purehelpers\ndiff --git a/git-squash.sh b/git-squash.sh\nnew file mode 100755\nindex 0000000..64b5949\n--- /dev/null\n+++ b/git-squash.sh\n@@ -0,0 +1,77 @@\n+#!/bin/sh\n+#\n+# Squash commits from HEAD up to ... into one commit.\n+\n+SUBDIRECTORY_OK=Yes\n+OPTIONS_KEEPDASHDASH=\n+OPTIONS_SPEC=\"\\\n+git-squash [options] <commit-ish>\n+--\n+author=           use author <author>\n+C,reuse-message=  use commit data from <commit-ish>\n+F,file=           use commit message in <file>\n+m,message=        use commit message <msg>\n+e,edit            force edit of commit message\n+s,signoff         add Signed-off-by:\n+include-merges    don't fail if merge is in between\n+\"\n+\n+. git-sh-setup\n+require_work_tree\n+\n+# test if working tree is clean\n+git rev-parse --verify HEAD >/dev/null &&\n+git update-index --refresh &&\n+git diff-files --quiet &&\n+git diff-index --cached --quiet HEAD -- ||\n+\tdie \"Working tree is dirty\"\n+\n+git var GIT_COMMITTER_IDENT >/dev/null ||\n+\tdie \"You need to set your committer info first\"\n+\n+HEAD=$(git rev-parse --verify HEAD) ||\n+\tdie \"No HEAD?\"\n+\n+commitstr=\"git commit \"\n+merges=\n+while test $# -gt 1\n+do\n+\tcase \"$1\" in\n+\t-m|-F|-C|--author)\n+\t\tcommitstr=\"$commitstr $1 '$2'\"\n+\t\tshift\n+\t\t;;\n+\t-e|-s)\n+\t\tcommitstr=\"$commitstr $1\"\n+\t\t;;\n+\t--include-merges)\n+\t\tmerges=y\n+\t\t;;\n+\t--)\n+\t\tbreak\n+\t\t;;\n+\tesac\n+\tshift\n+done\n+\n+test $# -gt 2 &&\n+\tdie \"Wrong number of arguments.\"\n+test $# -lt 2 &&\n+\tdie \"No commit given.\"\n+shift\n+\n+commit=\"$1\"\n+git rev-parse --verify \"$commit\" >/dev/null ||\n+\tdie \"$commit is no valid commit.\"\n+\n+# check for merges if no --include-merges given\n+test -z \"$merges\" &&\n+git log \"$commit..\" | grep -q \"^Merge:\" &&\n+\tdie \"$commit..HEAD contains a merge commit. You may try --include-merges.\"\n+\n+# reset and commit\n+git reset --soft \"$commit\"\n+eval \"$commitstr\" || {\n+\tgit reset --hard $HEAD\n+\tdie \"Commit failed\"\n+}\ndiff --git a/t/t3150-squash.sh b/t/t3150-squash.sh\nnew file mode 100755\nindex 0000000..9f18995\n--- /dev/null\n+++ b/t/t3150-squash.sh\n@@ -0,0 +1,66 @@\n+#!/bin/sh\n+\n+test_description='git-squash'\n+\n+. ./test-lib.sh\n+\n+test_expect_success setup '\n+\t: >file1 &&\n+\t: >file2 &&\n+\t: >file3 &&\n+\t: >file4 &&\n+\t: >file5 &&\n+\t: >file6 &&\n+\tgit add file1 &&\n+\tgit commit -m file1 &&\n+\tgit add file2 &&\n+\tgit commit -m file2 &&\n+\tgit checkout -b master2 HEAD^ &&\n+\tgit add file3 &&\n+\tgit commit -m file3 &&\n+\tgit checkout master &&\n+\tgit merge master2 &&\n+\tgit add file4 &&\n+\tgit commit -m file4 &&\n+\tgit add file5 &&\n+\tgit commit -m file5 &&\n+\tgit add file6 &&\n+\tgit commit -m file6\n+'\n+\n+test_expect_success 'git-squash HEAD^ is a nop and fails' '\n+\tgit checkout -b first master &&\n+\t! git squash HEAD^ &&\n+\ttest \"$(git rev-parse HEAD)\" = \"$(git rev-parse first)\" &&\n+\ttest \"$(git rev-parse master)\" = \"$(git rev-parse first)\"\n+'\n+\n+test_expect_success 'git-squash works' '\n+\tgit checkout -b second master &&\n+\tgit squash -m \"file5 and file6\" --signoff HEAD^^ &&\n+\ttest \"$(git rev-parse HEAD)\" = \"$(git rev-parse second)\" &&\n+\ttest -f file1 -a -f file2 -a -f file3 -a \\\n+\t     -f file4 -a -f file5 -a -f file6\n+'\n+\n+test_expect_success 'git-squash fails if merge in between' '\n+\tgit checkout -b third master &&\n+\t! git squash -C master master2^ &&\n+\ttest \"$(git rev-parse HEAD)\" = \"$(git rev-parse third)\" &&\n+\ttest \"$(git rev-parse master)\" = \"$(git rev-parse third)\"\n+'\n+\n+test_expect_success 'git-squash works with --include-merges if merge in between' '\n+\tgit checkout -b fourth master &&\n+\tgit squash -C master --include-merges master2^ &&\n+\ttest \"$(git rev-parse HEAD)\" = \"$(git rev-parse fourth)\"\n+'\n+\n+test_expect_success 'git-squash aborts correctly if no commit message given' '\n+\tgit checkout -b fifth master &&\n+\t! git squash HEAD~2 &&\n+\ttest \"$(git rev-parse HEAD)\" = \"$(git rev-parse fifth)\" &&\n+\ttest \"$(git rev-parse master)\" = \"$(git rev-parse fifth)\"\n+'\n+\n+test_done\n-- \n1.5.5.3\n"},{"id":"79262","messageId":"alpine.DEB.1.00.0806092133260.1783@racer","threadId":"13855","inReplyTo":"1213043398-30524-1-git-send-email-s-beyer@gmx.net","subject":"Re: [RFC/PATCH] Add git-squash tool and tests","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-09T20:34:55Z","receivedAt":"2008-06-09T20:34:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 9 Jun 2008, Stephan Beyer wrote:\n\n> git-squash is a simple command that, given the parent commit of X,\n> squashes the commits X..HEAD into one.\n\nIsn't it possible to do this with something like\n\n\t$ git reset --hard X^ &&\n\t  git merge --no-ff --squash HEAD@{1}\n\n?\n\nCiao,\nDscho\n"},{"id":"79266","messageId":"20080609204327.GD8079@leksak.fem-net","threadId":"13855","inReplyTo":"7vprqqh06j.fsf@gitster.siamese.dyndns.org","subject":"Re: squashing patches","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-09T20:43:27Z","receivedAt":"2008-06-09T20:43:27Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"> > Comments? Opinions? Ideas?\n> \n> I actually expected that the primitive command sequence the backward\n> compatible \"edit\" would expand to would be a pair, \"pick\" followed by\n> \"pause\".\n\nSomething \"like\" this was my veeeery first approach: \"edit\" with commit\nwas the backwards-compatible \"edit\" and without arguments was your\n\"pause\".\nExample:\n\tpick ea7beef\n\tedit\t\t# or \"pause\" as you suggested\nAfter a little discussion this became:\n\tpick --edit ea7beef\n\nAnd I can't objectively say what's better\n\n> Whenever the sequencer sees \"pause\", it does not do anything but\n> reports the current HEAD and gives the control back to the user, so that\n> the user can do amend or whatever before telling you to --continue.\n\nYes.\n\n> Similarly, I expected the backward-compatible \"squash\" to expand to a\n> pair, \"pick\" followed by \"zucchini 2\".  Whenever the sequencer sees\n> \"zucchini <n>\", it prepares a commit log to describe the top <n> commits,\n> resets HEAD back by <n> commits, and gives control to your editor.\n\nThat's right.  See the RFC/PATCH about git-squash mail or its parent\nmail[1] ;-)\n\n 1. http://article.gmane.org/gmane.comp.version-control.git/84391 2) ff.\n    and\n    http://article.gmane.org/gmane.comp.version-control.git/84420\n\nThe open question is, if we should do this by a natural number <n> or\nby a commit.\nThe natural number approach seems easier, but imagine someone pauses\nand does some commits (not --amend)... Here the behavior of these\napproaches differs. ;-)\n\n> About the other parts in your original message:\n> \n>  - The \"tag\" command looked a little out of place;\n\nEh, why?\n\n>  - I would have called your \"file\" command \"patch\" (we might want to have\n>    another file related operation later).\n\nOk. \"file\" and \"patch\" were both choices to me. Don't know, why I\ndecided for \"file\".\n\n>  - The --author option presumably would be to lie about the authorship but\n>    without taking it from an existing commit.  (1) Don't you need to have\n>    an option similar to -C option of \"git-commit\"?  (2) Don't you need to\n>    also be able to lie about the author timestamp?\n\nRight. ;)\n\nRegards and thanks,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79267","messageId":"20080609205321.GA15912@sigill.intra.peff.net","threadId":"13855","inReplyTo":"20080609204327.GD8079@leksak.fem-net","subject":"Re: squashing patches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-09T20:53:21Z","receivedAt":"2008-06-09T20:53:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 09, 2008 at 10:43:27PM +0200, Stephan Beyer wrote:\n\n> Something \"like\" this was my veeeery first approach: \"edit\" with commit\n> was the backwards-compatible \"edit\" and without arguments was your\n> \"pause\".\n> Example:\n> \tpick ea7beef\n> \tedit\t\t# or \"pause\" as you suggested\n> After a little discussion this became:\n> \tpick --edit ea7beef\n> \n> And I can't objectively say what's better\n\nI am just watching this from the sidelines, but it seems to me that you\nare best off creating the directives as modular and orthogonal as\npossible.  It is very simple to create \"pick $1; edit\" from \"pick --edit\n$1\" later, but it is more difficult to go the other way around.\n\nIOW, worry early about flexibility, and later you can build syntactic\nsugar if you need to.\n\n-Peff\n"},{"id":"79268","messageId":"484D984F.20700@gnu.org","threadId":"13855","inReplyTo":"alpine.DEB.1.00.0806092133260.1783@racer","subject":"Re: [RFC/PATCH] Add git-squash tool and tests","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-06-09T20:53:35Z","receivedAt":"2008-06-09T20:53:35Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> Isn't it possible to do this with something like\n> \n> \t$ git reset --hard X^ &&\n> \t  git merge --no-ff --squash HEAD@{1}\n\nYes, that's true!  And very cool.\n\nIn turn, ...\n\n> Junio, this could be a backend for the zucchini instruction, by just\n>  zucchini <n>  =>  git-squash \"HEAD~$(expr $n + 1)\"    ;-) \n\n... zucchini becomes\n\n   git reset --hard HEAD~$(expr $n)\n   git merge --no-ff --squash HEAD@{1}\n\nPaolo\n"},{"id":"79270","messageId":"7vskvmfhjj.fsf@gitster.siamese.dyndns.org","threadId":"13855","inReplyTo":"20080609204327.GD8079@leksak.fem-net","subject":"Re: squashing patches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-09T21:02:40Z","receivedAt":"2008-06-09T21:02:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephan Beyer <s-beyer@gmx.net> writes:\n\n>> > Comments? Opinions? Ideas?\n>> \n>> I actually expected that the primitive command sequence the backward\n>> compatible \"edit\" would expand to would be a pair, \"pick\" followed by\n>> \"pause\".\n>\n> Something \"like\" this was my veeeery first approach: \"edit\" with commit\n> was the backwards-compatible \"edit\" and without arguments was your\n> \"pause\".\n> Example:\n> \tpick ea7beef\n> \tedit\t\t# or \"pause\" as you suggested\n> After a little discussion this became:\n> \tpick --edit ea7beef\n>\n> And I can't objectively say what's better\n\nMe neither.  My \"expectation\" came primarily from what I understood,\nnamely you seemt to prefer atomism, and not from \"I want things to be this\nway\".\n\nIf we think any proposed and future instruction would be reasonable to\nhave --edit option, then all insn implementation would need to support\n\"edit\" option anyway, and the users do not have to remember which insn\ndoes and does not support --edit so both forms would work equally well\n(and \"--edit option\" would make the insn stream shorter, which may be\ngood).  But probably \"mark --edit\" and \"reset --edit\" would not make\nsense, so a separate \"edit\" insn may be more generic and useful.\n\n> The open question is, if we should do this by a natural number <n> or\n> by a commit.\n> The natural number approach seems easier, but imagine someone pauses\n> and does some commits (not --amend)... Here the behavior of these\n> approaches differs. ;-)\n\nI see.  Not using count but setting an explicit mark and using that commit\nsounds more robust, considering that use case.\n\n>> About the other parts in your original message:\n>> \n>>  - The \"tag\" command looked a little out of place;\n>\n> Eh, why?\n\nWhy not?\n\nI just wondered why there was a support only for lightweight tag there.\nYou do not have \"branch\" command, and your \"tag\" command does not seem to\nsupport things like -a, -s, -m<msg>, etc.  Not that I think you should\nsupport full \"tag\" and \"branch\" command set, but it seemed a bit odd.\n"},{"id":"79275","messageId":"alpine.DEB.1.00.0806092232480.1783@racer","threadId":"13855","inReplyTo":"484D984F.20700@gnu.org","subject":"Re: [RFC/PATCH] Add git-squash tool and tests","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-09T21:34:25Z","receivedAt":"2008-06-09T21:34:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 9 Jun 2008, Paolo Bonzini wrote:\n\n> > Junio, this could be a backend for the zucchini instruction, by just\n> >  zucchini <n>  =>  git-squash \"HEAD~$(expr $n + 1)\"    ;-) \n> \n> ... zucchini becomes\n> \n>   git reset --hard HEAD~$(expr $n)\n>   git merge --no-ff --squash HEAD@{1}\n\nExcept that zucchini is meant for the sequencer, which can implement it \nmuch more efficiently (i.e. it does not have to check out HEAD~$n).  Also, \nit must not rely on reflogs being enabled.\n\nsequencer is plumbing, while the reset mantra is porcelain.\n\nCiao,\nDscho\n"},{"id":"79298","messageId":"20080609234208.GE8079@leksak.fem-net","threadId":"13855","inReplyTo":"alpine.DEB.1.00.0806092232480.1783@racer","subject":"Re: [RFC/PATCH] Add git-squash tool and tests","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-09T23:42:08Z","receivedAt":"2008-06-09T23:42:08Z","isPatch":true,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"> Except that zucchini is meant for the sequencer, which can implement it \n> much more efficiently (i.e. it does not have to check out HEAD~$n).  Also, \n> it must not rely on reflogs being enabled.\n> \n> sequencer is plumbing, while the reset mantra is porcelain.\n\nDo I get you right, that the builtin sequencer must not use any of the\nporcelain like cherry-pick, reset and even commit?\n\n(Perhaps I got it wrong, but it doesn't seem \"right\" to me, if a\nplumbing uses porcelain.)\n\nCurrently my prototype *uses* these porcelain, so is it a porcelain in\nits current state? ;)\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79299","messageId":"20080609234610.GF8079@leksak.fem-net","threadId":"13855","inReplyTo":"alpine.DEB.1.00.0806092133260.1783@racer","subject":"Re: [RFC/PATCH] Add git-squash tool and tests","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-09T23:46:10Z","receivedAt":"2008-06-09T23:46:10Z","isPatch":true,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\n> Isn't it possible to do this with something like\n> \n> \t$ git reset --hard X^ &&\n> \t  git merge --no-ff --squash HEAD@{1}\n\n$ git merge --no-ff --squash HEAD@{1}\nYou cannot combine --squash with --no-ff.\n\nBut without --no-ff it somehow squashes to the index, I just have to\ncommit ;-)\n\n\nBtw,\nif you husk and boil git-squash.sh a while, you get down to\n  git reset --soft X^\n  git commit {options}\nwhich is way simpler.\n\nThe rest is just usage-blabla, option passing and checking for merges\nthat should result in an error if no --include-merges is provided.\n\n(But, yes, as git-squash is porcelain this doesn't matter at all.)\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79300","messageId":"20080609235733.GG8079@leksak.fem-net","threadId":"13855","inReplyTo":"20080609205321.GA15912@sigill.intra.peff.net","subject":"Re: squashing patches","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-09T23:57:33Z","receivedAt":"2008-06-09T23:57:33Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\n> I am just watching this from the sidelines, but it seems to me that you\n> are best off creating the directives as modular and orthogonal as\n> possible.  It is very simple to create \"pick $1; edit\" from \"pick --edit\n> $1\" later, but it is more difficult to go the other way around.\n\nPerhaps it is just me, but isn't \"pick X ; edit\"\nmore modular and orthogonal than \"pick --edit X\"? ;-)\n\nBut yes, the \"pick --edit X\" => \"pick X ; edit\" conversion seems easier.\n\nAnd I'm slightly confused which solution seems better to you for now ;)\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79302","messageId":"alpine.DEB.1.00.0806100121150.1783@racer","threadId":"13855","inReplyTo":"20080609234208.GE8079@leksak.fem-net","subject":"Re: [RFC/PATCH] Add git-squash tool and tests","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-10T00:26:33Z","receivedAt":"2008-06-10T00:26:33Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 10 Jun 2008, Stephan Beyer wrote:\n\n> > Except that zucchini is meant for the sequencer, which can implement it \n> > much more efficiently (i.e. it does not have to check out HEAD~$n).  Also, \n> > it must not rely on reflogs being enabled.\n> > \n> > sequencer is plumbing, while the reset mantra is porcelain.\n> \n> Do I get you right, that the builtin sequencer must not use any of the \n> porcelain like cherry-pick, reset and even commit?\n\nAFAIAC cherry-pick and reset, and even commit, are not \"pure\" porcelain: \nyou can rely on their exit code and to a certain extent on their output.  \nAlthough I would rather use commit-tree from a script than commit.\n\nI'd probably even use git update-ref instead of reset --soft, but then, I \n_would_ use cherry-pick.\n\nSo there is a lot of gray.\n\n> (Perhaps I got it wrong, but it doesn't seem \"right\" to me, if a \n> plumbing uses porcelain.)\n> \n> Currently my prototype *uses* these porcelain, so is it a porcelain in \n> its current state? ;)\n\nI would say as long as it is meant to be used by a human, it is porcelain.  \nAnd I do not think that git-sequencer falls into that category.\n\nSo it should avoid pure porcelains, such as \"git show\", and use the \n(robust) low-level tools instead.\n\nBut I feel quite silly talking about that at length; I think that you can \nuse whatever gets a prototype done, and then go on and make it a builtin.\n\nCiao,\nDscho\n"},{"id":"79304","messageId":"20080610003816.GH8079@leksak.fem-net","threadId":"13855","inReplyTo":"7vskvmfhjj.fsf@gitster.siamese.dyndns.org","subject":"Re: squashing patches","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-10T00:38:16Z","receivedAt":"2008-06-10T00:38:16Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\n> > Example:\n> > \tpick ea7beef\n> > \tedit\t\t# or \"pause\" as you suggested\n> > After a little discussion this became:\n> > \tpick --edit ea7beef\n> >\n> > And I can't objectively say what's better\n> \n> Me neither.  My \"expectation\" came primarily from what I understood,\n> namely you seemt to prefer atomism, and not from \"I want things to be this\n> way\".\n\nYes I prefer atomism, because it helps to keep things simple and stupid.\n\n> If we think any proposed and future instruction would be reasonable to\n> have --edit option, then all insn implementation would need to support\n> \"edit\" option anyway, and the users do not have to remember which insn\n> does and does not support --edit\n\nCurrently every insn where it makes sense (indeed, this may be\nsubjective) does support --edit.  So currently \"file\" (or \"patch\"),\n\"pick\", \"merge\" and \"squash\" do, because they commit something.\n\nBut you are right (and I think Peff meant the same), that the separate\ninsn is more generic and thus it's more flexible.\n\nSo would you prefer a)\"pause\" or b)\"edit\"?\nOr as text:\na)\nedit [<commit>]::\n\tPauses the sequencer process to let you manually make changes.\n+\nAfter you have finished your changes and added them to the index,\ninvoke `git-sequencer --continue`.\nIf you only want to edit the last commit message with an editor,\nrun `git commit --amend` (see linkgit:git-commit[1]) before.\n+\nIf `<commit>` is given, pick `<commit>` first. This is a short form for\n`pick <commit>` and `edit` on separate lines.)\n\nb)\nedit <commit>::\n\tPicks a commit and pauses the sequencer process to let you\n\tmake changes.\n+\nThis is a short form for `pick <commit> and `pause` on separate lines.\n\npause::\t\t# (perhaps options may occur later, if they make sense)\n\tPauses the sequencer process to let you manually make changes.\n+\nAfter you have finished your changes and added them to the index, \ninvoke `git-sequencer --continue`.\nIf you only want to edit the last commit message with an editor,\nrun `git commit --amend` (see linkgit:git-commit[1]) before.\n\n\nMore flexible and modular seems to be the approach b).\nBut I want your opinion to go sure. ;-)\n\n> I see.  Not using count but setting an explicit mark and using that commit\n> sounds more robust, considering that use case.\n\nSo I take the --up-to syntax from Paolo?\nSeemed right to me.\n\n> >>  - The \"tag\" command looked a little out of place;\n> >\n> > Eh, why?\n> \n> Why not?\n\nBecause it's practical.\nThe marks are only available during sequencer process and it's just\nuseful to tag something that you can reach by that name afterwards\n(or during sequencing, too).\nThe user could use tag instead of mark if he wants to keep the ref\nafter sequencing.\nI also can imagine sequencer-using scripts, that want to tag a version\nrelease or something.\n\n> I just wondered why there was a support only for lightweight tag there.\n\nBasically because it's in next :)\nAnd then I thought \"Ok, nice. Let's keep it.\".\n\n> You do not have \"branch\" command, and your \"tag\" command does not seem to\n> support things like -a, -s, -m<msg>, etc.\n\nHmmm, -a, -s and -m could even be useful.\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79306","messageId":"20080610010033.GB16050@sigill.intra.peff.net","threadId":"13855","inReplyTo":"20080609235733.GG8079@leksak.fem-net","subject":"Re: squashing patches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-10T01:00:33Z","receivedAt":"2008-06-10T01:00:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 10, 2008 at 01:57:33AM +0200, Stephan Beyer wrote:\n\n> > I am just watching this from the sidelines, but it seems to me that you\n> > are best off creating the directives as modular and orthogonal as\n> > possible.  It is very simple to create \"pick $1; edit\" from \"pick --edit\n> > $1\" later, but it is more difficult to go the other way around.\n> \n> Perhaps it is just me, but isn't \"pick X ; edit\"\n> more modular and orthogonal than \"pick --edit X\"? ;-)\n\nSorry, I chose a bad phrase. When I said \"create X from Y\", I meant\n\"when the user gives you Y, you can produce the canonical X\". Not \"once\nwe have the canonical Y, you can create X out of it.\"\n\nSo I appear to have said the exact opposite of what I meant. :)\n\n> But yes, the \"pick --edit X\" => \"pick X ; edit\" conversion seems easier.\n\nExactly.\n\n-Peff\n"},{"id":"79310","messageId":"20080610012159.GI8079@leksak.fem-net","threadId":"13855","inReplyTo":"m3d4mqwnxh.fsf@localhost.localdomain","subject":"Re: [RFC] git-sequencer.txt","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-10T01:21:59Z","receivedAt":"2008-06-10T01:21:59Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"> > SYNOPSIS\n> > --------\n> > [verse]\n> > 'git-sequencer' [-v | --verbose] <file> [<branch>]\n> \n> I think that you should think carefully if there would be no troubles\n> with this way of specifying options.  Perhaps explicit file option\n> (-F/--file=<file>), or optional '--' separating revisions.  But\n> perhaps my fears are for nothing, and current proposal is good\n> solution.\n\nWell, I think we (my mentors and me) had around three different versions\nof a synopsis.\nATM I think the synopsis is not a very important thing to discuss, as it is\nrelatively easy changeable even in the last minute. ;)\n\nBut what are your actual fears?  What troubles do you think of?\n\n> > 'git-sequencer' --continue | --skip | --abort | --edit\n> \n> The common '--continue | --skip | --abort' infrastructure is, I think,\n> one of the most important things about this.  I'd like to have\n> '--what' (or '--status') option to tell us if we are in the middle of\n> sequence of oprations, and what this sequence is (rebase, rebase -i,\n> am, revert, cherry-pick, sequencer <file>,...).\n\nI've read the discussion about git-what and I wrote it down on a yellow\nmemo sheet *g* (no real TODO list) to have such a thing in git-sequencer.\n\nFirst I didn't want to have it in the prototype so I didn't add it to\nthe spec.\nBut it leads me to an open question I've also noticed on testing:\n\nIf you currently start a rebase or am and there's a conflict and\nyou do\n\tgit sequencer --continue\ninstead of\n\tgit rebase --continue\nor\n\tgit am --resolved\nthe cleanup code of rebase/am is not executed and thus the job is not\nproperly finished.\n\nHow to prevent this?\nMy first idea is the one I don't really like: the user tools temporarily\ngenerate some \"post-sequencer scripts\", that get executed after\nfinished sequencing. This way, it doesn't matter if you call git\nsequencer --continue, git rebase --continue or git am --resolved to \nfinish the job.\n\nThe second idea is that somehow the user tool should set a \"CALLER\"\nenvironment variable or tell the caller otherwise (--caller=rebase?)\nand git-sequencer only continues if called by the same caller.\n\nThe workflow is like this:\n $ git rebase -i\n ...\n Sequencing (3/5)\n Conflict!\n Fix and do git-rebase --continue\n $\n $ # fix\n $\n $ git sequencer --continue\n Use git-rebase --continue.\n $ git-rebase --continue\n ...\n Sequencing finished.\n Succesfully rebased foo bar blub.\n\nThe string \"git-rebase --continue\" (or \"git-am --resolved\") must also be\n-- somehow (environment?) -- transferred to git...\nThe same for --abort and --skip.\n\nIdeas for a clean solution?\n\n> > TODO FILE FORMAT\n> > ----------------\n> > edit <commit>::\n> > file [<options>] <file>::\n> > mark <mark>::\n> > merge [<options>] <commit-ish1> <commit-ish2> ... <commit-ishN>::\n> \n> > pick [<options>] <commit>::\n> > \tPick (see linkgit:git-cherry-pick[1]) a commit.\n> > \tSequencer will pause on conflicts.\n> \n> Two comments (as I don't use \"git rebase -i\", preferring to work with\n> StGIT, Quilt-like patch management interface).\n\nOh, I've neither experienced stgit nor quilt, but I can imagine that it\nis some stack-(or push/pop)-based patch management.\n\n> Thus I'd like to have either \"pick -R\" or \"revert\" command.\n\nOk ;-)\n\n> Second, about \"pick\" accepring (I guess) git-cherry-pick options: I\n> would like to have documentation on '--mainline <parent-number>'\n> option in git-sequencer manpage, or at lest explicitely mentioned that\n> it can be used to pick merge commits.\n\nBtw it is currently pretty stupid and doesn't accept any git-cherry-pick\noptions.\n\nAnd I didn't know that --mainline exists. I've always thought the first\nparent in the parent list is the \"mainline\".\nWell, seems to be an easier-to-use alternative to the \"merge\" insn if you \nwant to keep the non-mainline parents, commit message and authorship.\nSo I think, it's ok to support it ;)\n\n> BTW, is \"pick --no-commit\"  symmetric equivalent^W alternative to \"squash\"?\n\nSeems that it's yet another variant to realize squash, but less generic\nthan the reset --soft ; commit approach.\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79313","messageId":"200806100646.36528.chriscool@tuxfamily.org","threadId":"13855","inReplyTo":"20080610012159.GI8079@leksak.fem-net","subject":"Re: [RFC] git-sequencer.txt","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2008-06-10T04:46:35Z","receivedAt":"2008-06-10T04:46:35Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le mardi 10 juin 2008, Stephan Beyer a écrit :\n> > > SYNOPSIS\n> > > --------\n> > > [verse]\n> > > 'git-sequencer' [-v | --verbose] <file> [<branch>]\n> >\n> > I think that you should think carefully if there would be no troubles\n> > with this way of specifying options.  Perhaps explicit file option\n> > (-F/--file=<file>), or optional '--' separating revisions.  But\n> > perhaps my fears are for nothing, and current proposal is good\n> > solution.\n>\n> Well, I think we (my mentors and me) had around three different versions\n> of a synopsis.\n\nYes, we discussed:\n\n'git-sequencer' [-v | --verbose] [-b <branch>] [<file>]\n\nthat would use stdin if <file> is not provided. If -b <branch> is used and \n<branch> does not already exists, it would create it.\n\n> ATM I think the synopsis is not a very important thing to discuss, as it\n> is relatively easy changeable even in the last minute. ;)\n>\n> But what are your actual fears?  What troubles do you think of?\n>\n> > > 'git-sequencer' --continue | --skip | --abort | --edit\n> >\n> > The common '--continue | --skip | --abort' infrastructure is, I think,\n> > one of the most important things about this.  I'd like to have\n> > '--what' (or '--status') option to tell us if we are in the middle of\n> > sequence of oprations, and what this sequence is (rebase, rebase -i,\n> > am, revert, cherry-pick, sequencer <file>,...).\n>\n> I've read the discussion about git-what and I wrote it down on a yellow\n> memo sheet *g* (no real TODO list) to have such a thing in git-sequencer.\n>\n> First I didn't want to have it in the prototype so I didn't add it to\n> the spec.\n> But it leads me to an open question I've also noticed on testing:\n>\n> If you currently start a rebase or am and there's a conflict and\n> you do\n> \tgit sequencer --continue\n> instead of\n> \tgit rebase --continue\n> or\n> \tgit am --resolved\n> the cleanup code of rebase/am is not executed and thus the job is not\n> properly finished.\n>\n> How to prevent this?\n> My first idea is the one I don't really like: the user tools temporarily\n> generate some \"post-sequencer scripts\", that get executed after\n> finished sequencing. This way, it doesn't matter if you call git\n> sequencer --continue, git rebase --continue or git am --resolved to\n> finish the job.\n>\n> The second idea is that somehow the user tool should set a \"CALLER\"\n> environment variable or tell the caller otherwise (--caller=rebase?)\n> and git-sequencer only continues if called by the same caller.\n\nMaybe the sequencer can look at the filename it is passed.\nIf it is something like \"$GIT_DIR/*/git-rebase--interactive-todo\" that can \nmean it is called by \"git rebase --interactive\".\n\nAnd then maybe when \"git sequencer --continue\" is called interactively, it \ncan say something like:\n\n\"This sequencer run was started by 'git rebase --interactive' please \ncontinue using 'git rebase --continue'.\"\n\nThanks,\nChristian.\n"},{"id":"79314","messageId":"200806100817.42495.jnareb@gmail.com","threadId":"13855","inReplyTo":"20080610012159.GI8079@leksak.fem-net","subject":"Re: [RFC] git-sequencer.txt","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-10T06:17:41Z","receivedAt":"2008-06-10T06:17:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 10 Jun 2008, Stephan Beyer wrote:\n\nCould you please try not to cut (remove) quotes attributions? It is harder to follow discussion without them...\n\n> Jakub Narebski wrote:\n\n>> Second, about \"pick\" accepring (I guess) git-cherry-pick options: I\n>> would like to have documentation on '--mainline <parent-number>'\n>> option in git-sequencer manpage, or at lest explicitely mentioned that\n>> it can be used to pick merge commits.\n> \n> Btw it is currently pretty stupid and doesn't accept any git-cherry-pick\n> options.\n> \n> And I didn't know that --mainline exists. I've always thought the first\n> parent in the parent list is the \"mainline\".\n\nIt depends on the workflow.  Git tries to not make first parent all\nthat special.  Due to using fast-forward yourline can actually be\nsecond parent.\n\nProbably better name would be --pick-parent.  Note that without this\noption there is no way to \"pick\", as in pick changes brought by commit,\nmerge commit (unless you default to first-parent...).\n\n> Well, seems to be an easier-to-use alternative to the \"merge\" insn if you \n> want to keep the non-mainline parents, commit message and authorship.\n> So I think, it's ok to support it ;)\n\nThey are two opposite sides of spectrum.  \"pick --mainline\" is to pick\na merge, \"merge\" is to create merge commit.  You might want to make\nmerge into ordinary commit, make ordinary commit into merge, make merge\ninto merge preserving other parents, make merge into merge rewriting all\nparents.\n\n> > BTW, is \"pick --no-commit\"  symmetric equivalent^W alternative to \"squash\"?\n> \n> Seems that it's yet another variant to realize squash, but less generic\n> than the reset --soft ; commit approach.\n\nI'm not sure if less generic.  You can use \"pick; squash; squash\" or \n\"no-commit; no-commit; pick\".\n-- \nJakub Narebski\nPoland\n"},{"id":"79328","messageId":"20080610085955.GB5642@leksak.fem-net","threadId":"13855","inReplyTo":"200806100646.36528.chriscool@tuxfamily.org","subject":"Re: [RFC] git-sequencer.txt","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-10T08:59:55Z","receivedAt":"2008-06-10T08:59:55Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\n> Maybe the sequencer can look at the filename it is passed.\n> If it is something like \"$GIT_DIR/*/git-rebase--interactive-todo\" that can \n> mean it is called by \"git rebase --interactive\".\n\nIt's another variant, but then with every new sequencer-user you have to\nadd another entry to the \"sequencer caller database\".\n\nThat means: if a user writes a script that uses sequencer he has to make\nchanges to sequencer itself. Baaad for extensibility.\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79427","messageId":"200806110610.50619.chriscool@tuxfamily.org","threadId":"13855","inReplyTo":"20080610085955.GB5642@leksak.fem-net","subject":"Re: [RFC] git-sequencer.txt","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2008-06-11T04:10:50Z","receivedAt":"2008-06-11T04:10:50Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nLe mardi 10 juin 2008, Stephan Beyer a écrit :\n> Hi,\n>\n> > Maybe the sequencer can look at the filename it is passed.\n> > If it is something like \"$GIT_DIR/*/git-rebase--interactive-todo\" that\n> > can mean it is called by \"git rebase --interactive\".\n>\n> It's another variant, but then with every new sequencer-user you have to\n> add another entry to the \"sequencer caller database\".\n>\n> That means: if a user writes a script that uses sequencer he has to make\n> changes to sequencer itself. Baaad for extensibility.\n\nWe could have config options for that. For example:\n\n[sequenceruser \"user_script1\"]\n\tfilename = user-script1-todo\n\tcontinuecall = user_script1.sh --continue\n\nRegards,\nChristian.\n"},{"id":"79465","messageId":"alpine.LNX.1.00.0806111246000.19665@iabervon.org","threadId":"13855","inReplyTo":"200806100646.36528.chriscool@tuxfamily.org","subject":"Re: [RFC] git-sequencer.txt","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-11T17:07:55Z","receivedAt":"2008-06-11T17:07:55Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 10 Jun 2008, Christian Couder wrote:\n\n> Le mardi 10 juin 2008, Stephan Beyer a écrit :\n\n> > But it leads me to an open question I've also noticed on testing:\n> >\n> > If you currently start a rebase or am and there's a conflict and\n> > you do\n> > \tgit sequencer --continue\n> > instead of\n> > \tgit rebase --continue\n> > or\n> > \tgit am --resolved\n> > the cleanup code of rebase/am is not executed and thus the job is not\n> > properly finished.\n> >\n> > How to prevent this?\n> > My first idea is the one I don't really like: the user tools temporarily\n> > generate some \"post-sequencer scripts\", that get executed after\n> > finished sequencing. This way, it doesn't matter if you call git\n> > sequencer --continue, git rebase --continue or git am --resolved to\n> > finish the job.\n> >\n> > The second idea is that somehow the user tool should set a \"CALLER\"\n> > environment variable or tell the caller otherwise (--caller=rebase?)\n> > and git-sequencer only continues if called by the same caller.\n> \n> Maybe the sequencer can look at the filename it is passed.\n> If it is something like \"$GIT_DIR/*/git-rebase--interactive-todo\" that can \n> mean it is called by \"git rebase --interactive\".\n> \n> And then maybe when \"git sequencer --continue\" is called interactively, it \n> can say something like:\n> \n> \"This sequencer run was started by 'git rebase --interactive' please \n> continue using 'git rebase --continue'.\"\n\nI expect that most script users will do something like:\n\n  generate-todo-file | git-sequencer\n\nSo, if there's anything to do to clean up after the outer script, the file \ngit-sequencer gets is probably stdin.\n\nOne solution would be to have a \"caller\" option to sequencer, and when \nsequencer finishes, it runs \"git $caller --cleanup\". That way, you can use \n\"git sequencer --continue\", and it will do the caller-specific cleanup \n(also, don't forget the --abort case).\n\nIt might also be good to have options for some generic stuff, like \"remove \na particular directory\" for callers that can just put all their temporary \nstuff in a single directory and don't have anything to clean up other than \ngetting rid of it.\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"79529","messageId":"20080612002258.GC7200@leksak.fem-net","threadId":"13855","inReplyTo":"20080607220101.GM31040@leksak.fem-net","subject":"[RFCv2/FYI] git-sequencer.txt","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-12T00:22:58Z","receivedAt":"2008-06-12T00:22:58Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\n> I inline-attached the documentation (and somehow specification)\n> for git-sequencer (my GSoC'08 project) for you to comment on.\n\nHere's the second and - if there are no big protests - last attempt\nbefore I send the prototype RFC/PATCH patchset to the list.\n\nNote that I didn't add the \"comment\" (or \"amend\") insn[1] proposed by\nPierre Habouzit currently, but this is no problem.\n\n 1. http://thread.gmane.org/gmane.comp.version-control.git/84616\n\nThere's also an undocumented --caller option.\nI mean, it is as undocumented as \"git-am --rebasing\",\nbecause it should only be used by sequencer user scripts.\n\nRegards,\n  Stephan\n\n------------------------------ git-sequencer.txt ------------------------------\ngit-sequencer(1)\n================\n\nNAME\n----\ngit-sequencer - Execute a sequence of git instructions\n\nSYNOPSIS\n--------\n[verse]\n'git-sequencer' [--batch] [--onto=<base>] [--verbose] [<file>]\n'git-sequencer' --continue | --skip | --abort | --edit | --status\n\n\nDESCRIPTION\n-----------\nExecutes a sequence of git instructions to HEAD or `<base>`.\nThe sequence is given by `<file>` or standard input.\nAlso see 'TODO FILE FORMAT' below.\n\nBefore doing anything, the TODO file is checked for correct syntax \nand sanity.\n\nIn case of a conflict or request in the TODO file, git-sequencer will\npause. On conflict you can use git-diff to locate the markers (`<<<<<<`) \nand make edits to resolve the conflict.\n\nFor each file you edit, you need to tell git the changes by doing\n\n    git add <file>\n\nAfter resolving the conflict manually and updating the index with the\ndesired resolution, you can continue the sequencing process with\n\n    git sequencer --continue\n\nAlternatively, you can undo the git-sequencer progress with\n\n    git sequencer --abort\n\nor skip the current instruction with\n\n    git sequencer --skip\n\nor correct the TODO file with\n\n    git sequencer --edit\n\nDuring pauses or when finished with the sequencing task, the current\nHEAD will always be the result of the last processed instruction.\n\n\nOPTIONS\n-------\n<file>::\n\tFilename of the TODO file.  If omitted, standard input is used.\n\tSee 'TODO FILE FORMAT' below.\n\n-B::\n--batch::\n\tRun in batch mode. If unexpected user intervention is needed\n\t(e.g. a conflict or the need to run an editor), git-sequencer fails.\n+\nNote that the sanity check fails, if you use this option\nand an instruction like `edit` or `pause`.\n\n--onto=<base>::\n\tCheckout given commit or branch before sequencing.\n\tIf you provide a branch, sequencer will make the provided\n\tchanges on the branch, i.e. the branch will be changed.\n\n--continue::\n\tRestart the sequencing process after having resolved a merge conflict.\n\n--abort::\n\tRestore the original branch and abort the sequence operation.\n\n--skip::\n\tRestart the sequencing process by skipping the current patch.\n\n--status::\n\tShow the current status of git-sequencer and what\n\toperations can be done to change that status.\n\n--edit::\n\tInvoke editor to edit the undone rest of the TODO file.\n+\nThe file is syntax- and sanity-checked afterwards, so that you can \nsafely run `git sequencer --skip` or `--continue` after editing.\nIf you nonetheless noticed that you made a mistake, you can \noverwrite `.git/sequencer/todo` with `.git/sequencer/todo.old` and\nrerun `git sequencer --edit`.\n+\nIf the check fails you are prompted if you want to correct your \nchanges, edit again, cancel editing or really want to save.\n\n-v::\n--verbose::\n\tBe more verbose. [XXX: to be defined more accurately, i.e. print diffstat]\n\n\nNOTES\n-----\n\nWhen sequencing, it is possible, that you are changing the history of\na branch in a way that can cause problems for anyone who already has \na copy of the branch in their repository and tries to pull updates from\nyou.  You should understand the implications of using git-sequencer on\na repository that you share.\n\ngit-sequencer will usually be called by another git porcelain, like\nlinkgit:git-am[1] or linkgit:git-rebase[1].\n\n\nTODO FILE FORMAT\n----------------\n\nThe TODO file contains basically one instruction per line.\n\nBlank lines will be ignored. \nAll characters after a `#` character will be ignored until the end of a line.\n\nThe following instructions can be used:\n\n\nedit <commit>::\n\tPicks a commit and pauses the sequencer process to let you\n\tmake changes.\n+\nThis is a short form for `pick <commit> and `pause` on separate lines.\n\n\nmark <mark>::\n\tSet a symbolic mark for the last commit.\n\t`<mark>` is an unsigned integer starting at 1 and\n\tprefixed with a colon, e.g. `:1`.\n+\nThe marks can help if you want to refer to commits that you\ncreated during the sequencer process, e.g. if you want to\nmerge such a commit.\n+\nThe set marks are removed after the sequencer has completed.\n\n\nmerge [<options>] <commit-ish1> <commit-ish2> ... <commit-ishN>::\n\tMerge commits into HEAD.\n+\nA commit can also be given by a mark, if prefixed with a colon.\n+\nIf you do not provide a commit message (using `-F`, `-m`, `--reference` \nor `--standard`), an editor will be invoked.\n+\nSee the following list and 'GENERAL OPTIONS' for values of `<option>`:\n\n\t--standard;;\n\t\tGenerates a commit message like 'Merge ... into HEAD'.\n\t\tSee also linkgit:git-fmt-merge-msg[1].\n\t\n\t-s <strategy>;;\n\t--strategy=<strategy>;;\n\t\tUse the given merge strategy.\n\t\tSee also linkgit:git-merge[1].\n\n\npick [<options>] <commit>::\n\tPick (see linkgit:git-cherry-pick[1]) a commit.\n\tSequencer will pause on conflicts.\n+\nSee the following list and 'GENERAL OPTIONS' for values of `<option>`:\n\n\t-R;;\n\t--revert;;\n\t\tRevert the changes introduced by pick <commit>.\n\t\n\t--mainline=<n>;;\n\t--pick-parent=<n>;;\n\t\tAllows you to pick merge commits by specifying the\n\t\tparent number (beginning from 1) to let sequencer\n\t\treplay the changes relative to the specified parent.\n\n\npatch [<options>] <file>::\n\tIf file `<file>` is a pure (diff) patch, then apply the patch.\n\tIf no `--message` option is given, an editor will\n\tbe invoked to enter a commit message.\n+\nIf `<file>` is a linkgit:git-format-patch[1]-formatted patch,\nthen the patch will be commited.\n+\nSee the following list and 'GENERAL OPTIONS' for values of `<option>`:\n\n\t-3;;\n\t--3way;;\n\t\tWhen the patch does not apply cleanly, fall back on\n\t\t3-way merge, if the patch records the identity of blobs\n\t\tit is supposed to apply to, and we have those blobs\n\t\tavailable locally.\n\n\t-k;;\n\t\tPass `-k` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).\n\n\t-n;;\n\t\tPass `-n` flag to `git-mailinfo` (see\n\t\tlinkgit:git-mailinfo[1]).\n\n\t-u;;\n\t\tPass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).\n\t\tThe proposed commit log message taken from the e-mail\n\t\tis re-coded into UTF-8 encoding (configuration variable\n\t\t`i18n.commitencoding` can be used to specify project's\n\t\tpreferred encoding if it is not UTF-8).\n+\nThis was optional in prior versions of git, but now it is the\ndefault. You could use `-n` to override this.\n\n\t-*;;\n\t\tAny other dash-prefixed option is passed to\n\t\tlinkgit:git-apply[1].\n\t\tThis is especially useful for flags like\n\t\t`--reverse`, `-C<n>`, `-p<n>` or `--whitespace=<action>`.\n\n\npause::\n\tPauses the sequencer process to let you manually make changes.\n\tFor example, you can re-edit the done commit, fix bugs or typos,\n\tor you can make further commits on top of HEAD before continuing.\n+\nAfter you have finished your changes and added them to the index,\ninvoke `git-sequencer --continue`.\nIf you only want to edit the last commit message with an editor,\nrun `git commit --amend` (see linkgit:git-commit[1]) before.\n\n\nreset <commit-ish>::\n\tGo back (see linkgit:git-reset[1] `--hard`) to commit `<commit-ish>`.\n\t`<commit-ish>` can also be given by a mark, if prefixed with a colon.\n\n\nsquash [<options>] <commit>::\n\tAdd the changes introduced by `<commit>` to the last commit.\n+\nSee 'GENERAL OPTIONS' for values of `<option>`.\n\nsquash [<options>] --up-to <mark>::\n\tSquash all commits up to the given mark into one commit.\n\tThere must not be any merge commits in between.\n+\nSee the following list and 'GENERAL OPTIONS' for values of `<option>`:\n\n\t--collect-signoffs;;\n\t\tCollect the Signed-by-off: lines of each commit and\n\t\tadd them to the squashed commit message.\n\t\n\t--include-merges;;\n\t\tSanity check does not fail if you have merges\n\t\tbetween HEAD and <mark>.\n\n\ntag <tag>::\n\tSet tag `<tag>` to the current HEAD,\n\tsee also linkgit:git-tag[1].\n\tIf another commit is tagged `<tag>`, it will lose this tag,\n\ti.e. the tag will be reset to HEAD.\n\n\n\nGENERAL OPTIONS\n---------------\n\nBesides some special options, the instructions\n`patch`, `merge`, `pick`, `squash` take the following general options:\n\n--author=<author>::\n\tOverride the author name and e-mail address used in the commit.\n\tUse `A U Thor <author@example.com>` format.\n\n-C <commit-ish>::\n--reuse-commit=<commit-ish>::\n--reference=<commit-ish>::\n\tReuse message and authorship data from specified commit.\n\n-M <commit-ish>\n--reuse-message=<commit-ish>::\n\tReuse message from specified commit.\n\tNote, that only the commit message is reused\n\tand not the authorship information.\n\n-F <file>::\n--file=<file>::\n\tTake the commit message from the given file.\n\n-m <msg>::\n--message=<msg>::\n\tUse the given `<msg>` as the commit message.\n\n-s::\n--signoff::\n\tAdd `Signed-off-by:` line to the commit message (if not yet there),\n\tusing the committer identity of yourself.\n\n\nRETURN VALUES\n-------------\n\ngit-sequencer returns:\n\n* `0`, if git-sequencer successfully completed all the instructions\n       in the TODO file or successfully aborted after\n       `git-sequencer --abort`,\n* `2`, on user-requested pausing, e.g.\n       when using the `edit` instruction.\n* `3`, on pauses that are not requested, e.g.\n       when there are conflicts to resolve.\n* any other value on error, e.g.\n  syntax errors in the TODO file or\n  running git-sequencer on a bare repository.\n\n\nEXAMPLES\n--------\n\nXXX [Here the usage of all commands should become clear,\nbut it's braindamaged to write this section as long as the file format\nis in discussion.]\n\n\nSEE ALSO\n--------\nlinkgit:git-add[1],\nlinkgit:git-am[1],\nlinkgit:git-cherry-pick[1],\nlinkgit:git-commit[1],\nlinkgit:git-fmt-merge-msg[1],\nlinkgit:git-format-patch[1],\nlinkgit:git-rebase[1],\nlinkgit:git-reset[1],\nlinkgit:git-tag[1]\n\n\nAuthors\n-------\nXXX\n\nDocumentation\n-------------\nDocumentation by Stephan Beyer and the git-list <git@vger.kernel.org>.\n\nGIT\n---\nPart of the linkgit:git[1] suite\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79532","messageId":"48507C70.8010402@gnu.org","threadId":"13855","inReplyTo":"20080612002258.GC7200@leksak.fem-net","subject":"Re: [RFCv2/FYI] git-sequencer.txt","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-06-12T01:31:28Z","receivedAt":"2008-06-12T01:31:28Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> \t--collect-signoffs;;\n> \t\tCollect the Signed-by-off: lines of each commit and\n> \t\tadd them to the squashed commit message.\n\nI think this makes sense only if -m/-F/-C/-c (see later) is used, \nbecause otherwise the default behavior would be to concatenate all \nmessages and call the editor, right?  Would it be a no-op if those \noptions are not given?\n\n> tag <tag>::\n> \tSet tag `<tag>` to the current HEAD,\n> \tsee also linkgit:git-tag[1].\n> \tIf another commit is tagged `<tag>`, it will lose this tag,\n> \ti.e. the tag will be reset to HEAD.\n\nIs this a lightweight or a heavyweight tag?  I guess lightweight -- the \ntag command should probably support -a, -s and -u like git-tag does. \nUnless -c/-C/-F/-m is given, the sequencer will then run the editor.\n\n> -C <commit-ish>::\n> --reuse-commit=<commit-ish>::\n> --reference=<commit-ish>::\n> \tReuse message and authorship data from specified commit.\n\nWhy --reference?  Also,\n\n> -M <commit-ish>\n> --reuse-message=<commit-ish>::\n> \tReuse message from specified commit.\n> \tNote, that only the commit message is reused\n> \tand not the authorship information.\n\nFor consistency with git-commit I would think it's better to have\n\n   -c <commit-ish>::\n   -C <commit-ish>::\n   --reedit-message=<commit-ish>::\n   --reuse-message=<commit-ish>::\n\tTake existing commit object, and reuse the log message and the\n         authorship information (including the timestamp) when creating\n         the commit. With -C (or --reuse-message), the editor is not\n\tinvoked; with -c (or --reedit-message) the user can further edit\n\tthe commit message.\n\n(I know it's confusing that it's reusing the message too, but...) and \nthen a separate option:\n\n   -A\n   --author-override::\n\tForce authorship information for commits created by the command\n\tto be the data in git's configuration files.\n\n... if it is not too complicated to implement.\n\nTo satisfy Pierre's comment, you might also add a \"-e\" general option, \nwhich forces an invocation of the editor -- even if -C/-m/-F are given, \nand even if the command is pick/patch/merge.  I guess that in order to \nsupport -C/-m/-F you already have to use git-cherry-pick and git-merge's \n--no-commit options, so it should not be hard to implement.\n\nPaolo\n"},{"id":"79542","messageId":"7vabhr9qru.fsf@gitster.siamese.dyndns.org","threadId":"13855","inReplyTo":"20080612002258.GC7200@leksak.fem-net","subject":"Re: [RFCv2/FYI] git-sequencer.txt","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-12T05:16:37Z","receivedAt":"2008-06-12T05:16:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephan Beyer <s-beyer@gmx.net> writes:\n\n> Note that the sanity check fails, if you use this option\n> and an instruction like `edit` or `pause`.\n>\n> --onto=<base>::\n> \tCheckout given commit or branch before sequencing.\n> \tIf you provide a branch, sequencer will make the provided\n> \tchanges on the branch, i.e. the branch will be changed.\n\nI think you called this --onto by modeling after rebase, but I am not sure\nif that is a good generic naming.  Worse, \"a branch that is not the\ncurrent one that is rebased\" in rebase is not specified with \"--onto\" but\nwith the extra argument.\n\nIs checking out that <base> branch considered as part of the sequencing\noperation, or it is something that happens before the sequencing?  In\nother words, if a sequencing stops and the user says \"sequencer --abort\",\nwhere does it take the user back to?  The state the <base> is checked out,\nor the state before that checkout happened?  Can't the front-end emit an\ninsn to checkout or detach as the first insn?\n\nBy the way, is it specified if sequencer will always work by:\n\n (1) remember the initial branch;\n\n (2) detach the HEAD;\n\n (3) run the operation;\n\n (4) and finally (unless the user says --abort) reattaching the original\n     branch to the resulting HEAD?\n\nThat would mean the sequencer would essentially munge only one branch\n(unless started from a detached HEAD state).  I think this is a reasonable\ndesign decision (and a limitation) for the currently expected front-ends,\nbut I think this is a perfectly sane backend for filter-branch (without\nany tree or content munging), and this limitation might later come back\nand bite us.\n\n> --skip::\n> \tRestart the sequencing process by skipping the current patch.\n\n\"patch\"?\n\nWhat is the set of insn that can possibly give control back and give\nyou a chance to say \"--skip\"?\n\n - pick can conflict and --skip would mean \"reset to the tree before the\n   pick and continue on to the next insn\";\n\n - Same goes for merge and patch (the semantics of \"squash <commit>\" is\n   fuzzy to me);\n\n - pause can give control back to you.  What should --skip do?  I guess\n   \"no-op\" is the right answer.\n\n> --status::\n> \tShow the current status of git-sequencer and what\n> \toperations can be done to change that status.\n\nMeaning \"what insns have we done, what insn were we in the middle of\nexecuting, and what insns are still remaining\"?\n\n> merge [<options>] <commit-ish1> <commit-ish2> ... <commit-ishN>::\n> \tMerge commits into HEAD.\n> +\n> A commit can also be given by a mark, if prefixed with a colon.\n> +\n> If you do not provide a commit message (using `-F`, `-m`, `--reference` \n> or `--standard`), an editor will be invoked.\n> +\n> See the following list and 'GENERAL OPTIONS' for values of `<option>`:\n>\n> \t--standard;;\n> \t\tGenerates a commit message like 'Merge ... into HEAD'.\n> \t\tSee also linkgit:git-fmt-merge-msg[1].\n\nIt seems you are assuming (and I am not saying it is a bad assumption)\nthat sequencer first detached the HEAD and operates on that state until it\nis done.  Perhaps we would want to reword \"into HEAD\" somehow?  If we are\nrebasing branch \"main\", even if sequencer internally detaches the HEAD to\ncarry out individual steps, we would want to see the resulting history to\nsay \"into main\", wouldn't we?\n\n> patch [<options>] <file>::\n> \tIf file `<file>` is a pure (diff) patch, then apply the patch.\n> \tIf no `--message` option is given, an editor will\n> \tbe invoked to enter a commit message.\n\nHmm.  Are there cases where you might want to feed more than one patches\nand then finally make the commit?  You could emulate it with\n\n\tmark :1\n\tpatch --message=dummy file1\n        patch --message=dummy file2\n\tsquash --upto :1\n\nbut it might make sense to allow more than one files for this use case,\nlike\n\n\tpatch file1 file2\n\nAlthough that would introduce another issue, which is what to do if file1\nis a naked diff and file2 is a mbox (with possibly more than one patches),\nor vice versa.\n\n>...\n> \t-u;;\n> \t\tPass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).\n>...\n> This was optional in prior versions of git, but now it is the\n> default. You could use `-n` to override this.\n\nI personally do not think it is worth supporting this b/c compatibility\noption in a new command \"sequencer\".\n\n> pause::\n> \tPauses the sequencer process to let you manually make changes.\n> \tFor example, you can re-edit the done commit, fix bugs or typos,\n> \tor you can make further commits on top of HEAD before continuing.\n> +\n> After you have finished your changes and added them to the index,\n> invoke `git-sequencer --continue`.\n> If you only want to edit the last commit message with an editor,\n> run `git commit --amend` (see linkgit:git-commit[1]) before.\n\nbefore \"saying --continue\"?\n\n> reset <commit-ish>::\n> \tGo back (see linkgit:git-reset[1] `--hard`) to commit `<commit-ish>`.\n> \t`<commit-ish>` can also be given by a mark, if prefixed with a colon.\n>\n> squash [<options>] <commit>::\n> \tAdd the changes introduced by `<commit>` to the last commit.\n\nJust like you explained \"edit <commit>\" in terms of \"pick\" and \"pause\", we\nmight want to explain that this is \"pick\" and \"squash --up-to HEAD^\" (or\nis it HEAD^^\"?).\n\n> +\n> See 'GENERAL OPTIONS' for values of `<option>`.\n>\n> squash [<options>] --up-to <mark>::\n> \tSquash all commits up to the given mark into one commit.\n> \tThere must not be any merge commits in between.\n\n\"In between\" in \"inclusive\" sense, that is, neither <mark> nor HEAD cannot\nbe a merge?  Also --up-to feels somewhat wrong.  It is more like down-to\nbut perhaps \"from\" would be a better wording.\n\n> \t--include-merges;;\n> \t\tSanity check does not fail if you have merges\n> \t\tbetween HEAD and <mark>.\n\nAnd what gets recorded?  A squashed merge?\n\nA \"squash --up-to <mark>\" (modulo off-by-one I can never get straight X-<)\nessentially:\n\n\tlog --reverse <mark>.. >msg\n\treset --soft <mark>\n        commit --amend -F msg\n\nso recording this result, when there is a merge in between, is like\nrunning \"merge --squash\".\n\n> tag <tag>::\n> \tSet tag `<tag>` to the current HEAD,\n> \tsee also linkgit:git-tag[1].\n> \tIf another commit is tagged `<tag>`, it will lose this tag,\n> \ti.e. the tag will be reset to HEAD.\n\nHmm.  It is hard to judge this without seeing how the front-ends use it.\nIt might make sense to give lower-level access to update-ref instead, so\nthat more than one branches can be updated as well, but I am not sure.\nHow would this interact with \"--abort\"?\n"},{"id":"79597","messageId":"200806121610.43674.jnareb@gmail.com","threadId":"13855","inReplyTo":"20080612002258.GC7200@leksak.fem-net","subject":"Re: [RFCv2/FYI] git-sequencer.txt","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-12T14:10:42Z","receivedAt":"2008-06-12T14:10:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Stephan Beyer wrote:\n>\n> git-sequencer(1)\n> ================\n> \n> NAME\n> ----\n> git-sequencer - Execute a sequence of git instructions\n> \n> SYNOPSIS\n> --------\n> [verse]\n> 'git-sequencer' [--batch] [--onto=<base>] [--verbose] [<file>]\n> 'git-sequencer' --continue | --skip | --abort | --edit | --status\n\nI'm not sure if --edit should be mentioned in line with \"processing\"\ncommands: --continue, --skip, --abort and related --status.\n \nI'm not sure if it is necessary at all, but if we want to have this\nequivalent to \"git rebase --interactive\" it should be, I think, put\nseparately.\n\n> Alternatively, you can [...] correct the TODO file with\n> \n>     git sequencer --edit\n\nCan you ensure that editor would be invoked with current line\nat the current action (isns?)?  Or will you be presenting only\nwith not performed yet actions?  If not, what would happen if\nuser modifies actions which had been done already?\n\nIn short, this is difficult thing to implement... besides of\ncourse initial edit, with series file seeded by current history\n\"replay\" description.\n \n> OPTIONS\n> -------\n> <file>::\n> \tFilename of the TODO file.  If omitted, standard input is used.\n> \tSee 'TODO FILE FORMAT' below.\n\nOmitted for standard input, --stdin for standard imput, or special\nfilename of '-' for standard input?\n \n> --onto=<base>::\n> \tCheckout given commit or branch before sequencing.\n> \tIf you provide a branch, sequencer will make the provided\n> \tchanges on the branch, i.e. the branch will be changed.\n\nI'm not sure if repeating rebase design is best idea.  But this\nferature is certainly necessary...\n \n> --status::\n> \tShow the current status of git-sequencer and what\n> \toperations can be done to change that status.\n\nHow it would look like?  Current caller, current operation, progress\nreport (action n/m), status (e.g. CONFLICT or edit, or amend),\nsuggested actions (--continue, sometimes --skip, --abort)?\n \n> --edit::\n> \tInvoke editor to edit the undone rest of the TODO file.\n\nAhh... only the rest of the file...\n\n> -v::\n> --verbose::\n> \tBe more verbose. [XXX: to be defined more accurately, i.e. print diffstat]\n\nI think it would be nice to have --quiet mode (which perhaps --batch\nwould imply, or perhaps not), which would make git-sequencer to not\nreport progress report (i.e. which actions are being done).\n \n> git-sequencer will usually be called by another git porcelain, like\n> linkgit:git-am[1] or linkgit:git-rebase[1].\n\nOr git-cherry-pick, or git-revert.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"79601","messageId":"20080612152928.GB6848@leksak.fem-net","threadId":"13855","inReplyTo":"48507C70.8010402@gnu.org","subject":"Re: [RFCv2/FYI] git-sequencer.txt","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-12T15:29:28Z","receivedAt":"2008-06-12T15:29:28Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nOn Wed, Jun 11, 2008 at 06:31:28PM -0700,\nPaolo Bonzini <bonzini@gnu.org> wrote to git@vger.kernel.org:\n>> \t--collect-signoffs;;\n>> \t\tCollect the Signed-by-off: lines of each commit and\n>> \t\tadd them to the squashed commit message.\n>\n> I think this makes sense only if -m/-F/-C/-c (see later) is used,  \n> because otherwise the default behavior would be to concatenate all  \n> messages and call the editor, right?  Would it be a no-op if those  \n> options are not given?\n\nNo, because the default behavior is cat it all together and call the\neditor, the user sees in the editor:\n\n\tMessage of commit 1\n\n\tSigned-off-by: A\n\n\tMessage of commit 2\n\n\tSigned-off-by: B\n\n\tMessage of commit 3\n\n\tSigned-off-by: A\n\tSigned-off-by: C\n\nAnd with --collect-signoffs this could be like:\n\n\tMessage of commit 1\n\n\tMessage of commit 2\n\n\tMessage of commit 3\n\n\tSigned-off-by: A\n\tSigned-off-by: B\n\tSigned-off-by: C\n\n>> tag <tag>::\n>> \tSet tag `<tag>` to the current HEAD,\n>> \tsee also linkgit:git-tag[1].\n>> \tIf another commit is tagged `<tag>`, it will lose this tag,\n>> \ti.e. the tag will be reset to HEAD.\n>\n> Is this a lightweight or a heavyweight tag?  I guess lightweight -- the  \n> tag command should probably support -a, -s and -u like git-tag does.  \n> Unless -c/-C/-F/-m is given, the sequencer will then run the editor.\n\nIt is a lightweight tag currently.\nWell, I've taken it because it was in rebase-i of \"next\" and currently\nI use it because it makes one merge test case really simple by tagging\nthe parents of the planned merge.\n\nI don't know if it is really useful to sequencer users and I don't know\nif its better to drop from the documentation but keep it for my test \ncase ;-)\n\nBecause I'm pretty unsure about it, I didn't change anything on \"tag\" \nafter Junio's complaints about it.\n\n>> -C <commit-ish>::\n>> --reuse-commit=<commit-ish>::\n>> --reference=<commit-ish>::\n>> \tReuse message and authorship data from specified commit.\n>\n> Why --reference?\n\nI know that it's inconsistent to git-commit and I hoped nobody would\nnotice. ;-)\n\nThe reason why I didn't want `-C' to be `--reuse-message' is:\n 1. it is a misleading long option name, and\n 2. some days ago the long option was not really documented,\n    so everyone and everything is using -C.\n    (See\n\tgit show bc47c29\n     and/or\n\tgit grep -e reuse-message\n     in git.git)\n\nI think that --reuse-commit is much less misleading, since \n--reuse-message-and-authorship is too long ;-)\nAnd Joerg Sommer's patchset which migrated to next introduced the\nterm \"reference merge\" (see \"git show d9711a80\", the first \"die\" in the\nfirst hunk), and I thought the term \"reference\" is nicer than\n\"reuse message and authorship\". But, of course, I also see the\ndisadvantage that it can be mixed up with refs.\n\nI still vote for \"-C/--reuse-commit\" and because nobody and\nnothing uses --reuse-message in git-commit I even dare propose\nto change it to --reuse-commit there.\n\n>> -M <commit-ish>\n>> --reuse-message=<commit-ish>::\n>> \tReuse message from specified commit.\n>> \tNote, that only the commit message is reused\n>> \tand not the authorship information.\n\nThis is something I'd like to keep.\n\n> For consistency with git-commit I would think it's better to have\n>\n>   -c <commit-ish>::\n>   -C <commit-ish>::\n>   --reedit-message=<commit-ish>::\n>   --reuse-message=<commit-ish>::\n> \tTake existing commit object, and reuse the log message and the\n>         authorship information (including the timestamp) when creating\n>         the commit. With -C (or --reuse-message), the editor is not\n> \tinvoked; with -c (or --reedit-message) the user can further edit\n> \tthe commit message.\n>\n> (I know it's confusing that it's reusing the message too, but...)\n\nLater you speak of using the -e option to force edit of the message.\nI think that \"-c\" is not needed if you can use \"-C f00babe -e\".\n\n> and then a separate option:\n>\n>   -A\n>   --author-override::\n> \tForce authorship information for commits created by the command\n> \tto be the data in git's configuration files.\n>\n> ... if it is not too complicated to implement.\n\nCurrently you can pass --author as a general option.\nPerhaps this is not as easy to handle for the user, but if we\nreally really really want the -A/--author-override, we can add it later.\n\n> To satisfy Pierre's comment, you might also add a \"-e\" general option,  \n> which forces an invocation of the editor -- even if -C/-m/-F are given,  \n> and even if the command is pick/patch/merge.  I guess that in order to  \n> support -C/-m/-F you already have to use git-cherry-pick and git-merge's  \n> --no-commit options, so it should not be hard to implement.\n\nI hoped someone will come up with -e ;-)\nSo \"reinvent\" a general option -e/--edit that just goes sure to invoke\nan editor should be fine.\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79603","messageId":"1213285131-32051-1-git-send-email-s-beyer@gmx.net","threadId":"13855","inReplyTo":"20080612152928.GB6848@leksak.fem-net","subject":"[RFC/PATCH] git-commit: Change --reuse-message to --reuse-commit.","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-12T15:38:51Z","receivedAt":"2008-06-12T15:38:51Z","isPatch":true,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"The reason for the change is, that --reuse-message is\nmisleading, because the long option name does not tell\nthe user, that the authorship information is kept.\n---\nHi,\n\nI can imagine the negative feedback as\n * don't change long-time-used options\n * --reuse-commit, but --reedit-message?\n * ...\n\nBut I want to give it a try ;-)\n 1. I think that the --reuse-message long option \n    is not used by anyone, but you can quickly generate\n    a counterexample :)\n    \n    Why not used? Because it was not documented in \n    git-commit.txt until \"Sun Jun 8 03:36:08 2008 +0200\"\n    (git show bc47c29).\n 2. Later we could add something like -M/--reuse-message\n    that just reuses the message and not the authorship.\n\nSee also the parent mail.\n  http://article.gmane.org/gmane.comp.version-control.git/84760\n\nRegards,\n  Stephan\n\n Documentation/git-commit.txt |    2 +-\n builtin-commit.c             |    2 +-\n 2 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 7e8b4ff..f713f40 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -59,7 +59,7 @@ OPTIONS\n \ttold git about are not affected.\n \n -C <commit>::\n---reuse-message=<commit>::\n+--reuse-commit=<commit>::\n \tTake an existing commit object, and reuse the log message\n \tand the authorship information (including the timestamp)\n \twhen creating the commit.\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex 90200ed..9c0b2da 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -90,7 +90,7 @@ static struct option builtin_commit_options[] = {\n \tOPT_STRING(0, \"author\", &force_author, \"AUTHOR\", \"override author for commit\"),\n \tOPT_CALLBACK('m', \"message\", &message, \"MESSAGE\", \"specify commit message\", opt_parse_m),\n \tOPT_STRING('c', \"reedit-message\", &edit_message, \"COMMIT\", \"reuse and edit message from specified commit \"),\n-\tOPT_STRING('C', \"reuse-message\", &use_message, \"COMMIT\", \"reuse message from specified commit\"),\n+\tOPT_STRING('C', \"reuse-commit\", &use_message, \"COMMIT\", \"reuse message from specified commit\"),\n \tOPT_BOOLEAN('s', \"signoff\", &signoff, \"add Signed-off-by:\"),\n \tOPT_STRING('t', \"template\", &template_file, \"FILE\", \"use specified template file\"),\n \tOPT_BOOLEAN('e', \"edit\", &edit_flag, \"force edit of commit\"),\n-- \n1.5.5.3\n"},{"id":"79604","messageId":"4851471A.3030400@gnu.org","threadId":"13855","inReplyTo":"20080612152928.GB6848@leksak.fem-net","subject":"Re: [RFCv2/FYI] git-sequencer.txt","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-06-12T15:56:10Z","receivedAt":"2008-06-12T15:56:10Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> The reason why I didn't want `-C' to be `--reuse-message' is:\n>  1. it is a misleading long option name, and\n>  2. some days ago the long option was not really documented,\n>     so everyone and everything is using -C.\n>     (See\n> \tgit show bc47c29\n>      and/or\n> \tgit grep -e reuse-message\n>      in git.git)\n\nYes, I agree (though I still maintain that --reuse-message is better if \nonly because it is more consistent).\n\n>>> -M <commit-ish>\n>>> --reuse-message=<commit-ish>::\n>>> \tReuse message from specified commit.\n>>> \tNote, that only the commit message is reused\n>>> \tand not the authorship information.\n> \n> This is something I'd like to keep.\n\nDo you have a use case?\n\n> Later you speak of using the -e option to force edit of the message.\n> I think that \"-c\" is not needed if you can use \"-C f00babe -e\".\n\nWell, so is for git-commit but...\n\n> Currently you can pass --author as a general option.\n> Perhaps this is not as easy to handle for the user, but if we\n> really really really want the -A/--author-override, we can add it later.\n\nThe idea is that -M = \"-A -C ba123\"...\n\nPaolo\n"},{"id":"79607","messageId":"20080612170715.GC6848@leksak.fem-net","threadId":"13855","inReplyTo":"7vabhr9qru.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFCv2/FYI] git-sequencer.txt","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-12T17:07:15Z","receivedAt":"2008-06-12T17:07:15Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nJunio C Hamano wrote:\n> > Note that the sanity check fails, if you use this option\n> > and an instruction like `edit` or `pause`.\n> >\n> > --onto=<base>::\n> > \tCheckout given commit or branch before sequencing.\n> > \tIf you provide a branch, sequencer will make the provided\n> > \tchanges on the branch, i.e. the branch will be changed.\n> \n> I think you called this --onto by modeling after rebase, but I am not sure\n> if that is a good generic naming.\n\nFirst it was called --branch=<branch>, but I considered this to be wrong, \nbecause it's also possible to work on a detached tree.\n\nThen I thought, that the rebase name is somehow right.\n\n> Worse, \"a branch that is not the current one that is rebased\" in rebase is\n> not specified with \"--onto\" but with the extra argument.\n> \n> Is checking out that <base> branch considered as part of the sequencing\n> operation, or it is something that happens before the sequencing?  In\n> other words, if a sequencing stops and the user says \"sequencer --abort\",\n> where does it take the user back to?  The state the <base> is checked out,\n> or the state before that checkout happened?  Can't the front-end emit an\n> insn to checkout or detach as the first insn?\n\nUsing git-sequencer --onto you specify the commit (or branch) where\nthe TODO insns are executed on.\n(If you provide a branch, the branch ref points to the result of the \nsequencing process. If not, the sequencer process finishes on a detached\nHEAD, just as it started.)\n\nIf you are on master and do\n\tgit sequencer --onto foo todo-file\nand later do a\n\tgit sequencer --abort\nthen you are back on master \"as if nothing happened\".\n\nIf the process finishes successfully, you are on \"foo\".\n\nI think this is quite handy and intuitive.\n\nBtw, I didn't include the --onto stuff into the test suite of\nmy prototype branch yet, so the only thing that currently tests\nthis is git-rebase --interactive, that does a\n\tgit-sequencer --onto \"$ONTO\" \"$TODO\"\nand this works well.\n\nI didn't include it yet, because the questions you addressed were\nsomehow still open to me.\n\n\nIf you don't provide --onto, it works on the current HEAD,\nmay it be a branch or detached HEAD.\n\n> By the way, is it specified if sequencer will always work by:\n\nCurrently nothing of that is *specified*, but I can tell what the\nprototype currently does.\n\n> \n>  (1) remember the initial branch;\n\nIt saves the initial branch and commit, yes.\n\n>  (2) detach the HEAD;\n\nIt currently does not detach the HEAD if a branch is given in --onto.\nImho this is a bug -- thanks -- but the fix is easy ;-)\n\n>  (3) run the operation;\n> \n>  (4) and finally (unless the user says --abort) reattaching the original\n>      branch to the resulting HEAD?\n\nYes. (Currently the reattaching is done \"automagically\" because of the\nbug it doesn't detach the head.)\n\n> That would mean the sequencer would essentially munge only one branch\n> (unless started from a detached HEAD state).  I think this is a reasonable\n> design decision (and a limitation) for the currently expected front-ends,\n> but I think this is a perfectly sane backend for filter-branch (without\n> any tree or content munging), and this limitation might later come back\n> and bite us.\n\nSorry, I currently don't understand you. ;-)\nI've never used filter-branch so I'm a bit out of background here.\n\nI currently wonder if it's better to remove --onto and let the \nsequencer users do that.\nSo that, for example, the rebase-i has to checkout the detached $ONTO\nand then just call git-sequencer \"$TODO\".\n(If we do it this way... Daniel, you were right *grin*)\n\nWhat do you think?\n\n> > --skip::\n> > \tRestart the sequencing process by skipping the current patch.\n> \n> \"patch\"?\n\n\"instruction\". Thanks.\n\n> What is the set of insn that can possibly give control back and give\n> you a chance to say \"--skip\"?\n> \n>  - pick can conflict and --skip would mean \"reset to the tree before the\n>    pick and continue on to the next insn\";\n\nRight.\n\n>  - Same goes for merge and patch (the semantics of \"squash <commit>\" is\n>    fuzzy to me);\n\nRight.\n\nI've already considered squash, I c&p a comment from the prototype:\n # Hm, somehow I don't think --skip on a conflicting squash\n # may be useful, but if someone wants to do it, it should \n # do the obvious: skip what squash would do.\n\nThis means, if you do\n\tsquash --up-to :1\nit will just not squash all the commits from :1 to HEAD.\nIf you do\n\tsquash <commit>\nit will not pick <commit> and squash it with the last.\n\n>  - pause can give control back to you.  What should --skip do?  I guess\n>    \"no-op\" is the right answer.\n\nRight. In other words: --skip equals --continue.\nI've already considered this and when in \"pause\", git --status does not\ntell the user that he can do --skip, although he can.\n\n> > --status::\n> > \tShow the current status of git-sequencer and what\n> > \toperations can be done to change that status.\n> \n> Meaning \"what insns have we done, what insn were we in the middle of\n> executing, and what insns are still remaining\"?\n\nIf sequencer is paused somewhere:\n - what insns have we done\n - are we in a conflict or pause?\n - what insns are still remaining\n - what options does sequencer run with?\n   (The only option that can be reported is currently\n    --verbose)\n - what can the user run to abort/continue/skip?\n\nAnd \"Sequencer not running\" if sequencer is not started\nor has finished or whatever.\n\n> > merge [<options>] <commit-ish1> <commit-ish2> ... <commit-ishN>::\n> > \tMerge commits into HEAD.\n> > +\n> > A commit can also be given by a mark, if prefixed with a colon.\n> > +\n> > If you do not provide a commit message (using `-F`, `-m`, `--reference` \n> > or `--standard`), an editor will be invoked.\n> > +\n> > See the following list and 'GENERAL OPTIONS' for values of `<option>`:\n> >\n> > \t--standard;;\n> > \t\tGenerates a commit message like 'Merge ... into HEAD'.\n> > \t\tSee also linkgit:git-fmt-merge-msg[1].\n> \n> It seems you are assuming (and I am not saying it is a bad assumption)\n> that sequencer first detached the HEAD and operates on that state until it\n> is done.  Perhaps we would want to reword \"into HEAD\" somehow?\n\nI'd also prefer something different, but currently this is what\ngit-fmt-merge-msg provides in the way I use it.\n\n> If we are rebasing branch \"main\", even if sequencer internally detaches the HEAD to\n> carry out individual steps, we would want to see the resulting history to\n> say \"into main\", wouldn't we?\n\nYes, that's right. (Well, I wouldn't even care if the \"into ...\" is\nomitted at all because in a graph log you usually can see what is merged\ninto what.)\n\nI currently keep this.\nBut I'm open for code suggestions to solve this when I have posted the\nprototype.\n\n> > patch [<options>] <file>::\n> > \tIf file `<file>` is a pure (diff) patch, then apply the patch.\n> > \tIf no `--message` option is given, an editor will\n> > \tbe invoked to enter a commit message.\n> \n> Hmm.  Are there cases where you might want to feed more than one patches\n> and then finally make the commit?  You could emulate it with\n> \n> \tmark :1\n> \tpatch --message=dummy file1\n>         patch --message=dummy file2\n> \tsquash --upto :1\n> \n> but it might make sense to allow more than one files for this use case,\n> like\n> \n> \tpatch file1 file2\n> \n> Although that would introduce another issue, which is what to do if file1\n> is a naked diff and file2 is a mbox (with possibly more than one patches),\n> or vice versa.\n\nOr what to do if file1 introduces a conflict.\n\nWe've (my mentors and me) started such a discussion several times and\nalways said \"Ok, let's keep this for later.\". Now that we have the\nsquash --up-to solution, I think we should stick with it. \nAnd when we have the code base, we can add features. \n\n> >...\n> > \t-u;;\n> > \t\tPass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).\n> >...\n> > This was optional in prior versions of git, but now it is the\n> > default. You could use `-n` to override this.\n> \n> I personally do not think it is worth supporting this b/c compatibility\n> option in a new command \"sequencer\".\n\nThanks!\n\nThe same for --binary?  Oh, I haven't even included it... :)\n\n> > pause::\n> > \tPauses the sequencer process to let you manually make changes.\n> > \tFor example, you can re-edit the done commit, fix bugs or typos,\n> > \tor you can make further commits on top of HEAD before continuing.\n> > +\n> > After you have finished your changes and added them to the index,\n> > invoke `git-sequencer --continue`.\n> > If you only want to edit the last commit message with an editor,\n> > run `git commit --amend` (see linkgit:git-commit[1]) before.\n> \n> before \"saying --continue\"?\n\nIs it really not clear? (What else?)\nOk, I add it.\n\nPerhaps it's also better to announce the `-e/--edit` option here (see \nPaolo's reply) for users who just want to change the commit message.\n\n> > reset <commit-ish>::\n> > \tGo back (see linkgit:git-reset[1] `--hard`) to commit `<commit-ish>`.\n> > \t`<commit-ish>` can also be given by a mark, if prefixed with a colon.\n> >\n> > squash [<options>] <commit>::\n> > \tAdd the changes introduced by `<commit>` to the last commit.\n> \n> Just like you explained \"edit <commit>\" in terms of \"pick\" and \"pause\", we\n> might want to explain that this is \"pick\" and \"squash --up-to HEAD^\" (or\n> is it HEAD^^\"?).\n\nIt is HEAD^^, but squash --up-to does only accept marks, so:\n\n\tThis is a short form for `mark :10`, `pick <commit> and\n\t`squash --up-to :10` on separate lines.\n\nwould be more accurate, but isn't really true, since no mark is\ngenerated, the --skip behavior is a different, etc.\nI think I don't like to include such a note.\n\n> > squash [<options>] --up-to <mark>::\n> > \tSquash all commits up to the given mark into one commit.\n> > \tThere must not be any merge commits in between.\n> \n> \"In between\" in \"inclusive\" sense, that is, neither <mark> nor HEAD cannot\n> be a merge?\n\nAssuming that <mark> is a mark for HEAD~N, then\nHEAD~0, HEAD~1, HEAD~2, ..., HEAD~(N+1) must not be a merge commit.\n\nExample:\n\tmerge ...\n\tmark :3\n\tpick ...\n\tpatch ...\n\tsquash --up-to :3\nworks.\nThis will result in a merge and a squashed pick/patch commit.\n\nSee a perhaps better description below.\n\n> Also --up-to feels somewhat wrong.  It is more like down-to\n> but perhaps \"from\" would be a better wording.\n\nShould we also use --from instead of --up-to then?\nI have no \"feeling\" about that, because \"to squash\" is a new word in my\nEnglish vocabulary since I've first used git-rebase -i ;)\n\nsquash [<options>] --from <mark>::\n\tSquash all commits from the given mark into one commit.\n\tThere must not be any `merge` instructions between the\n\t`mark` instruction and this `squash --from` instruction.\n\nDoes this make more sense to you?\n\n> > \t--include-merges;;\n> > \t\tSanity check does not fail if you have merges\n> > \t\tbetween HEAD and <mark>.\n> \n> And what gets recorded?  A squashed merge?\n\nWell, I have a test case for that but haven't yet looked what the result\nis. (It just checks, that it works.) ;-)\nFor me, such an operation does not make sense (since I currently don't\nknow every detail of git), but if there is somebody who wants that,\nhe or she should get it.\n\n> A \"squash --up-to <mark>\" (modulo off-by-one I can never get straight X-<)\n> essentially:\n> \n> \tlog --reverse <mark>.. >msg\n> \treset --soft <mark>\n>         commit --amend -F msg\n> \n> so recording this result, when there is a merge in between, is like\n> running \"merge --squash\".\n\nAha.\n\n> > tag <tag>::\n> > \tSet tag `<tag>` to the current HEAD,\n> > \tsee also linkgit:git-tag[1].\n> > \tIf another commit is tagged `<tag>`, it will lose this tag,\n> > \ti.e. the tag will be reset to HEAD.\n> \n> Hmm.  It is hard to judge this without seeing how the front-ends use it.\n\nRight :)\n\n> It might make sense to give lower-level access to update-ref instead, so\n> that more than one branches can be updated as well, but I am not sure.\n\nLike\n ref refs/heads/new_branch\nor\n ref refs/tags/foo\n\nThat sounds like a good idea. (And is written to the todo list.)\nHow should the insn be called? \"ref\"?\n\n> How would this interact with \"--abort\"?\n\nNice question.\nCurrently all tags are kept on --abort.\nSequencer could keep a list of generated tags (refs) and remove it \non --abort (or tell the user to remove them if she likes.)\n\nBut... I think I currently just keep it.\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79609","messageId":"20080612172009.GD6848@leksak.fem-net","threadId":"13855","inReplyTo":"200806121610.43674.jnareb@gmail.com","subject":"Re: [RFCv2/FYI] git-sequencer.txt","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-12T17:20:09Z","receivedAt":"2008-06-12T17:20:09Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nOn Thu, Jun 12, 2008 at 04:10:42PM +0200,\nJakub Narebski <jnareb@gmail.com> wrote to git@vger.kernel.org:\n> > SYNOPSIS\n> > --------\n> > [verse]\n> > 'git-sequencer' [--batch] [--onto=<base>] [--verbose] [<file>]\n> > 'git-sequencer' --continue | --skip | --abort | --edit | --status\n> \n> I'm not sure if --edit should be mentioned in line with \"processing\"\n> commands: --continue, --skip, --abort and related --status.\n\nHm I've put it in this line, because it's also an option that is rather\nthan a command and that takes no other options, as --continue, --skip,\n--abort, --status are.\n\nFor more information, everybody can scroll down and read the\ndescription.\n\n> > OPTIONS\n> > -------\n> > <file>::\n> > \tFilename of the TODO file.  If omitted, standard input is used.\n> > \tSee 'TODO FILE FORMAT' below.\n> \n> Omitted for standard input, --stdin for standard imput, or special\n> filename of '-' for standard input?\n\nIn the current spec it is omitted.\nIn the last one, it was '-'.\nMy mentors and me discussed also the --stdin/--file approach but put\nthat down.\n\n> > --onto=<base>::\n> > \tCheckout given commit or branch before sequencing.\n> > \tIf you provide a branch, sequencer will make the provided\n> > \tchanges on the branch, i.e. the branch will be changed.\n> \n> I'm not sure if repeating rebase design is best idea.  But this\n> ferature is certainly necessary...\n\nOk, you say that it's necessary.\nI thought this, too, up to Junio's mail I just replied to.\n\nNow I think I can get along without that and let the sequencer user\ntools prepare and finish that.\nThis *could* mean duplicated code, but currently the only tool\nthat would use this feature is rebase-i.\n\n> > -v::\n> > --verbose::\n> > \tBe more verbose. [XXX: to be defined more accurately, i.e. print diffstat]\n> \n> I think it would be nice to have --quiet mode (which perhaps --batch\n> would imply, or perhaps not), which would make git-sequencer to not\n> report progress report (i.e. which actions are being done).\n\nCurrently I have no idea what should be outputted and what not.\nI think I won't care about that for the prototypem but for the builtin\nsequencer.\n\nBut I add -q/--quiet to the spec, but --batch does not imply it ;)\n\n> > git-sequencer will usually be called by another git porcelain, like\n> > linkgit:git-am[1] or linkgit:git-rebase[1].\n> \n> Or git-cherry-pick, or git-revert.\n\nWell, I don't know about the others, but for me this is currently not\nclear ;-)\nThe prototype uses git-cherry-pick and I think the first versions of my\nbuiltin will also use it.\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79672","messageId":"4851FFE9.30108@gnu.org","threadId":"13855","inReplyTo":"20080612170715.GC6848@leksak.fem-net","subject":"Re: [RFCv2/FYI] git-sequencer.txt","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-06-13T05:04:41Z","receivedAt":"2008-06-13T05:04:41Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> squash [<options>] --from <mark>::\n> \tSquash all commits from the given mark into one commit.\n> \tThere must not be any `merge` instructions between the\n> \t`mark` instruction and this `squash --from` instruction.\n\n--after maybe?\n\nPaolo\n"},{"id":"79711","messageId":"20080613121607.GC7925@leksak.fem-net","threadId":"13855","inReplyTo":"4851FFE9.30108@gnu.org","subject":"Re: [RFCv2/FYI] git-sequencer.txt","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-13T12:16:07Z","receivedAt":"2008-06-13T12:16:07Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":">> squash [<options>] --from <mark>::\n>> \tSquash all commits from the given mark into one commit.\n>> \tThere must not be any `merge` instructions between the\n>> \t`mark` instruction and this `squash --from` instruction.\n>\n> --after maybe?\n\nI have no idea what is best here ;-)\nSomething that seems intuitive when you see:\n\n\tmerge ...\n\tmark :5\n\tpick 666babe\n\tpatch foo.patch\n\tpick fa1afe1\n\nNow?\n1)  squash --up-to :5\n2)  squash --from :5\n3)  squash --after :5\n\n(1) suggests the wrong direction...\nMy English feeling says that (2) \"squash from\" is better than \n(3) \"squash after\", but I'm not a native speaker ;-)\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"79725","messageId":"48528751.8070601@gnu.org","threadId":"13855","inReplyTo":"20080613121607.GC7925@leksak.fem-net","subject":"Re: [RFCv2/FYI] git-sequencer.txt","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-06-13T14:42:25Z","receivedAt":"2008-06-13T14:42:25Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> Now?\n> 1)  squash --up-to :5\n> 2)  squash --from :5\n> 3)  squash --after :5\n> \n> (1) suggests the wrong direction...\n> My English feeling says that (2) \"squash from\" is better than \n> (3) \"squash after\", but I'm not a native speaker ;-)\n\nYes, it would be squash \"everything after\" X.  --from sounds good enough.\n\nPaolo\n"},{"id":"79775","messageId":"4852C976.80007@free.fr","threadId":"13855","inReplyTo":"20080612170715.GC6848@leksak.fem-net","subject":"Re: [RFCv2/FYI] git-sequencer.txt","fromName":"Olivier Marin","fromEmail":"dkr+ml.git@free.fr","sentAt":"2008-06-13T19:24:38Z","receivedAt":"2008-06-13T19:24:38Z","isPatch":false,"sender":{"key":"dkr+ml.git@free.fr","avatar":null},"body":"Stephan Beyer a écrit :\n> Junio C Hamano wrote:\n>> How would [tag] interact with \"--abort\"?\n> \n> Nice question.\n> Currently all tags are kept on --abort.\n> Sequencer could keep a list of generated tags (refs) and remove it \n> on --abort (or tell the user to remove them if she likes.)\n\nWhat about tags that have been overwritten?\n\nAnd why the tag instruction replace an existing tag by default? Would\nnot be better to exit with an error during the sanity check if the tag\nalready exists? Perhaps it make sens to accept -f and -d options.\n\nWhat do you think?\n\nOlivier.\n"}]}