{"thread":{"id":"1576","subject":"[RFC] Stgit - patch history / add extra parents","startedAt":"2005-08-18T19:57:53Z","lastAt":"2005-08-31T17:17:26Z","messageCount":22,"participants":["Jan Veldeman","Catalin Marinas","Daniel Barkalow","Junio C Hamano","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7514","messageId":"20050818195753.GA9066@fanta","threadId":"1576","inReplyTo":null,"subject":"[RFC] Stgit - patch history / add extra parents","fromName":"Jan Veldeman","fromEmail":"jan.veldeman@gmail.com","sentAt":"2005-08-18T19:57:53Z","receivedAt":"2005-08-18T19:57:53Z","isPatch":false,"sender":{"key":"jan.veldeman@gmail.com","avatar":"https://gravatar.com/avatar/83744a7c7e462c17ea2747bb0b69bb1719a0a6a9769777ced20ec3f162f69fc4?d=mp&s=160"},"body":"Hi,\n\nI like stgit very much, but I feel there is still something missing:\nstgit is very handy when you use it for patches which should be pushed to\nmainline rather quickly. But for pacthes which won't be pushed immediately\nto mainline, it would be usefull to have a history of the patches itself.\n\nThe patch below, together with the following script could be used to\nmake snapshots of the patch stack (I call it freeze, as I thought snapshot\nwas already going to be used for something else):\n\n#!/bin/bash\n# stg-freeze\nset -ex\ntop=$(stg top)\n\n# Freeze the current stack\nbranchname=$(basename $(readlink .git/HEAD))\nwhile read patch\ndo\n\tcp .git/patches/$branchname/$patch/top .git/patches/$branchname/$patch/parent\ndone < .git/patches/$branchname/applied\n\n# Refresh the patches\nstg pop -a\nstg push -t $top\n# end stg-freeze\n\nNote: this is a proof of concept, when/if it would be incorporated, it\nshould be implemented in stgit itself, and a bit more efficient, especially\nthe refreshing of the patches ;-)\n\nThis is how it works: when not doing anything, stgit works as normal.\nOnce stg-freeze is called, it creates .git/patches/$branchname/$patch/parent\nwhich contains the SHA1 id of the \"frozen\" patch. By refreshing the stack,\nall patches now include the corresponding frozen patch as a parent.\n\nThe following script is a test I use. Add stg-freeze to the path and\nsource/run it in an empty directory, view with gitk afterwards:\n\n###\necho \"Initial commit\" | cg-init\nstg init\n\nstg new a -mpatch-1\necho a > a\nstg add a\nstg refresh -mpatch-1\nstg new b -mpatch-2\necho b > b\nstg add b\nstg refresh -mpatch-2\nstg-freeze\nstg pop\necho a2 >> a\nstg refresh -mpatch-1-update\nstg push\nstg-freeze\necho b2 >> b\nstg refresh -mpatch-2-update\n\n\nstg pop -a\necho c > c\ncg-add c\ncg-commit -m\"Mainline advance\"\nstg push -a\n\nstg-freeze\n\nstg pop -a\necho d > d\ncg-add d\ncg-commit -m\"Mainline advance 2\"\nstg push -a\n\nstg pop -a\necho e > e\ncg-add e\ncg-commit -m\"Mainline advance 3\"\nstg push -a\n\n###\n\nComments/remarks are very welcome.\n\n---\n stgit/stack.py |    9 ++++++++-\n 1 files changed, 8 insertions(+), 1 deletions(-)\n\n\ndiff --git a/stgit/stack.py b/stgit/stack.py\n--- a/stgit/stack.py\n+++ b/stgit/stack.py\n@@ -140,6 +140,13 @@ class Patch:\n         elif os.path.isfile(fname):\n             os.remove(fname)\n \n+    def get_parents(self):\n+        parents=[]\n+        if (self.__get_field('parent') != None):\n+                parents = parents + [self.__get_field('parent')]\n+        parents = parents + [ self.get_bottom() ]\n+        return parents\n+\n     def get_bottom(self):\n         return self.__get_field('bottom')\n \n@@ -362,7 +369,7 @@ class Series:\n         if not committer_email:\n             committer_email = patch.get_commemail()\n \n-        commit_id = git.commit(message = descr, parents = [patch.get_bottom()],\n+        commit_id = git.commit(message = descr, parents = patch.get_parents(),\n                                allowempty = True,\n                                author_name = author_name,\n                                author_email = author_email,\n"},{"id":"7559","messageId":"tnx64u2p81k.fsf@arm.com","threadId":"1576","inReplyTo":"20050818195753.GA9066@fanta","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-19T09:53:11Z","receivedAt":"2005-08-19T09:53:11Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Jan Veldeman <jan.veldeman@gmail.com> wrote:\n> I like stgit very much, but I feel there is still something missing:\n> stgit is very handy when you use it for patches which should be pushed to\n> mainline rather quickly. But for pacthes which won't be pushed immediately\n> to mainline, it would be usefull to have a history of the patches\n> itself.\n\nThe patch history feature was available in StGIT 0.1/0.2 releases\nwhere you should have run a 'stg commit' before 'stg refresh'. The\ncommit was handling all the history changes, with separate commit\nmessages and refresh was updating the main commit with 2 parents. I\nremoved it in 0.3 after some people (I think it was Paul Jackson and\nDaniel Barkalow) convinced me that this would make it yet another SCM\ninterface on top of GIT, which wasn't really my intention.\n\nThe main problem with having multiple parents for a commit object\ncorresponding to a patch is the upstream merging via 'git pull'. In\ngeneral you don't want a gatekeeper to pull the history of your patch\nbut the patch only.\n\n> The patch below, together with the following script could be used to\n> make snapshots of the patch stack (I call it freeze, as I thought snapshot\n> was already going to be used for something else):\n\n'snapshot' is not yet used for anything and I'm not sure how it is\nbest to be implemented. I thought about simply saving the current HEAD\ninto some .git/refs/heads/<file>, without preserving any history for\nthe patch. A gitk on this file would show the patches as they were on\nthe time of the snapshot creation. A new snapshot would remove this.\n\nIt might be best for a per-patch history to have a separate file in\n<branch>/<patch>/, maybe called freeze, which keeps this history\ninformation. The top one should remain unchanged. Its hash could be\naccessed with the 'stg id /freeze' command (implemented\nyesterday). This file would only be updated via the 'freeze' command\nand its parent would be the previous freeze value.\n\nWould this be close to what you need?\n\n-- \nCatalin\n"},{"id":"7570","messageId":"20050819182732.GA5512@fanta","threadId":"1576","inReplyTo":"tnx64u2p81k.fsf@arm.com","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Jan Veldeman","fromEmail":"jan.veldeman@gmail.com","sentAt":"2005-08-19T18:27:32Z","receivedAt":"2005-08-19T18:27:32Z","isPatch":false,"sender":{"key":"jan.veldeman@gmail.com","avatar":"https://gravatar.com/avatar/83744a7c7e462c17ea2747bb0b69bb1719a0a6a9769777ced20ec3f162f69fc4?d=mp&s=160"},"body":"Catalin Marinas wrote:\n\n> \n> The patch history feature was available in StGIT 0.1/0.2 releases\n> where you should have run a 'stg commit' before 'stg refresh'. The\n> commit was handling all the history changes, with separate commit\n> messages and refresh was updating the main commit with 2 parents. I\n> removed it in 0.3 after some people (I think it was Paul Jackson and\n> Daniel Barkalow) convinced me that this would make it yet another SCM\n> interface on top of GIT, which wasn't really my intention.\n\nhmm, I must have misted those threads, I'll try to find and read them.\n\n> \n> The main problem with having multiple parents for a commit object\n> corresponding to a patch is the upstream merging via 'git pull'. In\n> general you don't want a gatekeeper to pull the history of your patch\n> but the patch only.\n\nI agree that such history should not be imported into the mainline, but such\nhistory would still be very usefull when these patches won't be pushed to\nmailine immediately. Also, when pushing to mainline, this history can easily\nbe removed by removing the branch/patch/parent files and refreshing (this\nshould off course be automated)\n\n> \n> > The patch below, together with the following script could be used to\n> > make snapshots of the patch stack (I call it freeze, as I thought snapshot\n> > was already going to be used for something else):\n> \n> 'snapshot' is not yet used for anything and I'm not sure how it is\n> best to be implemented. I thought about simply saving the current HEAD\n> into some .git/refs/heads/<file>, without preserving any history for\n> the patch. A gitk on this file would show the patches as they were on\n> the time of the snapshot creation. A new snapshot would remove this.\n> \n> It might be best for a per-patch history to have a separate file in\n> <branch>/<patch>/, maybe called freeze, which keeps this history\n> information. The top one should remain unchanged. Its hash could be\n> accessed with the 'stg id /freeze' command (implemented\n> yesterday). This file would only be updated via the 'freeze' command\n> and its parent would be the previous freeze value.\n> \n> Would this be close to what you need?\n> \n\nhmm, not exactly, for example, when reordering the patches (including the\ntop one), I would like to see this in gitk.\nOr when a patch has been dropped (amongst a lot of patches), it should be\neasily spotted.\n\n\nBut even if the \"stg-freeze\" would not be incorporated into stgit, would it\nstill be possible to include some sort of extra parents directory. So that\nthe freeze can be implemented on top of stgit?\n\nTIA\n\nBest regards,\nJan\n"},{"id":"7572","messageId":"20050819194832.GA8562@fanta","threadId":"1576","inReplyTo":"tnx64u2p81k.fsf@arm.com","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Jan Veldeman","fromEmail":"jan.veldeman@gmail.com","sentAt":"2005-08-19T19:48:32Z","receivedAt":"2005-08-19T19:48:32Z","isPatch":false,"sender":{"key":"jan.veldeman@gmail.com","avatar":"https://gravatar.com/avatar/83744a7c7e462c17ea2747bb0b69bb1719a0a6a9769777ced20ec3f162f69fc4?d=mp&s=160"},"body":"Catalin Marinas wrote:\n\n> \n> The patch history feature was available in StGIT 0.1/0.2 releases\n> where you should have run a 'stg commit' before 'stg refresh'. The\n> commit was handling all the history changes, with separate commit\n> messages and refresh was updating the main commit with 2 parents. I\n> removed it in 0.3 after some people (I think it was Paul Jackson and\n> Daniel Barkalow) convinced me that this would make it yet another SCM\n> interface on top of GIT, which wasn't really my intention.\n\nI've quickly reread the threads about stg commit. Am I right to assume that\n_all_ history was being recorded? Because this is not what I want. The\nperson controlling the archive should specify when to record the history.\n\nSo for example, you only tag (freeze) the history when exporting the\npatches.  When an error is being reported on that version, it's easy to view\nit and also view the progress that was already been made on those patches.\n\n\nBest regards,\nJan\n"},{"id":"7577","messageId":"1124489735.6957.4.camel@localhost.localdomain","threadId":"1576","inReplyTo":"20050819182732.GA5512@fanta","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-19T22:15:35Z","receivedAt":"2005-08-19T22:15:35Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On Fri, 2005-08-19 at 20:27 +0200, Jan Veldeman wrote:\n> hmm, not exactly, for example, when reordering the patches (including the\n> top one), I would like to see this in gitk.\n> Or when a patch has been dropped (amongst a lot of patches), it should be\n> easily spotted.\n\nI tried your patch but the gitk image confused me. I will look again at\nit tomorrow (it's quite late in the UK now).\n\nOne immediate thing I noticed was that the commits directly accessible\nvia .git/HEAD are shown as empty by gitk and you would need to follow\nthe parents to see what they contain. For every freeze, the patches\nexpand to the right in gitk and the graph could get very complex after\nseveral freeze commands.\n\n-- \nCatalin\n"},{"id":"7598","messageId":"1124572356.7512.21.camel@localhost.localdomain","threadId":"1576","inReplyTo":"20050819194832.GA8562@fanta","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-20T21:12:36Z","receivedAt":"2005-08-20T21:12:36Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On Fri, 2005-08-19 at 21:48 +0200, Jan Veldeman wrote:\n> I've quickly reread the threads about stg commit. Am I right to assume that\n> _all_ history was being recorded? Because this is not what I want. The\n> person controlling the archive should specify when to record the history.\n\nTrue, I was talking about the full history, but I don't find the idea\nmuch different. There was another mail on this issue -\nhttp://article.gmane.org/gmane.comp.version-control.git/5191\n\n> So for example, you only tag (freeze) the history when exporting the\n> patches.  When an error is being reported on that version, it's easy to view\n> it and also view the progress that was already been made on those patches.\n\nI agree that it is a useful feature to be able to individually tag the\npatches. The problem is how to do this best. Your approach looks to me\nlike it's not following the GIT DAG structure recommendation. Maybe the\nGIT designers could further comment on this but a commit object with\nmultiple parents should be a result of a merge operation. A commit with\na single parent should represent a transition of the tree from one state\nto another. With the freeze command you proposed, a commit with multiple\nparents is no longer a result of a merge operation, but just a\nconvenience for tracking the patch history with gitk.\n\nI tried your patch and test script but, if you try to reorder the\npatches, the DAG structure become quite hard to understand and that's\nonly for a small set of frozen states.\n\nI think the best approach would be to keep a list of tags for each\npatch. They won't be browsable with gitk but the DAG structure would be\nclean. We might get another tool like gquilt to be able to show all the\nsaved states of a patch.\n\nSorry for not including your patch but, while I agree with the general\nidea of frozen patch states, I disagree with its implementation.\n\n-- \nCatalin\n"},{"id":"7603","messageId":"20050821094059.GA5453@fanta","threadId":"1576","inReplyTo":"1124572356.7512.21.camel@localhost.localdomain","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Jan Veldeman","fromEmail":"jan.veldeman@gmail.com","sentAt":"2005-08-21T09:40:59Z","receivedAt":"2005-08-21T09:40:59Z","isPatch":false,"sender":{"key":"jan.veldeman@gmail.com","avatar":"https://gravatar.com/avatar/83744a7c7e462c17ea2747bb0b69bb1719a0a6a9769777ced20ec3f162f69fc4?d=mp&s=160"},"body":"Catalin Marinas wrote:\n\n> > So for example, you only tag (freeze) the history when exporting the\n> > patches.  When an error is being reported on that version, it's easy to view\n> > it and also view the progress that was already been made on those patches.\n> \n> I agree that it is a useful feature to be able to individually tag the\n> patches. The problem is how to do this best. Your approach looks to me\n> like it's not following the GIT DAG structure recommendation. Maybe the\n> GIT designers could further comment on this but a commit object with\n> multiple parents should be a result of a merge operation. A commit with\n> a single parent should represent a transition of the tree from one state\n> to another. With the freeze command you proposed, a commit with multiple\n> parents is no longer a result of a merge operation, but just a\n> convenience for tracking the patch history with gitk.\n\nMy interpretation of parents is broader than only merges, and reading the\nREADME file, I believe it also the intension to do so (snippet from README\nfile):\n\nA \"commit\" object ties such directory hierarchies together into\na DAG of revisions - each \"commit\" is associated with exactly one tree\n(the directory hierarchy at the time of the commit). In addition, a\n\"commit\" refers to one or more \"parent\" commit objects that describe the\nhistory of how we arrived at that directory hierarchy.\n\n\nAnother advantage of this approach is when pushing the top of your\nrepository to others, less rebasing would be noticed:\nWhen pushing the top of your stack out to others, the new one won't be a\n(possibly indirect) child of the previous push. This makes updating such a\nhead more dificult. With this approach, the new head will be a (possibly\nindirect) child of the previous one (except when the top patch has been\nremoved, but this corner case could also be solved).\n\nBecause of this less rebasing, this aproach also facilitates co-development\non stgit patch stacks: by using a base:top id pair, the stgit patch stack\ncould be initialized, including its exported history. By following the\nparent/child relations, 2 patch stacks could be compared and merged.\n\n> \n> I tried your patch and test script but, if you try to reorder the\n> patches, the DAG structure become quite hard to understand and that's\n> only for a small set of frozen states.\n\nI acknowledge this problem, but the solution for this would be to give\ngitk another way of viewing such history: only the latest description of a\npatch should be visible and the history should become more horizontal\n(because the older descriptions wouldn't be shown, the history of those\npatches could be viewed on the line with the latest description)\n\nBut changing gitk would only be usefull when this approach would be taken.\n\n> \n> I think the best approach would be to keep a list of tags for each\n> patch. They won't be browsable with gitk but the DAG structure would be\n> clean. We might get another tool like gquilt to be able to show all the\n> saved states of a patch.\n> \n> Sorry for not including your patch but, while I agree with the general\n> idea of frozen patch states, I disagree with its implementation.\n> \n\nI understand your objections when limiting parents only to merges, but I see\nthem broader. So as you said: we indeed need a git designer to clear this up\nfor us.\n\nBest regards,\nJan\n"},{"id":"7624","messageId":"Pine.LNX.4.63.0508221707520.23242@iabervon.org","threadId":"1576","inReplyTo":"20050821094059.GA5453@fanta","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-22T22:10:02Z","receivedAt":"2005-08-22T22:10:02Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 21 Aug 2005, Jan Veldeman wrote:\n\n> Catalin Marinas wrote:\n>\n> > > So for example, you only tag (freeze) the history when exporting the\n> > > patches.  When an error is being reported on that version, it's easy to view\n> > > it and also view the progress that was already been made on those patches.\n> >\n> > I agree that it is a useful feature to be able to individually tag the\n> > patches. The problem is how to do this best. Your approach looks to me\n> > like it's not following the GIT DAG structure recommendation. Maybe the\n> > GIT designers could further comment on this but a commit object with\n> > multiple parents should be a result of a merge operation. A commit with\n> > a single parent should represent a transition of the tree from one state\n> > to another. With the freeze command you proposed, a commit with multiple\n> > parents is no longer a result of a merge operation, but just a\n> > convenience for tracking the patch history with gitk.\n>\n> My interpretation of parents is broader than only merges, and reading the\n> README file, I believe it also the intension to do so (snippet from README\n> file):\n>\n> A \"commit\" object ties such directory hierarchies together into\n> a DAG of revisions - each \"commit\" is associated with exactly one tree\n> (the directory hierarchy at the time of the commit). In addition, a\n> \"commit\" refers to one or more \"parent\" commit objects that describe the\n> history of how we arrived at that directory hierarchy.\n\nOne factor not mentioned there is that, as things move upstream, we often\nwant to discard a lot of history; if someone commits constantly to deal\nwith editor malfunction or something, we don't really want to take all of\nthis junk into the project history when it is cleaned up and accepted.\n\nSo the point is that there are things which are, in fact, parents, but we\ndon't want to list them, because it's not desired information.\n\nProbably the right thing is to have two views of the stack: the internal\nview, showing what actually happened, and the external view, showing what\nwould have happened if the developers had done everything right the first\ntime. When you make changes to the series, this adds to the internal view\nand entirely replaces the external view.\n\nI think that users will also want to discard the commits from the stack\nbefore rebasing in favor of the commits after, because (a) rebasing isn't\nall that interesting, especially if there's minimal merging, and (b)\notherwise you'd get a ton of boring commits that obscure the interesting\nones.\n\nI think that the best rule would be that, when you modify a patch, the\nprevious version is the new version's parent, and when you rebase a\nseries, you include as a parent any parent of the input that isn't also in\nthe input (but never include the input itself as a parent of the output;\nthe point of rebasing is to pretend that it was the newer mainline that\nyou modified). This should mean that the internal history of a patch\nconsists of the present version, based on each version that was replaced\ndue to changing the patch rather than rebasing it.\n\nOf course, there's an interesting situation with the commits earlier in a\nseries from a patch that was changed not being ancestors of the newer\nversions of those patches (because they weren't interesting in the\ndevelopment of those patches) but accessible as the commits that an\ninteresting patch was based on.\n\nA possible solution is just to consider the revision of any patch a\nsignificant event in the history of the whole stack, causing all of the\npatches to get a new retained version.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7632","messageId":"7vmzn91mxq.fsf@assigned-by-dhcp.cox.net","threadId":"1576","inReplyTo":"20050821094059.GA5453@fanta","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-23T01:06:41Z","receivedAt":"2005-08-23T01:06:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jan Veldeman <jan.veldeman@gmail.com> writes:\n\n> ... So as you said: we indeed need a git designer to clear this up\n> for us.\n\nI understand I am counted as one of the \"git designers\"; I have\nbeen aware of this thread but I have to admit that I am way\nbehind and have not caught up with the issues.  I'll try to\ncomment on them when I feel I know enough about the issues\ninvolved, but not right now.  Sorry.\n\nPlease do not start explain them to me yet, I am behind due to\nlack of time and you would end up wasting your time.\n"},{"id":"7653","messageId":"tnxvf1wd24m.fsf@arm.com","threadId":"1576","inReplyTo":"Pine.LNX.4.63.0508221707520.23242@iabervon.org","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-23T16:55:21Z","receivedAt":"2005-08-23T16:55:21Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Daniel Barkalow <barkalow@iabervon.org> wrote:\n> One factor not mentioned there is that, as things move upstream, we often\n> want to discard a lot of history; if someone commits constantly to deal\n> with editor malfunction or something, we don't really want to take all of\n> this junk into the project history when it is cleaned up and\n> accepted.\n\nThat's true but Jan's proposal is to choose which commits to preserve\nin the history via a 'freeze' command. That's a bit difficult to\nimplement in a clean way since the patches are floating on top of the\nstack base and they change every time the base changes. It is possible\nthat a previous frozen state might no longer apply on top of a new\nbase.\n\n> So the point is that there are things which are, in fact, parents, but we\n> don't want to list them, because it's not desired information.\n\nWhat's the definition of a parent in GIT terms? What are the\nrestriction for a commit object to be a parent? Can a parent be an\narbitrarily chosen commit?\n\n> Probably the right thing is to have two views of the stack: the internal\n> view, showing what actually happened, and the external view, showing what\n> would have happened if the developers had done everything right the first\n> time. When you make changes to the series, this adds to the internal view\n> and entirely replaces the external view.\n\nThat's what I've been thinking. StGIT currently only implements the\nexternal view.\n\nAn StGIT patch is a represented by a top and bottom commit\nobjects. The bottom one is the same as the parent of the top\ncommit. The patch is the diff between the top's tree id and the\nbottom's tree id.\n\nJan's proposal is to allow a freeze command to save the current top\nhash and later be used as a second parent for the newly generated\ntop. The problem I see with this approach is that (even for the\ninternal view you described) the newly generated top will have two\nparents, new-bottom and old-top, but only the diff between new-top and\nnew-bottom is meaningful. The diff between new-top and old-top (as a\nparent-child relation) wouldn't contain anything relevant to the patch\nbut all the new changes to the base of the stack.\n\nIs the above an acceptable usage of the GIT DAG structure?\n\n> I think that users will also want to discard the commits from the stack\n> before rebasing in favor of the commits after, because (a) rebasing isn't\n> all that interesting, especially if there's minimal merging, and (b)\n> otherwise you'd get a ton of boring commits that obscure the interesting\n> ones.\n\nStGIT does this currently. The old commit is no longer available and\ncan be pruned (I still need to save the commits corresponding to the\nunpushed patches since prune would remove those as well).\n\n> I think that the best rule would be that, when you modify a patch, the\n> previous version is the new version's parent, and when you rebase a\n> series, you include as a parent any parent of the input that isn't also in\n> the input (but never include the input itself as a parent of the output;\n> the point of rebasing is to pretend that it was the newer mainline that\n> you modified). This should mean that the internal history of a patch\n> consists of the present version, based on each version that was replaced\n> due to changing the patch rather than rebasing it.\n\nSince you proposed this, my above usage of the DAG structure would be\nfine then.\n\n> Of course, there's an interesting situation with the commits earlier in a\n> series from a patch that was changed not being ancestors of the newer\n> versions of those patches (because they weren't interesting in the\n> development of those patches) but accessible as the commits that an\n> interesting patch was based on.\n>\n> A possible solution is just to consider the revision of any patch a\n> significant event in the history of the whole stack, causing all of the\n> patches to get a new retained version.\n\nThat's another idea to think about.\n\n-- \nCatalin\n\n\nP.S. I'll be away until next week and not able to follow-up the\ndiscussions.\n"},{"id":"7658","messageId":"Pine.LNX.4.63.0508231304130.23242@iabervon.org","threadId":"1576","inReplyTo":"tnxvf1wd24m.fsf@arm.com","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-23T18:05:57Z","receivedAt":"2005-08-23T18:05:57Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 23 Aug 2005, Catalin Marinas wrote:\n\n> > So the point is that there are things which are, in fact, parents, but we\n> > don't want to list them, because it's not desired information.\n>\n> What's the definition of a parent in GIT terms? What are the\n> restriction for a commit object to be a parent? Can a parent be an\n> arbitrarily chosen commit?\n\nSomething is legitimate as a parent if someone took that commit and did\nsomething to it to get the new commit. The operation which caused the\nchange is not specified. But you only want to include it if anyone cares\nabout the parent.\n\n(For example, I often start with a chunk of work that does multiple things\nand is committed; I take mainline and generate a series of commits from\nthere. It would be legitimate to list my development commit as a parent of\neach of these, since I did actually take it and strip out the unrelated\nchanges. This would be a bit confusing in the log, but would make merges\nbetween something based on the \"messy\" version and something based on the\n\"refined\" version work well. On the other hand, I don't want to report the\nexistance of the messy version, so I don't include it.)\n\n> An StGIT patch is a represented by a top and bottom commit\n> objects. The bottom one is the same as the parent of the top\n> commit. The patch is the diff between the top's tree id and the\n> bottom's tree id.\n>\n> Jan's proposal is to allow a freeze command to save the current top\n> hash and later be used as a second parent for the newly generated\n> top. The problem I see with this approach is that (even for the\n> internal view you described) the newly generated top will have two\n> parents, new-bottom and old-top, but only the diff between new-top and\n> new-bottom is meaningful. The diff between new-top and old-top (as a\n> parent-child relation) wouldn't contain anything relevant to the patch\n> but all the new changes to the base of the stack.\n\nHaving a useful diff isn't really a requirement for a parent; the diff in\nthe case of a merge is going to be the total of everything that happened\nelsewhere. The point is to be able to reach some commits between which\nthere are interesting diffs.\n\nThis also depends on how exactly freeze is used; if you use it before\ncommiting a modification to the patch without rebasing, you get:\n\nold-top -> new-top\n      ^    ^\n       \\  /\n      bottom\n\nbottom to old-top is the old patch\nbottom to new-top is the new patch\nold-top to new-top is the change to the patch\n\nThen you want to keep new-top as a parent for rebasings until one of these\nis frozen. These links are not interesting to look at, but preserve the\npath to the old-top:new-top change, which is interesting.\n\nIgnoring the links to the corresponding bottoms, the development therefore\nlooks like:\n\nlocal1 -> local2 -> merge -> local3 -> merge\n^                   ^                  ^\nmainline---->-->--------->------>-->----->\n\nAnd this is how development is normally supposed to look. The trick is to\nonly include a minimal number of merges.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7667","messageId":"20050823212305.GA5936@fanta","threadId":"1576","inReplyTo":"Pine.LNX.4.63.0508231304130.23242@iabervon.org","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Jan Veldeman","fromEmail":"jan.veldeman@gmail.com","sentAt":"2005-08-23T21:23:05Z","receivedAt":"2005-08-23T21:23:05Z","isPatch":false,"sender":{"key":"jan.veldeman@gmail.com","avatar":"https://gravatar.com/avatar/83744a7c7e462c17ea2747bb0b69bb1719a0a6a9769777ced20ec3f162f69fc4?d=mp&s=160"},"body":"Daniel Barkalow wrote:\n\n> On Tue, 23 Aug 2005, Catalin Marinas wrote:\n> \n> Something is legitimate as a parent if someone took that commit and did\n> something to it to get the new commit. The operation which caused the\n> change is not specified. But you only want to include it if anyone cares\n> about the parent.\n\nThis is indeed what I thought a parent should be used for. As an adition,\nI'll try to explain why I would sometimes want to care about some parents:\n\nI want to track a mailine tree, but have quite a few changes, which shoudn't\nbe commited to the mainline immediately (let's call it my development tree).\nThis is why I would use stgit. But I would also want to colaborate with\nother developers on this development tree, so I sometimes want to make\nupdates available of this development tree to the others. This is where\ncurrent stgit falls short. To easily share this development tree, I want\nsome history (not all, only the ones I choose) of this development tree\nincluded, so that the other developers can easily follow my development.\n\nThe parents which should be visible to the outside, will always be versions\nof my development tree, which I have previously pushed out. My way of\nworking would become:\n* make changes, all over the place, using stgit\n* still make changes (none of these gets tracked, intermittent versions are\n  lost)\n* having a good day: changes looks good, I want to push this out:\n  * push my tree out\n  * stgit-free (which makes the pushed out commits, the new parents of my\n    stgit patches)\n* restart from top\n\n[...]\n> This also depends on how exactly freeze is used; if you use it before\n> commiting a modification to the patch without rebasing, you get:\n> \n> old-top -> new-top\n>       ^    ^\n>        \\  /\n>       bottom\n> \n> bottom to old-top is the old patch\n> bottom to new-top is the new patch\n> old-top to new-top is the change to the patch\n> \n> Then you want to keep new-top as a parent for rebasings until one of these\n> is frozen. These links are not interesting to look at, but preserve the\n> path to the old-top:new-top change, which is interesting.\n\nmy proposal does something like this, but a little more: not only does it\nkeep track of the link between old-top and new-top, it also keeps track of\nthe links between old-patch-in-between and new-patch-in-between.\n(This makes sense when the top is being removed or reordered)\n\nI hope this kind of clarifies my intension.\n\n\nThank you for clarifying the meaning of parents.\n\nBest regards,\nJan\n"},{"id":"7676","messageId":"Pine.LNX.4.63.0508231731370.23242@iabervon.org","threadId":"1576","inReplyTo":"20050823212305.GA5936@fanta","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-23T22:23:57Z","receivedAt":"2005-08-23T22:23:57Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 23 Aug 2005, Jan Veldeman wrote:\n\n> Daniel Barkalow wrote:\n>\n> > On Tue, 23 Aug 2005, Catalin Marinas wrote:\n> >\n> > Something is legitimate as a parent if someone took that commit and did\n> > something to it to get the new commit. The operation which caused the\n> > change is not specified. But you only want to include it if anyone cares\n> > about the parent.\n>\n> This is indeed what I thought a parent should be used for. As an adition,\n> I'll try to explain why I would sometimes want to care about some parents:\n>\n> I want to track a mailine tree, but have quite a few changes, which shoudn't\n> be commited to the mainline immediately (let's call it my development tree).\n> This is why I would use stgit. But I would also want to colaborate with\n> other developers on this development tree, so I sometimes want to make\n> updates available of this development tree to the others. This is where\n> current stgit falls short. To easily share this development tree, I want\n> some history (not all, only the ones I choose) of this development tree\n> included, so that the other developers can easily follow my development.\n>\n> The parents which should be visible to the outside, will always be versions\n> of my development tree, which I have previously pushed out. My way of\n> working would become:\n> * make changes, all over the place, using stgit\n> * still make changes (none of these gets tracked, intermittent versions are\n>   lost)\n> * having a good day: changes looks good, I want to push this out:\n>   * push my tree out\n>   * stgit-free (which makes the pushed out commits, the new parents of my\n>     stgit patches)\n> * restart from top\n\nI'm not sure how applicable to this situation stgit really is; I see stgit\nas optimized for the case of a patch set which is basically done, where\nyou want to keep it applicable to the mainline as the mainline advances.\n\nFor your application, I'd just have a git branch full of various stuff,\nand then generate clean commits by branching mainline, diffing development\nagainst it, cutting the diff down to just what I want to push, and\napplying that. Then the clean patch goes into stgit.\n\n> [...]\n> > This also depends on how exactly freeze is used; if you use it before\n> > commiting a modification to the patch without rebasing, you get:\n> >\n> > old-top -> new-top\n> >       ^    ^\n> >        \\  /\n> >       bottom\n> >\n> > bottom to old-top is the old patch\n> > bottom to new-top is the new patch\n> > old-top to new-top is the change to the patch\n> >\n> > Then you want to keep new-top as a parent for rebasings until one of these\n> > is frozen. These links are not interesting to look at, but preserve the\n> > path to the old-top:new-top change, which is interesting.\n>\n> my proposal does something like this, but a little more: not only does it\n> keep track of the link between old-top and new-top, it also keeps track of\n> the links between old-patch-in-between and new-patch-in-between.\n> (This makes sense when the top is being removed or reordered)\n\nI was thinking of this as being the top and bottom commits for a single\ntracked patch, not as a whole series. I think patches lower wouldn't be\naffected, and patches higher would see this as a rebase.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7686","messageId":"7virxwmbcu.fsf@assigned-by-dhcp.cox.net","threadId":"1576","inReplyTo":"tnxvf1wd24m.fsf@arm.com","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-24T00:23:29Z","receivedAt":"2005-08-24T00:23:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Catalin Marinas <catalin.marinas@gmail.com> writes:\n\n> What's the definition of a parent in GIT terms? What are the\n> restriction for a commit object to be a parent? Can a parent be an\n> arbitrarily chosen commit?\n\nYes it can.  GIT does not care if the commit ancestry does not\nmake sense in contents terms (i.e. you can record one tree\nobject in a commit object, and record another, completely\nunrelated tree object in a commit object that has the first\ncommit object as its parent).  The \"git-diff-tree\" output from\ncomparing those two commits may not make _any_ sense at all to\nthe human, though, but that is not a problem for GIT to do its\nwork.\n\n> That's what I've been thinking. StGIT currently only implements the\n> external view.\n>\n> An StGIT patch is a represented by a top and bottom commit\n> objects. The bottom one is the same as the parent of the top\n> commit. The patch is the diff between the top's tree id and the\n> bottom's tree id.\n>\n> Jan's proposal is to allow a freeze command to save the current top\n> hash and later be used as a second parent for the newly generated\n> top. The problem I see with this approach is that (even for the\n> internal view you described) the newly generated top will have two\n> parents, new-bottom and old-top, but only the diff between new-top and\n> new-bottom is meaningful. The diff between new-top and old-top (as a\n> parent-child relation) wouldn't contain anything relevant to the patch\n> but all the new changes to the base of the stack.\n>\n> Is the above an acceptable usage of the GIT DAG structure?\n\nSurely, as long as it stays internal as StGIT patch stacks.\nEven when it is exported (i.e. you manage to have other non\nStGIT managed tree to pull and merge with such a commit), the\ndevelopment history _might_ look funny and complicated, but it\nshould not be a problem for GIT to handle.  After all, you are\ndoing complicated thing in the StGIT patch stacks when you pop,\npush and freeze number of times, so your history is complicated.\nIf you want to record that history at least for StGIT internal\nbookkeeping purposes, GIT should not prevent you from doing it.\n\nHaving said that, I would 100% agree with you that having a\ncleansed external view would be a good idea.  It makes merging\nwith StGIT managed repositories much more acceptable to ordinary\nGIT managed history.\n"},{"id":"7695","messageId":"Pine.LNX.4.58.0508231922340.3317@g5.osdl.org","threadId":"1576","inReplyTo":"7virxwmbcu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-08-24T02:26:27Z","receivedAt":"2005-08-24T02:26:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 23 Aug 2005, Junio C Hamano wrote:\n> \n> Yes it can.  GIT does not care if the commit ancestry does not\n> make sense in contents terms (i.e. you can record one tree\n> object in a commit object, and record another, completely\n> unrelated tree object in a commit object that has the first\n> commit object as its parent).  The \"git-diff-tree\" output from\n> comparing those two commits may not make _any_ sense at all to\n> the human, though, but that is not a problem for GIT to do its\n> work.\n\nOne issue is later merges.\n\nIf you have incorrect parent information, trying to do a merge may prove\nimpossible and/or ignore changes from the \"already merged\" stream. By\nmarking another head as a parent, you basically say \"I have merged\n_everything_ leading up to that other head\", and if you have only actually\ndone a partial merge (and gotten just a part of the changes, ignoring the\nothers), you'll have to notice that yourself, and forward-port the rest by\nhand.\n\nFor stgit, this probably doesn't matter.\n\n\t\tLinus\n"},{"id":"7744","messageId":"20050825070955.GA762@eros.intern.mind.be","threadId":"1576","inReplyTo":"Pine.LNX.4.63.0508231731370.23242@iabervon.org","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Jan Veldeman","fromEmail":"jan.veldeman@gmail.com","sentAt":"2005-08-25T07:09:55Z","receivedAt":"2005-08-25T07:09:55Z","isPatch":false,"sender":{"key":"jan.veldeman@gmail.com","avatar":"https://gravatar.com/avatar/83744a7c7e462c17ea2747bb0b69bb1719a0a6a9769777ced20ec3f162f69fc4?d=mp&s=160"},"body":"Daniel Barkalow wrote:\n\n[...]\n> > The parents which should be visible to the outside, will always be versions\n> > of my development tree, which I have previously pushed out. My way of\n> > working would become:\n> > * make changes, all over the place, using stgit\n> > * still make changes (none of these gets tracked, intermittent versions are\n> >   lost)\n> > * having a good day: changes looks good, I want to push this out:\n> >   * push my tree out\n> >   * stgit-free (which makes the pushed out commits, the new parents of my\n> >     stgit patches)\n> > * restart from top\n> \n> I'm not sure how applicable to this situation stgit really is; I see stgit\n> as optimized for the case of a patch set which is basically done, where\n> you want to keep it applicable to the mainline as the mainline advances.\n\nMaybe I forgot to mention this: I would also like to have my development\ntree split up in a patch stack. The separate patches makes tracking the\nmainline a lot easier (conflicts are a lot easier to solve)\n\n> \n> For your application, I'd just have a git branch full of various stuff,\n> and then generate clean commits by branching mainline, diffing development\n> against it, cutting the diff down to just what I want to push, and\n> applying that. Then the clean patch goes into stgit.\n\nBut this would assume that once the patch goes into stgit, it won't\nchange except when the parent gets updated. I think we will still change\nthe patches quite a bit and simultanious by a couple of people.\n\n> \n> > [...]\n> > my proposal does something like this, but a little more: not only does it\n> > keep track of the link between old-top and new-top, it also keeps track of\n> > the links between old-patch-in-between and new-patch-in-between.\n> > (This makes sense when the top is being removed or reordered)\n> \n> I was thinking of this as being the top and bottom commits for a single\n> tracked patch, not as a whole series. I think patches lower wouldn't be\n> affected, and patches higher would see this as a rebase.\n> \n\nah, ok, I misunderstood that part\n\nBest regards,\nJan\n\nPS. sorry if my responses are sometimes a bit late, I'm trying to find\nmore time to spend on this list ;-)\n"},{"id":"7753","messageId":"Pine.LNX.4.63.0508251210030.23242@iabervon.org","threadId":"1576","inReplyTo":"20050825070955.GA762@eros.intern.mind.be","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-25T19:41:23Z","receivedAt":"2005-08-25T19:41:23Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 25 Aug 2005, Jan Veldeman wrote:\n\n> Daniel Barkalow wrote:\n>\n> > I'm not sure how applicable to this situation stgit really is; I see stgit\n> > as optimized for the case of a patch set which is basically done, where\n> > you want to keep it applicable to the mainline as the mainline advances.\n>\n> Maybe I forgot to mention this: I would also like to have my development\n> tree split up in a patch stack. The separate patches makes tracking the\n> mainline a lot easier (conflicts are a lot easier to solve)\n\nI just try to keep things in this state sufficiently briefly that it\ndoesn't become a problem. I also split things up into a bunch of branches,\nrather than into a stack of patches, and only work on parallel development\nbefore I've actually got a candidate for a series.\n\n> But this would assume that once the patch goes into stgit, it won't\n> change except when the parent gets updated. I think we will still change\n> the patches quite a bit and simultanious by a couple of people.\n\nThe extension I had proposed to stgit should work for this; it would let\nyou version control each patch just like other git projects. I just think\nit wouldn't work so well before the group has agreed on what patches there\nare.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7960","messageId":"1125438074.6961.20.camel@localhost.localdomain","threadId":"1576","inReplyTo":"Pine.LNX.4.63.0508231304130.23242@iabervon.org","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-30T21:41:14Z","receivedAt":"2005-08-30T21:41:14Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Back from holiday. Thanks to all who replied to this thread.\n\nOn Tue, 2005-08-23 at 14:05 -0400, Daniel Barkalow wrote:\n> Having a useful diff isn't really a requirement for a parent; the diff in\n> the case of a merge is going to be the total of everything that happened\n> elsewhere. The point is to be able to reach some commits between which\n> there are interesting diffs.\n> \n> This also depends on how exactly freeze is used; if you use it before\n> commiting a modification to the patch without rebasing, you get:\n> \n> old-top -> new-top\n>       ^    ^\n>        \\  /\n>       bottom\n> \n> bottom to old-top is the old patch\n> bottom to new-top is the new patch\n> old-top to new-top is the change to the patch\n> \n> Then you want to keep new-top as a parent for rebasings until one of these\n> is frozen. These links are not interesting to look at, but preserve the\n> path to the old-top:new-top change, which is interesting.\n\nThis was my initial StGIT implementation (up to version 0.3), only that\nthere was no freeze command. Since I want an StGIT tree to be clean to\nthe outside world, I wouldn't keep multiple parents for the visible top\nof a patch.\n\nAs I understand from Junio's and Linus' e-mails (on the 23rd of August),\nthere might be problems with merging the HEAD of an StGIT-managed tree\nif the above method is accessible via HEAD.\n\n> Ignoring the links to the corresponding bottoms, the development therefore\n> looks like:\n> \n> local1 -> local2 -> merge -> local3 -> merge\n> ^                   ^                  ^\n> mainline---->-->--------->------>-->----->\n> \n> And this is how development is normally supposed to look. The trick is to\n> only include a minimal number of merges.\n\nA merge occurs every time a patch is rebased. Anyway, having the bottoms\nin the graph (which is the main idea of StGIT) together with the old-top\n(or frozen state) parents make the graph pretty complicated.\n\n-- \nCatalin\n"},{"id":"7968","messageId":"20050831085900.GA5764@fanta","threadId":"1576","inReplyTo":"1125438074.6961.20.camel@localhost.localdomain","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Jan Veldeman","fromEmail":"jan.veldeman@gmail.com","sentAt":"2005-08-31T08:59:00Z","receivedAt":"2005-08-31T08:59:00Z","isPatch":false,"sender":{"key":"jan.veldeman@gmail.com","avatar":"https://gravatar.com/avatar/83744a7c7e462c17ea2747bb0b69bb1719a0a6a9769777ced20ec3f162f69fc4?d=mp&s=160"},"body":"Catalin, Daniel,\n\nthank you both for your input.\nI'll try your recommendations (when time is available ;-) and see how it\ngoes.\n\nBest regards,\nJan\n"},{"id":"7969","messageId":"tnxhdd6o4gk.fsf@arm.com","threadId":"1576","inReplyTo":"20050823212305.GA5936@fanta","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-31T09:12:11Z","receivedAt":"2005-08-31T09:12:11Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Jan Veldeman <jan.veldeman@gmail.com> wrote:\n> The parents which should be visible to the outside, will always be versions\n> of my development tree, which I have previously pushed out. My way of\n> working would become:\n> * make changes, all over the place, using stgit\n> * still make changes (none of these gets tracked, intermittent versions are\n>   lost)\n> * having a good day: changes looks good, I want to push this out:\n>   * push my tree out\n>   * stgit-free (which makes the pushed out commits, the new parents of my\n>     stgit patches)\n\nWhen the tree status looks good, you could tag it and the whole stack\n(the commits corresponding to the patches) would be available via this\ntag.\n\nAs I said, I agree with the idea of freezing a patch and even having\nmultiple parents to a commit but this commit should not be visible via\nHEAD. We could have another id for a patch, 'frozen', which stores the\nlast frozen state with the parents being the previous frozen\nstates. Its SHA1 value could be accessed via 'stg id <patch>/frozen'\n(in the same way as /top and /bottom ids).\n\n-- \nCatalin\n"},{"id":"7970","messageId":"tnxaciyo3qh.fsf@arm.com","threadId":"1576","inReplyTo":"Pine.LNX.4.63.0508231731370.23242@iabervon.org","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-31T09:27:50Z","receivedAt":"2005-08-31T09:27:50Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Daniel Barkalow <barkalow@iabervon.org> wrote:\n> On Tue, 23 Aug 2005, Jan Veldeman wrote:\n>> The parents which should be visible to the outside, will always be versions\n>> of my development tree, which I have previously pushed out. My way of\n>> working would become:\n>> * make changes, all over the place, using stgit\n>> * still make changes (none of these gets tracked, intermittent versions are\n>>   lost)\n>> * having a good day: changes looks good, I want to push this out:\n>>   * push my tree out\n>>   * stgit-free (which makes the pushed out commits, the new parents of my\n>>     stgit patches)\n>> * restart from top\n>\n> I'm not sure how applicable to this situation stgit really is; I see stgit\n> as optimized for the case of a patch set which is basically done, where\n> you want to keep it applicable to the mainline as the mainline advances.\n>\n> For your application, I'd just have a git branch full of various stuff,\n> and then generate clean commits by branching mainline, diffing development\n> against it, cutting the diff down to just what I want to push, and\n> applying that. Then the clean patch goes into stgit.\n\nStGIT has the 'refresh' command which allows a patch to be\nindefinitely modified (that's pretty much how I use StGIT). I use it\nfor the case where I would like to keep the changes in separate\nlogical entities (patches) but they are not independent enough to\ncreate separate branches.\n\nTake for example a new platform port, you can have some of the\nexisting code re-worked in a patch, some CPU support in the next\npatch, basic platform support in another patch, some device drivers\nspecific to this platform in yet another patch. Subsequent patches are\ndependent on the previous ones. Branching from the mainline for each\nof these features might not make sense and keeping all of them in the\nsame branch can make maintenance a bit more difficult.\n\n-- \nCatalin\n"},{"id":"7977","messageId":"Pine.LNX.4.63.0508311306540.23242@iabervon.org","threadId":"1576","inReplyTo":"1125438074.6961.20.camel@localhost.localdomain","subject":"Re: [RFC] Stgit - patch history / add extra parents","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-31T17:17:26Z","receivedAt":"2005-08-31T17:17:26Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 30 Aug 2005, Catalin Marinas wrote:\n\n> Back from holiday. Thanks to all who replied to this thread.\n> \n> On Tue, 2005-08-23 at 14:05 -0400, Daniel Barkalow wrote:\n> > Having a useful diff isn't really a requirement for a parent; the diff in\n> > the case of a merge is going to be the total of everything that happened\n> > elsewhere. The point is to be able to reach some commits between which\n> > there are interesting diffs.\n> > \n> > This also depends on how exactly freeze is used; if you use it before\n> > commiting a modification to the patch without rebasing, you get:\n> > \n> > old-top -> new-top\n> >       ^    ^\n> >        \\  /\n> >       bottom\n> > \n> > bottom to old-top is the old patch\n> > bottom to new-top is the new patch\n> > old-top to new-top is the change to the patch\n> > \n> > Then you want to keep new-top as a parent for rebasings until one of these\n> > is frozen. These links are not interesting to look at, but preserve the\n> > path to the old-top:new-top change, which is interesting.\n> \n> This was my initial StGIT implementation (up to version 0.3), only that\n> there was no freeze command. Since I want an StGIT tree to be clean to\n> the outside world, I wouldn't keep multiple parents for the visible top\n> of a patch.\n> \n> As I understand from Junio's and Linus' e-mails (on the 23rd of August),\n> there might be problems with merging the HEAD of an StGIT-managed tree\n> if the above method is accessible via HEAD.\n\nRight, you'd want a separate head which is what you ask people to merge; \nthe rest is only visible to people who are working on preparing the patch. \nBut you could keep both sets of stuff (sharing tree objects but not \ncommits).\n\n> > Ignoring the links to the corresponding bottoms, the development therefore\n> > looks like:\n> > \n> > local1 -> local2 -> merge -> local3 -> merge\n> > ^                   ^                  ^\n> > mainline---->-->--------->------>-->----->\n> > \n> > And this is how development is normally supposed to look. The trick is to\n> > only include a minimal number of merges.\n> \n> A merge occurs every time a patch is rebased. Anyway, having the bottoms\n> in the graph (which is the main idea of StGIT) together with the old-top\n> (or frozen state) parents make the graph pretty complicated.\n\nIt should be possible to drop merges such that there's only one between \nany pair of local changes. That is, if you rebase at the end of the line \nabove, it would get as parents local3 and the new bottom, not the last \nmerge and the new bottom.\n\nThe mainline changes only come in through the bottoms, so higher levels \nshould look the same, but with the lower levels in the place of mainline.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}