{"thread":{"id":"19289","subject":"auto-merge after push?","startedAt":"2009-05-11T14:23:27Z","lastAt":"2009-07-16T08:01:39Z","messageCount":18,"participants":["Michael S. Tsirkin","Jakub Narebski","Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"113542","messageId":"20090511142326.GA18260@redhat.com","threadId":"19289","inReplyTo":null,"subject":"auto-merge after push?","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-05-11T14:23:27Z","receivedAt":"2009-05-11T14:23:27Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"Hi!\nI'm working on two machines, and git allows me to switch between them\nand sync by means of git pull. When one machine is behind a firewall, I\ncan sometimes only do pushes, but then I have to rememeber to merge when\nI log into remote machine.\n\nIs there a way to trigger merge on remote after push somehow,\nso that running on local machine:\n>git push remote\nwould be equivalent to\n>ssh remote git pull local\n\nThanks,\n-- \nMST\n"},{"id":"113544","messageId":"m34ovrn1ww.fsf@localhost.localdomain","threadId":"19289","inReplyTo":"20090511142326.GA18260@redhat.com","subject":"Re: auto-merge after push?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-05-11T14:35:45Z","receivedAt":"2009-05-11T14:35:45Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Michael S. Tsirkin\" <mst@redhat.com> writes:\n\n> Hi!\n> I'm working on two machines, and git allows me to switch between them\n> and sync by means of git pull. When one machine is behind a firewall, I\n> can sometimes only do pushes, but then I have to rememeber to merge when\n> I log into remote machine.\n> \n> Is there a way to trigger merge on remote after push somehow,\n> so that running on local machine:\n> $ git push remote\n> would be equivalent to\n> $ ssh remote git pull local\n\nIn general this is not possible, because pull can result in merge\nconflicts, which you cannot resolve without access.  Why not push into\nremotes, and when you are on second machine, complete pull by merging\nchanges?  See GitFaq (or GitTips, I don't remember which) where such\napproach is described in more detail.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"113548","messageId":"alpine.DEB.1.00.0905111714250.4973@intel-tinevez-2-302","threadId":"19289","inReplyTo":"20090511142326.GA18260@redhat.com","subject":"Re: auto-merge after push?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-05-11T15:18:06Z","receivedAt":"2009-05-11T15:18:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 11 May 2009, Michael S. Tsirkin wrote:\n\n> I'm working on two machines, and git allows me to switch between them \n> and sync by means of git pull. When one machine is behind a firewall, I \n> can sometimes only do pushes, but then I have to rememeber to merge when \n> I log into remote machine.\n> \n> Is there a way to trigger merge on remote after push somehow,\n> so that running on local machine:\n> >git push remote\n> would be equivalent to\n> >ssh remote git pull local\n\nHow about something like\n\n$ git config alias.reverse-pull '!sh -c \"git push remote HEAD:TO_MERGE && \\\n\tssh remote \\\"cd directory && \\\n\t\tgit merge TO_MERGE && git branch -d TO_MERGE\\\"\"'\n\n?\n\nThe thing is, a merge can fail.  And then you already need direct access \nto the working directory in question.\n\nIf you were actually talking about fast-forward pushes (because you did \nthe merge locally already), this might help you:\n\n\thttp://thread.gmane.org/gmane.comp.version-control.git/110251\n\nCiao,\nDscho\n"},{"id":"113583","messageId":"20090511201705.GA21045@redhat.com","threadId":"19289","inReplyTo":"alpine.DEB.1.00.0905111714250.4973@intel-tinevez-2-302","subject":"Re: auto-merge after push?","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-05-11T20:17:05Z","receivedAt":"2009-05-11T20:17:05Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:\n> The thing is, a merge can fail.  And then you already need direct access \n> to the working directory in question.\n> \n> If you were actually talking about fast-forward pushes (because you did \n> the merge locally already), this might help you:\n> \n> \thttp://thread.gmane.org/gmane.comp.version-control.git/110251\n> \n> Ciao,\n> Dscho\n\nSounds good. But it looks like this patch is unlikely to be merged,\ndoes it not?\n\n-- \nMST\n"},{"id":"113587","messageId":"alpine.DEB.1.00.0905112302130.27348@pacific.mpi-cbg.de","threadId":"19289","inReplyTo":"20090511201705.GA21045@redhat.com","subject":"Re: auto-merge after push?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-05-11T21:03:27Z","receivedAt":"2009-05-11T21:03:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 11 May 2009, Michael S. Tsirkin wrote:\n\n> On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:\n> > The thing is, a merge can fail.  And then you already need direct access \n> > to the working directory in question.\n> > \n> > If you were actually talking about fast-forward pushes (because you did \n> > the merge locally already), this might help you:\n> > \n> > \thttp://thread.gmane.org/gmane.comp.version-control.git/110251\n> \n> Sounds good. But it looks like this patch is unlikely to be merged, does \n> it not?\n\nUnlikely to be merged by Junio?  Without success stories, certainly.\n\nBut you can do the same as I did: run your local Git with that patch.  I \nam actually growing fonder and fonder of denyCurrentBranch=updateInstead.  \nIt works beautifully here.\n\nOf course, I always know what I am doing.\n\nCiao,\nDscho\n\nP.S.: :-)\n"},{"id":"113590","messageId":"20090511211339.GD21045@redhat.com","threadId":"19289","inReplyTo":"alpine.DEB.1.00.0905112302130.27348@pacific.mpi-cbg.de","subject":"Re: auto-merge after push?","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-05-11T21:13:39Z","receivedAt":"2009-05-11T21:13:39Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Mon, May 11, 2009 at 11:03:27PM +0200, Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 11 May 2009, Michael S. Tsirkin wrote:\n> \n> > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:\n> > > The thing is, a merge can fail.  And then you already need direct access \n> > > to the working directory in question.\n> > > \n> > > If you were actually talking about fast-forward pushes (because you did \n> > > the merge locally already), this might help you:\n> > > \n> > > \thttp://thread.gmane.org/gmane.comp.version-control.git/110251\n> > \n> > Sounds good. But it looks like this patch is unlikely to be merged, does \n> > it not?\n> \n> Unlikely to be merged by Junio?  Without success stories, certainly.\n> \n> But you can do the same as I did: run your local Git with that patch.  I \n> am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  \n> It works beautifully here.\n> \n> Of course, I always know what I am doing.\n> \n> Ciao,\n> Dscho\n> \n> P.S.: :-)\n\nBTW, what exactly happens on conflict?\n\n-- \nMST\n"},{"id":"113603","messageId":"alpine.DEB.1.00.0905120127320.27348@pacific.mpi-cbg.de","threadId":"19289","inReplyTo":"20090511211215.GC21045@redhat.com","subject":"Re: auto-merge after push?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-05-11T23:28:47Z","receivedAt":"2009-05-11T23:28:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[assuming that you did not mean this mail to be private, I send the answer \nto the Git list...]\n\nOn Tue, 12 May 2009, Michael S. Tsirkin wrote:\n\n> On Mon, May 11, 2009 at 11:03:27PM +0200, Johannes Schindelin wrote:\n> > Hi,\n> > \n> > On Mon, 11 May 2009, Michael S. Tsirkin wrote:\n> > \n> > > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:\n> > > > The thing is, a merge can fail.  And then you already need direct access \n> > > > to the working directory in question.\n> > > > \n> > > > If you were actually talking about fast-forward pushes (because you did \n> > > > the merge locally already), this might help you:\n> > > > \n> > > > \thttp://thread.gmane.org/gmane.comp.version-control.git/110251\n> > > \n> > > Sounds good. But it looks like this patch is unlikely to be merged, does \n> > > it not?\n> > \n> > Unlikely to be merged by Junio?  Without success stories, certainly.\n> > \n> > But you can do the same as I did: run your local Git with that patch.  I \n> > am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  \n> > It works beautifully here.\n> > \n> > Of course, I always know what I am doing.\n> > \n> > Ciao,\n> > Dscho\n> > \n> > P.S.: :-)\n> \n> OK. Could you send me the patch pls? gmane doesn't seem to have a \"send\n> to mail\" coption.\n\nIt has.  It is a hidden function by the bot known as \"Johannes \nSchindelin\", listening on git@vger.kernel.org for requests:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/110251/raw\n\nCiao,\nDscho\n"},{"id":"113604","messageId":"alpine.DEB.1.00.0905120128510.27348@pacific.mpi-cbg.de","threadId":"19289","inReplyTo":"20090511211339.GD21045@redhat.com","subject":"Re: auto-merge after push?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-05-11T23:29:20Z","receivedAt":"2009-05-11T23:29:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 12 May 2009, Michael S. Tsirkin wrote:\n\n> On Mon, May 11, 2009 at 11:03:27PM +0200, Johannes Schindelin wrote:\n> \n> > On Mon, 11 May 2009, Michael S. Tsirkin wrote:\n> > \n> > > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:\n> > > > The thing is, a merge can fail.  And then you already need direct access \n> > > > to the working directory in question.\n> > > > \n> > > > If you were actually talking about fast-forward pushes (because you did \n> > > > the merge locally already), this might help you:\n> > > > \n> > > > \thttp://thread.gmane.org/gmane.comp.version-control.git/110251\n> > > \n> > > Sounds good. But it looks like this patch is unlikely to be merged, does \n> > > it not?\n> > \n> > Unlikely to be merged by Junio?  Without success stories, certainly.\n> > \n> > But you can do the same as I did: run your local Git with that patch.  I \n> > am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  \n> > It works beautifully here.\n> > \n> > Of course, I always know what I am doing.\n> \n> BTW, what exactly happens on conflict?\n\nWith this patch?  The push is refused.\n\nCiao,\nDscho\n"},{"id":"114246","messageId":"20090519093618.GA29601@redhat.com","threadId":"19289","inReplyTo":"alpine.DEB.1.00.0905112302130.27348@pacific.mpi-cbg.de","subject":"Re: auto-merge after push?","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-05-19T09:36:18Z","receivedAt":"2009-05-19T09:36:18Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Mon, May 11, 2009 at 11:03:27PM +0200, Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 11 May 2009, Michael S. Tsirkin wrote:\n> \n> > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:\n> > > The thing is, a merge can fail.  And then you already need direct access \n> > > to the working directory in question.\n> > > \n> > > If you were actually talking about fast-forward pushes (because you did \n> > > the merge locally already), this might help you:\n> > > \n> > > \thttp://thread.gmane.org/gmane.comp.version-control.git/110251\n> > \n> > Sounds good. But it looks like this patch is unlikely to be merged, does \n> > it not?\n> \n> Unlikely to be merged by Junio?  Without success stories, certainly.\n> \n> But you can do the same as I did: run your local Git with that patch.  I \n> am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  \n> It works beautifully here.\n\nSame here. I've been using denyCurrentBranch=updateInstead for about a\nweek now. I find very useful.\n\n> Of course, I always know what I am doing.\n\nHaven't seen any issues so far.\n\n\n> Ciao,\n> Dscho\n> \n> P.S.: :-)\n\n-- \nMST\n"},{"id":"116066","messageId":"20090611104020.GA12036@redhat.com","threadId":"19289","inReplyTo":"alpine.DEB.1.00.0905112302130.27348@pacific.mpi-cbg.de","subject":"Re: auto-merge after push?","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-06-11T10:40:20Z","receivedAt":"2009-06-11T10:40:20Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Mon, May 11, 2009 at 11:03:27PM +0200, Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 11 May 2009, Michael S. Tsirkin wrote:\n> \n> > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:\n> > > The thing is, a merge can fail.  And then you already need direct access \n> > > to the working directory in question.\n> > > \n> > > If you were actually talking about fast-forward pushes (because you did \n> > > the merge locally already), this might help you:\n> > > \n> > > \thttp://thread.gmane.org/gmane.comp.version-control.git/110251\n> > \n> > Sounds good. But it looks like this patch is unlikely to be merged, does \n> > it not?\n> \n> Unlikely to be merged by Junio?  Without success stories, certainly.\n> \n> But you can do the same as I did: run your local Git with that patch.  I \n> am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  \n> It works beautifully here.\n> \n> Of course, I always know what I am doing.\n> \n> Ciao,\n> Dscho\n> \n> P.S.: :-)\n\nSo here's a success story:\n\nI have been using this patch for 1 month now, on all my trees, with\ndenyCurrentBranch=updateInstead\nI find it very useful for several reasons:\n- I commit on my development machine, then push to test machine\n- I debug and fix an issue on test machine, push change back to devel machine\n- If I'm going from home to the office, I just push into the machine at the office, and when\n  I get there the tree is set up and ready for me to hack on, same on my way back\n\nOf course all the same things can be accomplished with a set of scripts,\nbut frankly I never got them to be as flexible and easy to use as this\npatch. This patch simply works for me. Thanks for it Johannes, and I\nhope it makes it into upstream at some point, so that more people can\nbenefit from it.\n\n-- \nMST\n"},{"id":"117843","messageId":"20090711203831.GA10875@redhat.com","threadId":"19289","inReplyTo":"20090611104020.GA12036@redhat.com","subject":"Re: auto-merge after push?","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-07-11T20:38:31Z","receivedAt":"2009-07-11T20:38:31Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Thu, Jun 11, 2009 at 01:40:20PM +0300, Michael S. Tsirkin wrote:\n> On Mon, May 11, 2009 at 11:03:27PM +0200, Johannes Schindelin wrote:\n> > Hi,\n> > \n> > On Mon, 11 May 2009, Michael S. Tsirkin wrote:\n> > \n> > > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:\n> > > > The thing is, a merge can fail.  And then you already need direct access \n> > > > to the working directory in question.\n> > > > \n> > > > If you were actually talking about fast-forward pushes (because you did \n> > > > the merge locally already), this might help you:\n> > > > \n> > > > \thttp://thread.gmane.org/gmane.comp.version-control.git/110251\n> > > \n> > > Sounds good. But it looks like this patch is unlikely to be merged, does \n> > > it not?\n> > \n> > Unlikely to be merged by Junio?  Without success stories, certainly.\n> > \n> > But you can do the same as I did: run your local Git with that patch.  I \n> > am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  \n> > It works beautifully here.\n> > \n> > Of course, I always know what I am doing.\n> > \n> > Ciao,\n> > Dscho\n> > \n> > P.S.: :-)\n> \n> So here's a success story:\n> \n> I have been using this patch for 1 month now, on all my trees, with\n> denyCurrentBranch=updateInstead\n> I find it very useful for several reasons:\n> - I commit on my development machine, then push to test machine\n> - I debug and fix an issue on test machine, push change back to devel machine\n> - If I'm going from home to the office, I just push into the machine at the office, and when\n>   I get there the tree is set up and ready for me to hack on, same on my way back\n> \n> Of course all the same things can be accomplished with a set of scripts,\n> but frankly I never got them to be as flexible and easy to use as this\n> patch. This patch simply works for me. Thanks for it Johannes, and I\n> hope it makes it into upstream at some point, so that more people can\n> benefit from it.\n\nHey, Johannes, so .. how about trying to push it out to Junio?\nMaybe if this lands in pu more people will try it and there\nwill be more success stories?\n\n-- \nMST\n"},{"id":"117849","messageId":"alpine.DEB.1.00.0907120441440.3155@pacific.mpi-cbg.de","threadId":"19289","inReplyTo":"20090711203831.GA10875@redhat.com","subject":"Re: auto-merge after push?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-07-12T02:42:03Z","receivedAt":"2009-07-12T02:42:03Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 11 Jul 2009, Michael S. Tsirkin wrote:\n\n> On Thu, Jun 11, 2009 at 01:40:20PM +0300, Michael S. Tsirkin wrote:\n> > On Mon, May 11, 2009 at 11:03:27PM +0200, Johannes Schindelin wrote:\n> > > Hi,\n> > > \n> > > On Mon, 11 May 2009, Michael S. Tsirkin wrote:\n> > > \n> > > > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:\n> > > > > The thing is, a merge can fail.  And then you already need direct access \n> > > > > to the working directory in question.\n> > > > > \n> > > > > If you were actually talking about fast-forward pushes (because you did \n> > > > > the merge locally already), this might help you:\n> > > > > \n> > > > > \thttp://thread.gmane.org/gmane.comp.version-control.git/110251\n> > > > \n> > > > Sounds good. But it looks like this patch is unlikely to be merged, does \n> > > > it not?\n> > > \n> > > Unlikely to be merged by Junio?  Without success stories, certainly.\n> > > \n> > > But you can do the same as I did: run your local Git with that patch.  I \n> > > am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  \n> > > It works beautifully here.\n> > > \n> > > Of course, I always know what I am doing.\n> > > \n> > > Ciao,\n> > > Dscho\n> > > \n> > > P.S.: :-)\n> > \n> > So here's a success story:\n> > \n> > I have been using this patch for 1 month now, on all my trees, with\n> > denyCurrentBranch=updateInstead\n> > I find it very useful for several reasons:\n> > - I commit on my development machine, then push to test machine\n> > - I debug and fix an issue on test machine, push change back to devel machine\n> > - If I'm going from home to the office, I just push into the machine at the office, and when\n> >   I get there the tree is set up and ready for me to hack on, same on my way back\n> > \n> > Of course all the same things can be accomplished with a set of scripts,\n> > but frankly I never got them to be as flexible and easy to use as this\n> > patch. This patch simply works for me. Thanks for it Johannes, and I\n> > hope it makes it into upstream at some point, so that more people can\n> > benefit from it.\n> \n> Hey, Johannes, so .. how about trying to push it out to Junio?\n> Maybe if this lands in pu more people will try it and there\n> will be more success stories?\n\nWell, I use it myself, what more can I say?\n\nCiao,\nDscho\n"},{"id":"117874","messageId":"7vocrplhbv.fsf@alter.siamese.dyndns.org","threadId":"19289","inReplyTo":"alpine.DEB.1.00.0907120441440.3155@pacific.mpi-cbg.de","subject":"Re: auto-merge after push?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-12T21:30:44Z","receivedAt":"2009-07-12T21:30: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> Well, I use it myself, what more can I say?\n\nIt's rather hard to justify a feature that is available to the general\npublic with documentation that only says \"we tell you what happens in\nterms of low-level commands when you use this feature, we warn you that\nthis has its own set of possible complications, but we do not specify what\nthey are, nor how to recover from them. You should know what you are doing\nif you choose to use it\".\n\nThat is not very helpful.\n\nIf this _were_ implemented as a sample hook on the receiving end, with\nample comments that the users can read to undersand the issues before\ndeciding to install it on their repositories, it might have been an easier\nsell.\n\nIf Dscho is short on time, perhaps somebody else can improve upon the\ndocumentation part of the patch?  It's a long time ago that I took a look\nat the patch text itself but I had a recorrection that the code itself was\nreasonable (and it is a well known fact that I tend not to notice bugs in\nDscho's code so it is not a very useful thing for me to go back to look at\nthe code again now when I am short on brain cycles).\n"},{"id":"117880","messageId":"alpine.DEB.1.00.0907130028350.3155@pacific.mpi-cbg.de","threadId":"19289","inReplyTo":"7vocrplhbv.fsf@alter.siamese.dyndns.org","subject":"Re: auto-merge after push?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-07-12T22:31:07Z","receivedAt":"2009-07-12T22:31:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 12 Jul 2009, Junio C Hamano wrote:\n\n> If Dscho is short on time, perhaps somebody else can improve upon the\n> documentation part of the patch?\n\nThat would be fabulous.  It is not looking as if my Git time balance is \ngoing to improve (as far as Git is concerned) now that I accepted to take \non more responsibilities in my day job.\n\nIt does not help, of course, that I wanted this jgit gui toy out to the \npublic, either.\n\nCiao,\nDscho\n"},{"id":"118030","messageId":"20090715145430.GB9075@redhat.com","threadId":"19289","inReplyTo":"7vocrplhbv.fsf@alter.siamese.dyndns.org","subject":"Re: auto-merge after push?","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-07-15T14:54:30Z","receivedAt":"2009-07-15T14:54:30Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Sun, Jul 12, 2009 at 02:30:44PM -0700, Junio C Hamano wrote:\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > Well, I use it myself, what more can I say?\n> \n> It's rather hard to justify a feature that is available to the general\n> public with documentation that only says \"we tell you what happens in\n> terms of low-level commands when you use this feature, we warn you that\n> this has its own set of possible complications, but we do not specify what\n> they are, nor how to recover from them. You should know what you are doing\n> if you choose to use it\".\n> \n> That is not very helpful.\n> \n> If this _were_ implemented as a sample hook on the receiving end, with\n> ample comments that the users can read to undersand the issues before\n> deciding to install it on their repositories, it might have been an easier\n> sell.\n> \n> If Dscho is short on time, perhaps somebody else can improve upon the\n> documentation part of the patch?  It's a long time ago that I took a look\n> at the patch text itself but I had a recorrection that the code itself was\n> reasonable (and it is a well known fact that I tend not to notice bugs in\n> Dscho's code so it is not a very useful thing for me to go back to look at\n> the code again now when I am short on brain cycles).\n> \n\nSo, let me summarize the issues:\n- if the tree is pushed into while files are being actively read\n  (e.g. built from), the build will get an inconsistent state\n- even worse if one of the files is open for editing or is being written\n  into: the file will get corrupted\n- if there are uncommitted changes in the tree, the push is denied\n\nAre there others?\n\n-- \nMST\n"},{"id":"118042","messageId":"7v1vohg2vf.fsf@alter.siamese.dyndns.org","threadId":"19289","inReplyTo":"20090715145430.GB9075@redhat.com","subject":"Re: auto-merge after push?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-15T19:31:00Z","receivedAt":"2009-07-15T19:31:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" <mst@redhat.com> writes:\n\n> So, let me summarize the issues:\n> - if the tree is pushed into while files are being actively read\n>   (e.g. built from), the build will get an inconsistent state\n> - even worse if one of the files is open for editing or is being written\n>   into: the file will get corrupted\n> - if there are uncommitted changes in the tree, the push is denied\n>\n> Are there others?\n\n - If you choose to detach-on-push, the user who _thought_ was advancing\n   the history of a branch using the work tree will get very confusing\n   results.  The branch will be advanced by the push, and the work tree\n   user is required to notice the situation, later at some point merging\n   the work done in the work tree that went to the detached HEAD state.\n\n - What happens if the automerge gets conflict?\n\nHaving said that, I think it is a _wrong_ approach to try summarizing the\nissues along these lines, without stating the most fundamental restriction.\n\nIf the push-from-sideways is done without any coordination between the\nperson pushes and the person who uses the work tree, _any_ solution that\nmodifies the work tree behind the back of that work-tree person will not\nwork without surprising him, so listing the possible surprises is\npointless.\n\nOn the other hand, all of the above \"issues\" (including yours) will become\nonly implementation details of a workflow when there is a coordination\nbetween the pusher and the work-tree person.  In the most trivial case,\nboth are you, and the repository with the work tree is your private\nworking area.\n\nSo I would suggest stressing the need for this coordination before\nstarting to list the \"issues\".\n\nBe it \"detach\" or \"automerge\", the workflow helped with the patch is\nmerely a deviation of the mothership-satellite configuration (look for\n\"satellite\" in the FAQ) where you push from satellite to mothership (each\nhas its own work tree) to achieve logically what you would want to perform\nwith a pull in the other direction, that is:\n\n satellite$ git push mothership:project master:refs/remotes/satellite/master\n satellite$ ssh mothership 'cd project && git merge remotes/satellite/master'\n\nThe necessary \"coordination\" between the two repositories is that the last\nstep, \"merge what was pushed\", must be done when the work tree checked out\nin the mothership repository is in a state that is suitable for performing\nthe merge, e.g. no extra change to the index that is unrelated to the\nmerge, no local change that interferes with the merge, etc.\n\nThe auto-merge-upon-push patch by Dscho, however, places a further\nrestriction on top of the stock satellite-mothership configuration,\nexactly because it is automated.  In an unautomated workflow, you can\nafford to choose _when_ to merge, independent from when to push:\n\n satellite$ git push mothership:project master:refs/remotes/satellite/master\n satellite$ ssh mothership\n mothership$ cd project\n ... work further to finish off what you did on the mothership ...\n mothership$ git commit\n mothership$ git merge remotes/satellite/master\n\nTypically, when you are done (for the day, for example) on satellite, you\npush it out to the mothership, even though the mothership repository's\nwork tree may have independent local changes (aka WIP) you have left when\nyou last worked there.  After switching to work in the mothership, you\ncan continue working on the WIP to finish it before merging what you did\non the satellite the previous day.\n\nThe automated way will trade this flexibility off with convenience (you do\nnot have to have the interactive session on the mothership only to perform\nthe merge), so you will be required to leave the mothership work tree and\nthe index in a good shape any time you might want to push into it from the\nsatellite.  It is a small price to pay, and depending on the situation\n(the most obvious is when you do not even have an interactive shell access\nto the mothership) you may not even have that flexibility to begin with,\nin which case there is no downside.\n"},{"id":"118044","messageId":"20090715195718.GA12033@redhat.com","threadId":"19289","inReplyTo":"7v1vohg2vf.fsf@alter.siamese.dyndns.org","subject":"Re: auto-merge after push?","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2009-07-15T19:57:18Z","receivedAt":"2009-07-15T19:57:18Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Wed, Jul 15, 2009 at 12:31:00PM -0700, Junio C Hamano wrote:\n> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n> \n> > So, let me summarize the issues:\n> > - if the tree is pushed into while files are being actively read\n> >   (e.g. built from), the build will get an inconsistent state\n> > - even worse if one of the files is open for editing or is being written\n> >   into: the file will get corrupted\n> > - if there are uncommitted changes in the tree, the push is denied\n> >\n> > Are there others?\n> \n>  - If you choose to detach-on-push, the user who _thought_ was advancing\n>    the history of a branch using the work tree will get very confusing\n>    results.  The branch will be advanced by the push, and the work tree\n>    user is required to notice the situation, later at some point merging\n>    the work done in the work tree that went to the detached HEAD state.\n\nI never use detach on push. Let's remove that option for now?\n\n>  - What happens if the automerge gets conflict?\n\npush is denied, unless you push with -f, then I think you get the new\nhead.  Note that merge is not the right word here: only fast forward is\ndone I think.  Right, Dscho?\n\n> Having said that, I think it is a _wrong_ approach to try summarizing the\n> issues along these lines, without stating the most fundamental restriction.\n\nSure. I am just trying to figure out all the details before I try to\nwrite this up. The coordination issue is obviously the main thing, I was\ntrying to enumerate the less obvious ones.\n\n> If the push-from-sideways is done without any coordination between the\n> person pushes and the person who uses the work tree, _any_ solution that\n> modifies the work tree behind the back of that work-tree person will not\n> work without surprising him, so listing the possible surprises is\n> pointless.\n> \n> On the other hand, all of the above \"issues\" (including yours) will become\n> only implementation details of a workflow when there is a coordination\n> between the pusher and the work-tree person.  In the most trivial case,\n> both are you, and the repository with the work tree is your private\n> working area.\n> \n> So I would suggest stressing the need for this coordination before\n> starting to list the \"issues\".\n> \n> Be it \"detach\" or \"automerge\", the workflow helped with the patch is\n> merely a deviation of the mothership-satellite configuration (look for\n> \"satellite\" in the FAQ) where you push from satellite to mothership (each\n> has its own work tree) to achieve logically what you would want to perform\n> with a pull in the other direction, that is:\n> \n>  satellite$ git push mothership:project master:refs/remotes/satellite/master\n>  satellite$ ssh mothership 'cd project && git merge remotes/satellite/master'\n> \n> The necessary \"coordination\" between the two repositories is that the last\n> step, \"merge what was pushed\", must be done when the work tree checked out\n> in the mothership repository is in a state that is suitable for performing\n> the merge, e.g. no extra change to the index that is unrelated to the\n> merge, no local change that interferes with the merge, etc.\n> \n> The auto-merge-upon-push patch by Dscho, however, places a further\n> restriction on top of the stock satellite-mothership configuration,\n> exactly because it is automated.  In an unautomated workflow, you can\n> afford to choose _when_ to merge, independent from when to push:\n> \n>  satellite$ git push mothership:project master:refs/remotes/satellite/master\n>  satellite$ ssh mothership\n>  mothership$ cd project\n>  ... work further to finish off what you did on the mothership ...\n>  mothership$ git commit\n>  mothership$ git merge remotes/satellite/master\n> \n> Typically, when you are done (for the day, for example) on satellite, you\n> push it out to the mothership, even though the mothership repository's\n> work tree may have independent local changes (aka WIP) you have left when\n> you last worked there.  After switching to work in the mothership, you\n> can continue working on the WIP to finish it before merging what you did\n> on the satellite the previous day.\n> \n> The automated way will trade this flexibility off with convenience (you do\n> not have to have the interactive session on the mothership only to perform\n> the merge), so you will be required to leave the mothership work tree and\n> the index in a good shape any time you might want to push into it from the\n> satellite.  It is a small price to pay, and depending on the situation\n> (the most obvious is when you do not even have an interactive shell access\n> to the mothership) you may not even have that flexibility to begin with,\n> in which case there is no downside.\n\nThanks for the explanation.\n"},{"id":"118092","messageId":"alpine.DEB.1.00.0907160953580.3155@pacific.mpi-cbg.de","threadId":"19289","inReplyTo":"20090715195718.GA12033@redhat.com","subject":"Re: auto-merge after push?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-07-16T08:01:39Z","receivedAt":"2009-07-16T08:01:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 15 Jul 2009, Michael S. Tsirkin wrote:\n\n> On Wed, Jul 15, 2009 at 12:31:00PM -0700, Junio C Hamano wrote:\n> > \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n> > \n> > > So, let me summarize the issues:\n> > > - if the tree is pushed into while files are being actively read\n> > >   (e.g. built from), the build will get an inconsistent state\n> > > - even worse if one of the files is open for editing or is being written\n> > >   into: the file will get corrupted\n> > > - if there are uncommitted changes in the tree, the push is denied\n> > >\n> > > Are there others?\n> > \n> >  - If you choose to detach-on-push, the user who _thought_ was advancing\n> >    the history of a branch using the work tree will get very confusing\n> >    results.  The branch will be advanced by the push, and the work tree\n> >    user is required to notice the situation, later at some point merging\n> >    the work done in the work tree that went to the detached HEAD state.\n> \n> I never use detach on push. Let's remove that option for now?\n\nI do not use it.  But I added it upon explicit request.\n\n> >  - What happens if the automerge gets conflict?\n> \n> push is denied, unless you push with -f, then I think you get the new\n> head.  Note that merge is not the right word here: only fast forward is\n> done I think.  Right, Dscho?\n\nLemme look at that patch (it is pretty old by now...).\n\nActually, my patch has nothing to do with allowing only fast-forwards \nunless the push is forced.\n\nThe documentation states that a read-tree -u -m HEAD is performed.  This \ncan fail when a file is not up-to-date.  As far as I can tell, read-tree \n-u -m HEAD refuses to update the index in such a situation.\n\nSo if there are files to be updated by the push which are dirty, the push \nwill update the ref as requested, nevertheless error out, the index will \nbe untouched, and so will be the working directory (unless I fscked up the \npatch, which is quite possible, as I was writing this just to get a \nquieter mailing list again).\n\nOne thing I got right, though, was the commit message.\n\n> > Having said that, I think it is a _wrong_ approach to try summarizing \n> > the issues along these lines, without stating the most fundamental \n> > restriction.\n> \n> Sure. I am just trying to figure out all the details before I try to \n> write this up. The coordination issue is obviously the main thing, I was \n> trying to enumerate the less obvious ones.\n\nHappily enough, it is the duty of the local guy to actually set the config \nvariable.  And to allow the other guy (who might be one and the same guy a \nla \"I am schizophrenic and me too\") is also the privilege of the local \nguy.\n\nCiao,\nDscho\n"}]}