Access command line arguments from In-Process Python hook

[Steve Hoelzer]

On Fri, Jun 20, 2014 at 2:29 PM,  <durwin at mgtsciences.com> wrote:
> Steve Hoelzer <shoelzer at gmail.com> wrote on 06/20/2014 01:18:10 PM:
>
>> From: Steve Hoelzer <shoelzer at gmail.com>
>> To: Durwin De La Rue <durwin at mgtsciences.com>
>> Cc: Mercurial List <mercurial at selenic.com>, Matt Mackall <mpm at selenic.com>
>> Date: 06/20/2014 01:18 PM
>> Subject: Re: Access command line arguments from In-Process Python hook
>>
>> On Thu, Jun 19, 2014 at 2:31 PM,  <durwin at mgtsciences.com> wrote:
>> > Steve Hoelzer <shoelzer at gmail.com> wrote on 06/19/2014 01:24:51 PM:
>> >
>> >> From: Steve Hoelzer <shoelzer at gmail.com>
>> >> To: durwin <durwin at mgtsciences.com>
>> >> Cc: Mercurial List <mercurial at selenic.com>, Matt Mackall
>> >> <mpm at selenic.com>
>> >> Date: 06/19/2014 01:25 PM
>> >> Subject: Re: Access command line arguments from In-Process Python hook
>> >>
>> >> On Thu, Jun 19, 2014 at 1:27 PM,  <durwin at mgtsciences.com> wrote:
>> >> > Steve Hoelzer <shoelzer at gmail.com> wrote on 06/19/2014 12:04:35 PM:
>> >> >
>> >> >> From: Steve Hoelzer <shoelzer at gmail.com>
>> >> >> To: durwin at mgtsciences.com
>> >> >> Cc: Matt Mackall <mpm at selenic.com>, Mercurial List
>> >> >> <mercurial at selenic.com>
>> >> >> Date: 06/19/2014 12:04 PM
>> >> >> Subject: Re: Access command line arguments from In-Process Python
>> >> >> hook
>> >> >>
>> >> >> On Thu, Jun 19, 2014 at 10:33 AM,  <durwin at mgtsciences.com> wrote:
>> >> >> > Normally when a new branch is pushed the option
>> >> >> > --new-branch is specified. So using the force option for both
>> >> >> > normal
>> >> >> > and
>> >> >> > branch pushes is an acceptable method for what I am doing?  The
>> >> >> > repository
>> >> >> > will handle the forced push appropriately for both branch and
>> >> >> > non-branches?
>> >> >>
>> >> >> The force option "will push all new heads on all branches" according
>> >> >> to:
>> >> >>
>> >> >>
>> >> > http://www.selenic.com/mercurial/hg.1.html
>> >> >
>> >> >>
>> >> >> That sounds like what you want.
>> >> >>
>> >> >> Steve
>> >> >
>> >> > Thank you.  I've done some testing and it looks like it does the job.
>> >> > What
>> >> > has me a little concerned is the last part of the sentence,  "...an
>> >> > action
>> >> > which will almost always cause confusion for collaborators".
>> >>
>> >> The wording is not clear, but I think it is warning about getting
>> >> multiple heads on a branch in a public or shared repo, a situation
>> >> "which will almost always cause confusion for collaborators". Regular
>> >> pushes (non forced) prevent that from happening, so these repos will
>> >> never end up in that situation. (Well, unless someone has multiple
>> >> heads in a private repo and does push -f.)
>> >>
>> >> Using push -f for syncing simply makes the repos mirrors of each other
>> >> with all heads, and therefore all branches. If users don't push
>> >> multiple heads per branch, the synched repos will never have multiple
>> >> heads per branch.
>> >>
>> > Thank you.  That makes me feel better.
>>
>> Actually, thinking about this more, there is a small chance that
>> multiple heads could get created. Let's say two people are working on
>> the same branch in their own clones. Then they both push at the same
>> time, but one person pushes to repo A and the other pushes to repo B.
>> Neither push creates multiple heads in the destination repo, so both
>> will succeed, but the head in A is different from the head in B. Then
>> the syncing happens with push -f and both repos end up with both
>> heads.
>>
>> I think this could only happen in very small windows of time. When a
>> push begins to one repo, a 2nd push to the other repo would have to
>> start before the 1st push completes. It's not likely, but it is
>> possible.
>>
>> It's also easy to fix. Just pull, merge the heads, and push. The
>> syncing will mirror the new single head and everyone will get it when
>> they pull.
>>
>> Steve
>
> Thank you for this insight.  For the small chance of this happening compared
> to the times I had to manually sync, I think it is acceptable.  Should it
> occur, and both sides end up with 2 heads, everyone that does a pull
> afterwards should see the problem, correct??

Everyone who pulls would get both heads. Committing on top of either
head and then pushing will succeed (even without push -f) since it is
not creating a third head, just advancing one of the existing heads.
The tools will not warn you about what's going on. Somebody will have
to recognize that this happened and merge the heads to avoid
"confusion for collaborators".

Steve