{"thread":{"id":"32165","subject":"Requirements for integrating a new git subcommand","startedAt":"2012-11-22T05:30:12Z","lastAt":"2012-11-26T11:01:29Z","messageCount":12,"participants":["Eric S. Raymond","Shawn Pearce","Michael J Gruber","Peter Krefting","Christian Couder","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"203641","messageId":"20121122053012.GA17265@thyrsus.com","threadId":"32165","inReplyTo":null,"subject":"Requirements for integrating a new git subcommand","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-22T05:30:12Z","receivedAt":"2012-11-22T05:30:12Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"I have completed work on git-weave (the tool I had called 'gitpacker' in some\nprevious postings). I want to submit a patch that integrates it into git;\nin hopes of smoothing the process I have some technical and procedural \nquestions. \n\nFirst, however, let me present the git-weave documentation for design\nreview:\n\n----------------------------------------------------------------------\ngit-weave(1)\n============\n\nNAME\n----\ngit-weave - Weave a sequence of trees and log data into a repository\n\nSYNOPSIS\n--------\n[verse]\n'git-weave' [-v] [-m limit] [-q] indir outdir\n\nDESCRIPTION\n-----------\ngit-weave accepts an input directory containing a sequence of\nsubdirectories and a metadata file, and composes them into a \ngit repository created under the specified output directory\n(which must not exist).\n\nIf the input directory is identifiably a git repository, the weave\noperation is reversed; tree states from each commit are unraveled into\nthe output directory with a log holding commit metadata\n(committer/author/comment information and parent headers representing\nlinks of the repository DAG) and tags.\n\nThis tool is primarily intended for importing and working with project\nhistories that have been preserved only as linear sequences of release\nsnapshots. It may also be useful for surgery on linear repositories\n\nWhile the weave operation can build a commit graph with any structure\ndesired, an important restriction of the inverse (unraveling)\noperation is that it operates on *master branches only*. The unravel\noperation discards non-master-branch content, emitting a warning \nto standard error when it has to do so.\n\nCommits from the repository's master branch are unraveled into\ndirectories named for integers from 1 increasing, but their order of\ncomposition when re-woven is actually set by the sequence of entries\nin the metadata file. File trees may be inserted or removed without\nhindering re-weaving provided the pointers in the log's parent fields\nare fixed up properly.\n\nMETADATA FILE FORMAT\n--------------------\nThe metadata file format will contain three kinds of stanzas: entries\nfor commits, entries for lightweight tags, and entries for annotated\ntags.\n\nA commit stanza has headers similar to those in a commit raw log:\ncommit, committer, author, and optionally parent headers. The header\ncontents are not hash IDs, but arbitrary text cookies either declared\nby a previous commit stanza or referencing one. The following example\ndeclares \"8\" to be a commit ID, and references a previous commit\nidentified as '7'. Note that commit IDs are not required to be\nnumeric strings, though the unravel operation generates them that way.\n\n------------\ncommit 8\nparent 7\nauthor Eric S. Raymond 1325026869 +0000\ncommitter Eric S. Raymond 1325026869 +0000\n\nInitial revision\n.\n------------\n\nThe text body of a commit comment or tag comment entry is delimited\nfrom the headers by an empty line; the text body must always end with\n\".\" on a line by itself; and text lines beginning with \".\" will have\nan additional \".\" prepended to them.\n\nA commit stanza may also have a \"directory\" header. If present, this \nsets the name of the subdirectory in which git-weave expects to\nfind the content tree for this commit. For example\n\n------------\ncommit 24\ndirectory intercal-0.17\nparent 23\nauthor Eric S. Raymond 1325026489 +0000\ncommitter Eric S. Raymond 1325026489 +0000\n\nThe state of the INTERCAL project at release 0.17.\n.\n------------\n\nA label stanza declares a lightweight tag. This example declares a\ntag 'sample' pointing at the commit identified as 102.\n\n------------\nlabel sample\nrefers-to 102\n------------\n\nA tag stanza declares an annotated tag. This one declares a tag named\n'annotated1' pointing at the commit declared as 99.\n\n------------\ntag annotated1\nrefers-to 99\ntagger Eric S. Raymond Sat Nov 17 03:16:26 2012 -0500\n\nThis is an example annotated tag.\n.\n------------\n\nWhen you are composing commit and tag stanzas by hand, you can count\non any of the date formats normally acceptable to git to be\nrecognized.\n\nIf, when weaving, any committer or author or tagger line, the date is omitted,\ngit-weave will supply as a default the latest modification time of\nany file in the corresponding tree.\n\nIf a committer or author or tagger line is omitted entirely, the\nuser's name and email address as retrieved by ''git-config'' will\nbe supplied as defaults, and the date will default as above.\n\nThus, the following variation on one of the previous examples \nis a valid stanza:\n\n------------\ncommit 24\ndirectory intercal-0.17\nparent 23\n\nThe state of the INTERCAL project at release 0.17.\n.\n------------\n\nOPTIONS\n-------\n-q::\n\tBe quiet. Suppress the normal spinning-baton progress meter\n\twith timing information.\n\n-m::\n\tLimit the number of commits or trees processed to a specified\n\tinteger maximum. '0' means process all of them.\n\n-v::\n\tBe verbose, enabling progress and command-execution messages\n\tThis option will probably be of interest only to developers;\n\tconsult the source code for details.\n\nEXAMPLES\n--------\n* Weave a sequence of trees in the directory 'unraveled' \ninto a git repository in the directory 'repo'. \n+\n------------\n$ rm -fr repo; git-weave unraveled repo\n------------\n+\nThe metadata is expected to be in 'unraveled/log'. This mode of\noperation is triggered when there is no file 'unraveled/.git', \n\n* Unravel a repository in the directory 'repo' into a sequence\nof file trees and a metadata log in the directory 'unraveled'.\n+\n------------\n$ rm -fr unraveled; git-weave repo unraveled\n------------\n+\nThis mode of operation is triggered when there is a 'repo/.git' file.\n\nSEE ALSO\n--------\nlinkgit:git-log[1]\nlinkgit:git-checkout[1]\nlinkgit:git-add[1]\nlinkgit:git-mktree[1]\nlinkgit:git-ls-tree[1]\nlinkgit:git-update-references[1]\n\nGIT\n---\nNot yet part of the linkgit:git[1] suite\n----------------------------------------------------------------------\n\nYes, there are scripts in contrib that do similar things. git-weave\nis an improvement is several ways: (a) it is documented, (b) I am\nshipping it with a functional test, (c) I am prepared to maintain it \nand am quite unlikely to drop out of sight :-), (d) it does both\nthe import operation *and its inverse*, and (e) it is rather more\npowerful, including the ability to decorate the import with \nannotated tags.\n\nNow *my* questions:\n\n1. I have a round-trip test for the tool that I can very easily adapt\nto speak TAP. To function, the test will require a small linear\nhistory to operate on in the form of an import-stream file (so the\nresult of round-tripping through a weave-unravel can be diffed against\nthe original). Does the distribution include any test repos? If\nso, where can I find them?\n\n2. I understand that a \"git foo\" command is typically implemented\nas \"git-foo\" binary or script in /usr/lib/git-core. What I don't\nknow is what the other interfacing requirements are. Are they\ndocumented anywhere? In particular...\n\n3. Is there any registration protocol other than simply installing \nthe extension in the subcommand library?\n\n4. How does \"git help\" work? That is, how is a subcommand expected\nto know when it is being called to export its help text?\n\n5. I don't see any extensions written in Python. Are there any special\nrequirements or exclusions for Python scripts?\n-- \n\t\tEric S. Raymond\n"},{"id":"203645","messageId":"CAJo=hJsQjXEhmfRUEgBc=RkF3Lk8QVqUqmeAJiOZ0dtvcMYVFw@mail.gmail.com","threadId":"32165","inReplyTo":"20121122053012.GA17265@thyrsus.com","subject":"Re: Requirements for integrating a new git subcommand","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2012-11-22T19:17:34Z","receivedAt":"2012-11-22T19:17:34Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Wed, Nov 21, 2012 at 9:30 PM, Eric S. Raymond wrote:\n> I have completed work on git-weave (the tool I had called 'gitpacker' in some\n> previous postings). I want to submit a patch that integrates it into git;\n> in hopes of smoothing the process I have some technical and procedural\n> questions.\n...\n> Now *my* questions:\n>\n> 1. I have a round-trip test for the tool that I can very easily adapt\n> to speak TAP. To function, the test will require a small linear\n> history to operate on in the form of an import-stream file (so the\n> result of round-tripping through a weave-unravel can be diffed against\n> the original). Does the distribution include any test repos? If\n> so, where can I find them?\n\nNo. We create the repositories from scratch using a series of\ncommands. If you look at the test library the environment is set in a\npredictable way so the author, committer and timestamps are all set to\na single well known value, allowing Git to create a commit that is\nreproducible on all platforms. A test_tick function is used in the\nscripts to move the clock, allowing different times to be used. For an\nexample see t7502-commit.sh, or really any script in that directory.\n\n> 2. I understand that a \"git foo\" command is typically implemented\n> as \"git-foo\" binary or script in /usr/lib/git-core. What I don't\n> know is what the other interfacing requirements are. Are they\n> documented anywhere? In particular...\n\nNope. \"git foo\" will invoke \"git-foo\" with GIT_DIR set in the\nenvironment, so you know what repository to act against, and so does\nany git command you recursively invoke. Other than that there really\naren't any interface requirements. Your program is executed with\nwhatever arguments the caller gave you. Its pretty simple UNIX stuff.\n:-)\n\n> 3. Is there any registration protocol other than simply installing\n> the extension in the subcommand library?\n\nNope. Running \"git whatever-this-is-i-have-no-idea\" will try to\nexecute \"git-whatever-this-is-i-have-no-idea\" via $PATH, after adding\n/usr/lib/git-core to the front of $PATH. Its pretty simple actually.\nIf your standard C library can find the program in $PATH its run, if\nit can't find it, it dies.\n\n> 4. How does \"git help\" work? That is, how is a subcommand expected\n> to know when it is being called to export its help text?\n\nIIRC \"git help foo\" runs \"man git-foo\".\n\n> 5. I don't see any extensions written in Python. Are there any special\n> requirements or exclusions for Python scripts?\n\nNope, it just has to be executable. We don't have any current Python\ncode. IIRC the last Python code was the implementation of\ngit-merge-recursive, which was ported to C many years ago. We avoid\nPython because it is not on every platform where Git is installed. Yes\nPython is very portable and can be installed in many places, but we\nprefer not to make it a requirement.\n"},{"id":"203667","messageId":"20121122221107.GA16069@thyrsus.com","threadId":"32165","inReplyTo":"CAJo=hJsQjXEhmfRUEgBc=RkF3Lk8QVqUqmeAJiOZ0dtvcMYVFw@mail.gmail.com","subject":"Re: Requirements for integrating a new git subcommand","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-22T22:11:07Z","receivedAt":"2012-11-22T22:11:07Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Shawn Pearce :\n> [Lots of helpful stuff ended by]\n> > 4. How does \"git help\" work? That is, how is a subcommand expected\n> > to know when it is being called to export its help text?\n> \n> IIRC \"git help foo\" runs \"man git-foo\".\n\nOK, that makes sense.\n\n> > 5. I don't see any extensions written in Python. Are there any special\n> > requirements or exclusions for Python scripts?\n> \n> Nope, it just has to be executable. We don't have any current Python\n> code. IIRC the last Python code was the implementation of\n> git-merge-recursive, which was ported to C many years ago. We avoid\n> Python because it is not on every platform where Git is installed. Yes\n> Python is very portable and can be installed in many places, but we\n> prefer not to make it a requirement.\n\nI find that odd. You avoid Python but use shellscripts? *blink*\n\nOne would think shellscripts were a much more serious portability problem.\n-- \n\t\tEric S. Raymond\n"},{"id":"203691","messageId":"50AF3E36.4080800@drmicha.warpmail.net","threadId":"32165","inReplyTo":"20121122221107.GA16069@thyrsus.com","subject":"Re: Requirements for integrating a new git subcommand","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-11-23T09:13:26Z","receivedAt":"2012-11-23T09:13:26Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Eric S. Raymond venit, vidit, dixit 22.11.2012 23:11:\n> Shawn Pearce :\n>> [Lots of helpful stuff ended by]\n>>> 4. How does \"git help\" work? That is, how is a subcommand expected\n>>> to know when it is being called to export its help text?\n>>\n>> IIRC \"git help foo\" runs \"man git-foo\".\n> \n> OK, that makes sense.\n> \n>>> 5. I don't see any extensions written in Python. Are there any special\n>>> requirements or exclusions for Python scripts?\n>>\n>> Nope, it just has to be executable. We don't have any current Python\n>> code. IIRC the last Python code was the implementation of\n>> git-merge-recursive, which was ported to C many years ago. We avoid\n>> Python because it is not on every platform where Git is installed. Yes\n>> Python is very portable and can be installed in many places, but we\n>> prefer not to make it a requirement.\n> \n> I find that odd. You avoid Python but use shellscripts? *blink*\n> \n> One would think shellscripts were a much more serious portability problem.\n\nDifferent versions of python can be a mess to deal with, also, at least\nwith respect to standard modules being \"standard\" or not for a specific\nversion.\n\nIn any case, the point is that we try to avoid *additional*\ndependencies. Shell and perl are given with the status quo.\n\nThat being said, we also have remote helpers in python. The testsuite\ncan run tests depending on the availability of python.\n\nRegarding git-weave, I'm wondering (without having looked at the code)\nhow this relates to git-archiv and git-fast-import/export, i.e. how much\nthis leverages existing infrastructure rather than reinventing the\nwheel. Do your \"trees\" correspond to a \"git tree\"?\n\nAgain, without having looked at the code, it seems to me that exploding\nblob and tree objects might give you a structure not much unlike\nweave's, and your instruction sheet resembles that of fast-import quite\na bit (plus date fill-in etc.).\n\nOne could even dream about implementing this as a remote helper instead...\n\nMichael\n"},{"id":"203692","messageId":"alpine.DEB.2.00.1211231022440.1431@ds9.cixit.se","threadId":"32165","inReplyTo":"20121122053012.GA17265@thyrsus.com","subject":"Re: Requirements for integrating a new git subcommand","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2012-11-23T09:27:23Z","receivedAt":"2012-11-23T09:27:23Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Eric S. Raymond:\n\n> git-weave(1)\n\n> Yes, there are scripts in contrib that do similar things.\n\nI was just about to say that the import direction of this seems to \nfill the same need as contrib/fast-import/import-directories.perl that \nI submitted a few years back.\n\nYour version seems only to be able to import a linear history, \nhowever, my tool does support creating merge commits (basically, the \nhistory I had to import was very messy and contained a lot of snapshot \ndirectories having been worked on in parallel).\n\n> (b) I am shipping it with a functional test,\n\nHmm, indeed. I have been thinking of trying to wrap up the test suite \nI have locally into something that could work within the Git testing \nframework, but haven't found the time to or energy for so far.\n\n\nAnyway, my sentiment is that if you can add support for merges in you \nweave tool, then I am very much for removing my old script from the \nrepository.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"203703","messageId":"20121123153541.GA20097@thyrsus.com","threadId":"32165","inReplyTo":"alpine.DEB.2.00.1211231022440.1431@ds9.cixit.se","subject":"Re: Requirements for integrating a new git subcommand","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-23T15:35:41Z","receivedAt":"2012-11-23T15:35:41Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Peter Krefting :\n> I was just about to say that the import direction of this seems to\n> fill the same need as contrib/fast-import/import-directories.perl\n> that I submitted a few years back.\n\nYours was the closest in functionality, yes.\n\n> Your version seems only to be able to import a linear history,\n> however, my tool does support creating merge commits (basically, the\n> history I had to import was very messy and contained a lot of\n> snapshot directories having been worked on in parallel).\n\ngit-weave can *weave* (import) a sequence with merge commits, as your\ntool can. What it can't do is unravel a nonlinear repo into a tree\nsequence that will round-trip through the weave operation. (Though I\nthought of a way I might be able to fix that last night.)\n \n> Anyway, my sentiment is that if you can add support for merges in\n> you weave tool, then I am very much for removing my old script from\n> the repository.\n\nThe support is there. I will take this as direction to (a) add a \ntest load demonstrating this, and (b) include the removal of\nimport-directories.perl in my integration patch.\n-- \n\t\tEric S. Raymond\n"},{"id":"203705","messageId":"20121123155306.GB20097@thyrsus.com","threadId":"32165","inReplyTo":"50AF3E36.4080800@drmicha.warpmail.net","subject":"Re: Requirements for integrating a new git subcommand","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-23T15:53:06Z","receivedAt":"2012-11-23T15:53:06Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Michael J Gruber :\n> Regarding git-weave, I'm wondering (without having looked at the code)\n> how this relates to git-archiv and git-fast-import/export, i.e. how much\n> this leverages existing infrastructure rather than reinventing the\n> wheel. Do your \"trees\" correspond to a \"git tree\"?\n\nThe unravel operation of git-weave is something like running\ngit-archive on every revision and saving the results in\nsequentially-named directories, except that it also produces a\nmetadata file that allows the operation to be inverted.\nSo it is strictly more powerful.\n\nThe weave operation could be implemented using git fast-import, which\nI am quite intimately familiar with from having written reposurgeon.\nFunctionally, the difference is that it would be a PITA to patch a\nfast-import stream to insert or modify or remove revisions in the\nmiddle, because the content of any given revision is in blobs that can\nstretch arbitrarily far back from its commit and are shared with\nother revisions. With git-weave tree-sequences these operations\nare easy and safe.\n\n> Again, without having looked at the code, it seems to me that exploding\n> blob and tree objects might give you a structure not much unlike\n> weave's, and your instruction sheet resembles that of fast-import quite\n> a bit (plus date fill-in etc.).\n\nThe weave log resembles an import stream, yes - that's because they\nhave to capture the same data ontology. One major difference is that weave\nlogs are designed to be generated and edited by humans.\n \n> One could even dream about implementing this as a remote helper instead...\n\nWhat is a \"remote helper\" in this context?\n-- \n\t\tEric S. Raymond\n"},{"id":"203709","messageId":"20121123162939.GA23962@thyrsus.com","threadId":"32165","inReplyTo":"CAJo=hJsQjXEhmfRUEgBc=RkF3Lk8QVqUqmeAJiOZ0dtvcMYVFw@mail.gmail.com","subject":"Re: Requirements for integrating a new git subcommand","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-23T16:29:39Z","receivedAt":"2012-11-23T16:29:39Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Shawn Pearce :\n> Nope, it just has to be executable. We don't have any current Python\n> code. IIRC the last Python code was the implementation of\n> git-merge-recursive, which was ported to C many years ago.\n\nThis turns out not to be quite true. The tree currently includes \ntwo Python scripts, a Perforce importer and a test helper.\n\nI'm in he process of writing up a document on command integration\nbased on your answers. I will submit it for incusion in the tree\nshortly.\n-- \n\t\tEric S. Raymond\n"},{"id":"203716","messageId":"CAP8UFD1aGJJMx74RXGTy4hO=Wdv3dDuX4P3UEEGgYvcA_j=M1A@mail.gmail.com","threadId":"32165","inReplyTo":"20121122221107.GA16069@thyrsus.com","subject":"Re: Requirements for integrating a new git subcommand","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2012-11-23T20:21:46Z","receivedAt":"2012-11-23T20:21:46Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Nov 22, 2012 at 11:11 PM, Eric S. Raymond wrote:\n> Shawn Pearce :\n>> [Lots of helpful stuff ended by]\n>> > 4. How does \"git help\" work? That is, how is a subcommand expected\n>> > to know when it is being called to export its help text?\n>>\n>> IIRC \"git help foo\" runs \"man git-foo\".\n>\n> OK, that makes sense.\n\n\"git help\" can also launch a browser to display the HTML version of\nthe man page.\nIt is looking for man pages and HTML docs in the paths given by \"git\n--man-path\" and \"git --html-path\".\n\nCheers,\nChristian.\n"},{"id":"203844","messageId":"7vmwy5xe9n.fsf@alter.siamese.dyndns.org","threadId":"32165","inReplyTo":"20121122053012.GA17265@thyrsus.com","subject":"Re: Requirements for integrating a new git subcommand","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-26T02:57:08Z","receivedAt":"2012-11-26T02:57:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Eric S. Raymond\" writes:\n\n> While the weave operation can build a commit graph with any structure\n> desired, an important restriction of the inverse (unraveling)\n> operation is that it operates on *master branches only*. The unravel\n> operation discards non-master-branch content, emitting a warning \n> to standard error when it has to do so.\n\nImagine that I have a simple four-commit diamond:\n\n I---A\n \\ \\\n B---M\n\nwhere Amy and Bob forked the initial commit made by Ian and created\none commit each, and their branches were merged into one 'master'\nbranch by a merge commit made by Mac. How many state snapshots will\nI see when I ask you to unravel this? Three, or four?\n\nIf you are going to give me all four states, then I do not\nunderstand why this needs to be limited to the master branch only.\nEven if you start from a single commit at the tip of 'master', once\nyou hit a merge, you will need to follow all of two (or more) paths\nto dig down to the root(s), so supporting to start digging from more\nthan one commit is not all that different.\n\nIf you are going to give me only three states, following the first\nparent ancestry chain, then the description needs to state it more\nclearly. I am not saying first-parent-only history is useless, but\nthe user needs to know that merges are flattened in the unraveled\nresult and the resulting history becomes linear, following the first\nparent ancestry chain of the original history (if that is what the\ntool does) before deciding if this tool matches what she needs.\n\nAs to the procedural stuff, I think others have sufficiently\nanswered already. If I may add something, a new stuff typically\nstart its life in contrib/ before it proves to be useful.\n"},{"id":"203849","messageId":"20121126044922.GA14505@thyrsus.com","threadId":"32165","inReplyTo":"7vmwy5xe9n.fsf@alter.siamese.dyndns.org","subject":"Re: Requirements for integrating a new git subcommand","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-26T04:49:22Z","receivedAt":"2012-11-26T04:49:22Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Junio C Hamano :\n> \"Eric S. Raymond\" writes:\n> \n> > While the weave operation can build a commit graph with any structure\n> > desired, an important restriction of the inverse (unraveling)\n> > operation is that it operates on *master branches only*. The unravel\n> > operation discards non-master-branch content, emitting a warning \n> > to standard error when it has to do so.\n> \n> Imagine that I have a simple four-commit diamond:\n> \n> I---A\n> \\ \\\n> B---M\n> \n> where Amy and Bob forked the initial commit made by Ian and created\n> one commit each, and their branches were merged into one 'master'\n> branch by a merge commit made by Mac. How many state snapshots will\n> I see when I ask you to unravel this? Three, or four?\n\nYou will see four tree states. I have managed to remove the\nmaster-branch-only restriction.\n\n> As to the procedural stuff, I think others have sufficiently\n> answered already. If I may add something, a new stuff typically\n> start its life in contrib/ before it proves to be useful.\n\nThank you, I have submitted a documentation patch which folds\nin the on-list discussion.\n\nAs a separate point...are you requesting that I submit my integration\npatch to drop git-weave in contrib? If so, I will of course comply.\n\nBut I will point out that git-weave is not a half-thought out\nexperiment; it is fully documented and has a functional test. The\ncase for its usefulness is bolstered by one previous contrib script,\nwhich the author has agreed to retire in favor of git-weave.\n-- \n\t\tEric S. Raymond\n"},{"id":"203864","messageId":"alpine.DEB.2.00.1211261201000.11881@ds9.cixit.se","threadId":"32165","inReplyTo":"20121123153541.GA20097@thyrsus.com","subject":"Re: Requirements for integrating a new git subcommand","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2012-11-26T11:01:29Z","receivedAt":"2012-11-26T11:01:29Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Eric S. Raymond:\n\n> and (b) include the removal of import-directories.perl in my \n> integration patch.\n\nYes, please.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"}]}