"Push creates new remote heads" and my humble workflow (kind of dummy question)

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

"Push creates new remote heads" and my humble workflow (kind of dummy question)

Victor Sudakov-2
Dear Colleagues,

I use a very simple workflow. I have a repository "in the cloud" (on a
VPC) and 2 clones thereof: on the home machine and on the office
machine. After committing some work at home, I push the changes, and
next morning pull them sitting at the office machine. And vice versa.

It all works usually fine except when it does not work quite the way I'd
like it to. Sometimes it happens that when trying to push my commits
into the cloud, I get the "push creates new remote heads" warning, and
I'm forced to merge.

It would be fine but often, after the merge, I see the same changeset
twice in my history: one as a result of yesterday's commit and again the
same changeset - as a result of the merge. It's aesthetically
unpleasant.

The worst is that I cannot catch what actions cause this situation.
Perhaps my forgetting to do "pull -u" before commit, or maybe not.

What would you advise me to do to a) grok the problem and b) never
repeate the mistake? I really don't want to see the identical changeset
twice.

An example: https://termbin.com/hww1
The changesets 132 and 134 are identical.

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: "Push creates new remote heads" and my humble workflow (kind of dummy question)

Tom Hindle


On Wed, Jul 15, 2020 at 5:01 AM Victor Sudakov <[hidden email]> wrote:
Dear Colleagues,

I use a very simple workflow. I have a repository "in the cloud" (on a
VPC) and 2 clones thereof: on the home machine and on the office
machine. After committing some work at home, I push the changes, and
next morning pull them sitting at the office machine. And vice versa.

It all works usually fine except when it does not work quite the way I'd
like it to. Sometimes it happens that when trying to push my commits
into the cloud, I get the "push creates new remote heads" warning, and
I'm forced to merge.

It would be fine but often, after the merge, I see the same changeset
twice in my history: one as a result of yesterday's commit and again the
same changeset - as a result of the merge. It's aesthetically
unpleasant.

The worst is that I cannot catch what actions cause this situation.
Perhaps my forgetting to do "pull -u" before commit, or maybe not.

Yes that is a likely explanation.
 

What would you advise me to do to a) grok the problem and b) never
repeate the mistake? I really don't want to see the identical changeset
twice.

If you do get into that situation again, and want to avoid a merge, check out rebase.
Here is a guide for thg, which will hopefully make it clear how it works:
 

An example: https://termbin.com/hww1
The changesets 132 and 134 are identical.

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: "Push creates new remote heads" and my humble workflow (kind of dummy question)

Uwe Brauer
In reply to this post by Victor Sudakov-2
>>> "VS" == Victor Sudakov <[hidden email]> writes:

> Dear Colleagues,

> The worst is that I cannot catch what actions cause this situation.
> Perhaps my forgetting to do "pull -u" before commit, or maybe not.

You could give


hg fetch


a try.


Warning the HG guru's advice ist *not to use it*,

but «hg fetch» does basically what «git pull» does, which depending on
your philosophy is a good or a dreadful thing.

Uwe Brauer

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: "Push creates new remote heads" and my humble workflow (kind of dummy question)

Victor Sudakov-2
Uwe Brauer wrote:

>
>
> > The worst is that I cannot catch what actions cause this situation.
> > Perhaps my forgetting to do "pull -u" before commit, or maybe not.
>
> You could give
>
>
> hg fetch
>
>
> a try.

This still does not help me understand what is really happening behind the
scenes: why the same changeset is duplicated in the repository. In other
words, why do I have to merge what's already there.


--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: "Push creates new remote heads" and my humble workflow (kind of dummy question)

Manuel Jacob
On 2020-07-16 04:09, Victor Sudakov wrote:

> Uwe Brauer wrote:
>>
>>
>> > The worst is that I cannot catch what actions cause this situation.
>> > Perhaps my forgetting to do "pull -u" before commit, or maybe not.
>>
>> You could give
>>
>>
>> hg fetch
>>
>>
>> a try.
>
> This still does not help me understand what is really happening behind
> the
> scenes: why the same changeset is duplicated in the repository. In
> other
> words, why do I have to merge what's already there.

What do you mean by "duplicated"?

Before the merge, you had two heads. To get one head, you can merge
them.

132 and 134 will have the same diff (if there was no merge conflict).
But that doesn’t mean that they are identical. It’s just a result of how
Mercurial shows the diff of merges (it shows the difference between the
first parent the merge).
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: "Push creates new remote heads" and my humble workflow (kind of dummy question)

Victor Sudakov-2
Manuel Jacob wrote:

> On 2020-07-16 04:09, Victor Sudakov wrote:
> > Uwe Brauer wrote:
> > >
> > >
> > > > The worst is that I cannot catch what actions cause this situation.
> > > > Perhaps my forgetting to do "pull -u" before commit, or maybe not.
> > >
> > > You could give
> > >
> > >
> > > hg fetch
> > >
> > >
> > > a try.
> >
> > This still does not help me understand what is really happening behind
> > the
> > scenes: why the same changeset is duplicated in the repository. In other
> > words, why do I have to merge what's already there.
>
> What do you mean by "duplicated"?
>
> Before the merge, you had two heads. To get one head, you can merge them.

Where did I have the two heads physically? There was one head at home, and
one head at work, that's true. But I never allowed to create two heads
in the cloud.

I want to fix my workflow somehow so that only one head (in all the
repos) exists at a time.

Maybe my many years of CVS/SVN experience are confusing me. Still I
like DVCS for the possibility to make intermediate commits locally
before pushing changes to the upstream repo.

>
> 132 and 134 will have the same diff (if there was no merge conflict). But
> that doesn’t mean that they are identical.

Oh.

> It’s just a result of how
> Mercurial shows the diff of merges (it shows the difference between the
> first parent the merge).

Very interesting. So because Changeset 134 has two parents, the diff is
shown in a special way?

For now I see that "hg diff -c 134" and "hg diff -c 132" look identical.
The same can be said about "hg log -r132 -p" and "hg log -r134 -p" -
identical except for the commit message and some metadata.  This is
confusing, the final tree (viewed with "hg log -p" or whatever) looks like
the changes were applied twice but in fact they were not.

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: "Push creates new remote heads" and my humble workflow (kind of dummy question)

Manuel Jacob
On 2020-07-16 07:20, Victor Sudakov wrote:

> Manuel Jacob wrote:
>> On 2020-07-16 04:09, Victor Sudakov wrote:
>> > Uwe Brauer wrote:
>> > >
>> > >
>> > > > The worst is that I cannot catch what actions cause this situation.
>> > > > Perhaps my forgetting to do "pull -u" before commit, or maybe not.
>> > >
>> > > You could give
>> > >
>> > >
>> > > hg fetch
>> > >
>> > >
>> > > a try.
>> >
>> > This still does not help me understand what is really happening behind
>> > the
>> > scenes: why the same changeset is duplicated in the repository. In other
>> > words, why do I have to merge what's already there.
>>
>> What do you mean by "duplicated"?
>>
>> Before the merge, you had two heads. To get one head, you can merge
>> them.
>
> Where did I have the two heads physically? There was one head at home,
> and
> one head at work, that's true. But I never allowed to create two heads
> in the cloud.

Suppose we start in a situation where you have only one head X in the
home, work and cloud repos.

Then, in the work repo, you create A on X. A is now the single head in
the work repo. Before driving home, you forget to push.

Then, in the home repo, you create B on X. B is now the single head in
the home repo. You push to the central repo, which then also has a
single head B.

Then, in the work repo, you pull. Now you have two heads A and B in the
repo.

> I want to fix my workflow somehow so that only one head (in all the
> repos) exists at a time.

In your case, as the only person working on the repo, you could avoid
the situation by always pulling before committing and always pushing
before switching machines.

If you have the rebase extension enabled, you can pass "--rebase" to "hg
pull", which will linearize the changesets after pulling.

> Maybe my many years of CVS/SVN experience are confusing me. Still I
> like DVCS for the possibility to make intermediate commits locally
> before pushing changes to the upstream repo.
>
>>
>> 132 and 134 will have the same diff (if there was no merge conflict).
>> But
>> that doesn’t mean that they are identical.
>
> Oh.
>
>> It’s just a result of how
>> Mercurial shows the diff of merges (it shows the difference between
>> the
>> first parent the merge).
>
> Very interesting. So because Changeset 134 has two parents, the diff is
> shown in a special way?

Actually, Mercurial by default always shows the diff between the first
parent and the changeset. Merges aren’t handled specially.

> For now I see that "hg diff -c 134" and "hg diff -c 132" look
> identical.
> The same can be said about "hg log -r132 -p" and "hg log -r134 -p" -
> identical except for the commit message and some metadata.  This is
> confusing, the final tree (viewed with "hg log -p" or whatever) looks
> like
> the changes were applied twice but in fact they were not.

I don’t know how you created the merge changesets, but when using a
commit message like "Merge heads.", there will be no duplication in the
message.

In the future, hopefully Mercurial gets more useful diffs for merges. I
know that work on this was started, but I don’t think there’s something
ready to use.
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: "Push creates new remote heads" and my humble workflow (kind of dummy question)

Victor Sudakov-2
Manuel Jacob wrote:

[dd]

> > >
> > > Before the merge, you had two heads. To get one head, you can merge
> > > them.
> >
> > Where did I have the two heads physically? There was one head at home,
> > and
> > one head at work, that's true. But I never allowed to create two heads
> > in the cloud.
>
> Suppose we start in a situation where you have only one head X in the home,
> work and cloud repos.
>
> Then, in the work repo, you create A on X. A is now the single head in the
> work repo. Before driving home, you forget to push.

OK, I see.

>
> Then, in the home repo, you create B on X. B is now the single head in the
> home repo. You push to the central repo, which then also has a single head
> B.
>
> Then, in the work repo, you pull. Now you have two heads A and B in the
> repo.

If I "pull -u" in the work repo, will my working directory be updated to
B? Probably it will, because i've pulled from the central repo, right?
Is it a good idea to always run "pull -u"? (which I do).

>
> > I want to fix my workflow somehow so that only one head (in all the
> > repos) exists at a time.
>
> In your case, as the only person working on the repo, you could avoid the
> situation by always pulling before committing and always pushing before
> switching machines.

Can I enforce this discipline?

>
> If you have the rebase extension enabled, you can pass "--rebase" to "hg
> pull", which will linearize the changesets after pulling.

This sounds interesting. Can you please explain on the X,A,B example
above, what "pull --rebase" will do?

"rebase working directory to branch head" does not sound exactly clear.
Which branch? I don't have branches, just accidentally create two heads
from time to time.

[dd]

>
> > For now I see that "hg diff -c 134" and "hg diff -c 132" look identical.
> > The same can be said about "hg log -r132 -p" and "hg log -r134 -p" -
> > identical except for the commit message and some metadata.  This is
> > confusing, the final tree (viewed with "hg log -p" or whatever) looks
> > like
> > the changes were applied twice but in fact they were not.
>
> I don’t know how you created the merge changesets, but when using a commit
> message like "Merge heads.", there will be no duplication in the message.

It's not the duplication in the message that I object to, it's the
duplication in the diff ("hg log -p" output and such become confusing).

>
> In the future, hopefully Mercurial gets more useful diffs for merges. I know
> that work on this was started, but I don’t think there’s something ready to
> use.

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: "Push creates new remote heads" and my humble workflow (kind of dummy question)

Pierre-Yves David-2


On 7/16/20 11:28 AM, Victor Sudakov wrote:

> Manuel Jacob wrote:
>
> [dd]
>
>>>>
>>>> Before the merge, you had two heads. To get one head, you can merge
>>>> them.
>>>
>>> Where did I have the two heads physically? There was one head at home,
>>> and
>>> one head at work, that's true. But I never allowed to create two heads
>>> in the cloud.
>>
>> Suppose we start in a situation where you have only one head X in the home,
>> work and cloud repos.
>>
>> Then, in the work repo, you create A on X. A is now the single head in the
>> work repo. Before driving home, you forget to push.
>
> OK, I see.
>
>>
>> Then, in the home repo, you create B on X. B is now the single head in the
>> home repo. You push to the central repo, which then also has a single head
>> B.
>>
>> Then, in the work repo, you pull. Now you have two heads A and B in the
>> repo.
>
> If I "pull -u" in the work repo, will my working directory be updated to
> B? Probably it will, because i've pulled from the central repo, right?
> Is it a good idea to always run "pull -u"? (which I do).
>
>>
>>> I want to fix my workflow somehow so that only one head (in all the
>>> repos) exists at a time.
>>
>> In your case, as the only person working on the repo, you could avoid the
>> situation by always pulling before committing and always pushing before
>> switching machines.
>
> Can I enforce this discipline?

You can make sure you alway pull before committing by adding a hook in
your config.


[hooks]
pre-commit=hg pull -u

(hook provided without any testing, so migh need adjustment to work)

>
>>
>> If you have the rebase extension enabled, you can pass "--rebase" to "hg
>> pull", which will linearize the changesets after pulling.
>
> This sounds interesting. Can you please explain on the X,A,B example
> above, what "pull --rebase" will do?
>
> "rebase working directory to branch head" does not sound exactly clear.
> Which branch? I don't have branches, just accidentally create two heads
> from time to time.

Has soon are you start having multiple heads, you have topological branches.

In your case you have two heads B and C. each on they own "topological
branch"


A---B
  \
   \-C

Lets says you committed "C" locally and pulled "B". (so you working copy
is on changeset of C).

rebase will "recreate" C (as a new changeset, C') on top of B. So the
result will be:

A---B---C'

>
> [dd]
>
>>
>>> For now I see that "hg diff -c 134" and "hg diff -c 132" look identical.
>>> The same can be said about "hg log -r132 -p" and "hg log -r134 -p" -
>>> identical except for the commit message and some metadata.  This is
>>> confusing, the final tree (viewed with "hg log -p" or whatever) looks
>>> like
>>> the changes were applied twice but in fact they were not.
>>
>> I don’t know how you created the merge changesets, but when using a commit
>> message like "Merge heads.", there will be no duplication in the message.
>
> It's not the duplication in the message that I object to, it's the
> duplication in the diff ("hg log -p" output and such become confusing).
>
>>
>> In the future, hopefully Mercurial gets more useful diffs for merges. I know
>> that work on this was started, but I don’t think there’s something ready to
>> use.
>

--
Pierre-Yves David
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: "Push creates new remote heads" and my humble workflow (kind of dummy question)

Victor Sudakov-2
Pierre-Yves David wrote:

> >
> > > > >
> > > > > Before the merge, you had two heads. To get one head, you can merge
> > > > > them.
> > > >
> > > > Where did I have the two heads physically? There was one head at home,
> > > > and
> > > > one head at work, that's true. But I never allowed to create two heads
> > > > in the cloud.
> > >
> > > Suppose we start in a situation where you have only one head X in the home,
> > > work and cloud repos.
> > >
> > > Then, in the work repo, you create A on X. A is now the single head in the
> > > work repo. Before driving home, you forget to push.
> >
> > OK, I see.
> >
> > >
> > > Then, in the home repo, you create B on X. B is now the single head in the
> > > home repo. You push to the central repo, which then also has a single head
> > > B.
> > >
> > > Then, in the work repo, you pull. Now you have two heads A and B in the
> > > repo.
> >
> > If I "pull -u" in the work repo, will my working directory be updated to
> > B? Probably it will, because i've pulled from the central repo, right?
> > Is it a good idea to always run "pull -u"? (which I do).
> >
> > >
> > > > I want to fix my workflow somehow so that only one head (in all the
> > > > repos) exists at a time.
> > >
> > > In your case, as the only person working on the repo, you could avoid the
> > > situation by always pulling before committing and always pushing before
> > > switching machines.
> >
> > Can I enforce this discipline?
>
> You can make sure you alway pull before committing by adding a hook in your
> config.
>
>
> [hooks]
> pre-commit=hg pull -u
>
> (hook provided without any testing, so migh need adjustment to work)

This way, my history will be full of merges, which is not desirable.

> > >
> > > If you have the rebase extension enabled, you can pass "--rebase" to "hg
> > > pull", which will linearize the changesets after pulling.
> >
> > This sounds interesting. Can you please explain on the X,A,B example
> > above, what "pull --rebase" will do?
> >
> > "rebase working directory to branch head" does not sound exactly clear.
> > Which branch? I don't have branches, just accidentally create two heads
> > from time to time.
>
> Has soon are you start having multiple heads, you have topological branches.
>
> In your case you have two heads B and C. each on they own "topological
> branch"
>
>
> A---B
>  \
>   \-C
>
> Lets says you committed "C" locally and pulled "B". (so you working copy is
> on changeset of C).
>
> rebase will "recreate" C (as a new changeset, C') on top of B. So the result
> will be:
>
> A---B---C'

Great, but

a) what will happen when I push this rearranged history back into the
cloud repo?

b) do I need to hint to rebase what it should rebase on what? How
does it know that it should put C on top of B, and not vice versa? Does
it just always put the working copy topological branch on top of the
pulled branch?

Anyway, I should try it out in order to understand.

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

[pre-push hook seems buggy] (was: "Push creates new remote heads" and my humble workflow (kind of dummy question))

Uwe Brauer
In reply to this post by Pierre-Yves David-2

   > On 7/16/20 11:28 AM, Victor Sudakov wrote:

   > You can make sure you alway pull before committing by adding a hook in
   > your config.


   > [hooks]
   > pre-commit=hg pull -u


Thanks for pointing this out. I found this hook a bit too confusing so I
tried out
pre-push:

pre-push=hg pull -u

Works as expected

But


pre-push=hg fetch

Gave me

abort: working directory not at branch tip
(use 'hg update' to check out branch tip)
abort: pre-push hook exited with status 255


Which was nonsense. Just in case I run hg update
but received the same message.

Is this a BUG?

Regards

Uwe Brauer

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: "Push creates new remote heads" and my humble workflow (kind of dummy question)

Victor Sudakov-2
In reply to this post by Victor Sudakov-2
Victor Sudakov wrote:

> > > >
> > > > If you have the rebase extension enabled, you can pass "--rebase" to "hg
> > > > pull", which will linearize the changesets after pulling.
> > >
> > > This sounds interesting. Can you please explain on the X,A,B example
> > > above, what "pull --rebase" will do?
> > >
> > > "rebase working directory to branch head" does not sound exactly clear.
> > > Which branch? I don't have branches, just accidentally create two heads
> > > from time to time.
> >
> > Has soon are you start having multiple heads, you have topological branches.
> >
> > In your case you have two heads B and C. each on they own "topological
> > branch"
> >
> >
> > A---B
> >  \
> >   \-C
> >
> > Lets says you committed "C" locally and pulled "B". (so you working copy is
> > on changeset of C).
> >
> > rebase will "recreate" C (as a new changeset, C') on top of B. So the result
> > will be:
> >
> > A---B---C'
>
> Great, but
>
> a) what will happen when I push this rearranged history back into the
> cloud repo?
>
> b) do I need to hint to rebase what it should rebase on what? How
> does it know that it should put C on top of B, and not vice versa? Does
> it just always put the working copy topological branch on top of the
> pulled branch?
>
> Anyway, I should try it out in order to understand.

I've found out that whenever "hg pull" informs me about "+1 heads" and
suggests runnning 'hg merge' to merge, I can just do

hg rebase && hg push

and my history again becomes linear. I think this is great. Thanks to all who
replied, especially about rebase.

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [pre-push hook seems buggy]

Pierre-Yves David-2
In reply to this post by Uwe Brauer


On 7/19/20 9:11 AM, Uwe Brauer wrote:

>
>     > On 7/16/20 11:28 AM, Victor Sudakov wrote:
>
>     > You can make sure you alway pull before committing by adding a hook in
>     > your config.
>
>
>     > [hooks]
>     > pre-commit=hg pull -u
>
>
> Thanks for pointing this out. I found this hook a bit too confusing so I
> tried out
> pre-push:
>
> pre-push=hg pull -u
>
> Works as expected
>
> But
>
>
> pre-push=hg fetch
>
> Gave me
>
> abort: working directory not at branch tip
> (use 'hg update' to check out branch tip)
> abort: pre-push hook exited with status 255
>
>
> Which was nonsense. Just in case I run hg update
> but received the same message.
>
> Is this a BUG?

This could be a bug with topic. Which version of everyting are you using ?


--
Pierre-Yves David
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: "Push creates new remote heads" and my humble workflow (kind of dummy question)

Pierre-Yves David-2
In reply to this post by Victor Sudakov-2


On 7/18/20 6:13 PM, Victor Sudakov wrote:

> Pierre-Yves David wrote:
>>>
>>>>>>
>>>>>> Before the merge, you had two heads. To get one head, you can merge
>>>>>> them.
>>>>>
>>>>> Where did I have the two heads physically? There was one head at home,
>>>>> and
>>>>> one head at work, that's true. But I never allowed to create two heads
>>>>> in the cloud.
>>>>
>>>> Suppose we start in a situation where you have only one head X in the home,
>>>> work and cloud repos.
>>>>
>>>> Then, in the work repo, you create A on X. A is now the single head in the
>>>> work repo. Before driving home, you forget to push.
>>>
>>> OK, I see.
>>>
>>>>
>>>> Then, in the home repo, you create B on X. B is now the single head in the
>>>> home repo. You push to the central repo, which then also has a single head
>>>> B.
>>>>
>>>> Then, in the work repo, you pull. Now you have two heads A and B in the
>>>> repo.
>>>
>>> If I "pull -u" in the work repo, will my working directory be updated to
>>> B? Probably it will, because i've pulled from the central repo, right?
>>> Is it a good idea to always run "pull -u"? (which I do).
>>>
>>>>
>>>>> I want to fix my workflow somehow so that only one head (in all the
>>>>> repos) exists at a time.
>>>>
>>>> In your case, as the only person working on the repo, you could avoid the
>>>> situation by always pulling before committing and always pushing before
>>>> switching machines.
>>>
>>> Can I enforce this discipline?
>>
>> You can make sure you alway pull before committing by adding a hook in your
>> config.
>>
>>
>> [hooks]
>> pre-commit=hg pull -u
>>
>> (hook provided without any testing, so migh need adjustment to work)
>
> This way, my history will be full of merges, which is not desirable.

The point of this hook is to pull and update before you commit. So this
is not creating merge.

>>>> If you have the rebase extension enabled, you can pass "--rebase" to "hg
>>>> pull", which will linearize the changesets after pulling.
>>>
>>> This sounds interesting. Can you please explain on the X,A,B example
>>> above, what "pull --rebase" will do?
>>>
>>> "rebase working directory to branch head" does not sound exactly clear.
>>> Which branch? I don't have branches, just accidentally create two heads
>>> from time to time.
>>
>> Has soon are you start having multiple heads, you have topological branches.
>>
>> In your case you have two heads B and C. each on they own "topological
>> branch"
>>
>>
>> A---B
>>   \
>>    \-C
>>
>> Lets says you committed "C" locally and pulled "B". (so you working copy is
>> on changeset of C).
>>
>> rebase will "recreate" C (as a new changeset, C') on top of B. So the result
>> will be:
>>
>> A---B---C'
>
> Great, but
>
> a) what will happen when I push this rearranged history back into the
> cloud repo?

Mercurial has a phase concept. By default, you will not be able to
rebase content you have pulled (or already pushed). So you are not
"pushing back" anything since you push the version without merge from
the start.

> b) do I need to hint to rebase what it should rebase on what? How
> does it know that it should put C on top of B, and not vice versa? Does
> it just always put the working copy topological branch on top of the
> pulled branch?

If there are only one other head, hg rebase will pick that. Otherwise,
you can use `hg rebase --dest DESTINATION-REV`. You can also have a look
at `hg help rebase` in general.

--
Pierre-Yves David
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [pre-push hook seems buggy]

Uwe Brauer
In reply to this post by Pierre-Yves David-2

   > On 7/19/20 9:11 AM, Uwe Brauer wrote:

   > This could be a bug with topic.

Is this hook part of evolve?

   > Which version of everyting are you using ?

Hg: 5.2rc0+20200125  

(I know not recommendable, but 5.4 has an issue
with one of the extensions I use, and I had to time to sort that out)


Evolve, I thought I was using a devolper version, but my .hgrc tells me
differently.

So I presume I did it via pip
but I cannot find anyting in
.local
or /usr/local/lib

This now is embarresing: how can I find out where it is installed and
which version it is?

Regards

Uwe Brauer

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [pre-push hook seems buggy]

Uwe Brauer
In reply to this post by Pierre-Yves David-2

   > On 7/19/20 9:11 AM, Uwe Brauer wrote:

   > This could be a bug with topic. Which version of everyting are you using ?

Ok I am not senile, I installed evolve via pip and it seems to
hg_evolve-9.2.1.dist-info

Shall I change to the developer version?

Uwe Brauer  

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [pre-push hook seems buggy]

Pierre-Yves David-2
In reply to this post by Uwe Brauer


On 7/20/20 10:15 PM, Uwe Brauer wrote:
>
>     > On 7/19/20 9:11 AM, Uwe Brauer wrote:
>
>     > This could be a bug with topic.
>
> Is this hook part of evolve?

No, but topic mess a bit with branch head computation. Sometime is a way
that is a bit too hacky and lead this kind of bugs.

>
>     > Which version of everyting are you using ?
>
> Hg: 5.2rc0+20200125

You can use `hg version --verbose` to list the extension you use with
their versions.

>
> (I know not recommendable, but 5.4 has an issue
> with one of the extensions I use, and I had to time to sort that out)
>
>
> Evolve, I thought I was using a devolper version, but my .hgrc tells me
> differently.
>
> So I presume I did it via pip
> but I cannot find anyting in
> .local
> or /usr/local/lib
>
> This now is embarresing: how can I find out where it is installed and
> which version it is?
>
> Regards
>
> Uwe Brauer
>
>
> _______________________________________________
> Mercurial mailing list
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial
>

--
Pierre-Yves David
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [pre-push hook seems buggy]

Manuel Jacob
In reply to this post by Uwe Brauer
On 2020-07-20 22:17, Uwe Brauer wrote:
>> On 7/19/20 9:11 AM, Uwe Brauer wrote:
>
>    > This could be a bug with topic. Which version of everyting are you
> using ?
>
> Ok I am not senile, I installed evolve via pip and it seems to
> hg_evolve-9.2.1.dist-info
>
> Shall I change to the developer version?

When the package is already present in some version on your system, `pip
install X` won’t install X, unless you also pass the `--upgrade` option.

> Uwe Brauer
>
> _______________________________________________
> Mercurial mailing list
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: "Push creates new remote heads" and my humble workflow (kind of dummy question)

Victor Sudakov-2
In reply to this post by Pierre-Yves David-2
Pierre-Yves David wrote:
> On 7/18/20 6:13 PM, Victor Sudakov wrote:

[dd]

> >
> > a) what will happen when I push this rearranged history back into the
> > cloud repo?
>
> Mercurial has a phase concept. By default, you will not be able to rebase
> content you have pulled (or already pushed). So you are not "pushing back"
> anything since you push the version without merge from the start.
>
> > b) do I need to hint to rebase what it should rebase on what? How
> > does it know that it should put C on top of B, and not vice versa? Does
> > it just always put the working copy topological branch on top of the
> > pulled branch?
>
> If there are only one other head, hg rebase will pick that. Otherwise, you
> can use `hg rebase --dest DESTINATION-REV`. You can also have a look at `hg
> help rebase` in general.
>

Thanks Pierre-Yves, I think this is beginning to make sense to me.

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [pre-push hook seems buggy]

Uwe Brauer
In reply to this post by Pierre-Yves David-2
>>> "PD" == Pierre-Yves David <[hidden email]> writes:

   > On 7/20/20 10:15 PM, Uwe Brauer wrote:
   >> > On 7/19/20 9:11 AM, Uwe Brauer wrote:
   >> > This could be a bug with topic.
   >> Is this hook part of evolve?

   > No, but topic mess a bit with branch head computation. Sometime is a
   > way that is a bit too hacky and lead this kind of bugs.

So what shall I upgrade?  hg itself, I understand, but not evolve?


   >> > Which version of everyting are you using ?
   >> Hg: 5.2rc0+20200125

   > You can use `hg version --verbose` to list the extension you use with
   > their versions.

Thanks, there is one odd thing though.

I have in my .hgrc

hggit = /home/oub/ALLES/src/hg-git-heptapod/hggit


But

hg version --verbose tells me

 hggit                external  0.8.13 (dulwich 0.19.6)

Which seems to indicate that I use one installed by pip.
The only one I seem to find is
hg_git-0.8.11-py2.7.egg/hggit

I am a bit confused now.

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment