{"thread":{"id":"2629","subject":"[RFC 1/2] Use remote information in .git/config","startedAt":"2005-11-21T13:54:52Z","lastAt":"2005-11-27T12:52:56Z","messageCount":8,"participants":["Johannes Schindelin","Junio C Hamano","Ben Clifford","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"12431","messageId":"Pine.LNX.4.63.0511211452470.13775@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2629","inReplyTo":null,"subject":"[RFC 1/2] Use remote information in .git/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-21T13:54:52Z","receivedAt":"2005-11-21T13:54:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nThis patch allows to store shortcuts for fetch/pull into the config:\n\n\t[remote.junio]\n\t\turl = http://www.kernel.org/pub/scm/git/git.git\n\t\tpull = master:junio\n\t\tpull = todo:todo\n\t\tpull = +pu:pu\n\nNote that there is only one pair per \"pull\" line, to allow for spaces\n(urgh!) in the branch names.\n\nSigned-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n\n---\n\n\tThe different pull/push lines are identified by their branch name. \n\tSo, to update the pull line for \"todo\" to force fast forward, do\n\n\t\tgit-config-set remote.junio.pull +todo:todo '^todo:'\n\n git-parse-remote.sh |   10 ++++++++++\n 1 files changed, 10 insertions(+), 0 deletions(-)\n\napplies-to: 25c461c5c50b9d8c6cd836ca6a9df12f03f29621\nb0542d077b7bf6ee8b45854e47dcba73170c1e9a\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\nindex aea7b0e..cd976da 100755\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -22,6 +22,9 @@ get_data_source () {\n \t\telif test -f \"$GIT_DIR/branches/$1\"\n \t\tthen\n \t\t\techo branches\n+\t\telif test \"$(git-config-set --get remote.$1.url)\"\n+\t\tthen\n+\t\t\techo config\n \t\telse\n \t\t\techo ''\n \t\tfi ;;\n@@ -46,6 +49,9 @@ get_remote_url () {\n \t\turl=$(sed -e 's/#.*//' \"$GIT_DIR/branches/$token\")\n \t\techo \"$url/$remainder\"\n \t\t;;\n+\tconfig)\n+\t\tgit-config-set --get remote.$1.url\n+\t\t;;\n \t*)\n \t\tdie \"internal error: get-remote-url $1\" ;;\n \tesac\n@@ -60,6 +66,8 @@ get_remote_default_refs_for_push () {\n \t\tsed -ne '/^Push: */{\n \t\t\ts///p\n \t\t}' \"$GIT_DIR/remotes/$1\" ;;\n+\tconfig)\n+\t\tgit-config-set --get-all remote.$1.push ;;\n \t*)\n \t\tdie \"internal error: get-remote-default-ref-for-push $1\" ;;\n \tesac\n@@ -124,6 +132,8 @@ get_remote_default_refs_for_fetch () {\n \t\t\t\t\t\ts///p\n \t\t\t\t\t}' \"$GIT_DIR/remotes/$1\")\n \t\t;;\n+\tconfig)\n+\t\tgit-config-set --get-all remote.$1.pull ;;\n \t*)\n \t\tdie \"internal error: get-remote-default-ref-for-push $1\" ;;\n \tesac\n---\n0.99.9.GIT\n"},{"id":"12462","messageId":"7v4q65sst3.fsf@assigned-by-dhcp.cox.net","threadId":"2629","inReplyTo":"Pine.LNX.4.63.0511211452470.13775@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC 1/2] Use remote information in .git/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-21T19:29:44Z","receivedAt":"2005-11-21T19:29:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> This patch allows to store shortcuts for fetch/pull into the config:\n>\n> \t[remote.junio]\n> \t\turl = http://www.kernel.org/pub/scm/git/git.git\n> \t\tpull = master:junio\n> \t\tpull = todo:todo\n> \t\tpull = +pu:pu\n>\n> Note that there is only one pair per \"pull\" line, to allow for spaces\n> (urgh!) in the branch names.\n\nI think \"allow for spaces\" nonsense can be removed by now.  I\ndid it initially that way before making the ref name validation\ntighter with check-ref-format.  And if I understand what you\nwrote about multivalues correctly, your intent is that \"orders\ndo not matter\"; with pull refspecs, orders do matter, so it\nprobably is a good idea to allow only a single line.\n\nPersonally I do not mind moving remotes/branches information\nthere, except that I suspect the git-config-set interface makes\nit cumbersome to (1) find out what remotes I defined (i.e. an\nequivalent of \"ls .git/remotes\") and (2) remove a single remote\nwhen I do not want it anymore (--unset-all would remove the keys\nbut would leave the empty section).\n\nI am unsure if putting everything in .git/config file is the\nright approach, though.  What will we put there next?  ls-files\nignore patterns?  grafts?  alternates?  We should be able to\neven get rid of .git/refs directory hierarchy and replace that\nwith something like this:\n\n\t[refs]\n        \thead = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234\tfor master\n        \thead = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234\tfor pu\n\t\ttag = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234 for v1.0rc1\n\t...\n\nWhere will we stop, and why?\n\nI am worried about people later asking \"why do we have X in\nconfig but not Y\"?\n"},{"id":"12467","messageId":"Pine.LNX.4.63.0511212109440.4213@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2629","inReplyTo":"7v4q65sst3.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC 1/2] Use remote information in .git/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-21T20:24:44Z","receivedAt":"2005-11-21T20:24:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 21 Nov 2005, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > Note that there is only one pair per \"pull\" line, to allow for spaces\n> > (urgh!) in the branch names.\n> \n> I think \"allow for spaces\" nonsense can be removed by now.  I\n> did it initially that way before making the ref name validation\n> tighter with check-ref-format.  And if I understand what you\n> wrote about multivalues correctly, your intent is that \"orders\n> do not matter\"; with pull refspecs, orders do matter, so it\n> probably is a good idea to allow only a single line.\n\nOkay. (I also wondered how git-config-set could be used to replace the \nfirst pair, which is what gets merged when pulling).\n\n> Personally I do not mind moving remotes/branches information\n> there, except that I suspect the git-config-set interface makes\n> it cumbersome to (1) find out what remotes I defined (i.e. an\n> equivalent of \"ls .git/remotes\") and (2) remove a single remote\n> when I do not want it anymore (--unset-all would remove the keys\n> but would leave the empty section).\n\n(1) git-var -l | grep '^remote\\.'\n\n(2) I would add --remove-section for that. (Though I'll wait to implement \nthat until I know if people want it.)\n\n> I am unsure if putting everything in .git/config file is the\n> right approach, though.  What will we put there next?  ls-files\n> ignore patterns?  grafts?  alternates?  We should be able to\n> even get rid of .git/refs directory hierarchy and replace that\n> with something like this:\n> \n> \t[refs]\n>         \thead = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234\tfor master\n>         \thead = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234\tfor pu\n> \t\ttag = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234 for v1.0rc1\n> \t...\n> \n> Where will we stop, and why?\n\nAhh! I have a clear picture of what *I* would put into it: all interesting \nstatic data about that particular repository which I would not like to \nversion.\n\nFor that matter, .gitignore would stay where it is, though I'd also like \nto version grafts, i.e. move the location from .git/info/grafts to \n.gitgrafts (which would effectively end another thread on this list).\n\nI would not like to version refs, evidently, or alternates. But the refs \nwould not be static (they *want* to change often), while the alterates \nwould be.\n\nBut I will not be a bugger about it. If things stay where they are \n(including .git/remotes), I will not be sad. There was just this crazy \nidea in my head (not the tip of the development branch, but the object my \neyes are in), and I wanted to discuss it with you guys, just in case...\n\nCiao,\nDscho\n"},{"id":"12493","messageId":"7vhda5lf4t.fsf@assigned-by-dhcp.cox.net","threadId":"2629","inReplyTo":"Pine.LNX.4.63.0511212109440.4213@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC 1/2] Use remote information in .git/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-22T00:06:58Z","receivedAt":"2005-11-22T00:06:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> I am unsure if putting everything in .git/config file is the\n>> right approach, though.  What will we put there next?  ls-files\n>> ignore patterns?  grafts?  alternates?  We should be able to\n>> even get rid of .git/refs directory hierarchy and replace that\n>> with something like this:\n>> ...\n>> Where will we stop, and why?\n>\n> Ahh! I have a clear picture of what *I* would put into it: all interesting \n> static data about that particular repository which I would not like to \n> version.\n\nThere are certain things that _might_ benefit from the third\nkind we currently do not support: developer opt-in.\n\nCurrently, .gitignore and friends (what you call versioned) are\nproject-wide.  Anybody who follows git.git uses _the_ .gitignore\nthat is from the respository, although they can override with\ntheir own .git/info/exclude, which might be a good candidate for\n\"core.gitignore = ...\".  But certain people might want to share\ntheir forked .gitignore without going through hassles to\nintegrate that to project-wide copy.  \".gitignore\" might be a\nbad example, and grafts may be better.  People interested in\nLinux archaeology might want to share grafts to let them go back\nfrom tip of 2.6 all the way down to 2.4.0 (or before) while\nmajority of users do not share that interest.\n\nObviously, user.name is private to you, but you would still want\nto use the same across your repositories.\n\nOnce we start thinking about allowing the template mechansim to\ngive default \"config\" information to newly created repositories,\nhaving everything in one file may make things a bit awkward to\nhandle.  When you managed to make your colleage interested in\ngit development, you can let her copy your remotes/junio.  Once\nyou moved remotes/ to .git/config file, while you would not want\nher to use copy of your .git/config verbatim without updating at\nleast user.name, you would want to have her use other pieces in\nthe .git/config, including [remote.jnio] bits.\n\nThe following comments are not about your patch but I am having\na feeling that we ended up having too much flexibility.  It may\nnot necessarily be a bad thing when we view git as pure\nplumbing, but it makes things confusing to have too many \"you\ncould do it this way if you want to gain XXX, as long as you are\ncareful about YYY\".\n\nFor example, we do not define how checked-out tree, repository\nand object database _should_ work together.  The officially\nrecommended way is to have one object database at .git/objects/,\npossibly borrowing from somebody via objects/info/alternates,\nwhich hangs under one repository (.git), and the repository can\nhave one checked-out tree associated with it.\n\nHowever, it is possible to symlink .git/objects to somewhere\nelse, to share an object database between two repositories, as\nlong as you are careful when pruning (you can lose objects the\nrefs in other repository points at but you do not).\n\nEven worse (or better), you could symlink everything except the\nHEAD and index file to somewhere else to have one repository\nwith multiple checked-out trees (I believe Daniel does this), as\nlong as you are careful when pulling/fetching (fetching into a\nbranch that another working tree has checked out will move the\nhead commit there without updating the index).\n\nAnother example is the assumption we place on completeness of\nthe refs.  We pretty much declares that if there are some\nobjects you cannot reach starting from your refs, your\nrepository is corrupt (incomplete). But such an incomplete\nrepository can be useful in certain situations, and some things\nwork properly but not others.  I think using commit-walkers\nwithout -a option can easily create such an incomplete\nrepository.\n\nThe recent \"should commit be always utf-8\" thread probably falls\ninto this category.  We all know things should be in utf-8, but\nother things are possible as long as people understand\nboundaries.\n\nMost of the time, what we recommend are the BCP, but\nknowledgeable users can deviate from that, to gain some\nadvantage (e.g. reduced disk space using an incomplete\nrepository, convenience of having more than one checked-out\ntrees at the same time, not having to migrate to all UTF-8\nsystem) over the BCP if they are willing to sacrifice something\nelse or their use pattern is not affected negatively by what\nthey are losing (e.g. can live without an access to ancient\nhistory, be very careful when pruning and fetching, do not have\npeople whose names cannot be spelled in KOI-8).\n"},{"id":"12502","messageId":"Pine.LNX.4.63.0511220139120.6187@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2629","inReplyTo":"7vhda5lf4t.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC 1/2] Use remote information in .git/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-22T00:49:33Z","receivedAt":"2005-11-22T00:49:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 21 Nov 2005, Junio C Hamano wrote:\n\n> Once we start thinking about allowing the template mechansim to\n> give default \"config\" information to newly created repositories,\n> having everything in one file may make things a bit awkward to\n> handle.  When you managed to make your colleage interested in\n> git development, you can let her copy your remotes/junio.  Once\n> you moved remotes/ to .git/config file, while you would not want\n> her to use copy of your .git/config verbatim without updating at\n> least user.name, you would want to have her use other pieces in\n> the .git/config, including [remote.jnio] bits.\n\nWell, obviously I would patch git-fetch/-pull/-push to have an option \n(\"--store\") to store the current parameters under a certain nick name in \nthe config ;-)\n\nOr add a little option (which is easy) to generate commands which can be \npiped into a little script (think \"xmodmap -pke\").\n\n> The following comments are not about your patch but I am having\n> a feeling that we ended up having too much flexibility.  It may\n> not necessarily be a bad thing when we view git as pure\n> plumbing, but it makes things confusing to have too many \"you\n> could do it this way if you want to gain XXX, as long as you are\n> careful about YYY\".\n\nI wouldn't be so sad about the flexibility. It is an open source project, \nand the strength therein lies in many people having many (yes, even \nstupid) ideas, and trying to get them in. In the long run, the dumb ideas \nare thrown out, but what remains is a collection of gems.\n\nSo, it might be confusing for a noobee, but that's what we have \nDocumentation/tutorial for.\n\n> Most of the time, what we recommend are the BCP, but\n> knowledgeable users can deviate from that, to gain some\n> advantage (e.g. reduced disk space using an incomplete\n> repository, convenience of having more than one checked-out\n> trees at the same time, not having to migrate to all UTF-8\n> system) over the BCP if they are willing to sacrifice something\n> else or their use pattern is not affected negatively by what\n> they are losing (e.g. can live without an access to ancient\n> history, be very careful when pruning and fetching, do not have\n> people whose names cannot be spelled in KOI-8).\n\n'xactly. For example, I can do\n\n\tln -s .gitgrafts .git/info/grafts\n\nand have the effect that Linus just called \"nasty\". Point is, if I choose \nto do so, I can. Easily.\n\nCiao,\nDscho\n"},{"id":"12712","messageId":"41D1FCC0-E031-48FB-82A2-6CFDA2E03AC0@hawaga.org.uk","threadId":"2629","inReplyTo":"7v4q65sst3.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC 1/2] Use remote information in .git/config","fromName":"Ben Clifford","fromEmail":"benc@hawaga.org.uk","sentAt":"2005-11-24T22:33:56Z","receivedAt":"2005-11-24T22:33:56Z","isPatch":false,"sender":{"key":"benc@hawaga.org.uk","avatar":"https://gravatar.com/avatar/c7ce083471287f8e77b69dd147f757799d1efdd740727fd7e3003f33e88be898?d=mp&s=160"},"body":"\nOn 22 Nov 2005, at 05:29, Junio C Hamano wrote:\n\n>\n> Personally I do not mind moving remotes/branches information\n> there, except that I suspect the git-config-set interface makes\n> it cumbersome to (1) find out what remotes I defined (i.e. an\n> equivalent of \"ls .git/remotes\")\n\n(1) is useful to be able to do in a very lightweight way when doing  \ntab completion on remotes. Having heads, tags, remotes in nicely  \nnamed separate files makes that pretty straightforward; I don't know  \nif using a git-config- accessor would make this noticeably worse,  \nthough, as I haven't tried anything out there yet.\n\n-- \nBen • ベン • Бэн • 벤 • 班明\nhttp://www.hawaga.org.uk/ben/\nMy email is high latency but best way to contact me. Alternatively,  \nSMS number(s) at above URL.\n"},{"id":"12713","messageId":"Pine.LNX.4.63.0511250208110.28437@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2629","inReplyTo":"41D1FCC0-E031-48FB-82A2-6CFDA2E03AC0@hawaga.org.uk","subject":"Re: [RFC 1/2] Use remote information in .git/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-25T01:08:46Z","receivedAt":"2005-11-25T01:08:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 25 Nov 2005, Ben Clifford wrote:\n\n> On 22 Nov 2005, at 05:29, Junio C Hamano wrote:\n> \n> > Personally I do not mind moving remotes/branches information\n> > there, except that I suspect the git-config-set interface makes\n> > it cumbersome to (1) find out what remotes I defined (i.e. an\n> > equivalent of \"ls .git/remotes\")\n> \n> (1) is useful to be able to do in a very lightweight way when doing tab\n> completion on remotes. Having heads, tags, remotes in nicely named separate\n> files makes that pretty straightforward; I don't know if using a git-config-\n> accessor would make this noticeably worse, though, as I haven't tried anything\n> out there yet.\n\n\t git-var -l | sed -n \"s/^remote\\.\\([A-Za-z0-9]*\\)\\.url=.*$/\\1/p\"\n\nHth,\nDscho\n"},{"id":"12793","messageId":"20051127125256.GC22159@pasky.or.cz","threadId":"2629","inReplyTo":"Pine.LNX.4.63.0511250208110.28437@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC 1/2] Use remote information in .git/config","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-27T12:52:56Z","receivedAt":"2005-11-27T12:52:56Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Nov 25, 2005 at 02:08:46AM CET, I got a letter\nwhere Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...\n> On Fri, 25 Nov 2005, Ben Clifford wrote:\n> \n> > On 22 Nov 2005, at 05:29, Junio C Hamano wrote:\n> > \n> > > Personally I do not mind moving remotes/branches information\n> > > there, except that I suspect the git-config-set interface makes\n> > > it cumbersome to (1) find out what remotes I defined (i.e. an\n> > > equivalent of \"ls .git/remotes\")\n> > \n> > (1) is useful to be able to do in a very lightweight way when doing tab\n> > completion on remotes. Having heads, tags, remotes in nicely named separate\n> > files makes that pretty straightforward; I don't know if using a git-config-\n> > accessor would make this noticeably worse, though, as I haven't tried anything\n> > out there yet.\n> \n> \t git-var -l | sed -n \"s/^remote\\.\\([A-Za-z0-9]*\\)\\.url=.*$/\\1/p\"\n\nAll right, I've asked about this functionality in the other thread, and\nsomething like this seems to cut it (although I would just /\\([^.=]*\\)/\ninstead of restricting the remote name).\n\nHowever, it's a nice example of horrible interface. And confusing one\nat it, too.\n\nWhy git-var -l?! That makes no sense to me. git-var's function is to\n\"print the git users identity\" (no matter that it is grammatically\nwrong, that's what the synopsis says). This is something totally else,\nand I can't see what bussiness does this have in the git-var command.\nThis should belong into git-repo-config, which manages the rest of the\nconfig-related stuff.\n\nC'mon people, git's interface is inconsistent enough as it is now,\nno need to make it even worse. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"}]}