{"thread":{"id":"21435","subject":"[PATCH] Don't create the $GIT_DIR/branches directory on init","startedAt":"2009-10-30T17:20:28Z","lastAt":"2009-10-31T19:32:40Z","messageCount":8,"participants":["Robin Rosenberg","Junio C Hamano","Thomas Rast","Shawn O. Pearce"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"126396","messageId":"1256923228-18949-1-git-send-email-robin.rosenberg@dewire.com","threadId":"21435","inReplyTo":null,"subject":"[PATCH] Don't create the $GIT_DIR/branches directory on init","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2009-10-30T17:20:28Z","receivedAt":"2009-10-30T17:20:28Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Git itself does not even look at this directory. Any tools that\nactually needs it should create it itself.\n\nSigned-off-by: Robin Rosenberg \n---\n templates/branches-- | 1 -\n 1 files changed, 0 insertions(+), 1 deletions(-)\n delete mode 100644 templates/branches--\n\nShawn and other wants to stop JGit from creating this directory on\ninit with the motivation that newer Git version doesn't create it\nanymore. This patch would make that assertion true.\n\n-- robin\n\ndiff --git a/templates/branches-- b/templates/branches--\ndeleted file mode 100644\nindex fae8870..0000000\n--- a/templates/branches--\n+++ /dev/null\n@@ -1 +0,0 @@\n-: this is just to ensure the directory exists.\n-- \n1.6.5.2.102.g1f8896\n"},{"id":"126434","messageId":"7vhbtgk1k4.fsf@alter.siamese.dyndns.org","threadId":"21435","inReplyTo":"1256923228-18949-1-git-send-email-robin.rosenberg@dewire.com","subject":"Re: [PATCH] Don't create the $GIT_DIR/branches directory on init","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-30T21:35:23Z","receivedAt":"2009-10-30T21:35:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robin Rosenberg writes:\n\n> Git itself does not even look at this directory. Any tools that\n> actually needs it should create it itself.\n>\n> Signed-off-by: Robin Rosenberg \n> ---\n> templates/branches-- | 1 -\n> 1 files changed, 0 insertions(+), 1 deletions(-)\n> delete mode 100644 templates/branches--\n>\n> Shawn and other wants to stop JGit from creating this directory on\n> init with the motivation that newer Git version doesn't create it\n> anymore. This patch would make that assertion true.\n\nCogito now seems really dead ;-).\n\nUnless somebody complains I am Ok to queue this for 1.6.6.\n\n>\n> -- robin\n>\n> diff --git a/templates/branches-- b/templates/branches--\n> deleted file mode 100644\n> index fae8870..0000000\n> --- a/templates/branches--\n> +++ /dev/null\n> @@ -1 +0,0 @@\n> -: this is just to ensure the directory exists.\n> -- \n> 1.6.5.2.102.g1f8896\n"},{"id":"126517","messageId":"200910311011.31189.trast@student.ethz.ch","threadId":"21435","inReplyTo":"1256923228-18949-1-git-send-email-robin.rosenberg@dewire.com","subject":"Re: [PATCH] Don't create the $GIT_DIR/branches directory on init","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-31T09:11:29Z","receivedAt":"2009-10-31T09:11:29Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Robin Rosenberg wrote:\n> Git itself does not even look at this directory.\n\nThis contradicts the git-fetch manpage though: from urls-remotes.txt,\nit includes\n\n The name of one of the following can be used instead\n of a URL as `` argument:\n\n * a remote in the git configuration file: `$GIT_DIR/config`,\n * a file in the `$GIT_DIR/remotes` directory, or\n * a file in the `$GIT_DIR/branches` directory.\n\n(and a longer explanation of what they need to look like).\n\nSo which one is wrong?\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"126525","messageId":"200910311902.48317.robin.rosenberg@dewire.com","threadId":"21435","inReplyTo":"200910311011.31189.trast@student.ethz.ch","subject":"Re: [PATCH] Don't create the $GIT_DIR/branches directory on init","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2009-10-31T18:02:47Z","receivedAt":"2009-10-31T18:02:47Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"lördag 31 oktober 2009 10:11:29 skrev Thomas Rast:\n> Robin Rosenberg wrote:\n> > Git itself does not even look at this directory.\n>\n> This contradicts the git-fetch manpage though: from urls-remotes.txt,\n> it includes\n>\n> The name of one of the following can be used instead\n> of a URL as `` argument:\n>\n> * a remote in the git configuration file: `$GIT_DIR/config`,\n> * a file in the `$GIT_DIR/remotes` directory, or\n> * a file in the `$GIT_DIR/branches` directory.\n>\n> (and a longer explanation of what they need to look like).\n>\n> So which one is wrong?\n\nI, and a few other people, it seems. Seems the purpose of these\nfiles is a bit different. Git does look in these directories (both)\nwhen fetch is run. Seems remotes is not created by init though.\n\n-- robin\n"},{"id":"126526","messageId":"20091031180920.GN10505@spearce.org","threadId":"21435","inReplyTo":"200910311902.48317.robin.rosenberg@dewire.com","subject":"Re: [PATCH] Don't create the $GIT_DIR/branches directory on init","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-10-31T18:09:20Z","receivedAt":"2009-10-31T18:09:20Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Robin Rosenberg wrote:\n> > * a remote in the git configuration file: `$GIT_DIR/config`,\n> > * a file in the `$GIT_DIR/remotes` directory, or\n> > * a file in the `$GIT_DIR/branches` directory.\n> \n> I, and a few other people, it seems. Seems the purpose of these\n> files is a bit different. Git does look in these directories (both)\n> when fetch is run. Seems remotes is not created by init though.\n\nSince remotes isn't created by init, branches shouldn't be either.\nCogito is dead, and that was the main customer who wanted branches\nto be present in a repository.\n\nI think its safe to remove branches from the template repository\nand stop creating it, but continue to read from branches and\nremotes if they exist.\n\nWe might want to consider dropping support for them in 1.7.0\nor 1.8.0, because any new tools largely focus on config.\nE.g. git-remote probably can't edit branches or remotes, git-gui\nprobably doesn't use them, JGit doesn't use them.\n\n-- \nShawn.\n"},{"id":"126527","messageId":"7vr5sj8m5f.fsf@alter.siamese.dyndns.org","threadId":"21435","inReplyTo":"200910311011.31189.trast@student.ethz.ch","subject":"Re: [PATCH] Don't create the $GIT_DIR/branches directory on init","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-31T18:15:56Z","receivedAt":"2009-10-31T18:15:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> Robin Rosenberg wrote:\n>> Git itself does not even look at this directory.\n\nModern git Porcelains write remote definitions solely to .git/config, but\nstill reads from .git/{branches,remotes}. What we do not do is to update\nthese locations, and we do not need to have these locations to operate.\n\nSo \"not even look at\" is too strong; it just \"not touch\".\n\nI do not think there is reason to change that part of the equation. For\npeople who need to fetch and merge hundreds of random places, it is a lot\nhandier to be able to do\n\n\techo \"$url#$branch\" >.git/branch/$nickname\n rm .git/branch/$nickname\n\nto manage the set of locations added to and deleted from the daily\ncompose. Andrew Morton explicitly asked for this to be kept a few years\nago and I do not see a reason to deprecate this.\n\nNow, not installing an empty .git/branch directory does break the above\nworkflow. You would need to mkdir _once_ yourself, but I do not think\nthat is such a big deal.\n\nOn the other hand, I do not think it is such a big deal to have otherwise\nunused .git/branches/ directory, either. Robin wrote:\n\n Shawn and other wants to stop JGit from creating this directory on\n init with the motivation that newer Git version doesn't create it\n anymore. This patch would make that assertion true.\n\nand after re-reading it, I realize \"the motivation\" is not a motivation at\nall---it is merely an excuse (\"after this patch is applied, git wouldn't\ncreate it anymore\"---so JGit will have an excuse not to do so). It does\nnot say _why_ it shouldn't be there in the first place. IOW, we need to\nfill in the blank in: \"JGit is merely following suit; the reason git\nstopped creating the directory is ________\").\n\nThis patch alone breaks tests in the t55?? series quite a lot, and I am\ntempted to revert it. My time is more valuable than fixing the fallouts\nfrom this change, when the real purpose of the change is not yet stated.\n"},{"id":"126528","messageId":"20091031182416.GO10505@spearce.org","threadId":"21435","inReplyTo":"7vr5sj8m5f.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Don't create the $GIT_DIR/branches directory on init","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-10-31T18:24:16Z","receivedAt":"2009-10-31T18:24:16Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Modern git Porcelains write remote definitions solely to .git/config, but\n> still reads from .git/{branches,remotes}.\n...\n> Andrew Morton explicitly asked for this to be kept a few years\n> ago and I do not see a reason to deprecate this.\n...\n> Shawn and other wants to stop JGit from creating this directory on\n\nI probably said something like this. I won't bother denying it,\nbecause list archives are more accurate than my own fallible memory.\n\nBut I didn't know the Andrew Morton part above. After hearing it\nfrom you, I'm reversing my (apparent) direction here. We should\ncontinue to create the branches directory within a new repository.\n\nSorry Robin, but Andrew Morton matters. Its one stupid unused\ndirectory in a repository that will chew through thousands of inodes\nas loose objects. Its a drop in the bucket in terms of resource\ncost used by Git. And Andrew is someone whose workflow we don't\nwant to break if we can avoid it. He's a long time Git user who is\nalso high up in the kernel food chain. Interrupting him disrupts\na fair chunk of kernel work while he grumbles about the Goddamn\nIdiotic Truckload of s**t that Linus begat.\n\n> This patch alone breaks tests in the t55?? series quite a lot,\n\nDrop the patch.\n\n-- \nShawn.\n"},{"id":"126529","messageId":"7vmy377413.fsf@alter.siamese.dyndns.org","threadId":"21435","inReplyTo":"20091031182416.GO10505@spearce.org","subject":"Re: [PATCH] Don't create the $GIT_DIR/branches directory on init","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-31T19:32:40Z","receivedAt":"2009-10-31T19:32:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n>> This patch alone breaks tests in the t55?? series quite a lot,\n>\n> Drop the patch.\n\nOk, I missed that the unstated goal was \"we will eventually drop support\nfor reading from branches and remotes\". I think it is a worthy goal, but\nalso agree that should be done at 1.7.0 or 1.8.0 boundary.\n\nIf this were Andrew alone, I personally do not think it is such a big\ndeal. My understanding is that an eventual goal over there in the kernel\nland is to grow 'linux-next' tree even more so that akpm tree will shrink\nin the longer term, anyway. I consulted Andrew in early days while he was\nfighting with git to get his scripts to do what he needs them to do, and I\ncan do that again to bring them up-to-date if necessary.\n\nIn order to better support \"massive integrator\" workflow\nthat involves interacting with dozens of remote branches, we need to admit\nthat some of the things you can do if you are set up like Andrew are less\nconvenient to do via \"git remotes\" managing .git/config file. E.g.\n\n : add new\n $ echo \"$korg:/home/rmk/linux-2.6-arm.git#master\" >.git/branches/arm-current\n : remove stale\n $ rm -f .git/branches/powerpc\n : find source\n $ grep -r $something .git/branches\n : make random small changes, e.g. change branch name only\n $ vi .git/branches/sparc\n\nand we _might_ need to improve \"git remote\" interface before dropping\nsupport for reading branches and remotes files.\n\nAdmittedly, managing integration trees like -mm and linux-next needs not\njust nickname-to-repo-branch mapping but also involves the correct merge\norder anyway, and people like Andrew and Stephan Rothwell (linux-next)\nmaintain a text file to describe them that git does not know about.\n\nE.g. http://linux.f-seidel.de/linux-next/pmwiki/pmwiki.php?n=Linux-next.IncludedTrees\n\nWe do not have any infrastructure support for that kind of thing.\n\nTo manage 'pu' and 'next', I use specialized scripts (in my 'todo' branch,\nlook for Reintegrate script) myself, even though the number of topics I\nmanage is far smaller than what we are discussing here[*1*]. In that\nsense, the difference between the remotes sections in .git/config file and\n.git/branches/* files is not such a big issue in the larger picture.\n\nAs long as we keep the UI to deal with bare URL and branch names from the\ncommand line properly working, the \"massive intergrator\" workflow might be\nbetter done without _any_ remote definition, either in the config nor\nbranches/remotes files. Two integrator scripts might read like these:\n\n\t#!/bin/sh\n\t# fetch-all script\n # fetch from repositories\n failed=\n\twhile read nickname url branch\n do\n \tgit fetch -q \"$url\" \"+$branch:refs/remotes/$nickname\" ||\n\t\tfailed=\"$failed$nickname \"\n\tdone /var/tmp/redo-jch.sh\n $ Meta/Reintegrate jch..pu >/var/tmp/redo-pu.sh\n\n : queue a new topic\n $ git checkout -b xx/topic master\n $ git am -s $patch\n\n : update a topic\n $ git checkout xx/topic\n $ git am -s $patch\n\n : fix a topic (that is not in 'next' yet)\n $ git checkout xx/topic\n $ git rebase -i $(git merge-base master HEAD)\n\n : decide to graduate a topic to 'master'\n $ git checkout master\n $ git merge xx/topic\n\n : apply directly to master\n $ git checkout master\n $ git am -s $patch\n\n : update 'next' with what's new in 'master'\n $ git checkout next && git merge master\n : rebuild 'jch' (shadow of 'next')\n $ git branch -f jch master && git checkout jch\n $ sh /var/tmp/redo-jch.sh\n : at this point, 'jch' and 'next' must exactly match\n\n : add topics that are next-ready to 'jch' and test\n $ git merge xx/topic\n\n : merge them to 'next' as well\n $ Meta/Reintegrate master..jch >/var/tmp/redo-jch.sh\n $ git checkout next && sh /var/tmp/redo-jch.sh\n : at this point, 'jch' and 'next' must exactly match\n\n : rebuild 'pu'\n $ git branch -f pu jch && git checkout pu\n $ sh /var/tmp/redo-pu.sh\n : merge new topics\n $ git merge xx/topic\n"}]}