threads / discuss / 41930

Triangular workflows and some anecdotes from the trenches

Subject: Triangular workflows and some anecdotes from the trenches

## tl;dr

4 messages between Apr 5, 2016 and Apr 6, 2016.

replies: 3people: 2as markdown or json

Chris Packham· Apr 5, 2016, 11:06 UTC · lore

Hi,

We ran into something at $dayjob the other day. The actual problem was a developer ended up amending a commit that had already been pushed. It happens occasionally and is usually recoverable with a simple rebase and is generally a learning experience. In this particular case however things were a bit more complicated.

We had (attempted to) setup a triangular workflow. The developers would fetch from a server that was closer to them but push to the central server that was at the other end of a WAN link. Our build system would update the local server after a successful build for all configurations. The problem was instead of setting branch.<name>.pushdefault we were setting remote.origin.pushurl. So now the warning in git-remote(1) comes back to bite us and a lot of head scratching ensues.

It appears that the triangular workflow support is under-documented (mentioned in a couple of release notes and gitrevisions). I'm not suggesting we would have done the right thing if the documentation existed but we would have had a chance. Once we get our setup sorted I'll try and send an update for gitworkflows.txt (unless someone else beats me to it). There are a few blog post around the Internet that I might be able to draw upon.

The subject of preventing modifying published history has come up on this list before. And in-fact it's relatively simple to implement as an alias

  git config alias.amend '!git merge-base --is-ancestor HEAD
@{upstream} || git commit --amend'

I'm just wondering if something more official can be added to git commit --amend (and probably git rebase).

Finally I was wondering if there is any way of detecting if remote.*.pushurl and remote.*.url point to the same repo, although I'm not sure when you'd do such verification.

Thanks, Chris

Junio C Hamano· Apr 5, 2016, 22:24 UTC · re: Chris Packham · lore

Re: Triangular workflows and some anecdotes from the trenches

Chris Packham <judge.packham@gmail.com> writes:

Show 5 quoted lines

> We ran into something at $dayjob the other day. The actual problem was
> a developer ended up amending a commit that had already been pushed.
> It happens occasionally and is usually recoverable with a simple
> rebase and is generally a learning experience. In this particular case
> however things were a bit more complicated.

Developer ending up amending is not an issue per-se, unless the result is pushed back to the public.

However, it would be nicer if "git commit --amend", "git rebase", "git branch -f", and "git checkout -B" notices the situation and warns about what would happen.

Show 5 quoted lines

>   git config alias.amend '!git merge-base --is-ancestor HEAD
> @{upstream} || git commit --amend'
>
> I'm just wondering if something more official can be added to git
> commit --amend (and probably git rebase).

A bigger problem may be how you make sure everybody sets up @{upstream} correctly. You may fork your own copy of a branch from the target branch, start working on it, further fork other branches on your work to experiment different approaches, with the intention to later use the best one to update your first fork.

At which point, the @{upstream} of the secondary branches are your own first branch, not the public one--which is not a problem per-se, because your first branch (whose @{upstream} is the remote one) is not yet public and you should be allowed to freely update it to polish it by rewriting. But then after you push out your first branch as an interim snapshot to the public, you no longer want to rewrite the commits reachable from it. So (to put it mildly) it would be quite complex to get all the corner cases right, and the definition of "right" would probably depend on the exact workflow.

Chris Packham· Apr 6, 2016, 08:30 UTC · re: Junio C Hamano · lore

Re: Triangular workflows and some anecdotes from the trenches

On Wed, Apr 6, 2016 at 10:24 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> Chris Packham <judge.packham@gmail.com> writes:
>
>> We ran into something at $dayjob the other day. The actual problem was
>> a developer ended up amending a commit that had already been pushed.
>> It happens occasionally and is usually recoverable with a simple
>> rebase and is generally a learning experience. In this particular case
>> however things were a bit more complicated.
>
> Developer ending up amending is not an issue per-se, unless the
> result is pushed back to the public.

Correct and that was when the developer in question realised he had a problem.

Show 26 quoted lines

> However, it would be nicer if "git commit --amend", "git rebase",
> "git branch -f", and "git checkout -B" notices the situation and
> warns about what would happen.
>
>>   git config alias.amend '!git merge-base --is-ancestor HEAD
>> @{upstream} || git commit --amend'
>>
>> I'm just wondering if something more official can be added to git
>> commit --amend (and probably git rebase).
>
> A bigger problem may be how you make sure everybody sets up
> @{upstream} correctly.  You may fork your own copy of a branch from
> the target branch, start working on it, further fork other branches
> on your work to experiment different approaches, with the intention
> to later use the best one to update your first fork.
>
> At which point, the @{upstream} of the secondary branches are your
> own first branch, not the public one--which is not a problem per-se,
> because your first branch (whose @{upstream} is the remote one) is
> not yet public and you should be allowed to freely update it to
> polish it by rewriting.  But then after you push out your first
> branch as an interim snapshot to the public, you no longer want to
> rewrite the commits reachable from it.  So (to put it mildly) it
> would be quite complex to get all the corner cases right, and the
> definition of "right" would probably depend on the exact workflow.
>

I think you could still argue that if @{upstream} exists. Warn about (or disallow) re-writing anything anything that is reachable from it. There is still the possibility of if someone else rewinding @{upstream} on you and I think the scenario you've highlighted is just a case of doing it to yourself.

If you do want do want to re-write history you can still do so either by not setting @{upstream} or setting core.IKnowWhatImDoing = 1.

Junio C Hamano· Apr 6, 2016, 17:01 UTC · re: Chris Packham · lore

Re: Triangular workflows and some anecdotes from the trenches

Chris Packham <judge.packham@gmail.com> writes:

Show 6 quoted lines

> On Wed, Apr 6, 2016 at 10:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> Developer ending up amending is not an issue per-se, unless the
>> result is pushed back to the public.
>
> Correct and that was when the developer in question realised he had a problem.

But then "push" would have failed and correcting would all be local, no?

Show 22 quoted lines

>> A bigger problem may be how you make sure everybody sets up
>> @{upstream} correctly.  You may fork your own copy of a branch from
>> the target branch, start working on it, further fork other branches
>> on your work to experiment different approaches, with the intention
>> to later use the best one to update your first fork.
>>
>> At which point, the @{upstream} of the secondary branches are your
>> own first branch, not the public one--which is not a problem per-se,
>> because your first branch (whose @{upstream} is the remote one) is
>> not yet public and you should be allowed to freely update it to
>> polish it by rewriting.  But then after you push out your first
>> branch as an interim snapshot to the public, you no longer want to
>> rewrite the commits reachable from it.  So (to put it mildly) it
>> would be quite complex to get all the corner cases right, and the
>> definition of "right" would probably depend on the exact workflow.
>
> I think you could still argue that if @{upstream} exists. Warn about
> (or disallow) re-writing anything anything that is reachable from it.
>
> There is still the possibility of if someone else rewinding
> @{upstream} on you and I think the scenario you've highlighted is just
> a case of doing it to yourself.

But at that point, you are not doing much to help the normal users. I was actually expecting a response with a different approach, e.g. instead of relying on @{upstream} that may or may not serve as a good check anyway, make sure nothing reachable from any of the refs in refs/remotes/* is not updated by amend or rebase.