{"thread":{"id":"8965","subject":"finding the right remote branch for a commit","startedAt":"2007-07-10T14:49:07Z","lastAt":"2007-07-16T09:14:15Z","messageCount":7,"participants":["martin f krafft","Johannes Schindelin","Jakub Narebski","Matthias Lederhofer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"46955","messageId":"20070710144907.GA324@piper.oerlikon.madduck.net","threadId":"8965","inReplyTo":null,"subject":"finding the right remote branch for a commit","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-07-10T14:49:07Z","receivedAt":"2007-07-10T14:49:07Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"Dear list,\n\nI am trying to figure out a way to store ~/.etc in git. With SVN,\nI would have a .etc repository for each machine, which would use\nsvn:externals to reference locations of the various subdirectories,\nwhich SVN would then pull and assemble. Thus, my ~/.etc might be\n\n  ~/.etc\n  ~/.etc/ssh [svn+ssh://svn.madduck.net/priv/etc/ssh]\n  ~/.etc/vim [svn+ssh://svn.madduck.net/pub/etc/vim]\n  ...\n\nWith git, I am now considering using remote branches for this kind\nof stuff. So I'll have a repository for my ssh config and\na repository for my vim config, and so on.\n\nThe idea then is to create another repository for each machine and\nto register the remote tracking branches there in much the same way\nthat I used svn:externals previously (and with the added benefit\nthat I don't have to stay within subdirectories).\n\nThus, the vim repository might look like this:\n\n  .etc/\n  |-- vim/\n  |   `-- rc.vim\n  `-- .vimrc -> .etc/vim/rc.vim\n\nand the ssh configuration might be\n\n  .etc/\n  |-- ssh/\n  |   |-- config\n  |   `-- authorized_keys\n  `-- .ssh -> .etc/ssh/\n\nMy theory is that merging all those remotely tracked branches into\na local repo populates my home directory, and bringing it up to the\nlatest version is as simple as:\n\n  git remote update\n  git branch -r | xargs git merge   # any way to just merge all remote branches?\n\nSo far so good, this seems to work just fine.\n\nRight now I am trying to figure out how to push updates back to the\ncentral store so that other machines who \"subscribe\" to a given\nbranch can receive the updates.\n\nFor instance, I may have made a change to ~/.vimrc and to\n~/.ssh/config and committed each to the machine-local repository.\nWhat I need now is a way to tell me\n\n  (a) which commits are local and have not been merged from a remote\n      tracking branch. If I actually want to keep commits local,\n      e.g. because of changes only applicable to this one machine,\n      I can move them to a local branch and rebase that whenever the\n      remotes change.\n\n  (b) which commits should be pushed where. This is a bit of\n      a strange one it may seem, but in my case, remote branches are\n      orthogonal and never touch the same file. Thus, each file\n      belongs to one remote branch. How can I determine which one?\n\n      Or even better, how could I push all my local commits to the\n      respective remotes?\n\nThanks for any comments, and sorry to be cluttering the list with my\nnewbie stuff...\n\n-- \nmartin;              (greetings from the heart of the sun.)\n  \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nspamtraps: madduck.bogus@madduck.net\n \n\"moderation is a fatal thing. enough is as bad as a meal. more than\n enough is as good as a feast.\"\n                                                        -- oscar wilde\n"},{"id":"47083","messageId":"Pine.LNX.4.64.0707112226170.4516@racer.site","threadId":"8965","inReplyTo":"20070710144907.GA324@piper.oerlikon.madduck.net","subject":"Re: finding the right remote branch for a commit","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-11T21:26:23Z","receivedAt":"2007-07-11T21:26:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 10 Jul 2007, martin f krafft wrote:\n\n> I am trying to figure out a way to store ~/.etc in git. With SVN,\n> I would have a .etc repository for each machine, which would use\n> svn:externals to reference locations of the various subdirectories,\n> which SVN would then pull and assemble. Thus, my ~/.etc might be\n> \n>   ~/.etc\n>   ~/.etc/ssh [svn+ssh://svn.madduck.net/priv/etc/ssh]\n>   ~/.etc/vim [svn+ssh://svn.madduck.net/pub/etc/vim]\n>   ...\n>\n> [...] \n> \n> Thus, the vim repository might look like this:\n> \n>   .etc/\n>   |-- vim/\n>   |   `-- rc.vim\n>   `-- .vimrc -> .etc/vim/rc.vim\n> \n> and the ssh configuration might be\n> \n>   .etc/\n>   |-- ssh/\n>   |   |-- config\n>   |   `-- authorized_keys\n>   `-- .ssh -> .etc/ssh/\n\nOkay, after discussing this for a bit on IRC, here is what I would do (I \nalready said this on IRC, but the mailing list is really the better medium \nfor this):\n\nI would actually rename .etc/ into gits/, because it is not a directory \ncontaining settings, but a directory containing repositories.\n\nThen I would create bare repositories gits/vim.git/, gits/ssh.git/, \ngits/mutt.git/, etc. but as soon as I created them, I would make them \n\"unbare\", i.e. \"git config core.bare false\".\n\nEverytime I would work on, say, .vimrc, I would say \n\"--git-dir=$HOME/gits/vim.git\", or maybe even make an alias in \n$HOME/.gitconfig, which spares me that:\n\n$ git config --global vim '!git --git-dir=$HOME/gits/vim.git'\n\nThen I could see the status with\n\n$ git vim status\n\nCome to think of it, this is maybe what I would have done, but it appears \nto me that this is the _ideal_ use case for worktree:\n\nIn $HOME/gits:\n\n$ mkdir vim.git && cd vim.git\n$ git --work-tree=$HOME init\n$ cat >> info/exclude < EOF\n*\n!/.vimrc\nEOF\n\nThen you could do all Git operations like push, fetch, pull, log in \n$HOME/gits/vim.git, and all editing in $HOME.\n\nAt least that is the theory.\n\nIn practice, and I consider these all bugs, it does not work:\n\n- you have to say\n\n  $ git --work-tree=$HOME --bare init\n\n  which is a bit counterintuitive.  After all, it is _not_ a bare \n  repository.  The whole purpose of worktree, as far as I understand, is \n  to have a _detached_ repository, which would otherwise be called bare.\n\n- $ git status\n\n  does not do what you would expect: it fails, telling you that it needs a \n  work tree, of all things. You can say (tongue-in-cheek)\n\n  $ (export GIT_DIR=\"$(pwd)\" && cd \"$(git config core.worktree)\" &&\n     git status)\n\n  So, git knows about the location of the working tree, but just ignores \n  that.\n\n- In the case that you forget to set GIT_DIR, you better not have any \n  .git/ repository in $HOME/ or $HOME/gits/, because it will pick up that \n  instead!  Even if you are _inside_ a detached git directory!\n\n  So you better not try some games like this in a subdirectory of your \n  local git.git repository.  It is a fine way to get completely confused.  \n  And certainly do _not_ do something like \"git reset --hard <branch>\" \n  there.\n\n- Of course, it would be nice if something like that worked:\n\n  $ cd $HOME/gits/vim.git\n  $ git add $HOME/.vimrc\n\n  But it does not work, because it wants to _be_ in the work tree.  Of \n  course, you have to specify the GIT_DIR again, because the working tree \n  does not know about the location of the repository, but vice versa.\n\nThose are serious bugs.  Matthias, any idea how to fix them?\n\nCiao,\nDscho\n"},{"id":"47125","messageId":"20070712074745.GA28507@piper.oerlikon.madduck.net","threadId":"8965","inReplyTo":"Pine.LNX.4.64.0707112226170.4516@racer.site","subject":"Re: finding the right remote branch for a commit","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-07-12T07:47:45Z","receivedAt":"2007-07-12T07:47:45Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.07.11.2326 +0200]:\n> Okay, after discussing this for a bit on IRC, here is what I would\n> do (I already said this on IRC, but the mailing list is really the\n> better medium for this):\n\nI agree. However, I find IRC to have its merits. For instance, all\nof our discussion yesterday would have taken days over the list, but\non IRC I was able to interject when I did not understand something\nor you could stop me when I was going down a garden path.\n\nOf course, IRC isn't archived in the sense that lists are, which is\nwhy I make an effort to send updates to the list, such as I did to\nanother thread yesterday: http://marc.info/?l=git&m=118418250002028&w=2\n\n> I would actually rename .etc/ into gits/, because it is not\n> a directory containing settings, but a directory containing\n> repositories.\n\nYes and no. I already use ~/.etc/ to store my settings and symlink\ninto it, but I do like your idea too, actually. I have yet to go\nand try it, and I shall report back then.\n\n> Everytime I would work on, say, .vimrc, I would say\n> \"--git-dir=$HOME/gits/vim.git\", or maybe even make an alias in\n> $HOME/.gitconfig, which spares me that:\n\nI wish there were a way to determine which repository a file belongs\nto and then to automatically select the right repository. I guess\none can script that by iterating all repos and using git-ls-files,\npossibly caching the result.\n\nAnyway, I tried your approach and failed:\n\n  $ mkdir repo\n  $ GIT_DIR=repo git init\n  $ GIT_DIR=repo git config core.bare false\n  $ echo 1 >a; GIT_DIR=repo git add a; GIT_DIR=repo git commit -m.\n  fatal: add must be run in a work tree\n  nothing to commit (use \"git add file1 file2\" to include for commit)\n\nI am probably doing something wrong, but what?\n\n> Come to think of it, this is maybe what I would have done, but it appears \n> to me that this is the _ideal_ use case for worktree:\n\nYes, it does. I am downloading the source now and intend to work\nwith the HEAD (is that the right term for what I used to call trunk\nwhen I was doing SVN?) from now on (instead of the Debian package).\n\n> - you have to say\n> \n>   $ git --work-tree=$HOME --bare init\n> \n>   which is a bit counterintuitive.  After all, it is _not_ a bare \n>   repository.  The whole purpose of worktree, as far as I understand, is \n>   to have a _detached_ repository, which would otherwise be called bare.\n\nI said\n\n  GIT_DIR=repo git --work-tree `pwd` init\n\nand that seems to do everything it should, it sets core.worktree to\n. and core.bare to false.\n\n> Those are serious bugs.  Matthias, any idea how to fix them?\n\nThat would be splendid. I am operating off HEAD now, so feel free to\nprod me for any testing.\n\n-- \nmartin;              (greetings from the heart of the sun.)\n  \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nspamtraps: madduck.bogus@madduck.net\n \n\"a scientist once wrote that all truth passes through three stages:\n first it is ridiculed, then violently opposed and eventually,\n accepted as self-evident.\"\n                                                       -- schopenhauer\n"},{"id":"47133","messageId":"f74s56$cuc$1@sea.gmane.org","threadId":"8965","inReplyTo":"20070712074745.GA28507@piper.oerlikon.madduck.net","subject":"Re: finding the right remote branch for a commit","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-07-12T09:33:32Z","receivedAt":"2007-07-12T09:33:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"martin f krafft wrote:\n\n> Yes, it does. I am downloading the source now and intend to work\n> with the HEAD (is that the right term for what I used to call trunk\n> when I was doing SVN?) from now on (instead of the Debian package).\n\nHEAD means _current_ branch. You can work off 'master' or 'next' branches,\nand if you feel really adventurous even off 'pu' branch.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"47466","messageId":"20070715223341.GA3797@moooo.ath.cx","threadId":"8965","inReplyTo":"Pine.LNX.4.64.0707112226170.4516@racer.site","subject":"Re: finding the right remote branch for a commit","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-07-15T22:33:41Z","receivedAt":"2007-07-15T22:33:41Z","isPatch":false,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> In practice, and I consider these all bugs, it does not work:\n> \n> - you have to say\n> \n>   $ git --work-tree=$HOME --bare init\n> \n>   which is a bit counterintuitive.  After all, it is _not_ a bare \n>   repository.  The whole purpose of worktree, as far as I understand, is \n>   to have a _detached_ repository, which would otherwise be called bare.\n\nUse\n\n    $ git --work-tree \"$HOME\" --git-dir . init\n\ninstead.\n\nIMHO the --bare flag did not make much sense before the introduction\nof GIT_WORK_TREE and doesn't after, at least not with the meaning it\nhas: why should 'git --bare' mean to use the repository from cwd?\nOk, git --bare implies that you cannot use a working tree because\nyou're at the top of the git repository directory which may not be\nused as working tree.\n\nNow bare only means that some protection mechanisms are disabled and\nsome default values change (i.e. overwrite HEAD, enable/disable\nreflogs by default).  So maybe the name bare itself is a bit\ncounterintuitive now.\n\n> - $ git status\n> \n>   does not do what you would expect: it fails, telling you that it needs a \n>   work tree, of all things. You can say (tongue-in-cheek)\n> \n>   $ (export GIT_DIR=\"$(pwd)\" && cd \"$(git config core.worktree)\" &&\n>      git status)\n> \n>   So, git knows about the location of the working tree, but just ignores \n>   that.\n> \n> - In the case that you forget to set GIT_DIR, you better not have any \n>   .git/ repository in $HOME/ or $HOME/gits/, because it will pick up that \n>   instead!  Even if you are _inside_ a detached git directory!\n> \n>   So you better not try some games like this in a subdirectory of your \n>   local git.git repository.  It is a fine way to get completely confused.  \n>   And certainly do _not_ do something like \"git reset --hard <branch>\" \n>   there.\n>\n> - Of course, it would be nice if something like that worked:\n> \n>   $ cd $HOME/gits/vim.git\n>   $ git add $HOME/.vimrc\n> \n>   But it does not work, because it wants to _be_ in the work tree.  Of \n>   course, you have to specify the GIT_DIR again, because the working tree \n>   does not know about the location of the repository, but vice versa.\n\nUp to now you are supposed to be in the working tree all the time when\nusing it.  Therefore I'd call these feature requests rather than bugs :)\n\nFor git status it should be quite easy to add a special case to change\nto the top of the working tree as long as no paths are used as\nparameters.\n\nWhen paths are used (either with git status or git add) you'd have to\ntranslate the specified path to a path relative to the working tree.\nThis should be possible with chdir, getcwd and prefixcmp.  If this\ngets implemented for git status/git add it should probably get\nimplemented for all commands for which it makes sense.  I think this\nwould be nice to have but I'm not sure how complicated this is to\nimplement.\n"},{"id":"47481","messageId":"Pine.LNX.4.64.0707160036160.14781@racer.site","threadId":"8965","inReplyTo":"20070715223341.GA3797@moooo.ath.cx","subject":"Re: finding the right remote branch for a commit","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-15T23:48:08Z","receivedAt":"2007-07-15T23:48:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nyou left enough hints to convince me that you will not fix the bugs.  \nSo I will bite the bullet, and find some time this week to fix the issues.\n\nJunio, I'd really appreciated if you considered waiting with 1.5.3 (maybe \ndo an -rc2?) before these bugs are squashed.\n\nOn Mon, 16 Jul 2007, Matthias Lederhofer wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > In practice, and I consider these all bugs, it does not work:\n> > \n> > - you have to say\n> > \n> >   $ git --work-tree=$HOME --bare init\n> > \n> >   which is a bit counterintuitive.  After all, it is _not_ a bare \n> >   repository.  The whole purpose of worktree, as far as I understand, is \n> >   to have a _detached_ repository, which would otherwise be called bare.\n> \n> Use\n> \n>     $ git --work-tree \"$HOME\" --git-dir . init\n> \n> instead.\n\nWhy _should_ that be necessary at all?  I _already_ told git that the \nworking tree is somewhere else.  It makes _no sense at all_ to treat the \ncwd as anything else than the GIT_DIR, when --work-tree but no --git-dir \nwere specified.\n\n> IMHO the --bare flag did not make much sense before the introduction\n> of GIT_WORK_TREE and doesn't after, at least not with the meaning it\n> has: why should 'git --bare' mean to use the repository from cwd?\n\nTo the contrary, it makes tons of sense.  If you want to initialise a bare \nrepository, what _more_ natural way than to say \"git init --bare\"?  And \nwhat _more_ natural place to pick for GIT_DIR than the cwd, when you did \nnot specify --git-dir?\n\n> > [descriptions of bugs, that have been largely ignored]\n>\n> Up to now you are supposed to be in the working tree all the time when \n> using it.  Therefore I'd call these feature requests rather than bugs :)\n\nFeature requests? WTF? What reason is there for the _requirement_ to \nspecify a working tree, when git does not make use of it?  Hmm?\n\nCiao,\nDscho\n"},{"id":"47524","messageId":"20070716091415.GA31186@moooo.ath.cx","threadId":"8965","inReplyTo":"Pine.LNX.4.64.0707160036160.14781@racer.site","subject":"Re: finding the right remote branch for a commit","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-07-16T09:14:15Z","receivedAt":"2007-07-16T09:14:15Z","isPatch":false,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> On Mon, 16 Jul 2007, Matthias Lederhofer wrote:\n> \n> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > Use\n> > \n> >     $ git --work-tree \"$HOME\" --git-dir . init\n> > \n> > instead.\n> \n> Why _should_ that be necessary at all?  I _already_ told git that the \n> working tree is somewhere else.  It makes _no sense at all_ to treat the \n> cwd as anything else than the GIT_DIR, when --work-tree but no --git-dir \n> were specified.\n>\n> > IMHO the --bare flag did not make much sense before the introduction\n> > of GIT_WORK_TREE and doesn't after, at least not with the meaning it\n> > has: why should 'git --bare' mean to use the repository from cwd?\n> \n> To the contrary, it makes tons of sense.  If you want to initialise a bare \n> repository, what _more_ natural way than to say \"git init --bare\"?  And \n> what _more_ natural place to pick for GIT_DIR than the cwd, when you did \n> not specify --git-dir?\n\nAh, for git init it makes sense to have the --bare flag and also to\nuse the cwd as GIT_DIR when GIT_WORK_TREE is specified.\n\n> > > [descriptions of bugs, that have been largely ignored]\n\nThe last paragraphs were for the second and fourth one (git status/add\nfrom outside the working tree): it should be possible to fix this but\nit might be a bit complicated.  And if it is done for a few commands\nprobably all commands should support this.\n\nFor the third one (git picks up another git repository even if it is\ninside a 'detached working tree') I have no idea how to fix this.  The\nworking tree cannot be recognized in any way.  Maybe you can/should\nuse a symlink to the real repository named .git in this case?  But\nthis only works as long as you checkout only one repository in the\ndirectory.\n\n> > Up to now you are supposed to be in the working tree all the time when \n> > using it.  Therefore I'd call these feature requests rather than bugs :)\n> \n> Feature requests? WTF? What reason is there for the _requirement_ to \n> specify a working tree, when git does not make use of it?  Hmm?\n\nSorry, I don't understand what you mean yet.  Where does git require\nyou to specify a working tree?\n"}]}