{"thread":{"id":"13125","subject":"branch description","startedAt":"2008-04-15T16:51:49Z","lastAt":"2008-04-19T21:05:35Z","messageCount":23,"participants":["Stephen Sinclair","Russ Dill","Brian Gernhardt","Jakub Narebski","Junio C Hamano","Jeff King","Matt Graham","Mike Hommey","Johan Herland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"74455","messageId":"9b3e2dc20804150951scf8b3c7x26f3a56eab1f9840@mail.gmail.com","threadId":"13125","inReplyTo":null,"subject":"branch description","fromName":"Stephen Sinclair","fromEmail":"radarsat1@gmail.com","sentAt":"2008-04-15T16:51:49Z","receivedAt":"2008-04-15T16:51:49Z","isPatch":false,"sender":{"key":"radarsat1@gmail.com","avatar":null},"body":"Hi,\n\nI find it useful to use fairly short names for branches. However,\nsometimes I would like to have a full sentence to actually describe\nwhat the branch is for, without having the peruse the actual commits.\n\nThis is both for when I later can't remember why I made a certain\nbranch, or for when people clone and look at a list of branches\nwondering what the differences are between them.\n\nThis information could of course be kept on a web page, but it would\nbe nice to have it in the repo.\nIs there any such branch annotation command?\nIdeally I'd like to see a sentence displayed next to the branch name\nwhen I use \"git-branch\".\nPerhaps, git-branch --info or something.\n\n\nSteve\n"},{"id":"74456","messageId":"f9d2a5e10804151031o1d09c1f9od0ad78dcf9b746c5@mail.gmail.com","threadId":"13125","inReplyTo":"9b3e2dc20804150951scf8b3c7x26f3a56eab1f9840@mail.gmail.com","subject":"Re: branch description","fromName":"Russ Dill","fromEmail":"russ.dill@gmail.com","sentAt":"2008-04-15T17:31:06Z","receivedAt":"2008-04-15T17:31:06Z","isPatch":false,"sender":{"key":"russ.dill@gmail.com","avatar":"https://gravatar.com/avatar/989b24f3fa63126a35d7c74069e2626e715a3b1a86616be9962f7ceae04ff9c5?d=mp&s=160"},"body":"> I find it useful to use fairly short names for branches. However,\n> sometimes I would like to have a full sentence to actually describe\n> what the branch is for, without having the peruse the actual commits.\n\nMe too.\n\n> This information could of course be kept on a web page, but it would\n> be nice to have it in the repo.\n\nLike, putting your bug number in the branch name.\n\n> Is there any such branch annotation command?\n> Ideally I'd like to see a sentence displayed next to the branch name\n> when I use \"git-branch\".\n> Perhaps, git-branch --info or something.\n\nThe problem is that a branch is just a floating name for a line of\ndevelopment. Its not really a \"thing\" in the repository like a tag or\na commit. You'd need to make some sort of special tag that describes\nthe branch or somesuch.\n"},{"id":"74459","messageId":"C55CA6EB-D427-4CF5-923E-DE0071D2F870@silverinsanity.com","threadId":"13125","inReplyTo":"f9d2a5e10804151031o1d09c1f9od0ad78dcf9b746c5@mail.gmail.com","subject":"Re: branch description","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-04-15T18:01:41Z","receivedAt":"2008-04-15T18:01:41Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Apr 15, 2008, at 1:31 PM, Russ Dill wrote:\n\n> The problem is that a branch is just a floating name for a line of\n> development. Its not really a \"thing\" in the repository like a tag or\n> a commit. You'd need to make some sort of special tag that describes\n> the branch or somesuch.\n\nNo special tags needed. A simple file that I'll call .git/info/ \nref_names could be a set of lines that have \"\\t\", \nlike the following:\n\nrefs/heads/master\tCollection point for all my work\nrefs/heads/ref_names\tAdd descriptions for branches\nrefs/heads/segfault\tTrying to fix bug #12345\n\nSimple, no tags, new object types or anything. All you have to do is \nadd the bits to git-branch to add, edit, and remove the description \nalongside the branch itself.\n\nNow if you want to propagate these descriptions when you push and \npull, things get a lot more complicated.\n\n~~ Brian\n"},{"id":"74465","messageId":"m3iqyjrmmk.fsf@localhost.localdomain","threadId":"13125","inReplyTo":"f9d2a5e10804151031o1d09c1f9od0ad78dcf9b746c5@mail.gmail.com","subject":"Re: branch description","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-04-15T18:36:40Z","receivedAt":"2008-04-15T18:36:40Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Russ Dill\" writes:\n\n>> I find it useful to use fairly short names for branches. However,\n>> sometimes I would like to have a full sentence to actually describe\n>> what the branch is for, without having the peruse the actual commits.\n> \n> Me too.\n> \n>> This information could of course be kept on a web page, but it would\n>> be nice to have it in the repo.\n> \n> Like, putting your bug number in the branch name.\n> \n>> Is there any such branch annotation command?\n>> Ideally I'd like to see a sentence displayed next to the branch name\n>> when I use \"git-branch\".\n>> Perhaps, git-branch --info or something.\n> \n> The problem is that a branch is just a floating name for a line of\n> development. Its not really a \"thing\" in the repository like a tag or\n> a commit. You'd need to make some sort of special tag that describes\n> the branch or somesuch.\n\nErrr... not exactly. It is true that refs such like branches reside\noutside object database[1], and that names of refs are purely local\nmatter (see old master -> origin mapping, and new refs/heads/* ->\nrefs/remotes//* mapping). But you can examine list of\nbranches in remote repository using e.g. git-ls-remote or its\nequivalent in the git API.\n\nSo I think better solution would be to add this info somewhere outside\nobject database, for example in repository config (assuming that not\nall branches would have description) as it already stores branch\nrelated information, _and_ enhance commands to make use of this info,\nnot only git-branch, but also git-for-each-ref, git-show-refs and\ngit-ls-remote (and its equivalents).\n\nFootnotes:\n==========\n[1] And have to be, Mercurial misdesign nothwithstanding\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"74468","messageId":"7vej97x78v.fsf@gitster.siamese.dyndns.org","threadId":"13125","inReplyTo":"C55CA6EB-D427-4CF5-923E-DE0071D2F870@silverinsanity.com","subject":"Re: branch description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-15T19:12:16Z","receivedAt":"2008-04-15T19:12:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brian Gernhardt writes:\n\n> On Apr 15, 2008, at 1:31 PM, Russ Dill wrote:\n>\n>> The problem is that a branch is just a floating name for a line of\n>> development. Its not really a \"thing\" in the repository like a tag or\n>> a commit. You'd need to make some sort of special tag that describes\n>> the branch or somesuch.\n>\n> No special tags needed. A simple file that I'll call .git/info/\n> ref_names could be a set of lines that have \"\\t\",\n> like the following:\n>\n> refs/heads/master\tCollection point for all my work\n> refs/heads/ref_names\tAdd descriptions for branches\n> refs/heads/segfault\tTrying to fix bug #12345\n>\n> Simple, no tags, new object types or anything. All you have to do is\n> add the bits to git-branch to add, edit, and remove the description\n> alongside the branch itself.\n>\n> Now if you want to propagate these descriptions when you push and\n> pull, things get a lot more complicated.\n\nNot complicated at all. Put that description in-tree in a known location\n(say, \"help-branch\") in-tree and your propagation problem is solved.\n\nAnd have a scriptlet in $HOME/bin/git-help-branch to grep from that file.\n"},{"id":"74469","messageId":"20080415191930.GC31395@sigill.intra.peff.net","threadId":"13125","inReplyTo":"7vej97x78v.fsf@gitster.siamese.dyndns.org","subject":"Re: branch description","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-15T19:19:30Z","receivedAt":"2008-04-15T19:19:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 15, 2008 at 12:12:16PM -0700, Junio C Hamano wrote:\n\n> > No special tags needed. A simple file that I'll call .git/info/\n> > ref_names could be a set of lines that have \"\\t\",\n> > like the following:\n> >\n> > refs/heads/master\tCollection point for all my work\n> > refs/heads/ref_names\tAdd descriptions for branches\n> > refs/heads/segfault\tTrying to fix bug #12345\n> >\n> > Simple, no tags, new object types or anything. All you have to do is\n> > add the bits to git-branch to add, edit, and remove the description\n> > alongside the branch itself.\n> \n> Not complicated at all. Put that description in-tree in a known location\n> (say, \"help-branch\") in-tree and your propagation problem is solved.\n>\n> And have a scriptlet in $HOME/bin/git-help-branch to grep from that file.\n\nIt is perhaps a little slow if you want to do things like adding the\nhelp text to branch name decorations in log output. Maybe instead of a\nflat file, you could parallel the ref name hierarchy in a tree? I.e.,\n\n git checkout help-branch\n echo 'Collection point for all my work' >refs/heads/master\n git commit -a\n\nAs a bonus, you don't even need a git-help-branch script:\n\n git show help-branch:refs/heads/master\n\nAnd if you have more than one person tweaking the help-branch text,\nmerging will be much less painful.\n\n-Peff\n"},{"id":"74474","messageId":"9b3e2dc20804151353p2622ab19i2a04f5da9a6417ca@mail.gmail.com","threadId":"13125","inReplyTo":"7vej97x78v.fsf@gitster.siamese.dyndns.org","subject":"Re: branch description","fromName":"Stephen Sinclair","fromEmail":"radarsat1@gmail.com","sentAt":"2008-04-15T20:53:47Z","receivedAt":"2008-04-15T20:53:47Z","isPatch":false,"sender":{"key":"radarsat1@gmail.com","avatar":null},"body":"On Tue, Apr 15, 2008 at 3:12 PM, Junio C Hamano wrote:\n>\n> Not complicated at all. Put that description in-tree in a known location\n> (say, \"help-branch\") in-tree and your propagation problem is solved.\n>\n> And have a scriptlet in $HOME/bin/git-help-branch to grep from that file.\n\nHm, I wasn't sure if an in-tree solution would be appropriate.\nIt's possible, but I didn't really want this branch description to be\nsomething I have to deal with when merging..\nIdeally though this information _should_ be propagated through a\nclone, so something in-tree might make sense.\n\nWhen I posted I thought perhaps there was already a way to do this\nthat I hadn't encountered.\nPerhaps there could be an in-tree file .gitbranch that is simply a\nname:description pair, \"git-branch --info\" (or whatever) could be made\nto know how to parse that file if it exists.\n\nHowever I was hoping that the branch description could be made when\ncreating the branch, instead of having to associate it with an actual\ncommit.\n\nI don't know, I'll give it some thought and try to come up with a more\nconcrete proposal.\n\n\nSteve\n"},{"id":"74478","messageId":"C4EC2200-59E0-4FBE-AA5F-4A05DAF4A427@silverinsanity.com","threadId":"13125","inReplyTo":"9b3e2dc20804151353p2622ab19i2a04f5da9a6417ca@mail.gmail.com","subject":"Re: branch description","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-04-15T21:04:02Z","receivedAt":"2008-04-15T21:04:02Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Apr 15, 2008, at 4:53 PM, Stephen Sinclair wrote:\n\n> On Tue, Apr 15, 2008 at 3:12 PM, Junio C Hamano \n> wrote:\n>>\n>> Not complicated at all. Put that description in-tree in a known \n>> location\n>> (say, \"help-branch\") in-tree and your propagation problem is solved.\n>>\n>> And have a scriptlet in $HOME/bin/git-help-branch to grep from that \n>> file.\n>\n> Hm, I wasn't sure if an in-tree solution would be appropriate.\n> It's possible, but I didn't really want this branch description to be\n> something I have to deal with when merging..\n> Ideally though this information _should_ be propagated through a\n> clone, so something in-tree might make sense.\n>\n> When I posted I thought perhaps there was already a way to do this\n> that I hadn't encountered.\n> Perhaps there could be an in-tree file .gitbranch that is simply a\n> name:description pair, \"git-branch --info\" (or whatever) could be made\n> to know how to parse that file if it exists.\n>\n> However I was hoping that the branch description could be made when\n> creating the branch, instead of having to associate it with an actual\n> commit.\n\nA random thought:\n\nrefs/info/heads/help is a pointer to a blob that is full of name- \ndescription pairs. Instead of a full ref name it simply keeps the \nportion for a given subdirectory. On a pull, you can add refs/info/ \nheads/help:refs/info/remote/origin/help. Each subdirectory of refs \ngets it's own help blob. You may need to deal with merging on pull, \nbut it keeps the information separate from the commits and still pull/ \npushable.\n\n~~ Brian\n"},{"id":"74485","messageId":"20080415223716.GA1891@sigill.intra.peff.net","threadId":"13125","inReplyTo":"20080415191930.GC31395@sigill.intra.peff.net","subject":"Re: branch description","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-15T22:37:16Z","receivedAt":"2008-04-15T22:37:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 15, 2008 at 03:19:30PM -0400, Jeff King wrote:\n\n> > Not complicated at all. Put that description in-tree in a known location\n> > (say, \"help-branch\") in-tree and your propagation problem is solved.\n> >\n> > And have a scriptlet in $HOME/bin/git-help-branch to grep from that file.\n> \n> It is perhaps a little slow if you want to do things like adding the\n> help text to branch name decorations in log output. Maybe instead of a\n> flat file, you could parallel the ref name hierarchy in a tree? I.e.,\n\nIt occurred to me that you actually meant \"just stick it in a file in\nyour actual work tree\", not on a separate branch (for some reason,\nreading the name \"help-branch\" made me think you meant a ref).\n\nSo that is obviously the very simple solution. But for fun, and because\nmaybe somebody could learn something, here is a script implementing my\napproach. I dunno if it is worth including in contrib.\n\n-- >8 --\ncontrib: add git-refinfo\n\nThis is a cute hack to show one possible way of storing ref\ndescriptions. It might be useful to somebody. It also serves\nas a relatively short and simple example of how to script\ngit.\n\nSigned-off-by: Jeff King \n---\n contrib/examples/git-refinfo.sh | 87 +++++++++++++++++++++++++++++++++++++++\n 1 files changed, 87 insertions(+), 0 deletions(-)\n create mode 100755 contrib/examples/git-refinfo.sh\n\ndiff --git a/contrib/examples/git-refinfo.sh b/contrib/examples/git-refinfo.sh\nnew file mode 100755\nindex 0000000..b79a20f\n--- /dev/null\n+++ b/contrib/examples/git-refinfo.sh\n@@ -0,0 +1,87 @@\n+#!/bin/sh\n+#\n+# git-refinfo: a ref-description mechanism\n+#\n+# git-refinfo maintains a mapping of refnames to descriptions;\n+# it stores the mapping as a version-controlled tree. Each\n+# path in the tree represents a ref name, and the contents of\n+# that path are the description.\n+#\n+# That means you can either use git-refinfo to set or examine\n+# ref descriptions, or you can simply \"git checkout refinfo\"\n+# and view and edit the files directly.\n+\n+REFINFO=refs/heads/refinfo\n+SUBDIRECTORY_OK=Yes\n+USAGE='\n+git-refinfo set [] \n+git-refinfo get [ ...]'\n+. git-sh-setup\n+\n+die_usage() {\n+\techo >&2 \"usage: $USAGE\"\n+\texit 1\n+}\n+\n+full_ref() {\n+\tgit show-ref \"$1\" | sed -e 's/^[^ ]* //' -e '1q'\n+}\n+\n+heads() {\n+\tgit show-ref --heads | sed 's/.*refs\\/heads\\///'\n+}\n+\n+do_get() {\n+\tref=`full_ref \"$1\"`\n+\tcase \"$ref\" in\n+\t'') desc= ;;\n+\t *) desc=`git cat-file blob \"$REFINFO:$ref\" 2>/dev/null` ;;\n+\tesac\n+\tprintf '%s\\t%s\\n' \"$1\" \"$desc\"\n+}\n+\n+do_set() {\n+\tref=`full_ref \"$1\"`\n+\tcase \"$ref\" in\n+\t'')\n+\t\tcase \"$1\" in\n+\t\trefs/*) ref=$1 ;;\n+\t\theads/*) ref=refs/$1 ;;\n+\t\t*) ref=refs/heads/* ;;\n+\t\tesac\n+\t\t;;\n+\tesac\n+\tGIT_INDEX_FILE=$GIT_DIR/refinfo-index; export GIT_INDEX_FILE\n+\trm -f $GIT_INDEX\n+\told=`git rev-parse --verify $REFINFO 2>/dev/null`\n+\tcase \"$old\" in\n+\t'') parents= ;;\n+\t *) parents=\"-p $old\"; git read-tree $REFINFO ;;\n+\tesac\n+\tblob=`printf '%s\\n' \"$2\" | git hash-object -w --stdin`\n+\tgit update-index --add --cacheinfo 0644 $blob \"$ref\"\n+\ttree=`git write-tree`\n+\tcommit=`echo \"update $1\" | git commit-tree $tree $parents`\n+\tgit update-ref -m refinfo $REFINFO $commit $old\n+}\n+\n+case \"$1\" in\n+set)\n+\tshift\n+\tcase \"$#\" in\n+\t1) do_set \"`git symbolic-ref HEAD`\" \"$1\" ;;\n+\t2) do_set \"$1\" \"$2\" ;;\n+\t*) die_usage ;;\n+\tesac\n+\t;;\n+get)\n+\tshift\n+\tcase \"$#\" in\n+\t0) for i in `heads`; do do_get \"$i\"; done ;;\n+\t*) for i in \"$@\"; do do_get \"$i\"; done ;;\n+\tesac\n+\t;;\n+*)\n+\tdie_usage\n+esac\n+exit 0\n-- \n1.5.5.63.g4e41c\n"},{"id":"74486","messageId":"7vod8awwvz.fsf@gitster.siamese.dyndns.org","threadId":"13125","inReplyTo":"20080415223716.GA1891@sigill.intra.peff.net","subject":"Re: branch description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-15T22:56:00Z","receivedAt":"2008-04-15T22:56:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Apr 15, 2008 at 03:19:30PM -0400, Jeff King wrote:\n>\n>> > Not complicated at all. Put that description in-tree in a known location\n>> > (say, \"help-branch\") in-tree and your propagation problem is solved.\n>> >\n>> > And have a scriptlet in $HOME/bin/git-help-branch to grep from that file.\n>> \n>> It is perhaps a little slow if you want to do things like adding the\n>> help text to branch name decorations in log output. Maybe instead of a\n>> flat file, you could parallel the ref name hierarchy in a tree? I.e.,\n>\n> It occurred to me that you actually meant \"just stick it in a file in\n> your actual work tree\", not on a separate branch (for some reason,\n> reading the name \"help-branch\" made me think you meant a ref).\n>\n> So that is obviously the very simple solution. But for fun, and because\n> maybe somebody could learn something, here is a script implementing my\n> approach. I dunno if it is worth including in contrib.\n\nAnother independent approach I was very tempted to suggest was to mimick\nhow \"What's cooking\" has been maintained over time (in other words, what I\ndescribe here is a toolset that has proven to be viable and useful, backed\nby the real world experience ;-).\n\nAll the tools I use for this are stored in my 'todo' branch, and I have a\ncheckout of the 'todo' branch in Meta/ subdirectory.\n\nThe core workhorse of this toolset is \"Meta/topic.perl\" script. It lists\ntopic branches, and shows the list of commits on each branch that are\nstill not integrated in the final integration branch. The script has a\nbuilt-in assumption of how the topic branches are named, and what\nintegration branches there are (namely, 'master', 'next' and 'pu'), but it\nshould not be too hard if somebody wants to generalize it to have more\nthan two \"still cooking\" stages and how they are named.\n\nThe' topic' script is called by \"Meta/WC\" script (obviously, that stands\nfor \"What's Cooking\") that applies a slight formatting of its output.\nThere isn't much to see in this intermediate script.\n\nWhen I send out a new edition of \"What's cooking\", I feed the previous\nedition of the message to \"Meta/UWC\" (\"Update What's Cooking\") script.\n\nThis script:\n\n - reads the old edition from its standard input, to remember the commits\n and explanatory text associated with each topic in the previous round;\n\n - reads from the \"Meta/WC\" output to learn the commits that currently\n reside in each topic;\n\n - compares the above two, insert new branches into \"[New topics]\"\n section, and mark the changed topics.\n\n - outputs the new edition to the standard output.\n\nThen I can add descriptions for new topics, edit them for the ones whose\nstatus have changed.\n\nI do not personally keep any temporary or in-tree copies, because I happen\nto do all the above in my MUA edit buffer. But if I wanted to, I could\nuse one in-tree file dedicated for it and track it as part of the\ncontents.\n"},{"id":"74506","messageId":"m3abjushvs.fsf@localhost.localdomain","threadId":"13125","inReplyTo":"7vej97x78v.fsf@gitster.siamese.dyndns.org","subject":"Re: branch description","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-04-16T01:33:48Z","receivedAt":"2008-04-16T01:33:48Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano writes:\n\n> Brian Gernhardt writes:\n> \n>> On Apr 15, 2008, at 1:31 PM, Russ Dill wrote:\n>>\n>>> The problem is that a branch is just a floating name for a line of\n>>> development. Its not really a \"thing\" in the repository like a tag or\n>>> a commit. You'd need to make some sort of special tag that describes\n>>> the branch or somesuch.\n>>\n>> No special tags needed. A simple file that I'll call .git/info/\n>> ref_names could be a set of lines that have \"\\t\",\n>> like the following:\n>>\n>> refs/heads/master\tCollection point for all my work\n>> refs/heads/ref_names\tAdd descriptions for branches\n>> refs/heads/segfault\tTrying to fix bug #12345\n[...]\n>> Now if you want to propagate these descriptions when you push and\n>> pull, things get a lot more complicated.\n> \n> Not complicated at all. Put that description in-tree in a known location\n> (say, \"help-branch\") in-tree and your propagation problem is solved.\n> \n> And have a scriptlet in $HOME/bin/git-help-branch to grep from that file.\n\nPlease, let's don't repeat Mercurial mistake of placing unversioned\ninformation (such as branch names in case of Mercurial, or branches\ndescriptions in this case) in-tree, i.e. version it. Think of what\nwould happen if you reset to the state (or checkout to some branch\nwith the state) which is before some branch was created, or before\nsome branch got description. Mercurial deals with this using\n\"special\" not lika in-tree treatment of such a file... I don't think\nit is a good idea.\n\nI think it wouldb be better to put branches descriptions somewhere\noutside object repository, be it .git/info/ref_names of .git/config.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"74518","messageId":"20080416025537.GA7878@sigill.intra.peff.net","threadId":"13125","inReplyTo":"m3abjushvs.fsf@localhost.localdomain","subject":"Re: branch description","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-16T02:55:37Z","receivedAt":"2008-04-16T02:55:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 15, 2008 at 06:33:48PM -0700, Jakub Narebski wrote:\n\n> Please, let's don't repeat Mercurial mistake of placing unversioned\n> information (such as branch names in case of Mercurial, or branches\n> descriptions in this case) in-tree, i.e. version it. Think of what\n> would happen if you reset to the state (or checkout to some branch\n> with the state) which is before some branch was created, or before\n> some branch got description. Mercurial deals with this using\n> \"special\" not lika in-tree treatment of such a file... I don't think\n> it is a good idea.\n\nI think that is a reasonable argument.\n\n> I think it wouldb be better to put branches descriptions somewhere\n> outside object repository, be it .git/info/ref_names of .git/config.\n\nBut you make a jump in logic here when you make the alternative to put\nit outside the object repository. Your first point argues against\nversioning meta-information _along with the rest of the state_, but\nthere's no reason it can't be versioned separately (e.g., in another\nbranch that just has such meta-info).\n\n-Peff\n"},{"id":"74501","messageId":"9b3e2dc20804152028s571ea2edm3cdbac7db57e6d8d@mail.gmail.com","threadId":"13125","inReplyTo":"m3abjushvs.fsf@localhost.localdomain","subject":"Re: branch description","fromName":"Stephen Sinclair","fromEmail":"radarsat1@gmail.com","sentAt":"2008-04-16T03:28:49Z","receivedAt":"2008-04-16T03:28:49Z","isPatch":false,"sender":{"key":"radarsat1@gmail.com","avatar":null},"body":"On Tue, Apr 15, 2008 at 9:33 PM, Jakub Narebski wrote:\n> (such as branch names in case of Mercurial, or branches\n> descriptions in this case)\n\nThis got me thinking...\nIt's a little crazy, but: since branch descriptions would essentially\njust be an extension of the branch name, play basically the same role\nand have the same requirements for storage, cloning, etc., what about\nusing some syntax in the branch name itself to separate a \"short name\"\nand a \"long name\"..\n\nThat is, you could store it as,\nrefs/heads/wip:work_in_progress\n\nand git-branch would report,\n\nwip\n\nwhile git-branch --long would report the long names,\n\nwip:work_in_progress\n\nor could parse it to something more legible:\n\nwip \"Work in progress\"\n\nOf course this would require modification to refspec-related code,\nwhich is likely more work than it's worth..\nHm, well just an idea anyways. Probably not a good idea to save\nmeta-data in a filename.\n\n\nSteve\n"},{"id":"74499","messageId":"1c5969370804152046h8d67630m697ca71b523b04d9@mail.gmail.com","threadId":"13125","inReplyTo":"m3abjushvs.fsf@localhost.localdomain","subject":"Re: branch description","fromName":"Matt Graham","fromEmail":"mdg149@gmail.com","sentAt":"2008-04-16T03:46:26Z","receivedAt":"2008-04-16T03:46:26Z","isPatch":false,"sender":{"key":"mdg149@gmail.com","avatar":"https://gravatar.com/avatar/a1f130a60a6550f75e8d7d3849e58e46494f36bfaf764a38cfd695ac85de8576?d=mp&s=160"},"body":"On Tue, Apr 15, 2008 at 9:33 PM, Jakub Narebski wrote:\n> Junio C Hamano writes:\n>\n> > Brian Gernhardt writes:\n> >\n> >> On Apr 15, 2008, at 1:31 PM, Russ Dill wrote:\n> >>\n> >>> The problem is that a branch is just a floating name for a line of\n> >>> development. Its not really a \"thing\" in the repository like a tag or\n> >>> a commit. You'd need to make some sort of special tag that describes\n> >>> the branch or somesuch.\n> >>\n> >> No special tags needed. A simple file that I'll call .git/info/\n> >> ref_names could be a set of lines that have \"\\t\",\n> >> like the following:\n> >>\n> >> refs/heads/master Collection point for all my work\n> >> refs/heads/ref_names Add descriptions for branches\n> >> refs/heads/segfault Trying to fix bug #12345\n> [...]\n>\n> >> Now if you want to propagate these descriptions when you push and\n> >> pull, things get a lot more complicated.\n> >\n> > Not complicated at all. Put that description in-tree in a known location\n> > (say, \"help-branch\") in-tree and your propagation problem is solved.\n> >\n> > And have a scriptlet in $HOME/bin/git-help-branch to grep from that file.\n>\n> Please, let's don't repeat Mercurial mistake of placing unversioned\n> information (such as branch names in case of Mercurial, or branches\n> descriptions in this case) in-tree, i.e. version it. Think of what\n> would happen if you reset to the state (or checkout to some branch\n> with the state) which is before some branch was created, or before\n> some branch got description. Mercurial deals with this using\n> \"special\" not lika in-tree treatment of such a file... I don't think\n> it is a good idea.\n>\n> I think it wouldb be better to put branches descriptions somewhere\n> outside object repository, be it .git/info/ref_names of .git/config.\n\nI agree that outside the object repository would be better.\nPropogating branch descriptions doesn't seem all that useful. I\nwouldn't usually expect to want a branch for the same purpose as the\nupstream repository and it would seem weird to get a default\ndescription of it coming along with the branch. Just like I give my\nbranches my own name, I would expect to have to give them my own\ndescription.\n"},{"id":"74524","messageId":"7vfxtmtlm0.fsf@gitster.siamese.dyndns.org","threadId":"13125","inReplyTo":"m3abjushvs.fsf@localhost.localdomain","subject":"Re: branch description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-16T05:27:51Z","receivedAt":"2008-04-16T05:27:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Please, let's don't repeat Mercurial mistake of placing unversioned\n> information (such as branch names in case of Mercurial, or branches\n> descriptions in this case) in-tree, i.e. version it.\n\nIs it really a \"mistake\" in Mercurial's context?\n\nI thought that their named branches do have defined \"starting point\", and\nit is not a mistake at all for them to version \"from this point on, this\nlineage of history is associated with this symbolic name (which is a\nbranch)\".\n\nIt probably does not make sense in the context of git where a branch is\ndefined to be \"illusion\" (at least currently).\n"},{"id":"74525","messageId":"20080416055508.GA28725@glandium.org","threadId":"13125","inReplyTo":"9b3e2dc20804152028s571ea2edm3cdbac7db57e6d8d@mail.gmail.com","subject":"Re: branch description","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-04-16T05:55:08Z","receivedAt":"2008-04-16T05:55:08Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Apr 15, 2008 at 11:28:49PM -0400, Stephen Sinclair wrote:\n> On Tue, Apr 15, 2008 at 9:33 PM, Jakub Narebski wrote:\n> > (such as branch names in case of Mercurial, or branches\n> > descriptions in this case)\n> \n> This got me thinking...\n> It's a little crazy, but: since branch descriptions would essentially\n> just be an extension of the branch name, play basically the same role\n> and have the same requirements for storage, cloning, etc., what about\n> using some syntax in the branch name itself to separate a \"short name\"\n> and a \"long name\"..\n> \n> That is, you could store it as,\n> refs/heads/wip:work_in_progress\n\nWhy not simply add the text after the sha1 in the refs/heads/branch_name\nfile ? Obviously current and older git code should be checked to know\nwhether they could cope with the extra data without failing...\n\nThis would also have the advantage that renaming the branch would not\nlose the description.\n\nMike\n"},{"id":"74531","messageId":"200804161029.18601.johan@herland.net","threadId":"13125","inReplyTo":"1c5969370804152046h8d67630m697ca71b523b04d9@mail.gmail.com","subject":"Re: branch description","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-04-16T08:29:18Z","receivedAt":"2008-04-16T08:29:18Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 16 April 2008, Matt Graham wrote:\n> On Tue, Apr 15, 2008 at 9:33 PM, Jakub Narebski wrote:\n> > I think it wouldb be better to put branches descriptions somewhere\n> > outside object repository, be it .git/info/ref_names of .git/config.\n> \n> I agree that outside the object repository would be better.\n> Propogating branch descriptions doesn't seem all that useful. I\n> wouldn't usually expect to want a branch for the same purpose as the\n> upstream repository and it would seem weird to get a default\n> description of it coming along with the branch. Just like I give my\n> branches my own name, I would expect to have to give them my own\n> description.\n\nOn the contrary, when I clone/pull from some repo, I would very much like to\nhave a copy of its branch description stored locally. Of course, these\ndescriptions should be renamed along with their corresponding branch upon\nentering my repo. To illustrate: Suppose I clone/pull \"refs/heads/foo\" from\na remote repo \"bob\". The branch will be stored as \"refs/remotes/bob/foo\" in\nmy repo. Now, if \"refs/heads/foo\" on \"bob\" has a branch description, I would\nlike to have that branch description copied into my repo, but referring to\n\"refs/remotes/bob/foo\" instead of \"refs/heads/foo\", of course.\n\nNow, when it comes to my own local branches, I agree with you: If I make a\nnew local branch \"refs/heads/foo\" that tracks \"refs/remotes/bob/foo\", I will\nprobably not want git to copy the branch description automatically.\n\nHowever, I do agree that putting branch description inside the working tree\nis not the right solution. So far, the best proposal I've seen, is Hommey's\nsuggestion of storing the description after the sha1 in the ref file itself.\nOf course, git would have to be taught (a) to handle ref files with\ndescriptions, and (b) to propagate descriptions along with refs.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"74586","messageId":"200804162156.27435.jnareb@gmail.com","threadId":"13125","inReplyTo":"7vfxtmtlm0.fsf@gitster.siamese.dyndns.org","subject":"Re: branch description","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-04-16T19:56:26Z","receivedAt":"2008-04-16T19:56:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 16 April 2008, Junio C Hamano wrote:\n> Jakub Narebski writes:\n> \n> > Please, let's don't repeat Mercurial mistake of placing unversioned\n> > information (such as branch names in case of Mercurial, or branches\n> > descriptions in this case) in-tree, i.e. version it.\n\nI'm sorry, I meant here \"tags\" not \"branch names\"... I think...\n\n> Is it really a \"mistake\" in Mercurial's context?\n\nIf we are talking about tags support in Mercurial, I think it is\nmistake or at least bad design decision. Tags are, and should be,\nunversioned (or at least versioned separately) but propagated (or\nrather propagatable). Mercurial offers either in-tree .hgtags,\nwhich are always automatically propagated (not merely propagatable);\nbut this mechanism is by default versioned, and Mercurial does\ncomplicated dance to get reasonable tags semantic. And there is\n[theoretical] problem of merging .hgtags file; perhaps solved by\nspecialized merge strategy for this file.\n\nAlternatively Mercurial offers so called local tags, which are not\nversioned, but not propagated (and AFAIK non propagatable).\n\nSo yes, it is a bad design in my opinion.\n\n> I thought that their named branches do have defined \"starting point\", and\n> it is not a mistake at all for them to version \"from this point on, this\n> lineage of history is associated with this symbolic name (which is a\n> branch)\".\n\nWhat happens if there is branching point _after_ such \"branch naming tag\"?\nUnless branch names are purely local and non-propagatable, and Mercurial\ncan use local revision numbers or something like this...\n\nI find this CVS legacy to branching (doesn't Subversion use also\nsomething like that) to be stupid.\n\n> It probably does not make sense in the context of git where a branch is\n> defined to be \"illusion\" (at least currently).\n\nBTW. another tool that has yet another idea of what \"branch\" is\nis Monotone, which AFAIK understands branch in reflog sense, via\nMonotone's signature signatures ;-)\n\nP.S. Cc-ed mercurial mailing list, to give them chance to respond\nto those \"accusations\"... if it is not subscribe only...\n-- \nJakub Narebski\nPoland\n"},{"id":"74721","messageId":"200804182358.31041.jnareb@gmail.com","threadId":"13125","inReplyTo":"200804161029.18601.johan@herland.net","subject":"Re: branch description","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-04-18T21:58:30Z","receivedAt":"2008-04-18T21:58:30Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 16 April 2008, Johan Herland wrote:\n\n[cut that being able to propagate description of branches is a good idea]\n\n> However, I do agree that putting branch description inside the working tree\n> is not the right solution. So far, the best proposal I've seen, is Hommey's\n> suggestion of storing the description after the sha1 in the ref file itself.\n> Of course, git would have to be taught (a) to handle ref files with\n> descriptions, and (b) to propagate descriptions along with refs.\n\n(c) find a place for branch descriptions in packed refs.\n\n\nLet me sum up here proposals where to put branch description:\n1. Put them in branch..description in repository config. Not easily\n (automatically) propagated for dumb transports.\n2. Put them in-tree, which is a bad idea because branches are\n un-versioned (or versioned separately), so branches description\n should also be un-versioned.\n3. Put them in GIT_DIR/info/refs_description, in some format. It makes\n it very easy to add support for propagation for dumb transports.\n Native transport probably would need some extension. Should not\n interfere with the rest of git code.\n4. Store description after sha1 in the ref file itself. Automatic\n propagation for dumb transport (whether we want it or not). Native\n transport as above. Very high probabily of interfering with the rest\n of code, especially shell part of Git. Need to find a place for\n descriptions in pack-refs.\n5. Store them as value of 'refs/heads/' file in a tree for\n a commit for a special '' separate special branch; at least\n if I understand this proposal correctly. Something like IIRC the\n 'notes' / 'annotations' idea was implemented (on git mailing list;\n it never got into mainline).\n\n\nI think that the best proposal is (3), not (4) as you say.\n-- \nJakub Narebski\nPoland\n"},{"id":"74748","messageId":"200804191118.50105.johan@herland.net","threadId":"13125","inReplyTo":"200804182358.31041.jnareb@gmail.com","subject":"Re: branch description","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-04-19T09:18:49Z","receivedAt":"2008-04-19T09:18:49Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Friday 18 April 2008, Jakub Narebski wrote:\n> On Wed, 16 April 2008, Johan Herland wrote:\n> > So far, the best proposal I've seen, is Hommey's suggestion of storing\n> > the description after the sha1 in the ref file itself. \n> > Of course, git would have to be taught (a) to handle ref files with\n> > descriptions, and (b) to propagate descriptions along with refs.\n> \n> (c) find a place for branch descriptions in packed refs.\n\nThis shouldn't be too hard. Today, we already have one kind of \"special\"\nlines in the packed-refs format: \"peeled\", which uses lines starting with\n\"^\". I think we could add another special kind of line called \"description\"\nwhich uses lines starting with \"#\". Multiline descriptions (if we want to\nsupport such) would just have \"#\" prepended to each line, and the parser\nwould associate all \"#\"-lines with the most recently parsed ref (like it\ndoes for the \"^\"-line today).\n\n> Let me sum up here proposals where to put branch description:\n> 1. Put them in branch..description in repository config. Not easily\n> (automatically) propagated for dumb transports.\n> 2. Put them in-tree, which is a bad idea because branches are\n> un-versioned (or versioned separately), so branches description\n> should also be un-versioned.\n> 3. Put them in GIT_DIR/info/refs_description, in some format. It makes\n> it very easy to add support for propagation for dumb transports.\n> Native transport probably would need some extension. Should not\n> interfere with the rest of git code.\n> 4. Store description after sha1 in the ref file itself. Automatic\n> propagation for dumb transport (whether we want it or not). Native\n> transport as above. Very high probabily of interfering with the rest\n> of code, especially shell part of Git. Need to find a place for\n> descriptions in pack-refs.\n> 5. Store them as value of 'refs/heads/' file in a tree for\n> a commit for a special '' separate special branch; at\n> least if I understand this proposal correctly. Something like IIRC\n> the 'notes' / 'annotations' idea was implemented (on git mailing list;\n> it never got into mainline).\n> \n> \n> I think that the best proposal is (3), not (4) as you say.\n\nThe problem with (3) vs. (4) is that in (3) we must make sure that whenever\na branch is moved/renamed (e.g. \"git clone\", \"git branch -m\", probably more\nas well), the corresponding description is moved/renamed as well. This is\nelegantly solved in (4). But as you say, (4) may have implementation\ndifficulties of its own. I guess the first acceptable implementation will\nwin.\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"74759","messageId":"7v1w51g2q5.fsf@gitster.siamese.dyndns.org","threadId":"13125","inReplyTo":"200804191118.50105.johan@herland.net","subject":"Re: branch description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-19T17:43:14Z","receivedAt":"2008-04-19T17:43:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> The problem with (3) vs. (4) is that in (3) we must make sure that whenever\n> a branch is moved/renamed (e.g. \"git clone\", \"git branch -m\", probably more\n> as well), the corresponding description is moved/renamed as well. This is\n> elegantly solved in (4).\n\nIf your \"elegently solved\" is coming from an assumption that it is enough\nfor \"git mv\" (for example) to just copy whatever is in .git/refs/heads/foo\nto .git/refs/heads/bar without understanding what is contained in it, that\nassumption unfortunately does not hold.\n\nYou must support packed refs, so you need to teach the refs infrastructure\nwhat per-branch attributes there are other than the commit object name it\npoints at anyway.\n\nAnd we already do -- when you do \"branch -m foo bar\", corresponding config\nentries are also renamed. We also move reflogs.\n\nA possible approach that would work, which contains elements from (4), is\nto change implementations of loose ref to have this extra info in loose\nref files (that is what (4) is), *and* introduce another separate\nmechanism to store corresponding information for packed refs elsewhere.\nPropagation needs to deal with both representations, renaming needs to\ndeal with both representations, looking up needs to deal with both\nrepresentations, everybody needs to deal with both representations.\n\nIf you are going to invent \"another separate mechanism\" to support packed\nrefs anyway, why not use that same mechanism to record information for\nloose ones as well? That is the approach suggested by (3). In either way\nwe need to teach relevant parts of the code for propagation, renaming,\nlooking up etc about the new mechanism.\n"},{"id":"74762","messageId":"200804192009.36243.johan@herland.net","threadId":"13125","inReplyTo":"7v1w51g2q5.fsf@gitster.siamese.dyndns.org","subject":"Re: branch description","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-04-19T18:09:36Z","receivedAt":"2008-04-19T18:09:36Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Saturday 19 April 2008, Junio C Hamano wrote:\n> Johan Herland writes:\n> \n> > The problem with (3) vs. (4) is that in (3) we must make sure that whenever\n> > a branch is moved/renamed (e.g. \"git clone\", \"git branch -m\", probably more\n> > as well), the corresponding description is moved/renamed as well. This is\n> > elegantly solved in (4).\n> \n> If your \"elegently solved\" is coming from an assumption that it is enough\n> for \"git mv\" (for example) to just copy whatever is in .git/refs/heads/foo\n> to .git/refs/heads/bar without understanding what is contained in it, that\n> assumption unfortunately does not hold.\n> \n> You must support packed refs, so you need to teach the refs infrastructure\n> what per-branch attributes there are other than the commit object name it\n> points at anyway.\n> \n> And we already do -- when you do \"branch -m foo bar\", corresponding config\n> entries are also renamed. We also move reflogs.\n> \n> A possible approach that would work, which contains elements from (4), is\n> to change implementations of loose ref to have this extra info in loose\n> ref files (that is what (4) is), *and* introduce another separate\n> mechanism to store corresponding information for packed refs elsewhere.\n> Propagation needs to deal with both representations, renaming needs to\n> deal with both representations, looking up needs to deal with both\n> representations, everybody needs to deal with both representations.\n> \n> If you are going to invent \"another separate mechanism\" to support packed\n> refs anyway, why not use that same mechanism to record information for\n> loose ones as well? That is the approach suggested by (3). In either way\n> we need to teach relevant parts of the code for propagation, renaming,\n> looking up etc about the new mechanism.\n\nYou're right. Also, after thinking some more about this, it occured to me\nthat most code paths will probably _not_ be interested in branch\ndescriptions at all. It therefore makes sense to keep the descriptions away\nfrom the refs themselves, so that they don't impact performance.\n\nSo #3 (keeping descriptions in $GIT_DIR/info/refs_description) is probably\nthe best solution.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"74767","messageId":"200804192305.36780.jnareb@gmail.com","threadId":"13125","inReplyTo":"200804191118.50105.johan@herland.net","subject":"Re: branch description","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-04-19T21:05:35Z","receivedAt":"2008-04-19T21:05:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 19 April 2008, Johan Herland wrote:\n> On Friday 18 April 2008, Jakub Narebski wrote:\n\n>> Let me sum up here proposals where to put branch description:\n[...]\n>> 3. Put them in GIT_DIR/info/refs_description, in some format. It makes\n>> it very easy to add support for propagation for dumb transports.\n>> Native transport probably would need some extension. Should not\n>> interfere with the rest of git code.\n>> 4. Store description after sha1 in the ref file itself. Automatic\n>> propagation for dumb transport (whether we want it or not). Native\n>> transport as above. Very high probabily of interfering with the rest\n>> of code, especially shell part of Git. Need to find a place for\n>> descriptions in pack-refs.\n[...]\n>> \n>> I think that the best proposal is (3), not (4) as you say.\n> \n> The problem with (3) vs. (4) is that in (3) we must make sure that whenever\n> a branch is moved/renamed (e.g. \"git clone\", \"git branch -m\", probably more\n> as well), the corresponding description is moved/renamed as well. This is\n> elegantly solved in (4). But as you say, (4) may have implementation\n> difficulties of its own. I guess the first acceptable implementation will\n> win.\n\nFirst, git already has move corresponding reflog and per-branch\nconfiguration when renaming a branch, so it is nothing new for (3).\n\nSecond, implementation difficulties of (4) might be made stronger by\nthe fact that repository with branches with descriptions should be\nfetchable and clonable using both native and dumb protocols by older\nversions of git, and shouldn't cause troubles after fetching. (Assume\nthat git is new enough to understand packed refs). Backward\ncompatibility might kill this solution; but it might not.\n\nBTW. I have added line with description to loose ref, and a few\ncommands I tried didn't return (cause) any errors... so...\n-- \nJakub Narebski\nPoland\n"}]}