{"thread":{"id":"13209","subject":"git remote update -> rejected","startedAt":"2008-04-22T09:48:53Z","lastAt":"2008-04-22T22:04:35Z","messageCount":28,"participants":["Mike Galbraith","Jeff King","Johannes Schindelin","Teemu Likonen","Paolo Bonzini","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"74933","messageId":"1208857733.4695.37.camel@marge.simson.net","threadId":"13209","inReplyTo":null,"subject":"git remote update -> rejected","fromName":"Mike Galbraith","fromEmail":"efault@gmx.de","sentAt":"2008-04-22T09:48:53Z","receivedAt":"2008-04-22T09:48:53Z","isPatch":false,"sender":{"key":"efault@gmx.de","avatar":null},"body":"Greetings,\n\nDoes anyone know what could lead to this?  git doesn't have any trouble\n(well, hasn't had any yet) with any trees other than x86 and\nsched-devel. Nobody but little old me seems to be having this trouble...\n\ngit is pulled nearly every day, but checking out older versions doesn't\nmake any difference (unless i go too far back of course).\n\nmarge:..git/linux-2.6 # git remote update\nUpdating origin\nUpdating linux-next\nUpdating stable\nUpdating x86\n>From git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86\n ! [rejected]        latest     -> x86/latest  (non fast forward)\n ! [rejected]        master     -> x86/master  (non fast forward)\n ! [rejected]        testing    -> x86/testing  (non fast forward)\nUpdating sched-devel\n>From git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel\n ! [rejected]        for-akpm   -> sched-devel/for-akpm  (non fast forward)\n ! [rejected]        latest     -> sched-devel/latest  (non fast forward)\n ! [rejected]        master     -> sched-devel/master  (non fast forward)\n\nIf I rm/add the remote back, all goes fine... until it says rejected.\n\nmarge:..git/linux-2.6 # git remote rm x86\nmarge:..git/linux-2.6 # git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git\nmarge:..git/linux-2.6 # git remote update\nUpdating origin\nUpdating linux-next\nUpdating stable\nUpdating sched-devel\nUpdating x86\n>From git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86\n * [new branch]      base       -> x86/base\n * [new branch]      for-akpm   -> x86/for-akpm\n * [new branch]      for-linus  -> x86/for-linus\n * [new branch]      latest     -> x86/latest\n * [new branch]      master     -> x86/master\n * [new branch]      origin     -> x86/origin\n * [new branch]      testing    -> x86/testing\nmarge:..git/linux-2.6 #\n"},{"id":"74941","messageId":"20080422103458.GA14751@sigio.intra.peff.net","threadId":"13209","inReplyTo":"1208857733.4695.37.camel@marge.simson.net","subject":"Re: git remote update -> rejected","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-22T10:34:58Z","receivedAt":"2008-04-22T10:34:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 22, 2008 at 11:48:53AM +0200, Mike Galbraith wrote:\n\n> marge:..git/linux-2.6 # git remote update\n> Updating origin\n> Updating linux-next\n> Updating stable\n> Updating x86\n> >From git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86\n>  ! [rejected]        latest     -> x86/latest  (non fast forward)\n>  ! [rejected]        master     -> x86/master  (non fast forward)\n>  ! [rejected]        testing    -> x86/testing  (non fast forward)\n\nThe x86 tree was presumably rewound or rebased, which means that\nfetching their new position would overwrite your old. This is probably\nOK, since it looks like you have x86/* as tracking branches, and only\nthey would get overwritten. So it is probably safe to put a '+' in front\nof the 'fetch' line in your config file. E.g.,\n\n  [remote \"x86\"]\n    url = ...\n    fetch = +refs/heads/*:refs/remotes/x86/*\n\nSee 'git help fetch' for details.\n\n-Peff\n"},{"id":"74943","messageId":"1208861703.18689.2.camel@marge.simson.net","threadId":"13209","inReplyTo":"20080422103458.GA14751@sigio.intra.peff.net","subject":"Re: git remote update -> rejected","fromName":"Mike Galbraith","fromEmail":"efault@gmx.de","sentAt":"2008-04-22T10:55:03Z","receivedAt":"2008-04-22T10:55:03Z","isPatch":false,"sender":{"key":"efault@gmx.de","avatar":null},"body":"\nOn Tue, 2008-04-22 at 06:34 -0400, Jeff King wrote:\n> On Tue, Apr 22, 2008 at 11:48:53AM +0200, Mike Galbraith wrote:\n> \n> > marge:..git/linux-2.6 # git remote update\n> > Updating origin\n> > Updating linux-next\n> > Updating stable\n> > Updating x86\n> > >From git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86\n> >  ! [rejected]        latest     -> x86/latest  (non fast forward)\n> >  ! [rejected]        master     -> x86/master  (non fast forward)\n> >  ! [rejected]        testing    -> x86/testing  (non fast forward)\n> \n> The x86 tree was presumably rewound or rebased, which means that\n> fetching their new position would overwrite your old. This is probably\n> OK, since it looks like you have x86/* as tracking branches, and only\n> they would get overwritten. So it is probably safe to put a '+' in front\n> of the 'fetch' line in your config file. E.g.,\n> \n>   [remote \"x86\"]\n>     url = ...\n>     fetch = +refs/heads/*:refs/remotes/x86/*\n> \n> See 'git help fetch' for details.\n\nThanks a bunch.  I'll try it.  I notice that origin and linux-next\nalready had + prefix.  Presumably that came from the home repo.\n\n\t-Mike\n"},{"id":"74947","messageId":"20080422111113.GB11238@sigill.intra.peff.net","threadId":"13209","inReplyTo":"1208861703.18689.2.camel@marge.simson.net","subject":"Re: git remote update -> rejected","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-22T11:11:13Z","receivedAt":"2008-04-22T11:11:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 22, 2008 at 12:55:03PM +0200, Mike Galbraith wrote:\n\n> >   [remote \"x86\"]\n> >     url = ...\n> >     fetch = +refs/heads/*:refs/remotes/x86/*\n> > \n> > See 'git help fetch' for details.\n> \n> Thanks a bunch.  I'll try it.  I notice that origin and linux-next\n> already had + prefix.  Presumably that came from the home repo.\n\nCloning creates an origin with '+' in the fetch line, but \"git remote\nadd\" doesn't seem to. Hrm, it looks like this is a regression from the\nrecent rewrite in C.\n\nDscho, is this a bug, or was there a conscious decision that I missed?\n\nIf a bug, the fix is below.\n\n-- >8 --\nremote: create fetch config lines with '+'\n\nSince git-remote always uses remote tracking branches, it\nshould be safe to always force updates of those branches.\nI.e., we should generate\n\n  fetch = +refs/heads/*:refs/remotes/$remote/*\n\ninstead of\n\n  fetch = refs/heads/*:refs/remotes/$remote/*\n\nThis was the behavior of the perl version, which seems to\nhave been lost in the C rewrite.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n builtin-remote.c  |    1 +\n t/t5505-remote.sh |   10 ++++++++++\n 2 files changed, 11 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-remote.c b/builtin-remote.c\nindex 9d4432b..8b63619 100644\n--- a/builtin-remote.c\n+++ b/builtin-remote.c\n@@ -107,6 +107,7 @@ static int add(int argc, const char **argv)\n \t\tstruct path_list_item *item = track.items + i;\n \n \t\tstrbuf_reset(&buf2);\n+\t\tstrbuf_addch(&buf2, '+');\n \t\tif (mirror)\n \t\t\tstrbuf_addf(&buf2, \"refs/%s:refs/%s\",\n \t\t\t\t\titem->path, item->path);\ndiff --git a/t/t5505-remote.sh b/t/t5505-remote.sh\nindex af2d077..48ff2d4 100755\n--- a/t/t5505-remote.sh\n+++ b/t/t5505-remote.sh\n@@ -77,6 +77,16 @@ test_expect_success 'add another remote' '\n )\n '\n \n+test_expect_success 'remote forces tracking branches' '\n+(\n+\tcd test &&\n+\tcase `git config remote.second.fetch` in\n+\t+*) true ;;\n+\t *) false ;;\n+\tesac\n+)\n+'\n+\n test_expect_success 'remove remote' '\n (\n \tcd test &&\n-- \n1.5.5.1.116.g0023.dirty\n"},{"id":"74949","messageId":"alpine.DEB.1.00.0804221250010.4460@eeepc-johanness","threadId":"13209","inReplyTo":"20080422111113.GB11238@sigill.intra.peff.net","subject":"Re: git remote update -> rejected","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-22T11:58:07Z","receivedAt":"2008-04-22T11:58:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Tue, 22 Apr 2008, Jeff King wrote:\n\n> On Tue, Apr 22, 2008 at 12:55:03PM +0200, Mike Galbraith wrote:\n> \n> > >   [remote \"x86\"]\n> > >     url = ...\n> > >     fetch = +refs/heads/*:refs/remotes/x86/*\n> > > \n> > > See 'git help fetch' for details.\n> > \n> > Thanks a bunch.  I'll try it.  I notice that origin and linux-next\n> > already had + prefix.  Presumably that came from the home repo.\n> \n> Cloning creates an origin with '+' in the fetch line, but \"git remote\n> add\" doesn't seem to. Hrm, it looks like this is a regression from the\n> recent rewrite in C.\n\nThanks for working on this: I missed this thread (had too many mails to \ncatch up with).\n\n> Dscho, is this a bug, or was there a conscious decision that I missed?\n\nIt was a concious decision, but maybe it was wrong.\n\nMy rationale was this: if I mirror another person's repository, I want all \nthe history.  And I do want to keep it, even if the other person decides \nto clean the original repository out.\n\n(In this case, the reflogs would not help, since I do not have a HEAD \nreflog for all the deleted branches, and deleting the refs deletes their \nreflogs, too.)\n\nBut as I said, my rationale may very well be wrong.\n\nCiao,\nDscho\n"},{"id":"74953","messageId":"20080422124118.GA3098@mithlond.arda.local","threadId":"13209","inReplyTo":"20080422111113.GB11238@sigill.intra.peff.net","subject":"Re: git remote update -> rejected","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-04-22T12:41:18Z","receivedAt":"2008-04-22T12:41:18Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Jeff King wrote (2008-04-22 07:11 -0400):\n\n> remote: create fetch config lines with '+'\n> \n> Since git-remote always uses remote tracking branches, it\n> should be safe to always force updates of those branches.\n> I.e., we should generate\n> \n>   fetch = +refs/heads/*:refs/remotes/$remote/*\n> \n> instead of\n> \n>   fetch = refs/heads/*:refs/remotes/$remote/*\n> \n> This was the behavior of the perl version, which seems to\n> have been lost in the C rewrite.\n\nI agree, the \"+\" should be there. I see remote tracking branches as,\nwell, branches that track remote repository - no matter what happens\nthere. Local branches are under user's personal control, so if user\nwants to save/keep the information of remote branches he can create\nlocal ones out of them: git branch localcopy $remote/$branch\n"},{"id":"74956","messageId":"20080422125618.GA27577@sigill.intra.peff.net","threadId":"13209","inReplyTo":"alpine.DEB.1.00.0804221250010.4460@eeepc-johanness","subject":"Re: git remote update -> rejected","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-22T12:56:18Z","receivedAt":"2008-04-22T12:56:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Mike wrote:\n\n> > > Thanks a bunch.  I'll try it.  I notice that origin and linux-next\n> > > already had + prefix.  Presumably that came from the home repo.\n\nDscho wrote:\n\n> It was a concious decision, but maybe it was wrong.\n> \n> My rationale was this: if I mirror another person's repository, I want all \n> the history.  And I do want to keep it, even if the other person decides \n> to clean the original repository out.\n>\n> (In this case, the reflogs would not help, since I do not have a HEAD \n> reflog for all the deleted branches, and deleting the refs deletes their \n> reflogs, too.)\n\nHmm, there is an inconsistency here, though, since we set it up one way\non clone and another way on \"remote add\". Though if clone does finally\nbecome \"init + remote add + checkout\" that will resolve itself.\n\nStill, I think I prefer the old \"+\" behavior. We don't actually\n_delete_ branches, we just allow non-fast-forward updates. The reflogs\nwill still be there.\n\n-Peff\n"},{"id":"74955","messageId":"alpine.DEB.1.00.0804221354180.4460@eeepc-johanness","threadId":"13209","inReplyTo":"20080422124118.GA3098@mithlond.arda.local","subject":"Re: git remote update -> rejected","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-22T12:56:36Z","receivedAt":"2008-04-22T12:56:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 22 Apr 2008, Teemu Likonen wrote:\n\n> Local branches are under user's personal control, so if user wants to \n> save/keep the information of remote branches he can create local ones \n> out of them: git branch localcopy $remote/$branch\n\nFor your benefit, I just assume that you did not yet read my reply to \nPeff's mail.\n\nWith the --mirror mode, you can no longer discern clearly between local \nand remote branches.  This is basically what we had in the beginning, \nbefore the \"separate remotes layout\".\n\nSo your point is not valid, an update will interfer with \"local\" branches.\n\nAnd when those branches are deleted via \"git fetch\", you will not be able \nto reconstruct them easily, because the reflogs are deleted, too.\n\nCiao,\nDscho\n"},{"id":"74957","messageId":"20080422130122.GB27577@sigill.intra.peff.net","threadId":"13209","inReplyTo":"alpine.DEB.1.00.0804221354180.4460@eeepc-johanness","subject":"Re: git remote update -> rejected","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-22T13:01:23Z","receivedAt":"2008-04-22T13:01:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 22, 2008 at 01:56:36PM +0100, Johannes Schindelin wrote:\n\n> With the --mirror mode, you can no longer discern clearly between local \n> and remote branches.  This is basically what we had in the beginning, \n> before the \"separate remotes layout\".\n> \n> So your point is not valid, an update will interfer with \"local\" branches.\n> \n> And when those branches are deleted via \"git fetch\", you will not be able \n> to reconstruct them easily, because the reflogs are deleted, too.\n\nI think I'm a little confused. Is it possible to delete branches on a\nfetch? It looks like remote's --mirror option just specifies \"don't use\nseparate remote layout\". So again, there is no way to blow away reflogs\nthrough a fetch.\n\nOTOH, if you are using non-separate-remote layout, I think it makes\nsense to _not_ have the \"+\". OTOOH, when you call the option --mirror,\nit makes me think of \"push --mirror\" which implies \"+\".\n\n-Peff\n"},{"id":"74959","messageId":"alpine.DEB.1.00.0804221357420.4460@eeepc-johanness","threadId":"13209","inReplyTo":"20080422125618.GA27577@sigill.intra.peff.net","subject":"Re: git remote update -> rejected","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-22T13:03:43Z","receivedAt":"2008-04-22T13:03:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 22 Apr 2008, Jeff King wrote:\n\n> Dscho wrote:\n> \n> > It was a concious decision, but maybe it was wrong.\n> > \n> > My rationale was this: if I mirror another person's repository, I want \n> > all the history.  And I do want to keep it, even if the other person \n> > decides to clean the original repository out.\n> >\n> > (In this case, the reflogs would not help, since I do not have a HEAD \n> > reflog for all the deleted branches, and deleting the refs deletes \n> > their reflogs, too.)\n> \n> Hmm, there is an inconsistency here, though, since we set it up one way \n> on clone and another way on \"remote add\". Though if clone does finally \n> become \"init + remote add + checkout\" that will resolve itself.\n> \n> Still, I think I prefer the old \"+\" behavior. We don't actually\n> _delete_ branches, we just allow non-fast-forward updates. The reflogs\n> will still be there.\n\nOh, that's right: only \"git remote prune\" will delete stale refs only.\n\nBut my other point about possibly interfering with local branches still \nholds true.\n\nCiao,\nDscho\n"},{"id":"74958","messageId":"alpine.DEB.1.00.0804221404360.4460@eeepc-johanness","threadId":"13209","inReplyTo":"20080422130122.GB27577@sigill.intra.peff.net","subject":"Re: git remote update -> rejected","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-22T13:05:04Z","receivedAt":"2008-04-22T13:05:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 22 Apr 2008, Jeff King wrote:\n\n> OTOH, if you are using non-separate-remote layout, I think it makes\n> sense to _not_ have the \"+\". OTOOH, when you call the option --mirror,\n> it makes me think of \"push --mirror\" which implies \"+\".\n\nI am glad somebody else than me finds this to be a dilemma.\n\nCiao,\nDscho\n"},{"id":"74960","messageId":"20080422130918.GB27878@sigill.intra.peff.net","threadId":"13209","inReplyTo":"alpine.DEB.1.00.0804221357420.4460@eeepc-johanness","subject":"Re: git remote update -> rejected","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-22T13:09:18Z","receivedAt":"2008-04-22T13:09:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 22, 2008 at 02:03:43PM +0100, Johannes Schindelin wrote:\n\n> Oh, that's right: only \"git remote prune\" will delete stale refs only.\n> \n> But my other point about possibly interfering with local branches still \n> holds true.\n\nIn that case, I think that the '+' should come only without --mirror,\nand my complaint is then that \"--mirror\" is a horrible name for that\noption. Though when I saw it, I really expected it to do something about\nthe _push_ line, since that is the only other place we have a --mirror\noption. It would make sense to me for it to set up remote.$x.mirror\n(which is newly added in next). But then, git-remote doesn't seem to be\ngeared towards pushing at all.\n\n-Peff\n"},{"id":"74961","messageId":"alpine.DEB.1.00.0804221425310.4460@eeepc-johanness","threadId":"13209","inReplyTo":"20080422130918.GB27878@sigill.intra.peff.net","subject":"[PATCH] builtin-remote: resurrect forced updates to tracked branches","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-22T13:26:46Z","receivedAt":"2008-04-22T13:26:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nDuring the rewrite of git-remote as a builtin, the ability to force\nupdating the tracked branches (i.e. forcing non-fast-forwards) was\nlost.\n\nThis patch fixes that.\n\nNoticed by Mike Galbraith, analyzed by Jeff King.\n\nSigned-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n\n---\n\n\tOn Tue, 22 Apr 2008, Jeff King wrote:\n\n\t> On Tue, Apr 22, 2008 at 02:03:43PM +0100, Johannes Schindelin wrote:\n\t> \n\t> > Oh, that's right: only \"git remote prune\" will delete stale refs only.\n\t> > \n\t> > But my other point about possibly interfering with local \n\t> > branches still holds true.\n\t> \n\t> In that case, I think that the '+' should come only without \n\t> --mirror, and my complaint is then that \"--mirror\" is a horrible name \n\t> for that option. Though when I saw it, I really expected it to do \n\t> something about the _push_ line, since that is the only other place we \n\t> have a --mirror option. It would make sense to me for it to set up \n\t> remote.$x.mirror (which is newly added in next). But then, git-remote \n\t> doesn't seem to be geared towards pushing at all.\n\n\tI still think that the --mirror option has merit, but I missed \n\tthat your patch did fix the behviour _without_ --mirror.\n\n\tThis is my attempt.\n\n builtin-remote.c |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-remote.c b/builtin-remote.c\nindex d4f2132..117ff60 100644\n--- a/builtin-remote.c\n+++ b/builtin-remote.c\n@@ -114,7 +114,7 @@ static int add(int argc, const char **argv)\n \t\t\tstrbuf_addf(&buf2, \"refs/%s:refs/%s\",\n \t\t\t\t\titem->path, item->path);\n \t\telse\n-\t\t\tstrbuf_addf(&buf2, \"refs/heads/%s:refs/remotes/%s/%s\",\n+\t\t\tstrbuf_addf(&buf2, \"+refs/heads/%s:refs/remotes/%s/%s\",\n \t\t\t\t\titem->path, name, item->path);\n \t\tif (git_config_set_multivar(buf.buf, buf2.buf, \"^$\", 0))\n \t\t\treturn 1;\n"},{"id":"74963","messageId":"20080422133926.GB3098@mithlond.arda.local","threadId":"13209","inReplyTo":"alpine.DEB.1.00.0804221354180.4460@eeepc-johanness","subject":"Re: git remote update -> rejected","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-04-22T13:39:26Z","receivedAt":"2008-04-22T13:39:26Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Johannes Schindelin wrote (2008-04-22 13:56 +0100):\n\n> With the --mirror mode, you can no longer discern clearly between\n> local and remote branches.  This is basically what we had in the\n> beginning, before the \"separate remotes layout\".\n\nHmm, to me it looks like --mirror is for mirroring remote repository and\nhence the \"+\" makes sense in here too. It's like \"I want to make my\nrepository a copy of that remote repository\" hence the name 'mirror'.\nIt'll possibly overwrite local branches but in my way of thinking\nmirroring implies that possibility. The 'git remote' manual says that\n--mirror \"only makes sense in bare repositories\", so the manual seems to\nguide towards not having local working directory nor changes.\n"},{"id":"74964","messageId":"alpine.DEB.1.00.0804221449240.4460@eeepc-johanness","threadId":"13209","inReplyTo":"20080422133926.GB3098@mithlond.arda.local","subject":"Re: git remote update -> rejected","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-22T13:49:57Z","receivedAt":"2008-04-22T13:49:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 22 Apr 2008, Teemu Likonen wrote:\n\n> Johannes Schindelin wrote (2008-04-22 13:56 +0100):\n> \n> > With the --mirror mode, you can no longer discern clearly between\n> > local and remote branches.  This is basically what we had in the\n> > beginning, before the \"separate remotes layout\".\n> \n> Hmm, to me it looks like --mirror is for mirroring remote repository and \n> hence the \"+\" makes sense in here too. It's like \"I want to make my \n> repository a copy of that remote repository\" hence the name 'mirror'. \n> It'll possibly overwrite local branches but in my way of thinking \n> mirroring implies that possibility. The 'git remote' manual says that \n> --mirror \"only makes sense in bare repositories\", so the manual seems to \n> guide towards not having local working directory nor changes.\n\nOkay, how about this: take Peff's patch, but add a warning if --mirror is \nused on a non-bare repository?\n\nCiao,\nDscho\n"},{"id":"74965","messageId":"480DEDCC.8020809@gnu.org","threadId":"13209","inReplyTo":"alpine.DEB.1.00.0804221404360.4460@eeepc-johanness","subject":"Re: git remote update -> rejected","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-22T13:53:16Z","receivedAt":"2008-04-22T13:53:16Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 22 Apr 2008, Jeff King wrote:\n> \n>> OTOH, if you are using non-separate-remote layout, I think it makes\n>> sense to _not_ have the \"+\". OTOOH, when you call the option --mirror,\n>> it makes me think of \"push --mirror\" which implies \"+\".\n> \n> I am glad somebody else than me finds this to be a dilemma.\n\nPushing to a mirror implies a \"+\".  But pulling from a mirror had better \nnot imply a \"+\", as Dscho pointed out in this thread and implemented in \nhis patch.\n\nNon-fast-forward pulls from a non-mirror are safe, so they can imply a \"+\".\n\nMaybe, \"git remote add --mirror\" should add a \"push\" line instead of a \n\"fetch\" line, and should not allow -f or -t options.\n\nPaolo\n"},{"id":"74968","messageId":"20080422140440.GC3098@mithlond.arda.local","threadId":"13209","inReplyTo":"alpine.DEB.1.00.0804221449240.4460@eeepc-johanness","subject":"Re: git remote update -> rejected","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-04-22T14:04:40Z","receivedAt":"2008-04-22T14:04:40Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Johannes Schindelin wrote (2008-04-22 14:49 +0100):\n\n> On Tue, 22 Apr 2008, Teemu Likonen wrote:\n> \n> > Hmm, to me it looks like --mirror is for mirroring remote repository\n> > and hence the \"+\" makes sense in here too. It's like \"I want to make\n> > my repository a copy of that remote repository\" hence the name\n> > 'mirror'. It'll possibly overwrite local branches but in my way of\n> > thinking mirroring implies that possibility. The 'git remote' manual\n> > says that --mirror \"only makes sense in bare repositories\", so the\n> > manual seems to guide towards not having local working directory nor\n> > changes.\n> \n> Okay, how about this: take Peff's patch, but add a warning if --mirror\n> is used on a non-bare repository?\n\nSounds good to me. Indeed, giving a warning is _very_ good idea as\n--mirror is potentially, even likely, destructive with local changes and\nworking directory.\n"},{"id":"74969","messageId":"480DF1E7.5040900@gnu.org","threadId":"13209","inReplyTo":"20080422140440.GC3098@mithlond.arda.local","subject":"Re: git remote update -> rejected","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-22T14:10:47Z","receivedAt":"2008-04-22T14:10:47Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n>> Okay, how about this: take Peff's patch, but add a warning if --mirror\n>> is used on a non-bare repository?\n> \n> Sounds good to me. Indeed, giving a warning is _very_ good idea as\n> --mirror is potentially, even likely, destructive with local changes and\n> working directory.\n\nWhat about changing --mirror to add a push line instead of a fetch line?\n\nPaolo\n"},{"id":"74973","messageId":"alpine.DEB.1.00.0804221607190.4460@eeepc-johanness","threadId":"13209","inReplyTo":"480DF1E7.5040900@gnu.org","subject":"Re: git remote update -> rejected","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-22T15:08:11Z","receivedAt":"2008-04-22T15:08:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 22 Apr 2008, Paolo Bonzini wrote:\n\n> > > Okay, how about this: take Peff's patch, but add a warning if \n> > > --mirror is used on a non-bare repository?\n> > \n> > Sounds good to me. Indeed, giving a warning is _very_ good idea as \n> > --mirror is potentially, even likely, destructive with local changes \n> > and working directory.\n> \n> What about changing --mirror to add a push line instead of a fetch line?\n\nI would not expect --mirror to add a push line when \"git-remote add\" \nwithout --mirror does not a push line either.\n\nCiao,\nDscho\n"},{"id":"74976","messageId":"480E03A9.3040401@gnu.org","threadId":"13209","inReplyTo":"alpine.DEB.1.00.0804221607190.4460@eeepc-johanness","subject":"Re: git remote update -> rejected","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-22T15:26:33Z","receivedAt":"2008-04-22T15:26:33Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 22 Apr 2008, Paolo Bonzini wrote:\n> \n>>>> Okay, how about this: take Peff's patch, but add a warning if \n>>>> --mirror is used on a non-bare repository?\n>>> Sounds good to me. Indeed, giving a warning is _very_ good idea as \n>>> --mirror is potentially, even likely, destructive with local changes \n>>> and working directory.\n>> What about changing --mirror to add a push line instead of a fetch line?\n> \n> I would not expect --mirror to add a push line when \"git-remote add\" \n> without --mirror does not a push line either.\n\nLet me reverse the question.  When does it make sense to use \"git-remote \nadd --mirror\" with the current implementation?\n\nIt's not a rhetoric question.  I know when it would make sense to have \npush refspecs on a remote for which you plan to use \"git push --mirror\" \n(and in \"next\", that is the case if you create the remote with \n\"git-remote add --mirror\").  But I'm a total newbie for things that do \nnot fit my workflows, so I don't know when it would make sense to pull \nfrom that kind of remote.\n\nPaolo\n"},{"id":"74977","messageId":"480E1108.5090701@gnu.org","threadId":"13209","inReplyTo":"480E03A9.3040401@gnu.org","subject":"Re: git remote update -> rejected","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-22T16:23:36Z","receivedAt":"2008-04-22T16:23:36Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":">>> What about changing --mirror to add a push line instead of a fetch line?\n>>\n>> I would not expect --mirror to add a push line when \"git-remote add\" \n>> without --mirror does not a push line either.\n> \n> Let me reverse the question.  When does it make sense to use \"git-remote \n> add --mirror\" with the current implementation?\n> \n> It's not a rhetoric question.  I know when it would make sense to have \n> push refspecs on a remote for which you plan to use \"git push --mirror\" \n> (and in \"next\", that is the case if you create the remote with \n> \"git-remote add --mirror\").  But I'm a total newbie for things that do \n> not fit my workflows, so I don't know when it would make sense to pull \n> from that kind of remote.\n\nAnd actually, I just realized that what I expected from --mirror is this:\n\n[remote \"mirror\"]\n         url = blah\n         fetch = +refs/heads/*:refs/remotes/mirror/*\n         push = +refs/heads/*:refs/heads/*\n         mirror\n\n... so that I can check the state of the mirror with \"git log -1 \nmirror/master\", and still the push refspec is there so that my local \nremotes are not entirely mirrored.\n\nPaolo\n"},{"id":"74978","messageId":"alpine.DEB.1.00.0804221741570.4460@eeepc-johanness","threadId":"13209","inReplyTo":"480E1108.5090701@gnu.org","subject":"Re: git remote update -> rejected","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-22T16:42:25Z","receivedAt":"2008-04-22T16:42:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 22 Apr 2008, Paolo Bonzini wrote:\n\n> > > > What about changing --mirror to add a push line instead of a fetch \n> > > > line?\n> > >\n> > > I would not expect --mirror to add a push line when \"git-remote add\" \n> > > without --mirror does not a push line either.\n> > \n> > Let me reverse the question.  When does it make sense to use \n> > \"git-remote add --mirror\" with the current implementation?\n> > \n> > It's not a rhetoric question.  I know when it would make sense to have push\n> > refspecs on a remote for which you plan to use \"git push --mirror\" (and in\n> > \"next\", that is the case if you create the remote with \"git-remote add\n> > --mirror\").  But I'm a total newbie for things that do not fit my workflows,\n> > so I don't know when it would make sense to pull from that kind of remote.\n> \n> And actually, I just realized that what I expected from --mirror is this:\n> \n> [remote \"mirror\"]\n>         url = blah\n>         fetch = +refs/heads/*:refs/remotes/mirror/*\n>         push = +refs/heads/*:refs/heads/*\n>         mirror\n> \n> ... so that I can check the state of the mirror with \"git log -1\n> mirror/master\", and still the push refspec is there so that my local remotes\n> are not entirely mirrored.\n\nAFAICT this contradicts everything in the original thread resulting in the \n--mirror patch.\n\nCiao,\nDscho\n"},{"id":"74980","messageId":"7vd4ohzvda.fsf@gitster.siamese.dyndns.org","threadId":"13209","inReplyTo":"alpine.DEB.1.00.0804221354180.4460@eeepc-johanness","subject":"Re: git remote update -> rejected","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-22T16:50:57Z","receivedAt":"2008-04-22T16:50:57Z","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> For your benefit, I just assume that you did not yet read my reply to \n> Peff's mail.\n>\n> With the --mirror mode, you can no longer discern clearly between local \n> and remote branches.  This is basically what we had in the beginning, \n> before the \"separate remotes layout\".\n>\n> So your point is not valid, an update will interfer with \"local\" branches.\n\nI personally do not think _your_ point is valid.  Doesn't --mirror mean\nyou do not have local branches?\n\nAt least that was my understanding of the intention of the --mirror\noption.  You give control away to the other end on the ref namespace, so\nthat you can treat it as a, eh, \"mirror\".  Perhaps you would want to have\na single such repository behind a firewall or this side of slow link and\nuse it as a feeder repository to serve many other clones on this side.\n\nI personally do not think --mirror option makes sense with --track, nor\nit makes sense in a non-bare repository for that matter.\n"},{"id":"74984","messageId":"7vtzhtygcf.fsf@gitster.siamese.dyndns.org","threadId":"13209","inReplyTo":"alpine.DEB.1.00.0804221250010.4460@eeepc-johanness","subject":"Re: git remote update -> rejected","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-22T17:00:48Z","receivedAt":"2008-04-22T17:00:48Z","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>> Dscho, is this a bug, or was there a conscious decision that I missed?\n> ...\n> But as I said, my rationale may very well be wrong.\n\nWhatever the rationale was, it is very wrong if the series was about\nrewriting the scripted version in another language.  That is an\nindependent behaviour change.\n\nAnd I do think the fix should be applied to --mirror case as well.  If it\ndoes not \"mirror\" as it is told, what use would there be?\n"},{"id":"74992","messageId":"alpine.DEB.1.00.0804221823010.4460@eeepc-johanness","threadId":"13209","inReplyTo":"7vd4ohzvda.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] remote add: disallow --master and --mirror with non-bare repositories","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-22T17:23:45Z","receivedAt":"2008-04-22T17:23:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nIn most cases, --master or --mirror in a non-bare repository is an\nerror.  In those cases where it is not, the user is most likely editing\nthe config herself anyway.\n\nSigned-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n\n---\n\n\tOn Tue, 22 Apr 2008, Junio C Hamano wrote:\n\n\t> I personally do not think --mirror option makes sense with \n\t> --track, nor it makes sense in a non-bare repository for that matter.\n\n\tObviously meant for application together with Peff's patch.\n\n builtin-remote.c |    6 ++++++\n 1 files changed, 6 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-remote.c b/builtin-remote.c\nindex d4f2132..63f025c 100644\n--- a/builtin-remote.c\n+++ b/builtin-remote.c\n@@ -79,6 +79,12 @@ static int add(int argc, const char **argv)\n \n \targc = parse_options(argc, argv, options, builtin_remote_usage, 0);\n \n+\tif (mirror && is_bare_repository())\n+\t\tdie(\"--mirror with non-bare repository.\");\n+\n+\tif (master && is_bare_repository())\n+\t\tdie(\"--master with non-bare repository.\");\n+\n \tif (argc < 2)\n \t\tusage_with_options(builtin_remote_usage, options);\n \n"},{"id":"75001","messageId":"480E324F.8050808@gnu.org","threadId":"13209","inReplyTo":"alpine.DEB.1.00.0804221823010.4460@eeepc-johanness","subject":"Re: [PATCH] remote add: disallow --master and --mirror with non-bare repositories","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-22T18:45:35Z","receivedAt":"2008-04-22T18:45:35Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Johannes Schindelin wrote:\n> In most cases, --master or --mirror in a non-bare repository is an\n> error.  In those cases where it is not, the user is most likely editing\n> the config herself anyway.\n\nAh, so I think we're speaking about two different features... sorry for \nthe noise.\n\nPaolo\n"},{"id":"75004","messageId":"480E3294.4070807@gnu.org","threadId":"13209","inReplyTo":"alpine.DEB.1.00.0804221823010.4460@eeepc-johanness","subject":"Re: [PATCH] remote add: disallow --master and --mirror with non-bare repositories (review)","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-22T18:46:44Z","receivedAt":"2008-04-22T18:46:44Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"> +\tif (mirror && is_bare_repository())\n> +\t\tdie(\"--mirror with non-bare repository.\");\n> +\n\nMissing bang.  I think you need to adjust the testsuite, in fact.\n\nPaolo\n"},{"id":"75014","messageId":"alpine.DEB.1.00.0804222304100.22360@eeepc-johanness","threadId":"13209","inReplyTo":"480E3294.4070807@gnu.org","subject":"Re: [PATCH] remote add: disallow --master and --mirror with non-bare repositories (review)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-22T22:04:35Z","receivedAt":"2008-04-22T22:04:35Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 22 Apr 2008, Paolo Bonzini wrote:\n\n> > +\tif (mirror && is_bare_repository())\n> > +\t\tdie(\"--mirror with non-bare repository.\");\n> > +\n> \n> Missing bang.  I think you need to adjust the testsuite, in fact.\n\nYep, I probably do.  If Junio nobody else beats me to it.\n\nCiao,\nDscho\n"}]}