{"thread":{"id":"2444","subject":"tracking a tree that doesn't progress linearly","startedAt":"2005-11-11T03:18:31Z","lastAt":"2005-11-11T11:06:25Z","messageCount":4,"participants":["Paul Mackerras","Martin Langhoff","Catalin Marinas","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"11544","messageId":"17268.3463.252020.591687@cargo.ozlabs.ibm.com","threadId":"2444","inReplyTo":null,"subject":"tracking a tree that doesn't progress linearly","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2005-11-11T03:18:31Z","receivedAt":"2005-11-11T03:18:31Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"I want to be able to publish a git tree for others to follow but I\nalso want to be retain the freedom to remove commits and/or rebase\ncommits in the tree. For example, if someone sends me a patch and I\nput it in the tree, then they send me a revised version, I want to be\nable to roll back to just before I applied the older patch and start\nagain from there.\n\nWhat this means, AFAICS, is that the head of the published tree won't\nalways be a descendent of all previous values of the head. If\nsomebody is following the state of the tree by doing a git pull every\nso often, and I have rolled back the tree and applied some new\npatches, then the git pull will try to merge the old and new state,\nwhich is not what we want. What we want is something that just gets\nthe local tree to the same state as the remote tree.\n\nIs there a git command which does the equivalent of a git fetch,\nfollowed by setting the head and checking it out?\n\nOr is this an incredibly stupid idea for some reason that hasn't\noccurred to me yet? :)\n\nThanks,\nPaul.\n"},{"id":"11548","messageId":"46a038f90511102058p6536b17crc7c9f7ce93167934@mail.gmail.com","threadId":"2444","inReplyTo":"17268.3463.252020.591687@cargo.ozlabs.ibm.com","subject":"Re: tracking a tree that doesn't progress linearly","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-11-11T04:58:54Z","receivedAt":"2005-11-11T04:58:54Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/11/05, Paul Mackerras wrote:\n> I want to be able to publish a git tree for others to follow but I\n> also want to be retain the freedom to remove commits and/or rebase\n> commits in the tree.\n\nI sometimes want that too, but git doesn't have a 'rewind' semantics,\nand probably for a good reason. The approach I am studying is to\ncreate a thousand throaway short-lived branches. It is safe to publish\nthem as long as people following your branches _know_ that they'll be\norphaned, and that any commits they have on top of them they'll have\nto rebase.\n\nSo you could publish your tree with devel- heads, and\nannounce when you're moving to a newer one. People tracking your\nbranches can tend register & checkout the new branches, and do a\ngit-merge to rebase their patches to your new branch, or replay them\nwith git-format-patch and git-am.\n\nOn the other hand, if StGIT grows better support for sharing patches,\nit could make all this look like the stone age.\n\ncheers,\n\n\nmartin\n"},{"id":"11573","messageId":"tnxwtjfxyau.fsf@arm.com","threadId":"2444","inReplyTo":"17268.3463.252020.591687@cargo.ozlabs.ibm.com","subject":"Re: tracking a tree that doesn't progress linearly","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-11-11T10:40:25Z","receivedAt":"2005-11-11T10:40:25Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Paul Mackerras wrote:\n> I want to be able to publish a git tree for others to follow but I\n> also want to be retain the freedom to remove commits and/or rebase\n> commits in the tree. For example, if someone sends me a patch and I\n> put it in the tree, then they send me a revised version, I want to be\n> able to roll back to just before I applied the older patch and start\n> again from there.\n\nI'm facing a similar problem. I use StGIT for my development branch\n(usually with less than 20 patches) but I would like to export a HEAD\nfor others to pull from. When rebasing the patches with StGIT, the new\nHEAD wouldn't be a descendant of the old one.\n\nThe partial solution I got to was to make the master branch available\nto people and the devel branch private. Initially, the master branch\nwould pick the patches ('stg pick') from the devel branch which I want\nto make public. When I'm happy with the patches on the master branch,\nI run 'stg commit' and store them permanently (you won't be able to\nmodify them). After permanently storing the patches, I can use the\nmaster branch in the normal way with GIT (merge, pull, push etc.).\n\nWhen I get a patch in the devel branch updated, I just run 'stg pick\npatchname@devel' in the master branch. Because of the nature of the\nthree-way merge, the new picked patch should only contain the\ndifferences from the previous one. It might also cause conflicts which\nneed resolving if the new patch modifies lines which were present in\nthe old patch (i.e. not only additions or removals). At this point you\ncan change the patch description since the new picked patch only\nrepresents an update to the old one and not the full feature.\n\nThe only little drawback I see with this approach is that merging in\nthe latest changes from the mainline kernel could produce identical\nconflicts (if any) in both master and devel branches.\n\n-- \nCatalin\n"},{"id":"11575","messageId":"20051111110625.GO30496@pasky.or.cz","threadId":"2444","inReplyTo":"17268.3463.252020.591687@cargo.ozlabs.ibm.com","subject":"Re: tracking a tree that doesn't progress linearly","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-11T11:06:25Z","receivedAt":"2005-11-11T11:06:25Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Nov 11, 2005 at 04:18:31AM CET, I got a letter\nwhere Paul Mackerras said that...\n> I want to be able to publish a git tree for others to follow but I\n> also want to be retain the freedom to remove commits and/or rebase\n> commits in the tree. For example, if someone sends me a patch and I\n> put it in the tree, then they send me a revised version, I want to be\n> able to roll back to just before I applied the older patch and start\n> again from there.\n> \n> What this means, AFAICS, is that the head of the published tree won't\n> always be a descendent of all previous values of the head. If\n> somebody is following the state of the tree by doing a git pull every\n> so often, and I have rolled back the tree and applied some new\n> patches, then the git pull will try to merge the old and new state,\n> which is not what we want. What we want is something that just gets\n> the local tree to the same state as the remote tree.\n> \n> Is there a git command which does the equivalent of a git fetch,\n> followed by setting the head and checking it out?\n\nI plan to change the fast-forward condition in Cogito from\n\n\tis_ancestor(current, new_head)\n\nto\n\n\tcurrent == old_head || is_ancestor(current, new_head)\n\nwhich should enable you to do this - just rebase, and it will Just Work\nfor those cg-update'ing from you; the only problem si that cg-fetch +\ncg-merge will NOT work, but I have no simple workaround for that.\n\nI already proposed this several times and it was always passed in\nsilence, so I assume there are no problems with this approach.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"}]}