{"thread":{"id":"3068","subject":"StGIT: \"stg new\" vs \"stg new --force\"","startedAt":"2006-01-13T09:24:51Z","lastAt":"2006-01-24T21:23:05Z","messageCount":19,"participants":["Pavel Roskin","Karl Hasselström","Catalin Marinas","Yann Dirson","J. Bruce Fields"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"14608","messageId":"1137144291.20073.104.camel@dv","threadId":"3068","inReplyTo":null,"subject":"StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-01-13T09:24:51Z","receivedAt":"2006-01-13T09:24:51Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello, Catalin!\n\nMaybe I don't understand something in StGIT, but it seems strange that\n\"stg new\" creates empty patch by default and requires \"--force\" to\ncreate a non-empty patch.\n\nIt's much easier to give a patch a name once I know what it does. Most\ntimes I don't even intend to make a patch. Suppose, I compile\nsomething, then I find that some quick hack is needed to compile, then\nthe hack becomes a reasonable general solution. When does it make sense\nto run \"stg new\"? Obviously, at the point when I know the patch is good\nenough to be kept and sent upstream. It happens after I change some\nfiles, not before.\n\nIt's actually very rare that I decide to fix something like \"bug #42\nfrom the tracker\" before having changed a single line. It's also rare\nthat I follow through without getting distracted or realizing that I'm\nfixing some other bug instead.\n\nAlso, \"--force\" is a strong word for a switch. It's normally used for\noptions that could trigger information loss or unintended consequences\nthat are hard to undo. Telling StGIT to record my changes hardly\nqualifies as anything dangerous.\n\nI know of \"stg rename\", but I don't want to be forced to name a patch\nbefore it's ready.\n\nPossible solutions:\n\n1) \"stg new --force\" becomes \"stg new\" and \"stg new\" becomes \"stg new\n--empty\", i.e. empty files can only be created with the \"--empty\"\nswitch.\n2) \"stg new --force\" becomes \"stg record\" or something.\n3) \"stg new --force\" becomes \"stg new --record\" or something.\n4) \"stg new\" works both with and without modified files.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"14609","messageId":"20060113093420.GA25242@diana.vm.bytemark.co.uk","threadId":"3068","inReplyTo":"1137144291.20073.104.camel@dv","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-01-13T09:34:20Z","receivedAt":"2006-01-13T09:34:20Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-01-13 04:24:51 -0500, Pavel Roskin wrote:\n\n> 1) \"stg new --force\" becomes \"stg new\" and \"stg new\" becomes \"stg new\n> --empty\", i.e. empty files can only be created with the \"--empty\"\n> switch.\n> 2) \"stg new --force\" becomes \"stg record\" or something.\n> 3) \"stg new --force\" becomes \"stg new --record\" or something.\n> 4) \"stg new\" works both with and without modified files.\n\nI agree with Pavel. I like option 4 the most, and 3 the least; since\ncreating a new patch from existing edits is more common (for me) than\ncreating an empty patch, it's awkward to make that command much\nlonger.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"14714","messageId":"b0943d9e0601160018x206faf9ck@mail.gmail.com","threadId":"3068","inReplyTo":"1137144291.20073.104.camel@dv","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-01-16T08:18:07Z","receivedAt":"2006-01-16T08:18:07Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Hi Pavel,\n\nOn 13/01/06, Pavel Roskin wrote:\n> Maybe I don't understand something in StGIT, but it seems strange that\n> \"stg new\" creates empty patch by default and requires \"--force\" to\n> create a non-empty patch.\n\nThe 'new' command would fail to create a new patch if there are\nchanges in the tree.\n\nI also find myself using the '--force' option most of the time. Even\nwhen I create a an empty patch, I use to run 'status' before. The\ncurrent implementation is closer to Quilt where, AFAIK, you first\ncreate a new patch and use 'add' for every modified file. Since 'add'\nhas a different meaning in StGIT, it might also make sense to remove\nthe '--force' option.\n\n> 1) \"stg new --force\" becomes \"stg new\" and \"stg new\" becomes \"stg new\n> --empty\", i.e. empty files can only be created with the \"--empty\"\n> switch.\n> 2) \"stg new --force\" becomes \"stg record\" or something.\n> 3) \"stg new --force\" becomes \"stg new --record\" or something.\n> 4) \"stg new\" works both with and without modified files.\n\nRegarding (1), the newly created patch is empty anyway, you would need\nto run 'refresh' to add the modified patches to it ('stg series -e'\nwould show the empty patches prefixed with a 0).\n\nAnyway, I would also prefer option 4. If there are no objections, I'll\nmodify StGIT accordingly. It would also be useful to have a wiki page\nabout StGIT vs. Quilt to show the main differences.\n\n--\nCatalin\n"},{"id":"14783","messageId":"1137517300.20556.26.camel@dv","threadId":"3068","inReplyTo":"b0943d9e0601160018x206faf9ck@mail.gmail.com","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-01-17T17:01:40Z","receivedAt":"2006-01-17T17:01:40Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello, Catalin!\n\nOn Mon, 2006-01-16 at 08:18 +0000, Catalin Marinas wrote:\n> On 13/01/06, Pavel Roskin wrote:\n> > 1) \"stg new --force\" becomes \"stg new\" and \"stg new\" becomes \"stg new\n> > --empty\", i.e. empty files can only be created with the \"--empty\"\n> > switch.\n> > 2) \"stg new --force\" becomes \"stg record\" or something.\n> > 3) \"stg new --force\" becomes \"stg new --record\" or something.\n> > 4) \"stg new\" works both with and without modified files.\n> \n> Regarding (1), the newly created patch is empty anyway, you would need\n> to run 'refresh' to add the modified patches to it ('stg series -e'\n> would show the empty patches prefixed with a 0).\n\nI was going to suggest that would be logical to run \"stg refresh\"\nimplicitly if \"stg new\" is used on modified files. But then I realized\nthat it would be even better if future versions of StGIT allowed to\nrefresh (i.e. add changes to) patches other that the current one. In\nthis case, indeed, you don't want the newly created patch to suck in all\nthe changes in the local repository.\n\n> Anyway, I would also prefer option 4. If there are no objections, I'll\n> modify StGIT accordingly. It would also be useful to have a wiki page\n> about StGIT vs. Quilt to show the main differences.\n\nThat would be great!\n\nI'm trying to make StGIT my primary development tool, and I think it has\na great potential the could be realized if StGIT is freed from the need\nto emulate older tools.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"14789","messageId":"20060117215752.GH32585@nowhere.earth","threadId":"3068","inReplyTo":"1137517300.20556.26.camel@dv","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-01-17T21:57:52Z","receivedAt":"2006-01-17T21:57:52Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Tue, Jan 17, 2006 at 12:01:40PM -0500, Pavel Roskin wrote:\n> Hello, Catalin!\n> \n> On Mon, 2006-01-16 at 08:18 +0000, Catalin Marinas wrote:\n> > On 13/01/06, Pavel Roskin wrote:\n> > > 1) \"stg new --force\" becomes \"stg new\" and \"stg new\" becomes \"stg new\n> > > --empty\", i.e. empty files can only be created with the \"--empty\"\n> > > switch.\n> > > 2) \"stg new --force\" becomes \"stg record\" or something.\n> > > 3) \"stg new --force\" becomes \"stg new --record\" or something.\n> > > 4) \"stg new\" works both with and without modified files.\n> > \n> > Regarding (1), the newly created patch is empty anyway, you would need\n> > to run 'refresh' to add the modified patches to it ('stg series -e'\n> > would show the empty patches prefixed with a 0).\n> \n> I was going to suggest that would be logical to run \"stg refresh\"\n> implicitly if \"stg new\" is used on modified files. But then I realized\n> that it would be even better if future versions of StGIT allowed to\n> refresh (i.e. add changes to) patches other that the current one. In\n> this case, indeed, you don't want the newly created patch to suck in all\n> the changes in the local repository.\n\nI commonly also feel the need to \"stg refresh\" only part of the\ncurrent changes. Allowing to limit the files to be impacted by a\nrefresh could be a good addition.\n\nIt would even be useful sometimes to dispatch changes to a single file\ninto several patches. When they are distinct enough to be in\ndifferent diff hunks, it is pretty easy to split an existing patch,\nbut it could also be useful to only refresh a patch with specific diff\nhunks. A possibility would be to add a filterdiff-like \"-#\" flag,\nin addition to the above-suggested \"refresh \" (and possibly only\nallow to specify a single file together with this flag).\n\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"14792","messageId":"1137539762.12454.11.camel@dv","threadId":"3068","inReplyTo":"20060117215752.GH32585@nowhere.earth","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-01-17T23:16:02Z","receivedAt":"2006-01-17T23:16:02Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Tue, 2006-01-17 at 22:57 +0100, Yann Dirson wrote:\n> I commonly also feel the need to \"stg refresh\" only part of the\n> current changes. Allowing to limit the files to be impacted by a\n> refresh could be a good addition.\n\nAbsolutely.\n\n> It would even be useful sometimes to dispatch changes to a single file\n> into several patches. When they are distinct enough to be in\n> different diff hunks, it is pretty easy to split an existing patch,\n> but it could also be useful to only refresh a patch with specific diff\n> hunks. A possibility would be to add a filterdiff-like \"-#\" flag,\n> in addition to the above-suggested \"refresh \" (and possibly only\n> allow to specify a single file together with this flag).\n\nI think if would be better to improve \"stg fold\" to work on arbitrary\npatches. This way, you prepare the patch in the editor (which would not\nbe harder than finding hunk numbers) and fold it into the patch of your\nchoice. stg should check that the stack remains valid, possibly doing\ntrivial adjustments to the higher patches. The current tree should not\nbe impacted.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"14849","messageId":"20060118193717.GI32585@nowhere.earth","threadId":"3068","inReplyTo":"1137539762.12454.11.camel@dv","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-01-18T19:37:17Z","receivedAt":"2006-01-18T19:37:17Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Tue, Jan 17, 2006 at 06:16:02PM -0500, Pavel Roskin wrote:\n> > It would even be useful sometimes to dispatch changes to a single file\n> > into several patches. When they are distinct enough to be in\n> > different diff hunks, it is pretty easy to split an existing patch,\n> > but it could also be useful to only refresh a patch with specific diff\n> > hunks. A possibility would be to add a filterdiff-like \"-#\" flag,\n> > in addition to the above-suggested \"refresh \" (and possibly only\n> > allow to specify a single file together with this flag).\n> \n> I think if would be better to improve \"stg fold\" to work on arbitrary\n> patches. This way, you prepare the patch in the editor (which would not\n> be harder than finding hunk numbers) and fold it into the patch of your\n> choice. stg should check that the stack remains valid, possibly doing\n> trivial adjustments to the higher patches. The current tree should not\n> be impacted.\n\nThis sounds like a good idea as well (and I would use it on a near\ndaily basis as well ;). Obviously such a request can also fail,\neg. when requesting to fold a change into a patch, where a subsequent\npatch modifies the same lines.\n\nBut it would not be a replacement to selecting changes with a\ngranularity finer than file-level, which is what I wanted to suggest.\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"14861","messageId":"1137631749.13853.22.camel@dv","threadId":"3068","inReplyTo":"20060118193717.GI32585@nowhere.earth","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-01-19T00:49:09Z","receivedAt":"2006-01-19T00:49:09Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Wed, 2006-01-18 at 20:37 +0100, Yann Dirson wrote:\n> > > It would even be useful sometimes to dispatch changes to a single file\n> > > into several patches. When they are distinct enough to be in\n> > > different diff hunks, it is pretty easy to split an existing patch,\n> > > but it could also be useful to only refresh a patch with specific diff\n> > > hunks. A possibility would be to add a filterdiff-like \"-#\" flag,\n> > > in addition to the above-suggested \"refresh \" (and possibly only\n> > > allow to specify a single file together with this flag).\n> > \n> > I think if would be better to improve \"stg fold\" to work on arbitrary\n> > patches. This way, you prepare the patch in the editor (which would not\n> > be harder than finding hunk numbers) and fold it into the patch of your\n> > choice. stg should check that the stack remains valid, possibly doing\n> > trivial adjustments to the higher patches. The current tree should not\n> > be impacted.\n> \n> This sounds like a good idea as well (and I would use it on a near\n> daily basis as well ;). Obviously such a request can also fail,\n> eg. when requesting to fold a change into a patch, where a subsequent\n> patch modifies the same lines.\n\nDefinitely. Hard cases should be handled by hand.\n\n> But it would not be a replacement to selecting changes with a\n> granularity finer than file-level, which is what I wanted to suggest.\n\nWhy? Maybe you got confused by two meanings of the word \"patch\"? I\nthink StGIT should use some other term, e.g. changeset. I meant that\nthe diff file (e.g. made by \"stg diff\") could be edited and folded into\none of the StGIT patches (changesets). Unless you want non-interactive\nseparation of the hunks, using an editor should be a reasonable\napproach.\n\nI believe StGIT should be primarily designed to be used interactively.\nYour approach looks like a usability disaster to me. The user is\nsupposed to find numbers of the hunks, although s/he is working on the\nwhole file (since it's \"stg refresh\").\n\nMy approach suggests that the user work with the diff from the\nbeginning, and separates the changes by looking at them.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"14921","messageId":"20060119213838.GA27397@nowhere.earth","threadId":"3068","inReplyTo":"1137631749.13853.22.camel@dv","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-01-19T21:38:39Z","receivedAt":"2006-01-19T21:38:39Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Wed, Jan 18, 2006 at 07:49:09PM -0500, Pavel Roskin wrote:\n> > But it would not be a replacement to selecting changes with a\n> > granularity finer than file-level, which is what I wanted to suggest.\n> \n> Why? Maybe you got confused by two meanings of the word \"patch\"? I\n> think StGIT should use some other term, e.g. changeset. I meant that\n> the diff file (e.g. made by \"stg diff\") could be edited and folded into\n> one of the StGIT patches (changesets). Unless you want non-interactive\n> separation of the hunks, using an editor should be a reasonable\n> approach.\n\n> My approach suggests that the user work with the diff from the\n> beginning, and separates the changes by looking at them.\n\nOh, I think I now see what you meant. I'm not sure it would be a good\nidea to let the user edit the diff, although running an editor on it\nis not much different from feeding it through filterdiff, or a\neven through a graphical equivalent allowing to point at the hunks.\n\n\n> I believe StGIT should be primarily designed to be used interactively.\n\nI tend to disagree. 3rd-party apps like qgit should be able to let\nthe user do the selection, and tell the command-line tool what they\nwant to act upon. It may be useful as well if stg gains\ninteractivity, but should not become the only way to work with it\n(unix way of life).\n\n\n> Your approach looks like a usability disaster to me. The user is\n> supposed to find numbers of the hunks, although s/he is working on the\n> whole file (since it's \"stg refresh\").\n\nThat's what I'm currently doing to feed the hunk numbers to\nfilterdiff. Any improvement in the process would be welcomed :)\n\n\nMaybe we could have a \"fold\" or \"refresh\" variant that takes its\noutput from the output of \"stg diff\" (or any arbitrary diff on stdin,\nto be friendly with GUI wrappers) filtered by an arbitrary command.\nThat command could be \"cat\" to get the current \"refresh\" behaviour, or\nan editor wrapper acting on stdin/out, or a wrapper to filterdiff, or\nwhatever clever filter one would want to use.\n\nDoes it sound better ?\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"14939","messageId":"1137738224.27911.26.camel@dv","threadId":"3068","inReplyTo":"20060119213838.GA27397@nowhere.earth","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-01-20T06:23:44Z","receivedAt":"2006-01-20T06:23:44Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Thu, 2006-01-19 at 22:38 +0100, Yann Dirson wrote:\n> > I believe StGIT should be primarily designed to be used interactively.\n> \n> I tend to disagree. 3rd-party apps like qgit should be able to let\n> the user do the selection, and tell the command-line tool what they\n> want to act upon. It may be useful as well if stg gains\n> interactivity, but should not become the only way to work with it\n> (unix way of life).\n\nIn this particular case, the GUI frontend should be able to supply much\nmore data than the hunk numbers. It would be much safer.\n\nI didn't mean to say that StGIT shouldn't have any options for\nnon-interactive processing. I meant that whenever adding a feature, we\nshould try to make it immediately useful without any frontends or\nadditional software.\n\n> Maybe we could have a \"fold\" or \"refresh\" variant that takes its\n> output from the output of \"stg diff\" (or any arbitrary diff on stdin,\n> to be friendly with GUI wrappers) filtered by an arbitrary command.\n\nThat would be \"fold\". \"refresh\" like is saying - this patch should\nproduce this file. I actually tend to think now that deep refresh would\nbe confusing and dangerous if there is another patch closer in the stack\nworking with the same file, even in a separate part of it. stg would\neither report conflict with the higher patches use the file with the\nhigher patches reverted, and neither sounds good to me.\n\nDeep fold of the local changes would be much easier, since no other\npatch should have them.\n\n> That command could be \"cat\" to get the current \"refresh\" behaviour, or\n> an editor wrapper acting on stdin/out, or a wrapper to filterdiff, or\n> whatever clever filter one would want to use.\n> \n> Does it sound better ?\n\nYes. The first step would be to fix \"stg refresh --edit --showpatch\" to\nactually respect edits made to the patch.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"14959","messageId":"20060120182255.GD32177@fieldses.org","threadId":"3068","inReplyTo":"1137738224.27911.26.camel@dv","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-01-20T18:22:55Z","receivedAt":"2006-01-20T18:22:55Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Fri, Jan 20, 2006 at 01:23:44AM -0500, Pavel Roskin wrote:\n> On Thu, 2006-01-19 at 22:38 +0100, Yann Dirson wrote:\n> > That command could be \"cat\" to get the current \"refresh\" behaviour, or\n> > an editor wrapper acting on stdin/out, or a wrapper to filterdiff, or\n> > whatever clever filter one would want to use.\n> > \n> > Does it sound better ?\n> \n> Yes. The first step would be to fix \"stg refresh --edit --showpatch\" to\n> actually respect edits made to the patch.\n\nI tend to use stg refresh -es as a quick (well, not quite as quick as\nI'd like) way to look at the current patch. Often I leave it up while\nI'm working (editing the patched files). So if exiting from stg refresh\n-es suddenly started overwriting my working files, I'd be very\nunhappy....\n\n--b.\n"},{"id":"14984","messageId":"b0943d9e0601211020k20e2b18fy@mail.gmail.com","threadId":"3068","inReplyTo":"20060117215752.GH32585@nowhere.earth","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-01-21T18:20:07Z","receivedAt":"2006-01-21T18:20:07Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 17/01/06, Yann Dirson wrote:\n> It would even be useful sometimes to dispatch changes to a single file\n> into several patches. When they are distinct enough to be in\n> different diff hunks, it is pretty easy to split an existing patch,\n> but it could also be useful to only refresh a patch with specific diff\n> hunks. A possibility would be to add a filterdiff-like \"-#\" flag,\n> in addition to the above-suggested \"refresh \" (and possibly only\n> allow to specify a single file together with this flag).\n\nLimiting the refresh to a set of file wouldn't be hard but doing it\nper hunk it's a bit more complicated because StGIT only handles the\nchanges to the current tree over to GIT so that a new commit object is\ncreated. It doesn't control the individual hunks.\n\nWhat I usually do is create a dummy patch from the current changes,\npop it from the stack and only apply parts of it using emacs. Pushing\nthe dummy patch back would also show what changes were left to merge\nin a proper patch.\n\n--\nCatalin\n"},{"id":"14985","messageId":"b0943d9e0601211024s76528ce8m@mail.gmail.com","threadId":"3068","inReplyTo":"1137539762.12454.11.camel@dv","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-01-21T18:24:05Z","receivedAt":"2006-01-21T18:24:05Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 17/01/06, Pavel Roskin wrote:\n> I think if would be better to improve \"stg fold\" to work on arbitrary\n> patches. This way, you prepare the patch in the editor (which would not\n> be harder than finding hunk numbers) and fold it into the patch of your\n> choice. stg should check that the stack remains valid, possibly doing\n> trivial adjustments to the higher patches. The current tree should not\n> be impacted.\n\nNote that 'stg fold' uses git-apply-patch which doesn't take fuzzy\npatches (a feature I began to like actually). Modifying the patch in\nan editor might create some problems with applying.\n\n--\nCatalin\n"},{"id":"298221","messageId":"b0943d9e0601211031h2ef0a499s@mail.gmail.com","threadId":"3068","inReplyTo":"1137517300.20556.26.camel@dv","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-01-21T18:31:04Z","receivedAt":"2006-01-21T18:31:04Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 17/01/06, Pavel Roskin wrote:\n> I was going to suggest that would be logical to run \"stg refresh\"\n> implicitly if \"stg new\" is used on modified files. But then I realized\n> that it would be even better if future versions of StGIT allowed to\n> refresh (i.e. add changes to) patches other that the current one.\n\nI think that would be useful but not easy to implement. StGIT was\ndesigned so that all operations happen on the top patch. The current\ntree changes depend on the top patch and refreshing a different patch\nwith those changes would involve a three-way merge operation. This\nmerging can generate conflicts which are not relevant to the top tree\nand they might even destroy the changes (depending on the merge\noptions).\n\nThe way I work is, again, through a dummy patch which can be folded\ninto the patch I want. This way I am sure that I still have the\nchanges in the dummy patch if I'm not happy with the merge. Maybe all\nthese could be done transparently and automatically remove the dummy\npatch if conflicts exist.\n\n--\n"},{"id":"15030","messageId":"20060122000509.btnr4s4g0wgg0kwo@webmail.spamcop.net","threadId":"3068","inReplyTo":"b0943d9e0601211024s76528ce8m@mail.gmail.com","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-01-22T05:05:09Z","receivedAt":"2006-01-22T05:05:09Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello, Catalin!\n\nQuoting Catalin Marinas :\n\n> On 17/01/06, Pavel Roskin wrote:\n> > I think if would be better to improve \"stg fold\" to work on arbitrary\n> > patches. This way, you prepare the patch in the editor (which would not\n> > be harder than finding hunk numbers) and fold it into the patch of your\n> > choice. stg should check that the stack remains valid, possibly doing\n> > trivial adjustments to the higher patches. The current tree should not\n> > be impacted.\n>\n> Note that 'stg fold' uses git-apply-patch which doesn't take fuzzy\n> patches (a feature I began to like actually). Modifying the patch in\n> an editor might create some problems with applying.\n\nActually, the safest way would be to keep the original patch as presented to the\nuser. Then the new patch would be \"subtracted\" from the original patch (using\ne.g. interdiff from diff-utils). The the difference would be \"added\" to the\ncurrent version of the patch. Changes to \"binary files differ\" and similar\nline should be ignored. This way, changes to binary files are preserved.\n\nFor additional safety (and at expense or concurrency), it could be required that\n the patch is unchanged since the editor was launched. Editors tend to run for\na long time compared to non-interactive utilities.\n\nFuzziness should be tolerated to a point. Removing hunks could mean that the\nline numbers would be slightly off. If needed, the patch should be applied to\na temporary copy and regenerated from it.\n\n--\nRegards,\nPavel Roskin\n"},{"id":"15080","messageId":"1138080623.15105.51.camel@dv","threadId":"3068","inReplyTo":"20060120182255.GD32177@fieldses.org","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-01-24T05:30:23Z","receivedAt":"2006-01-24T05:30:23Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Fri, 2006-01-20 at 13:22 -0500, J. Bruce Fields wrote:\n> I tend to use stg refresh -es as a quick (well, not quite as quick as\n> I'd like) way to look at the current patch. Often I leave it up while\n> I'm working (editing the patched files). So if exiting from stg refresh\n> -es suddenly started overwriting my working files, I'd be very\n> unhappy....\n\nIf I understand correctly, \"stg refresh\" only modifies the repository,\nnot the files in the local directory. This shouldn't change.\n\nIt's only having two instances of \"stg refresh -es\" that would be a\nproblem if conflicting edits are made in both editors. The answer to\nthat is \"don't do it\".\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"15087","messageId":"20060124175443.GA29670@fieldses.org","threadId":"3068","inReplyTo":"1138080623.15105.51.camel@dv","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-01-24T17:54:43Z","receivedAt":"2006-01-24T17:54:43Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Jan 24, 2006 at 12:30:23AM -0500, Pavel Roskin wrote:\n> On Fri, 2006-01-20 at 13:22 -0500, J. Bruce Fields wrote:\n> > I tend to use stg refresh -es as a quick (well, not quite as quick as\n> > I'd like) way to look at the current patch. Often I leave it up while\n> > I'm working (editing the patched files). So if exiting from stg refresh\n> > -es suddenly started overwriting my working files, I'd be very\n> > unhappy....\n> \n> If I understand correctly, \"stg refresh\" only modifies the repository,\n> not the files in the local directory.\n\nWell, yeah, but the reason that makes sense is that it's modifying the\nrepository to bring it up to date with the working directory.\n\n> This shouldn't change.\n\nSo after you hand-edit the diff and exit \"stg refresh -es\", the top of\nthe current patch will no longer agree with the state of the working\ndirectory. What are you going to do on the next refresh? Or on the\nnext push or pop? This seems a little confusing.\n\n--b.\n"},{"id":"15089","messageId":"1138126671.24415.28.camel@dv","threadId":"3068","inReplyTo":"20060124175443.GA29670@fieldses.org","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-01-24T18:17:51Z","receivedAt":"2006-01-24T18:17:51Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Tue, 2006-01-24 at 12:54 -0500, J. Bruce Fields wrote:\n> On Tue, Jan 24, 2006 at 12:30:23AM -0500, Pavel Roskin wrote:\n> > On Fri, 2006-01-20 at 13:22 -0500, J. Bruce Fields wrote:\n> > > I tend to use stg refresh -es as a quick (well, not quite as quick as\n> > > I'd like) way to look at the current patch. Often I leave it up while\n> > > I'm working (editing the patched files). So if exiting from stg refresh\n> > > -es suddenly started overwriting my working files, I'd be very\n> > > unhappy....\n> > \n> > If I understand correctly, \"stg refresh\" only modifies the repository,\n> > not the files in the local directory.\n> \n> Well, yeah, but the reason that makes sense is that it's modifying the\n> repository to bring it up to date with the working directory.\n\nYes. As it stands now, the update is made using the local state after\nediting. If the patch becomes editable, the update will use the local\nstate before editing. It would still fit the original semantic as you\ndescribed it.\n\n> > This shouldn't change.\n> \n> So after you hand-edit the diff and exit \"stg refresh -es\", the top of\n> the current patch will no longer agree with the state of the working\n> directory. What are you going to do on the next refresh?\n\nPut remaining changes to the repository.\n\n> Or on the\n> next push or pop?\n\nRight now - protest loudly about local changes. In the future - proceed\ncautiously if there are no conflicts.\n\n> This seems a little confusing.\n\nTry removing the whole repository while \"stg refresh\" is running. THAT\nwould be confusing :-)\n\nSeriously, it would be nice to have an editor that would allow to edit\nthe patch and see the resulting file and vice versa. Maybe emacs could\nbe hacked to do it.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"15091","messageId":"b0943d9e0601241323u3cf6fbfbk@mail.gmail.com","threadId":"3068","inReplyTo":"1138126671.24415.28.camel@dv","subject":"Re: StGIT: \"stg new\" vs \"stg new --force\"","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-01-24T21:23:05Z","receivedAt":"2006-01-24T21:23:05Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 24/01/06, Pavel Roskin wrote:\n> Seriously, it would be nice to have an editor that would allow to edit\n> the patch and see the resulting file and vice versa. Maybe emacs could\n> be hacked to do it.\n\nI think emacs has some basic support via ediff-merge or smerge but\nit's difficult to integrate it with StGIT. Refreshing a patch with\nStGIT means updating the GIT index files with the latest changes in\nthe working directory, save the index and create a commit object\npointing to it.\n\n--\nCatalin\n"}]}