{"thread":{"id":"8194","subject":"[RFC] git-float","startedAt":"2007-05-17T21:18:05Z","lastAt":"2007-05-22T12:58:51Z","messageCount":3,"participants":["Michael S. Tsirkin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"42434","messageId":"20070517211805.GA29259@mellanox.co.il","threadId":"8194","inReplyTo":null,"subject":"[RFC] git-float","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-05-17T21:18:05Z","receivedAt":"2007-05-17T21:18:05Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"Hi!\nHere's a simple script I use to float a commit up the history -\nsimiliar to what stg float does if I understand it correctly.\n\nIs this a good way to implement it?\nWould it make sense to have something like this in git tree?\nDrop me a note.\n\n############################################################\n\n#!/bin/bash\n\ncheck_revision() {\n\tcase $# in\n\t2)\n\t\ttrue\n\t\t;;\n\t*)\n\t\techo \"Unable to float $1: it does not match a single non-merge commit\" >&2\n\t\texit 2\n\t\t;;\n\tesac\n}\nref=`git-rev-list --no-merges $1~1..$1`\ncheck_revision \"$1\" $ref\n\ngit-rebase --onto $ref~1 $ref && git-cherry-pick $ref\n\n-- \nMST\n"},{"id":"42441","messageId":"7v3b1v7z19.fsf@assigned-by-dhcp.cox.net","threadId":"8194","inReplyTo":"20070517211805.GA29259@mellanox.co.il","subject":"Re: [RFC] git-float","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-18T00:31:30Z","receivedAt":"2007-05-18T00:31:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" <mst@dev.mellanox.co.il> writes:\n\n> Here's a simple script I use to float a commit up the history -\n> similiar to what stg float does if I understand it correctly.\n>\n> Is this a good way to implement it?\n\n> git-rebase --onto $ref~1 $ref && git-cherry-pick $ref\n\nBecause git-rebase or git-cherry-pick can be interrupted with a\nconflict, this is not a good _implementation_.  The whole script\nneeds to have the sequencing and continue logic similar to the\none git-rebase has.\n\n> Would it make sense to have something like this in git tree?\n\nIncidentally, this is closely related to something that people\nhave wanted to have for a long time, which is to cherry-pick\nseries of commits.\n\nOne step of rebase and cherry-pick can be thought of as a\n\"rotate a commit\" operation.  When you cherry-pick a commit C on\ntop of where you are, the resulting tree is computed by applying\nthe commit C's effect to the current tree via 3-way merge.\n\n\tgit-merge-recursive C^ HEAD C\n\ngit-rebase without -m does the equivalent of the above \"rotate a\ncommit\" operation using patch + apply (and fall back to merge if\nthe patch does not cleanly apply) for performance reasons, but\nthe principle is the same.  And the commit message for the\nresult is taken from C itself.\n\ngit-rebase can be decomposed into three stages:\n\n (1) find the sequence of commits to reapply;\n\n (2) find the commit to start rebuilding onto and reset to it;\n\n (3) one by one, rotate the commits you found in (1), with\n     the sequencing support (--abort, --skip and --continue).\n\nThere is no reason, other than the fact that there is no other\ncommit rotator in git suite that needs sequencing, that these\nthree needs to be in a single program git-rebase.\n\nThe only difference with the above outline and your float is\nthat after you finish step (1), you record \"this commit also\nneeds to be replayed at the end\" information to the sequence.\n\nThe implementation of cherry-pick that takes commit range is\nalso obvious; instead of the computation git-rebase does for\nstep (1) above, we would allow arbitrary series of commits to be\nspecified from the command line (most likely using the revision\nlist notation A..B) to be replayed with the sequencing\nmachinery.\n"},{"id":"42979","messageId":"20070522125851.GC27385@mellanox.co.il","threadId":"8194","inReplyTo":"7v3b1v7z19.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] git-float","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-05-22T12:58:51Z","receivedAt":"2007-05-22T12:58:51Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Quoting Junio C Hamano <junkio@cox.net>:\n> Subject: Re: [RFC] git-float\n> \n> \"Michael S. Tsirkin\" <mst@dev.mellanox.co.il> writes:\n> \n> > Here's a simple script I use to float a commit up the history -\n> > similiar to what stg float does if I understand it correctly.\n> >\n> > Is this a good way to implement it?\n> \n> > git-rebase --onto $ref~1 $ref && git-cherry-pick $ref\n> \n> Because git-rebase or git-cherry-pick can be interrupted with a\n> conflict, this is not a good _implementation_.  The whole script\n> needs to have the sequencing and continue logic similar to the\n> one git-rebase has.\n> \n> > Would it make sense to have something like this in git tree?\n> \n> Incidentally, this is closely related to something that people\n> have wanted to have for a long time, which is to cherry-pick\n> series of commits.\n> \n> One step of rebase and cherry-pick can be thought of as a\n> \"rotate a commit\" operation.  When you cherry-pick a commit C on\n> top of where you are, the resulting tree is computed by applying\n> the commit C's effect to the current tree via 3-way merge.\n> \n> \tgit-merge-recursive C^ HEAD C\n> \n> git-rebase without -m does the equivalent of the above \"rotate a\n> commit\" operation using patch + apply (and fall back to merge if\n> the patch does not cleanly apply) for performance reasons, but\n> the principle is the same.  And the commit message for the\n> result is taken from C itself.\n> \n> git-rebase can be decomposed into three stages:\n> \n>  (1) find the sequence of commits to reapply;\n> \n>  (2) find the commit to start rebuilding onto and reset to it;\n> \n>  (3) one by one, rotate the commits you found in (1), with\n>      the sequencing support (--abort, --skip and --continue).\n> \n> There is no reason, other than the fact that there is no other\n> commit rotator in git suite that needs sequencing, that these\n> three needs to be in a single program git-rebase.\n> \n> The only difference with the above outline and your float is\n> that after you finish step (1), you record \"this commit also\n> needs to be replayed at the end\" information to the sequence.\n> \n> The implementation of cherry-pick that takes commit range is\n> also obvious; instead of the computation git-rebase does for\n> step (1) above, we would allow arbitrary series of commits to be\n> specified from the command line (most likely using the revision\n> list notation A..B) to be replayed with the sequencing\n> machinery.\n\nSo to summarize: you suggest creating a new low-level command\nthat gets a list of commits and applies them, with\nthe sequencing support (--abort, --skip and --continue).\nThen rewrite both cherry-pick and rebase on top of these,\nimplement git float (and maybe git kill which does just\ngit-rebase --onto $1~1 $1 I posted at some point) on top\nof this as well.\n\n-- \nMST\n"}]}