{"thread":{"id":"29051","subject":"[HELP] Adding git awareness to the darning patch management system.","startedAt":"2011-11-30T02:17:22Z","lastAt":"2011-12-01T23:40:42Z","messageCount":8,"participants":["Peter Williams","Jeff King","Tay Ray Chuan"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"180140","messageId":"4ED59232.3000807@users.sourceforge.net","threadId":"29051","inReplyTo":null,"subject":"[HELP] Adding git awareness to the darning patch management system.","fromName":"Peter Williams","fromEmail":"peter_ono@users.sourceforge.net","sentAt":"2011-11-30T02:17:22Z","receivedAt":"2011-11-30T02:17:22Z","isPatch":false,"sender":{"key":"peter_ono@users.sourceforge.net","avatar":null},"body":"I'm the author of the darning patch management system \n and would like some help adding git \nawareness to the system. At this stage of the development, \"awareness\" \nis fairly simple concept with two broad aims:\n\n1. presenting the file tree of the sources being patched in a way that \nmakes sense to the user including the current status of files from the \npoint of view of the underlying SCM (in this case, git), and\n\n2. detecting files with uncommitted changes (from the SCM's point of \nview) when the user adds them to a patch (or pushes a patch that \ncontains them) so that they may be alerted to the fact and offered the \nchoice of absorbing the uncommitted changes into the patch (or not).\n\nI've already implemented this interface for Mercurial (with which I am \nfamiliar) and looked at doing the same with git but had difficulty \ndiscovering the definitive mechanisms for obtaining the necessary data. \n So I'm soliciting your help in overcoming these problems.\n\nDarning's source is managed by Mercurial and can be perused at:\n\n\n\nThe interface to be implemented is defined in the file \ndarning/scm_ifce.py and the implementation for Mercurial is in the file \nscm_ifce_hg.py.\n\nAny help or pointers would be appreciated.\n\nThanks\nPeter\n"},{"id":"180142","messageId":"20111130072248.GG5317@sigill.intra.peff.net","threadId":"29051","inReplyTo":"4ED59232.3000807@users.sourceforge.net","subject":"Re: [HELP] Adding git awareness to the darning patch management system.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-30T07:22:48Z","receivedAt":"2011-11-30T07:22:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 30, 2011 at 12:17:22PM +1000, Peter Williams wrote:\n\n> 1. presenting the file tree of the sources being patched in a way\n> that makes sense to the user including the current status of files\n> from the point of view of the underlying SCM (in this case, git), and\n\nI'm not exactly sure what this means.\n\n> 2. detecting files with uncommitted changes (from the SCM's point of\n> view) when the user adds them to a patch (or pushes a patch that\n> contains them) so that they may be alerted to the fact and offered\n> the choice of absorbing the uncommitted changes into the patch (or\n> not).\n\nFor this, you probably want \"git diff-files --name-only\", which will\nshow files with differences in the working tree. Keep in mind that git\nhas an \"index\" or \"staging area\", which means that you have three states\nof content for a given path:\n\n 1. the state of the prior commit (i.e., HEAD)\n\n 2. the state that is marked to be committed when \"git commit\" is run\n (i.e., the index)\n\n 3. the state in the working tree\n\nYou can compare the first two with \"git diff-index\", and the latter two\nwith \"git diff-files\". You can also use \"git status --porcelain\" to get\na machine-readable output that shows how the three states match up, with\none line per file.\n\n> I've already implemented this interface for Mercurial (with which I\n> am familiar) and looked at doing the same with git but had difficulty\n> discovering the definitive mechanisms for obtaining the necessary\n> data. So I'm soliciting your help in overcoming these problems.\n\nI hope the above helps you some. If not, just ask. It might be easier to\nunderstand what you are looking for if you can give concrete examples.\n\n-Peff\n"},{"id":"180145","messageId":"CALUzUxrcWB62jARtgifTOocGL4gEGXDFMiO=ppHXzFyUmb+3ww@mail.gmail.com","threadId":"29051","inReplyTo":"4ED59232.3000807@users.sourceforge.net","subject":"Re: [HELP] Adding git awareness to the darning patch management system.","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2011-11-30T09:04:05Z","receivedAt":"2011-11-30T09:04:05Z","isPatch":false,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"On Wed, Nov 30, 2011 at 10:17 AM, Peter Williams\n wrote:\n> I'm the author of the darning patch management system\n> and would like some help adding git\n> awareness to the system. At this stage of the development, \"awareness\" is\n> fairly simple concept with two broad aims:\n\nThat link says it \"combines the strengths of quilt and mq and\neliminates their weaknesses\", but I don't see any info on why this is\nthe case with your program; it would be great it if you could provide\na quick start guide (probably easier to show this with some commands\nin the CLI rather than GUI screenshots).\n\nHave a look at StGit's tutorial\nhttp://www.procode.org/stgit/doc/tutorial.html (very similar to quilt\nand mq too) to see what I mean.\n\n-- \nCheers,\nRay Chuan\n"},{"id":"180187","messageId":"4ED6C0AE.9010703@users.sourceforge.net","threadId":"29051","inReplyTo":"CALUzUxrcWB62jARtgifTOocGL4gEGXDFMiO=ppHXzFyUmb+3ww@mail.gmail.com","subject":"Re: [HELP] Adding git awareness to the darning patch management system.","fromName":"Peter Williams","fromEmail":"peter_ono@users.sourceforge.net","sentAt":"2011-11-30T23:47:58Z","receivedAt":"2011-11-30T23:47:58Z","isPatch":false,"sender":{"key":"peter_ono@users.sourceforge.net","avatar":null},"body":"On 30/11/11 19:04, Tay Ray Chuan wrote:\n> On Wed, Nov 30, 2011 at 10:17 AM, Peter Williams\n> wrote:\n>> I'm the author of the darning patch management system\n>> and would like some help adding git\n>> awareness to the system. At this stage of the development, \"awareness\" is\n>> fairly simple concept with two broad aims:\n>\n> That link says it \"combines the strengths of quilt and mq and\n> eliminates their weaknesses\", but I don't see any info on why this is\n> the case with your program;\n\nDocumenting this is on my todo list (but not at the top).\n\nQuilt's weaknesses are documented on their website and my issues with MQ \nis that it (potentially) compromises the Mercurial repository and others \nto which it may push. (MQ also has the problem that its current \nmaintainers don't understand the workflow for which it was designed and \nare changing it to suit a different workflow.)\n\nThe repository compromise issue also applies to stgit.\n\nOther things darning adds are:\n\n1. tracking of copies and renames (not in quilt),\n2. tracking changes to files' modes (not in quilt),\n3. binary diffs (using git binary diff format for import/export), and\n4. help managing addition of trailing whitespace by patches.\n\n> it would be great it if you could provide\n> a quick start guide (probably easier to show this with some commands\n> in the CLI rather than GUI screenshots).\n\nAt this stage, the CLI is really only there to allow me to do script \nbased testing of darning's internals and is not a fully capable \ninterface. However, if you look in the directory test-cli for files \nwith a \".test\" suffix you will find examples of their use.\n\n>\n> Have a look at StGit's tutorial\n> http://www.procode.org/stgit/doc/tutorial.html (very similar to quilt\n> and mq too) to see what I mean.\n\nOK\n\nPeter\n"},{"id":"180184","messageId":"4ED6D0DB.3060800@users.sourceforge.net","threadId":"29051","inReplyTo":"20111130072248.GG5317@sigill.intra.peff.net","subject":"Re: [HELP] Adding git awareness to the darning patch management system.","fromName":"Peter Williams","fromEmail":"peter_ono@users.sourceforge.net","sentAt":"2011-12-01T00:56:59Z","receivedAt":"2011-12-01T00:56:59Z","isPatch":false,"sender":{"key":"peter_ono@users.sourceforge.net","avatar":null},"body":"On 30/11/11 17:22, Jeff King wrote:\n> On Wed, Nov 30, 2011 at 12:17:22PM +1000, Peter Williams wrote:\n>\n>> 1. presenting the file tree of the sources being patched in a way\n>> that makes sense to the user including the current status of files\n>> from the point of view of the underlying SCM (in this case, git), and\n>\n> I'm not exactly sure what this means.\n\nIf you look at the screenshots at sourceforge (which were produced on \ntop of a Mercurial repo) you'll notice that file names in the left most \ntree have letters in front of them and appear in different foreground \ncolours. These letters are the same as those returned by Mercurial's \nstatus command and, hence, give a Mercurial user an easy to understand \nsnapshot of the status of the files in the playground. The colour \ncoding is (relatively) arbitrary (and chosen by me) and is intended to \nmake it easier to detect the different file statuses.\n\nMy main problem is that I can't find a git file status command (and \nthere are a lot of them to choose from) that gives a snapshot of the \nstatuses of all files in a directory (including those not tracked or \nignored). A secondary problem is that, if I could cobble together \nstatuses from various commands, mapping git statuses to the Mercurial \nones for display would not be a good solution as they would not \nnecessarily make sense to a git user. (It's fairly clear to me from my \ninability to make sense of git's CLI that git users think differently to \nme, a Mercurial user, and it's unlikely that I can, without help, make a \nfile tree display that makes sense to a git user.)\n\n>\n>> 2. detecting files with uncommitted changes (from the SCM's point of\n>> view) when the user adds them to a patch (or pushes a patch that\n>> contains them) so that they may be alerted to the fact and offered\n>> the choice of absorbing the uncommitted changes into the patch (or\n>> not).\n>\n> For this, you probably want \"git diff-files --name-only\", which will\n> show files with differences in the working tree. Keep in mind that git\n> has an \"index\" or \"staging area\", which means that you have three states\n> of content for a given path:\n>\n> 1. the state of the prior commit (i.e., HEAD)\n>\n> 2. the state that is marked to be committed when \"git commit\" is run\n> (i.e., the index)\n>\n> 3. the state in the working tree\n\nThis is a prime example of the different mindset of the git user to the \nhg user.\n\n>\n> You can compare the first two with \"git diff-index\", and the latter two\n> with \"git diff-files\". You can also use \"git status --porcelain\" to get\n> a machine-readable output that shows how the three states match up, with\n> one line per file.\n\nThis is an example of why I'm confused. There are too many ways to do \n(similar) things and it's hard to know which to use.\n\n>\n>> I've already implemented this interface for Mercurial (with which I\n>> am familiar) and looked at doing the same with git but had difficulty\n>> discovering the definitive mechanisms for obtaining the necessary\n>> data. So I'm soliciting your help in overcoming these problems.\n>\n> I hope the above helps you some. If not, just ask. It might be easier to\n> understand what you are looking for if you can give concrete examples.\n\nMaybe an example of why I think the feature is useful might help. Say \nthat you start editing a file and then decide that you want to put this \nchange into a patch rather than committing it. If you were using quilt \nyou would have to do this manually by any of a number or ways such as:\n\n$ file > temp.patch\n$ file\n$ quilt new one.patch\n$ quilt add file\n$ patch -p1 file < temp.patch\n$ rm temp.patch\n\nIn darning, you just do:\n\n$ darn new one.patch\n$ darn add --absorb file\n\nIf you're using the GUI (the primary interface), it will report that the \nfile has uncommitted changes and offer the choice of absorbing the \nchanges into the new patch, forcing the new patch to consider the \ncurrent file state as its starting point or (of course) cancel the \naddition. The CLI command will fail if an attempt to add a file which \nhas uncommitted changes is made unless either the --absorb or --force \n(which uses the file's current content as the starting point from the \npatches point of view) options are used. (So, whichever interface is in \nuse, you have to explicitly state how you want uncommitted changes to be \ntreated.\n\nThe interface to the SCM to support this is two functions:\n\n1: get_files_with_uncommitted_changes() which called with no arguments \nreturns a list of the paths of all files with uncommitted changes or \nwhen given a list of file paths (the more common case) returns the \nsubset of that list which have uncommitted changes; and\n\n2. copy_clean_version_to(filepath, target_path) which makes a copy of \nthe file as recorded in the prior commit and places it at the \ntarget_path (usually where darning stores the \"original\" for reference \nwhen creating diffs).\n\nA similar mechanism is in place for the case where a file is added to a \npatch and the file is in an underlying patch with unrefreshed changes \nbut this requires no help from the underlying SCM.\n\nBoth of these mechanisms also come into play when a patch is \npushed/applied so that the user has (relatively painless) control over \nwhich changes end up in which patch.\n\nWith MQ and the above example, the file would be automatically added to \nthe current patch (or a new patch if you created one) absorbing the \nchanges whether you wanted it to or not. I.e. there is no way of \ncreating MQ patches that don't automatically absorb all uncommitted changes.\n\nThanks for your reply,\nPeter\nPS Darning can be used on top of git repository without \"git awareness\" \nbut is not as useful as it would be with it.\n"},{"id":"180193","messageId":"20111201062733.GB22141@sigill.intra.peff.net","threadId":"29051","inReplyTo":"4ED6D0DB.3060800@users.sourceforge.net","subject":"Re: [HELP] Adding git awareness to the darning patch management system.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-12-01T06:27:33Z","receivedAt":"2011-12-01T06:27:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 01, 2011 at 10:56:59AM +1000, Peter Williams wrote:\n\n> >I'm not exactly sure what this means.\n> \n> If you look at the screenshots at sourceforge (which were produced on\n> top of a Mercurial repo) you'll notice that file names in the left\n> most tree have letters in front of them and appear in different\n> foreground colours. These letters are the same as those returned by\n> Mercurial's status command and, hence, give a Mercurial user an easy\n> to understand snapshot of the status of the files in the playground.\n> The colour coding is (relatively) arbitrary (and chosen by me) and is\n> intended to make it easier to detect the different file statuses.\n>\n> My main problem is that I can't find a git file status command (and\n> there are a lot of them to choose from) that gives a snapshot of the\n> statuses of all files in a directory (including those not tracked or\n> ignored).\n\nThanks, that helps. You probably just want to use \"git status\n--porcelain\", which will show you the state of file modification with\nrespect to the index and the prior commit, as well as any untracked\nfiles. See the \"porcelain format\" section in \"git help status\".\n\nNote that \"git status\" will not print files which are not modified. You\nmay want to also run \"git ls-files\" to get the full listing of files,\nincluding unmodified ones.\n\n> A secondary problem is that, if I could cobble together statuses from\n> various commands, mapping git statuses to the Mercurial ones for\n> display would not be a good solution as they would not necessarily\n> make sense to a git user. (It's fairly clear to me from my inability\n> to make sense of git's CLI that git users think differently to me, a\n> Mercurial user, and it's unlikely that I can, without help, make a\n> file tree display that makes sense to a git user.)\n\nI'm hoping that \"git status --porcelain\" will give you a fairly close\nmapping of the basic \"what happened to this file\" concept, based on what\nI see in the second screenshot you mentioned.\n\nThe trickiest thing is the index, which represents an in-between state\nthat is not usually exposed by other version control systems. If your\ntool does not make use of the index, then it probably makes sense to\njust consider a path as modified if it has modifications staged in the\nindex or in the working tree, which maps to other VCS's idea of\n\"modified\" (because for them, marking something as to-be-committed and\ncommiting it are part of the same step).\n\n> >For this, you probably want \"git diff-files --name-only\", which will\n> >show files with differences in the working tree. Keep in mind that git\n> >has an \"index\" or \"staging area\", which means that you have three states\n> >of content for a given path:\n> >\n> > 1. the state of the prior commit (i.e., HEAD)\n> >\n> > 2. the state that is marked to be committed when \"git commit\" is run\n> > (i.e., the index)\n> >\n> > 3. the state in the working tree\n> \n> This is a prime example of the different mindset of the git user to\n> the hg user.\n\nYou don't have to use those features, of course. It's just that\nsomething like \"git status\" is going to report on the differences\nbetween those states, so as a tool writer you need to know they are\nthere (and as I said above, you are free to simplify if it fits into the\nmental model of your tool).\n\n> >You can compare the first two with \"git diff-index\", and the latter two\n> >with \"git diff-files\". You can also use \"git status --porcelain\" to get\n> >a machine-readable output that shows how the three states match up, with\n> >one line per file.\n> \n> This is an example of why I'm confused. There are too many ways to\n> do (similar) things and it's hard to know which to use.\n\nGit is made of little building blocks. The original way to see the\ndifferences between the index and the working tree was via diff-files.\nBut then people build bigger building blocks out of the smaller ones.\n\"git status\" is really just a shorthand for:\n\n git diff-index HEAD &&\n git diff-files &&\n git ls-files -o\n\nand is in fact implemented using those building blocks (originally as a\nshell script, though these days it is written in C). So you can choose\neither and get the same information. Choosing a higher-level building\nblock may save you some work, if the abstraction matches what you want.\nOtherwise, you can compose what you want from the lower levels.\n\nI know it sometimes leads to an overwhelming number of commands, and I'm\nnot trying to excuse git's tendency to confuse people. I'm just hoping\nto unconfuse you in this particular situation.\n\nIn your case, I think \"status\" is the most convenient level of\nabstraction for you, because you are interesting in looking at\ndifferences to both the index and HEAD (i.e., the prior commit). But if\nyou find as you implement that want more flexibility, you can switch to\nusing the lower-level commands yourself.\n\n> Maybe an example of why I think the feature is useful might help.\n> Say that you start editing a file and then decide that you want to\n> put this change into a patch rather than committing it. If you were\n> using quilt you would have to do this manually by any of a number or\n> ways such as:\n> \n> $ file > temp.patch\n> $ file\n> $ quilt new one.patch\n> $ quilt add file\n> $ patch -p1 file < temp.patch\n> $ rm temp.patch\n> \n> In darning, you just do:\n> \n> $ darn new one.patch\n> $ darn add --absorb file\n\nSure. We have stgit and topgit, which do similar patch management things\non top of git. I don't personally user either, though, so I don't have\nmuch to say on how they compare to darning, or whether it is worth\nlooking at their implementations.\n\n> The interface to the SCM to support this is two functions:\n> \n> 1: get_files_with_uncommitted_changes() which called with no\n> arguments returns a list of the paths of all files with uncommitted\n> changes or when given a list of file paths (the more common case)\n> returns the subset of that list which have uncommitted changes; and\n\n\"status\" will do this for you, modulo the simplification of the concept\nof the index, as we discussed above.\n\n> 2. copy_clean_version_to(filepath, target_path) which makes a copy of\n> the file as recorded in the prior commit and places it at the\n> target_path (usually where darning stores the \"original\" for\n> reference when creating diffs).\n\nYou probably want:\n\n git cat-file blob HEAD:filepath >target_path\n\n-Peff\n"},{"id":"180225","messageId":"4ED80EA2.80805@users.sourceforge.net","threadId":"29051","inReplyTo":"20111201062733.GB22141@sigill.intra.peff.net","subject":"Re: [HELP] Adding git awareness to the darning patch management system.","fromName":"Peter Williams","fromEmail":"peter_ono@users.sourceforge.net","sentAt":"2011-12-01T23:32:50Z","receivedAt":"2011-12-01T23:32:50Z","isPatch":false,"sender":{"key":"peter_ono@users.sourceforge.net","avatar":null},"body":"On 01/12/11 16:27, Jeff King wrote:\n> On Thu, Dec 01, 2011 at 10:56:59AM +1000, Peter Williams wrote:\n>\n>>> I'm not exactly sure what this means.\n>>\n>> If you look at the screenshots at sourceforge (which were produced on\n>> top of a Mercurial repo) you'll notice that file names in the left\n>> most tree have letters in front of them and appear in different\n>> foreground colours. These letters are the same as those returned by\n>> Mercurial's status command and, hence, give a Mercurial user an easy\n>> to understand snapshot of the status of the files in the playground.\n>> The colour coding is (relatively) arbitrary (and chosen by me) and is\n>> intended to make it easier to detect the different file statuses.\n>>\n>> My main problem is that I can't find a git file status command (and\n>> there are a lot of them to choose from) that gives a snapshot of the\n>> statuses of all files in a directory (including those not tracked or\n>> ignored).\n>\n> Thanks, that helps. You probably just want to use \"git status\n> --porcelain\", which will show you the state of file modification with\n> respect to the index and the prior commit, as well as any untracked\n> files. See the \"porcelain format\" section in \"git help status\".\n>\n> Note that \"git status\" will not print files which are not modified. You\n> may want to also run \"git ls-files\" to get the full listing of files,\n> including unmodified ones.\n>\n>> A secondary problem is that, if I could cobble together statuses from\n>> various commands, mapping git statuses to the Mercurial ones for\n>> display would not be a good solution as they would not necessarily\n>> make sense to a git user. (It's fairly clear to me from my inability\n>> to make sense of git's CLI that git users think differently to me, a\n>> Mercurial user, and it's unlikely that I can, without help, make a\n>> file tree display that makes sense to a git user.)\n>\n> I'm hoping that \"git status --porcelain\" will give you a fairly close\n> mapping of the basic \"what happened to this file\" concept, based on what\n> I see in the second screenshot you mentioned.\n>\n> The trickiest thing is the index, which represents an in-between state\n> that is not usually exposed by other version control systems. If your\n> tool does not make use of the index, then it probably makes sense to\n> just consider a path as modified if it has modifications staged in the\n> index or in the working tree, which maps to other VCS's idea of\n> \"modified\" (because for them, marking something as to-be-committed and\n> commiting it are part of the same step).\n\nYes, I think your right. For most of my purposes, I think that it's \nirrelevant whether a change is staged or not and the choices that I \noffer allow the user to do what he thinks is right for a file with \nchanges that are staged but uncommitted. For me to automatically do \nsomething based on whether the file was staged for a commit would be a \nmistake as I would be reducing the user's options.\n\nHowever, the distinction might be worth making in the file tree display \nto remind the user what's staged and what's not?\n\n>\n>>> For this, you probably want \"git diff-files --name-only\", which will\n>>> show files with differences in the working tree. Keep in mind that git\n>>> has an \"index\" or \"staging area\", which means that you have three states\n>>> of content for a given path:\n>>>\n>>> 1. the state of the prior commit (i.e., HEAD)\n>>>\n>>> 2. the state that is marked to be committed when \"git commit\" is run\n>>> (i.e., the index)\n>>>\n>>> 3. the state in the working tree\n>>\n>> This is a prime example of the different mindset of the git user to\n>> the hg user.\n>\n> You don't have to use those features, of course. It's just that\n> something like \"git status\" is going to report on the differences\n> between those states, so as a tool writer you need to know they are\n> there (and as I said above, you are free to simplify if it fits into the\n> mental model of your tool).\n>\n>>> You can compare the first two with \"git diff-index\", and the latter two\n>>> with \"git diff-files\". You can also use \"git status --porcelain\" to get\n>>> a machine-readable output that shows how the three states match up, with\n>>> one line per file.\n>>\n>> This is an example of why I'm confused. There are too many ways to\n>> do (similar) things and it's hard to know which to use.\n>\n> Git is made of little building blocks. The original way to see the\n> differences between the index and the working tree was via diff-files.\n> But then people build bigger building blocks out of the smaller ones.\n> \"git status\" is really just a shorthand for:\n>\n> git diff-index HEAD&&\n> git diff-files&&\n> git ls-files -o\n>\n> and is in fact implemented using those building blocks (originally as a\n> shell script, though these days it is written in C). So you can choose\n> either and get the same information. Choosing a higher-level building\n> block may save you some work, if the abstraction matches what you want.\n> Otherwise, you can compose what you want from the lower levels.\n>\n> I know it sometimes leads to an overwhelming number of commands, and I'm\n> not trying to excuse git's tendency to confuse people. I'm just hoping\n> to unconfuse you in this particular situation.\n\nAs an aside, I found it easier to delve into git's innards to find out \nhow to implement git binary patches than I did finding out how to do \nthings from the CLI :-).\n\n>\n> In your case, I think \"status\" is the most convenient level of\n> abstraction for you, because you are interesting in looking at\n> differences to both the index and HEAD (i.e., the prior commit). But if\n> you find as you implement that want more flexibility, you can switch to\n> using the lower-level commands yourself.\n\nI'll investigate this approach. How easy is it to distinguish low level \ncommands from high level commands?\n\n>\n>> Maybe an example of why I think the feature is useful might help.\n>> Say that you start editing a file and then decide that you want to\n>> put this change into a patch rather than committing it. If you were\n>> using quilt you would have to do this manually by any of a number or\n>> ways such as:\n>>\n>> $ file> temp.patch\n>> $ file\n>> $ quilt new one.patch\n>> $ quilt add file\n>> $ patch -p1 file< temp.patch\n>> $ rm temp.patch\n>>\n>> In darning, you just do:\n>>\n>> $ darn new one.patch\n>> $ darn add --absorb file\n>\n> Sure. We have stgit and topgit, which do similar patch management things\n> on top of git. I don't personally user either, though, so I don't have\n> much to say on how they compare to darning, or whether it is worth\n> looking at their implementations.\n\nAnd there's MQ on top of hg. I find the idea of doing \"temporary\" \ncommits (which is what these tools are essentially doing) a little risky \n(e.g. what happens if you do a push with temporary commits in place). \nWith MQ, I use its hook system to prevent this happening and I imagine \ngit provides something similar.\n\nOf course, these tools have the advantage that it's easier to promote a \npatch to a full blown commit than it is for quilt or darning in its \ncurrent form (I'm thinking about how to do this). At this stage, \ndarning is targeted at the user who has to maintain a set of patches on \ntop of a third party source tree without the need to eventually commit \nthe changes themselves (i.e. distribution managers).\n\nI've never used stgit or topgit but I have used both quilt and MQ a lot. \n I find them both quite usable but each with their own set of \nadvantages and disadvantages hence my attempt to make a tool as much \nlike them as possible but with a smaller set of disadvantages.\n\n>\n>> The interface to the SCM to support this is two functions:\n>>\n>> 1: get_files_with_uncommitted_changes() which called with no\n>> arguments returns a list of the paths of all files with uncommitted\n>> changes or when given a list of file paths (the more common case)\n>> returns the subset of that list which have uncommitted changes; and\n>\n> \"status\" will do this for you, modulo the simplification of the concept\n> of the index, as we discussed above.\n>\n>> 2. copy_clean_version_to(filepath, target_path) which makes a copy of\n>> the file as recorded in the prior commit and places it at the\n>> target_path (usually where darning stores the \"original\" for\n>> reference when creating diffs).\n>\n> You probably want:\n>\n> git cat-file blob HEAD:filepath>target_path\n>\n\nI think I might do this in two stages. First, just do the bit about \nadding files and pushing (as that is the most useful) and leave the file \ntree as a vanilla tree for the time being (as it looks like it may be \nmore complicated).\n\n\nThanks for your help,\nPeter\n"},{"id":"180226","messageId":"20111201234042.GA7294@sigill.intra.peff.net","threadId":"29051","inReplyTo":"4ED80EA2.80805@users.sourceforge.net","subject":"Re: [HELP] Adding git awareness to the darning patch management system.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-12-01T23:40:42Z","receivedAt":"2011-12-01T23:40:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 02, 2011 at 09:32:50AM +1000, Peter Williams wrote:\n\n> Yes, I think your right. For most of my purposes, I think that it's\n> irrelevant whether a change is staged or not and the choices that I\n> offer allow the user to do what he thinks is right for a file with\n> changes that are staged but uncommitted. For me to automatically do\n> something based on whether the file was staged for a commit would be\n> a mistake as I would be reducing the user's options.\n> \n> However, the distinction might be worth making in the file tree\n> display to remind the user what's staged and what's not?\n\nI'd personally start with ignoring the distinction, and then wait for\nsome enterprising user to suggest how it would be marked. That takes the\nburden off of you for guessing what representation would be best.\n\n> As an aside, I found it easier to delve into git's innards to find\n> out how to implement git binary patches than I did finding out how to\n> do things from the CLI :-).\n\nHeh. I think that is because the CLI is written by people (myself\nincluded) who want it to give them access to git's innards. ;)\n\n> >In your case, I think \"status\" is the most convenient level of\n> >abstraction for you, because you are interesting in looking at\n> >differences to both the index and HEAD (i.e., the prior commit). But if\n> >you find as you implement that want more flexibility, you can switch to\n> >using the lower-level commands yourself.\n> \n> I'll investigate this approach. How easy is it to distinguish low\n> level commands from high level commands?\n\ngit(1) has a list of \"porcelain\" and \"plumbing\" commands. If you are\nscripting, you generally want to stick with plumbing commands,\nlower-level whose output and behavior remains stable across releases.\n\nHowever, some porcelain commands offer a \"plumbing\" mode (despite the\nname, the \"--porcelain\" flag to some commands is what you want; it is\nabout offering parseable output that a custom porcelain could use. In\ngit lingo, your interface is one such porcelain).\n\n-Peff\n"}]}