Changing the tip

[rpelisse]

Hi,

I feel rather stupid to ask this, but I'm not sure on how to process
with this : I have a repo with N revision - no branches - my last 5
five commits were an experiment and does not lead to anything good
except breaking the product.

Now I want my repo's tip to come back to (N-5) revision,  and leave
the extra next one as a "dead branch". How should I do this ? change
the 'tip' name ? close the branch ?

--
Romain PELISSE,
"The trouble with having an open mind, of course, is that people will
insist on coming along and trying to put things in it" -- Terry
Pratchett
http://belaran.eu/

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Hans Meine-4]

On Thursday 22 October 2009 11:30:38 Romain Pelisse wrote:
> Now I want my repo's tip to come back to (N-5) revision,  and leave
> the extra next one as a "dead branch". How should I do this ? change
> the 'tip' name ? close the branch ?

First, simply update to the good rev. and proceed from there (committing
etc.), this will create a new branch.

You may later close or even remove the dead branch.  Closing is done using
"hg commit --close-branch", but AFAIK this new idea is not fully integrated
(yet?).  I mean, even hg itself does not ignore such closed branches in "hg
heads" for example.

HTH,
  Hans
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Marijn Vriens-2]

2009/10/22 Hans Meine <meine@...>

On Thursday 22 October 2009 11:30:38 Romain Pelisse wrote:
> Now I want my repo's tip to come back to (N-5) revision,  and leave
> the extra next one as a "dead branch". How should I do this ? change
> the 'tip' name ? close the branch ?

"tip" is just an alias for the latest committed revision in the repository (the one with the highest revision number)
 

First, simply update to the good rev. and proceed from there (committing
etc.), this will create a new branch.

You may later close or even remove the dead branch.  Closing is done using
"hg commit --close-branch", but AFAIK this new idea is not fully integrated
(yet?).  I mean, even hg itself does not ignore such closed branches in "hg
heads" for example.

Careful here, I suspect Romain is not referring to "named-branches" at all. --close-branch is about closing those.

When updating to a previous revision and doing a commit from there, you will create a new "head", effectively splitting off a new line of changes, which are, confusingly, also called "branches" but are much more light-weight then "named-branches". The way to remove a head is to merge it with an other head, or use history editing commands to remove the "line-of-changes".

Regards,
     Marijn Vriens.

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Isaac Jurado]

Replying Marijn Vriens:
>
> When updating to a previous revision and doing a commit from there, you will
> create a new "head", effectively splitting off a new line of changes, which
> are, confusingly, also called "branches" but are much more light-weight then
> "named-branches".

I don't think that is true.  Named branches are not "hevier" than heads,
since a named of a named branch is just a changeset attribute residing
in the changelog.

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Dirkjan Ochtman]

On Thu, Oct 22, 2009 at 13:41, Isaac Jurado <diptongo@...> wrote:
>> When updating to a previous revision and doing a commit from there, you will
>> create a new "head", effectively splitting off a new line of changes, which
>> are, confusingly, also called "branches" but are much more light-weight then
>> "named-branches".
>
> I don't think that is true.  Named branches are not "hevier" than heads,
> since a named of a named branch is just a changeset attribute residing
> in the changelog.

Named branches have a bunch of different semantics attached, though,
which I guess makes them heavier in some sense (e.g. the concept of
branch heads, which can be fairly confusing). I do of course agree
that named branches are not really heavier than unnamed
heads-as-branches in a storage sense.

I do suspect we have to be careful throwing the term "branches"
around; a branch could either be a clone, a head on some branch
(whether named or not, but usually only when there are more on than on
the same named branch in that clone...) or a named branches label...

Cheers,

Dirkjan

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[rpelisse]

Hi,

Thanks for your responses, let me clarify :

Yes I didn't used named branches, therefore, there is the issue of pushing two heads to the remote. I don't want to merge, because I'll end up having the unwanted modification is the new merged tip.
I want simply to go back the commit (N-5) and start from there, forgetting that the commit between N-4 and N include has ever existed...

2009/10/22 Dirkjan Ochtman <dirkjan@...>

On Thu, Oct 22, 2009 at 13:41, Isaac Jurado <diptongo@...> wrote:
>> When updating to a previous revision and doing a commit from there, you will
>> create a new "head", effectively splitting off a new line of changes, which
>> are, confusingly, also called "branches" but are much more light-weight then
>> "named-branches".
>
> I don't think that is true.  Named branches are not "hevier" than heads,
> since a named of a named branch is just a changeset attribute residing
> in the changelog.

Named branches have a bunch of different semantics attached, though,
which I guess makes them heavier in some sense (e.g. the concept of
branch heads, which can be fairly confusing). I do of course agree
that named branches are not really heavier than unnamed
heads-as-branches in a storage sense.

I do suspect we have to be careful throwing the term "branches"
around; a branch could either be a clone, a head on some branch
(whether named or not, but usually only when there are more on than on
the same named branch in that clone...) or a named branches label...

Cheers,

Dirkjan

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

--
Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
http://belaran.eu/

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Dirkjan Ochtman]

On Thu, Oct 22, 2009 at 14:30, Romain Pelisse <belaran@...> wrote:
> Yes I didn't used named branches, therefore, there is the issue of pushing
> two heads to the remote. I don't want to merge, because I'll end up having
> the unwanted modification is the new merged tip.
> I want simply to go back the commit (N-5) and start from there, forgetting
> that the commit between N-4 and N include has ever existed...

The merge command will still solve your problem:

hg merge unwanted-head
hg revert --no-backup -r. -a
hg commit -m "Cleaned up unwanted head"

Iterate for each unwanted head, then push.

Cheers,

Dirkjan
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Marijn Vriens-2]

On Thu, Oct 22, 2009 at 2:30 PM, Romain Pelisse <belaran@...> wrote:

Hi,

Thanks for your responses, let me clarify :

Yes I didn't used named branches, therefore, there is the issue of pushing two heads to the remote. I don't want to merge, because I'll end up having the unwanted modification is the new merged tip.
I want simply to go back the commit (N-5) and start from there, forgetting that the commit between N-4 and N include has ever existed...

The Mercurial Queues "MQ" extension has a "strip" command that will remove a revision and all the children of that revision. So if rev20 is the last "correct" revision and tip is at rev25, then doing "hg strip 21 will strip out 21 to 25 and make 20 the head (and possibly the tip again):

$ hg strip 21

"Strip"ping will only work if the 21-25 changes have not been pushed to an other repository yet. If they are, stripping will be of no use, since pulling from the remote repository will recreate those changes. You will need to strip then changessets from  each repository that has them, which might not be possible.  

I am not a fan of changing/rewriting history. But i do understand that some people feel a need to "show neatness" when reality was different.

Kind regards,
       Marijn.

2009/10/22 Dirkjan Ochtman <dirkjan@...>

On Thu, Oct 22, 2009 at 13:41, Isaac Jurado <diptongo@...> wrote:
>> When updating to a previous revision and doing a commit from there, you will
>> create a new "head", effectively splitting off a new line of changes, which
>> are, confusingly, also called "branches" but are much more light-weight then
>> "named-branches".
>
> I don't think that is true.  Named branches are not "hevier" than heads,
> since a named of a named branch is just a changeset attribute residing
> in the changelog.

Named branches have a bunch of different semantics attached, though,
which I guess makes them heavier in some sense (e.g. the concept of
branch heads, which can be fairly confusing). I do of course agree
that named branches are not really heavier than unnamed
heads-as-branches in a storage sense.

I do suspect we have to be careful throwing the term "branches"
around; a branch could either be a clone, a head on some branch
(whether named or not, but usually only when there are more on than on
the same named branch in that clone...) or a named branches label...

Cheers,

Dirkjan

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

--

Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
http://belaran.eu/

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Marijn Vriens-2]

On Thu, Oct 22, 2009 at 1:41 PM, Isaac Jurado <diptongo@...> wrote:

Replying Marijn Vriens:

>
> When updating to a previous revision and doing a commit from there, you will
> create a new "head", effectively splitting off a new line of changes, which
> are, confusingly, also called "branches" but are much more light-weight then
> "named-branches".

I don't think that is true.  Named branches are not "hevier" than heads,
since a named of a named branch is just a changeset attribute residing
in the changelog.

I was referring exclusively to the usage for the user. Having multiple heads are a consequence of parallel development and very common DVCSes.

It's normal for people coming from other VCSes to mercurial, to confuse "heads" and "named-branches". In those other systems creating a parallel development effort forces the user to create a "branch".

Current mercurial best practice, as I understand it, is that named-branches is to have branches for long running efforts like a version branch "branch2.x". Some projects have even decided that they prefer to use multiple repositories, instead of using named-branches

Regards,
        Marijn.

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[David Champion]

* On 22 Oct 2009, Dirkjan Ochtman wrote:
> The merge command will still solve your problem:
>
> hg merge unwanted-head
> hg revert --no-backup -r. -a
> hg commit -m "Cleaned up unwanted head"
>
> Iterate for each unwanted head, then push.

What Dirkjan describes here is for folding an unwanted head back into
the default branch's head.  It's a useful technique to know, but I
thought your situation was slightly different: you have only one head,
but you want to "forget" the last 5 revisions.  Almost the same thing
will work, just without the merge.

hg up tip              # update to (unwanted) tip
hg revert -a -r <n>    # <n> = revision number - 5
hg commit -m 'revert last 5 revisions'

You can get the current revision number with "hd id -n".

As Marijn has said, MQ's "strip" command will actually erase the
revisions from your repository.  But it is safer and easier to
understand just to revert them.  If you don't need them to be erased,
don't bother stripping them.

--
 -D.    dgc@...    NSIT    University of Chicago
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Isaac Jurado]

Replying Romain Pelisse:
>
> I want simply to go back the commit (N-5) and start from there,
> forgetting that the commit between N-4 and N include has ever
> existed...

If I understand correctly, you are looking for the obvious:

hg clone -r N-5 source_repo new_clean_repo

Of course, you need to know what the N-5 revision is (by using "hg log"
for example).

I don't really know why this hasn't been mentioned at all.  Maybe I'm
wrong.

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Adrian Buehlmann]

On 22.10.2009 17:40, Isaac Jurado wrote:

> Replying Romain Pelisse:
>> I want simply to go back the commit (N-5) and start from there,
>> forgetting that the commit between N-4 and N include has ever
>> existed...
>
> If I understand correctly, you are looking for the obvious:
>
> hg clone -r N-5 source_repo new_clean_repo
>
> Of course, you need to know what the N-5 revision is (by using "hg log"
> for example).
>
> I don't really know why this hasn't been mentioned at all.  Maybe I'm
> wrong.
>

You are right, provided there are no other heads in the
repo, which would be omitted when using -r, unless you
specify each head you want to keep with a separate -r.

   hg clone -r keep1 -r keep2 -r keep3 oldrepo newrepo

And provided the unwanted revisions have not yet been
published (i.e. pushed) anywhere ("the ship has not sailed
yet").

Side note:

I'm wondering if we should add a -P/--prune option to clone
(analogous to the one in 'hg log') for completeness sake.

This could be used as

   hg clone --prune first-unwanted-revision oldrepo newrepo

This would somewhat correspond to

   hg strip first-unwanted-revision

from the mq extension
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[rpelisse]

Hi,

Most of yours  solutions will work perfectly "locally" but what will happen when I push to the remote (and shared) server that has the extra 5 commits that I want to "leave behind" (i do not require to actually delete from the repository thoses commits, i just need them to become part of a "dead head" - and switch tip to another head.

By 'tip', what I am aiming at is that afterward any people clone/pull from this remote repositories will get all the commits, but their working directory will contain my new head, not the "dead one".

(I hope I still make sense here).

2009/10/22 Adrian Buehlmann <adrian@...>

On 22.10.2009 17:40, Isaac Jurado wrote:
> Replying Romain Pelisse:
>> I want simply to go back the commit (N-5) and start from there,
>> forgetting that the commit between N-4 and N include has ever
>> existed...
>
> If I understand correctly, you are looking for the obvious:
>
> hg clone -r N-5 source_repo new_clean_repo
>
> Of course, you need to know what the N-5 revision is (by using "hg log"
> for example).
>
> I don't really know why this hasn't been mentioned at all.  Maybe I'm
> wrong.
>

You are right, provided there are no other heads in the
repo, which would be omitted when using -r, unless you
specify each head you want to keep with a separate -r.

  hg clone -r keep1 -r keep2 -r keep3 oldrepo newrepo

And provided the unwanted revisions have not yet been
published (i.e. pushed) anywhere ("the ship has not sailed
yet").

Side note:

I'm wondering if we should add a -P/--prune option to clone
(analogous to the one in 'hg log') for completeness sake.

This could be used as

  hg clone --prune first-unwanted-revision oldrepo newrepo

This would somewhat correspond to

  hg strip first-unwanted-revision

from the mq extension

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

--
Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
http://belaran.eu/

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Isaac Jurado]

Replying Romain Pelisse:

> Hi,
>
> Most of yours  solutions will work perfectly "locally" but what will
> happen when I push to the remote (and shared) server that has the
> extra 5 commits that I want to "leave behind" (i do not require to
> actually delete from the repository thoses commits, i just need them
> to become part of a "dead head" - and switch tip to another head.
>
> By 'tip', what I am aiming at is that afterward any people clone/pull
> from this remote repositories will get all the commits, but their
> working directory will contain my new head, not the "dead one".

Then do what Dirkjan suggested.

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Julian Cowley]

On Thu, 22 Oct 2009, Marijn Vriens wrote:

> 2009/10/22 Hans Meine <meine@...>
>> First, simply update to the good rev. and proceed from there (committing
>> etc.), this will create a new branch.
>>
>> You may later close or even remove the dead branch.  Closing is done using
>> "hg commit --close-branch", but AFAIK this new idea is not fully integrated
>> (yet?).  I mean, even hg itself does not ignore such closed branches in "hg
>> heads" for example.
>
> Careful here, I suspect Romain is not referring to "named-branches" at all.
> --close-branch is about closing those.

Why should it only apply to named branches?  Can't it apply to repository
heads too?  See my arguments for this below.

> When updating to a previous revision and doing a commit from there, you will
> create a new "head", effectively splitting off a new line of changes, which
> are, confusingly, also called "branches" but are much more light-weight then
> "named-branches". The way to remove a head is to merge it with an other
> head, or use history editing commands to remove the "line-of-changes".

I recently surveyed the "heads" command with the -a and -c options to find
out why I've been so confused about their behavior.  I discovered that
there is really only one thing that bothers me about it:

     While "heads" when given the name of a branch eliminates all of the
     branch heads that have been closed, this same behavior doesn't apply
     to repository heads.

In other words, why do closed branches still show up in "heads" output?
Since, as you say above, repository heads are considered a type of branch,
why doesn't closing a branch with "commit --close-branch" work the same
way?

Matt has stated in the past [1] that "heads -a" shouldn't be valid since
-a really only applies to branch heads.  However it is allowed and at
present it gives the same output as "heads".

Maybe this could be resolved (or at least made more consistent) by leaving
"heads" to work as-is, but making "heads -a" show only open (non-closed)
repository heads.  If this is not agreeable, then make "heads -a" give an
error and use a separate option such as -o (for open) to only show open
repository heads.

It appears from the above and from the thread in July that people have the
same expectation about "heads" (or "heads -a") that I do. It is pretty
much the only thing in Mercurial that leaves me scratching my head.

[1] http://www.selenic.com/pipermail/mercurial/2009-July/026662.html
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Hans Meine-4]

On Tuesday 27 October 2009 12:58:33 Julian Cowley wrote:
> In other words, why do closed branches still show up in "heads" output?

Exactly.  I'd love to be able to use --close-branch to hide those heads.

To be honest, this is the first thing I tried (and the only thing for a
while), and because it failed, I simply did not expect "hg merge" to accept
the head as closed either, so I stopped trying to use this new hg feature,
although it definitely scratches one of my itches when used correctly.

Hoping this gets fixed/more votes,
  Hans
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial