{"thread":{"id":"41930","subject":"Triangular workflows and some anecdotes from the trenches","startedAt":"2016-04-05T11:06:06Z","lastAt":"2016-04-06T17:01:26Z","messageCount":4,"participants":["Chris Packham","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"282697","messageId":"CAFOYHZARoEXkT6kVy7+wMSqUxSVVHHMV5KfhU6FON3tB6XEuMg@mail.gmail.com","threadId":"41930","inReplyTo":null,"subject":"Triangular workflows and some anecdotes from the trenches","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2016-04-05T11:06:06Z","receivedAt":"2016-04-05T11:06:06Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Hi,\n\nWe ran into something at $dayjob the other day. The actual problem was\na developer ended up amending a commit that had already been pushed.\nIt happens occasionally and is usually recoverable with a simple\nrebase and is generally a learning experience. In this particular case\nhowever things were a bit more complicated.\n\nWe had (attempted to) setup a triangular workflow. The developers\nwould fetch from a server that was closer to them but push to the\ncentral server that was at the other end of a WAN link. Our build\nsystem would update the local server after a successful build for all\nconfigurations. The problem was instead of setting\nbranch..pushdefault we were setting remote.origin.pushurl. So\nnow the warning in git-remote(1) comes back to bite us and a lot of\nhead scratching ensues.\n\nIt appears that the triangular workflow support is under-documented\n(mentioned in a couple of release notes and gitrevisions). I'm not\nsuggesting we would have done the right thing if the documentation\nexisted but we would have had a chance. Once we get our setup sorted\nI'll try and send an update for gitworkflows.txt (unless someone else\nbeats me to it). There are a few blog post around the Internet that I\nmight be able to draw upon.\n\nThe subject of preventing modifying published history has come up on\nthis list before. And in-fact it's relatively simple to implement as\nan alias\n\n git config alias.amend '!git merge-base --is-ancestor HEAD\n@{upstream} || git commit --amend'\n\nI'm just wondering if something more official can be added to git\ncommit --amend (and probably git rebase).\n\nFinally I was wondering if there is any way of detecting if\nremote.*.pushurl and remote.*.url point to the same repo, although I'm\nnot sure when you'd do such verification.\n\nThanks,\nChris\n"},{"id":"282739","messageId":"xmqq37qz1ypa.fsf@gitster.mtv.corp.google.com","threadId":"41930","inReplyTo":"CAFOYHZARoEXkT6kVy7+wMSqUxSVVHHMV5KfhU6FON3tB6XEuMg@mail.gmail.com","subject":"Re: Triangular workflows and some anecdotes from the trenches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-04-05T22:24:17Z","receivedAt":"2016-04-05T22:24:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Packham writes:\n\n> We ran into something at $dayjob the other day. The actual problem was\n> a developer ended up amending a commit that had already been pushed.\n> It happens occasionally and is usually recoverable with a simple\n> rebase and is generally a learning experience. In this particular case\n> however things were a bit more complicated.\n\nDeveloper ending up amending is not an issue per-se, unless the\nresult is pushed back to the public.\n\nHowever, it would be nicer if \"git commit --amend\", \"git rebase\",\n\"git branch -f\", and \"git checkout -B\" notices the situation and\nwarns about what would happen.\n\n> git config alias.amend '!git merge-base --is-ancestor HEAD\n> @{upstream} || git commit --amend'\n>\n> I'm just wondering if something more official can be added to git\n> commit --amend (and probably git rebase).\n\nA bigger problem may be how you make sure everybody sets up\n@{upstream} correctly. You may fork your own copy of a branch from\nthe target branch, start working on it, further fork other branches\non your work to experiment different approaches, with the intention\nto later use the best one to update your first fork.\n\nAt which point, the @{upstream} of the secondary branches are your\nown first branch, not the public one--which is not a problem per-se,\nbecause your first branch (whose @{upstream} is the remote one) is\nnot yet public and you should be allowed to freely update it to\npolish it by rewriting. But then after you push out your first\nbranch as an interim snapshot to the public, you no longer want to\nrewrite the commits reachable from it. So (to put it mildly) it\nwould be quite complex to get all the corner cases right, and the\ndefinition of \"right\" would probably depend on the exact workflow.\n"},{"id":"282757","messageId":"CAFOYHZDx1cqwUnR9E=RQKboSfF4gWDjERvEWQA_YePZq64QarQ@mail.gmail.com","threadId":"41930","inReplyTo":"xmqq37qz1ypa.fsf@gitster.mtv.corp.google.com","subject":"Re: Triangular workflows and some anecdotes from the trenches","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2016-04-06T08:30:29Z","receivedAt":"2016-04-06T08:30:29Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Wed, Apr 6, 2016 at 10:24 AM, Junio C Hamano wrote:\n> Chris Packham writes:\n>\n>> We ran into something at $dayjob the other day. The actual problem was\n>> a developer ended up amending a commit that had already been pushed.\n>> It happens occasionally and is usually recoverable with a simple\n>> rebase and is generally a learning experience. In this particular case\n>> however things were a bit more complicated.\n>\n> Developer ending up amending is not an issue per-se, unless the\n> result is pushed back to the public.\n\nCorrect and that was when the developer in question realised he had a problem.\n\n> However, it would be nicer if \"git commit --amend\", \"git rebase\",\n> \"git branch -f\", and \"git checkout -B\" notices the situation and\n> warns about what would happen.\n>\n>> git config alias.amend '!git merge-base --is-ancestor HEAD\n>> @{upstream} || git commit --amend'\n>>\n>> I'm just wondering if something more official can be added to git\n>> commit --amend (and probably git rebase).\n>\n> A bigger problem may be how you make sure everybody sets up\n> @{upstream} correctly. You may fork your own copy of a branch from\n> the target branch, start working on it, further fork other branches\n> on your work to experiment different approaches, with the intention\n> to later use the best one to update your first fork.\n>\n> At which point, the @{upstream} of the secondary branches are your\n> own first branch, not the public one--which is not a problem per-se,\n> because your first branch (whose @{upstream} is the remote one) is\n> not yet public and you should be allowed to freely update it to\n> polish it by rewriting. But then after you push out your first\n> branch as an interim snapshot to the public, you no longer want to\n> rewrite the commits reachable from it. So (to put it mildly) it\n> would be quite complex to get all the corner cases right, and the\n> definition of \"right\" would probably depend on the exact workflow.\n>\n\nI think you could still argue that if @{upstream} exists. Warn about\n(or disallow) re-writing anything anything that is reachable from it.\nThere is still the possibility of if someone else rewinding\n@{upstream} on you and I think the scenario you've highlighted is just\na case of doing it to yourself.\n\nIf you do want do want to re-write history you can still do so either\nby not setting @{upstream} or setting core.IKnowWhatImDoing = 1.\n"},{"id":"282777","messageId":"xmqqbn5my8m1.fsf@gitster.mtv.corp.google.com","threadId":"41930","inReplyTo":"CAFOYHZDx1cqwUnR9E=RQKboSfF4gWDjERvEWQA_YePZq64QarQ@mail.gmail.com","subject":"Re: Triangular workflows and some anecdotes from the trenches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-04-06T17:01:26Z","receivedAt":"2016-04-06T17:01:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Packham writes:\n\n> On Wed, Apr 6, 2016 at 10:24 AM, Junio C Hamano wrote:\n>\n>> Developer ending up amending is not an issue per-se, unless the\n>> result is pushed back to the public.\n>\n> Correct and that was when the developer in question realised he had a problem.\n\nBut then \"push\" would have failed and correcting would all be local,\nno?\n\n>> A bigger problem may be how you make sure everybody sets up\n>> @{upstream} correctly. You may fork your own copy of a branch from\n>> the target branch, start working on it, further fork other branches\n>> on your work to experiment different approaches, with the intention\n>> to later use the best one to update your first fork.\n>>\n>> At which point, the @{upstream} of the secondary branches are your\n>> own first branch, not the public one--which is not a problem per-se,\n>> because your first branch (whose @{upstream} is the remote one) is\n>> not yet public and you should be allowed to freely update it to\n>> polish it by rewriting. But then after you push out your first\n>> branch as an interim snapshot to the public, you no longer want to\n>> rewrite the commits reachable from it. So (to put it mildly) it\n>> would be quite complex to get all the corner cases right, and the\n>> definition of \"right\" would probably depend on the exact workflow.\n>\n> I think you could still argue that if @{upstream} exists. Warn about\n> (or disallow) re-writing anything anything that is reachable from it.\n>\n> There is still the possibility of if someone else rewinding\n> @{upstream} on you and I think the scenario you've highlighted is just\n> a case of doing it to yourself.\n\nBut at that point, you are not doing much to help the normal users.\nI was actually expecting a response with a different approach, e.g.\ninstead of relying on @{upstream} that may or may not serve as a\ngood check anyway, make sure nothing reachable from any of the\nrefs in refs/remotes/* is not updated by amend or rebase.\n"}]}