branch assistance needed

[Dewey Hylton]

I've used fossil for years now with lots of commits to trunk and very few
very simple branches which tend to get merged right into trunk after only a
few commits. I have managed to get myself in a confusing place with one of
my projects.

Essentially what I did was to commit a change to a new branch, forget I was
in that branch and committed another unrelated change which should have
gone back to trunk but went into the branch. I then attempted to change
that latest commit by adding a 'trunk' tag and cancelling the new branch
tag. I'm pretty sure that was wrong, but I'm unsure now where to go with
this. I've tried a few other things to no avail, but now even after
executing 'fossil update trunk' the 'fossil branch' command shows I'm still
in the new branch.

So I have two problems to solve:
1) how do I properly move commits between branches (and to trunk, in my
case)?
2) how do I unfudge my current condition and get back to trunk?

[bch]

Post by Dewey Hylton
I've used fossil for years now with lots of commits to trunk and very few
very simple branches which tend to get merged right into trunk after only a
few commits. I have managed to get myself in a confusing place with one of
my projects.
Essentially what I did was to commit a change to a new branch, forget I
was in that branch and committed another unrelated change which should have
gone back to trunk but went into the branch. I then attempted to change
that latest commit by adding a 'trunk' tag and cancelling the new branch
tag. I'm pretty sure that was wrong, but I'm unsure now where to go with
this. I've tried a few other things to no avail, but now even after
executing 'fossil update trunk' the 'fossil branch' command shows I'm still
in the new branch.
1) how do I properly move commits between branches (and to trunk, in my
case)?
2) how do I unfudge my current condition and get back to trunk?

This would be a candidate for “pop latest commit (to stash??)”
functionality if the (apparently fiddly) touched pieces could all be
identified.

-bch

Post by Dewey Hylton
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Eduard]

1) See the `--cherrypick` switch to `fossil merge`.

2)

a. undo the tags you've fiddled with, so that branch=trunk is original
trunk and side-branch is branch=side-branch.

b. fossil checkout trunk

c. fossil merge --cherrypick <id_of_commit_you_want_to_move>

d. (optional) move the erroneous commit (I'm assuming the last commit on
`side-branch`) to branch `mistake` and set to hidden

Best,
Eduard

Post by Dewey Hylton
I've used fossil for years now with lots of commits to trunk and very
few very simple branches which tend to get merged right into trunk
after only a few commits. I have managed to get myself in a confusing
place with one of my projects.
Essentially what I did was to commit a change to a new branch, forget
I was in that branch and committed another unrelated change which
should have gone back to trunk but went into the branch. I then
attempted to change that latest commit by adding a 'trunk' tag and
cancelling the new branch tag. I'm pretty sure that was wrong, but I'm
unsure now where to go with this. I've tried a few other things to no
avail, but now even after executing 'fossil update trunk' the 'fossil
branch' command shows I'm still in the new branch.
1) how do I properly move commits between branches (and to trunk, in
my case)?
2) how do I unfudge my current condition and get back to trunk?
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Warren Young]

Essentially what I did was to commit a change to a new branch, forget I was in that branch and committed another unrelated change which should have gone back to trunk but went into the branch.

That’s no big problem so far. I’ve done it myself, probably more than once.

The right way to fix it at this point would be to cherrypick the changes that should have been on trunk from the branch onto trunk:

$ fossil up trunk
$ fossil merge --cherrypick abcd1234 …etc
$ [test]
$ fossil ci
$ fossil up my-new-branch

At that point, what you have is effectively as if you’d done this instead:

$ fossil up trunk
$ [hack, hack]
$ fossil ci
$ fossil up my-new-branch
$ fossil merge trunk

So, it’s an easy cleanup.

I then attempted to change that latest commit by adding a 'trunk' tag and cancelling the new branch tag.

Ow!

I'm pretty sure that was wrong, but I'm unsure now where to go with this.

Cleanup is similar to the above, it just creates an uglier timeline:

$ fossil up trunk
$ fossil merge --integrate my-new-branch
$ [test]
$ fossil ci
$ fossil merge --backout abcd1234 # ID of first checkin on my-new-branch
$ [test]
$ fossil ci
$ fossil merge --cherrypick abcd1234
$ fossil ci my-new-branch

You might have to give a checkin ID in the first command instead of a branch name if it isn’t putting you in the timeline where you think you ought to be. Fossil might even complain about having two “trunk” branch tips with this command; if so, the solution is the same.

It’s okay to give the same branch name in the last command as you used originally because Fossil just uses branch names as auto-propagating labels. Checkin IDs and their relationships are what matters to Fossil, not branch names. Still, you might prefer to give it a different name to avoid causing yourself confusion, even though Fossil isn’t confused at all.

[Nicola]

On 04/07/2018 00:18, Warren Young wrote:> On Jul 3, 2018, at 3:09 PM,

I then attempted to change that latest commit by adding a 'trunk'

tag and cancelling the new branch tag.

Ow!

As a newbie Fossil user, after reading

https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki

[…] check-ins can be freely moved between branches simply by altering
their tags

I was (mis)lead to believe that what the OP did might somehow work
(well, actually I was skeptic, so I tried on a test repository).

Maybe, the sentence above could be complemented with an example of how
to do that and how *not* to do it (e.g., explaining what the effect of
adding a 'trunk' tag to a random check-in is and why it should not be
done).

Nicola

[Marcelo]

Post by Nicola
Maybe, the sentence above could be complemented with an example of how
to do that and how *not* to do it (e.g., explaining what the effect of
adding a 'trunk' tag to a random check-in is and why it should not be
done).

​+1

[jungle Boogie]

Post by Nicola
On 04/07/2018 00:18, Warren Young wrote:> On Jul 3, 2018, at 3:09 PM,

I then attempted to change that latest commit by adding a 'trunk'

tag and cancelling the new branch tag.

Ow!

As a newbie Fossil user, after reading
https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki

[
] check-ins can be freely moved between branches simply by altering
their tags

I was (mis)lead to believe that what the OP did might somehow work
(well, actually I was skeptic, so I tried on a test repository).
Maybe, the sentence above could be complemented with an example of how
to do that and how *not* to do it (e.g., explaining what the effect of
adding a 'trunk' tag to a random check-in is and why it should not be
done).

So provide a patch with the enhancement and let's see what happens.

Post by Nicola
Nicola

[Nicola]

On 12:42AM, Wed, Jul 4, 2018 Nicola

Post by Nicola
Maybe, the sentence above could be complemented with an example of how
to do that and how *not* to do it (e.g., explaining what the effect of
adding a 'trunk' tag to a random check-in is and why it should not be
done).

So provide a patch with the enhancement and let's see what happens.

IIUC, the sentence refers to an implementation detail: moving check-ins
between branches is implemented by simply renaming tags. But, it is easy
(at least, for a newcomer like myself) on a first (and possibly second)
reading to interpret it in the sense that *the user* can move check-ins
between branches that way.

As for contributing to the project, currently I'd likely do more harm
than good :) I have been using Fossil for a short time, and many details
are not entirely clear to me yet (e.g., I still don't understand well
the purpose of tagging branches with both branch=name and sym-name), but
I am taking notes as I am learning, and I am willing to share them some
time in the future for the benefit of other beginners.

Nicola

[Warren Young]

moving check-ins between branches is implemented by simply renaming tags.

It’s better to say that you can move a checkin *and all of its children* by adding/changing a propagating tag to that checkin. In Fossil UI, this is the "Make this check-in the start of a new branch named:” option.

You cannot take a checkin with children and move just that one checkin to another branch with a single tag manipulation. For such tasks, we have to fall back on “fossil merge --cherrypick”.

Furthermore, you can’t merge checkins from one branch into another solely by messing with the tags on a checkin, whether plain-old tags as I think the OP was doing or the self-propagating tags that are the basis of Fossil’s branching system.

Here’s my best-effort attempt at recreating what the OP described:

https://imgur.com/a/6S4Y1nw

You either end up with two trunk branches or a single branch plus a checkin off the trunk branch that also happens to be tagged “trunk”.

I suspect what drh meant up-thread about an easier method in Fossil UI to fix this is that you should be able to straighten out a tangle in the timeline by re-applying propagating tags to the root of the branches to disentangle them. I agree that such tools are too rarely needed to be worth spending time on. We have alternate tarpit escape methods that work well enough already.

[d***@gmail.com]

Post by Warren Young
https://imgur.com/a/6S4Y1nw
You either end up with two trunk branches or a single branch plus a checkin off
the trunk branch that also happens to be tagged “trunk”.

That picture precisely describes my original predicament, which was then
followed by the realization that "fossil update trunk" did not get me back
to "true trunk" ...

[Richard Hipp]

Post by Dewey Hylton
Essentially what I did was to commit a change to a new branch, forget I was
in that branch and committed another unrelated change which should have
gone back to trunk but went into the branch.

I made that same mistake myself, recently. See
https://www.sqlite.org/src/timeline?c=64df1189

Perhaps the best way to fix this is to cherry-pick the fix into trunk.

Post by Dewey Hylton
then attempted to change
that latest commit by adding a 'trunk' tag and cancelling the new branch
tag. I'm pretty sure that was wrong, but I'm unsure now where to go with
this. I've tried a few other things to no avail, but now even after
executing 'fossil update trunk' the 'fossil branch' command shows I'm still
in the new branch.
1) how do I properly move commits between branches (and to trunk, in my
case)?

Cherry pick.

Post by Dewey Hylton
2) how do I unfudge my current condition and get back to trunk?

There is a way to undo your fudge. But, since this comes up so
rarely, there is not a convenient interface. That is something I
suppose I need to work on.

[Dewey Hylton]

Post by Richard Hipp

Post by Dewey Hylton
Essentially what I did was to commit a change to a new branch, forget I

was

Post by Dewey Hylton
in that branch and committed another unrelated change which should have
gone back to trunk but went into the branch.

I made that same mistake myself, recently. See
https://www.sqlite.org/src/timeline?c=64df1189

This makes me feel somewhat better. :)

In the end, I was able to get to where I wanted to be by executing 'fossil
up <UUID>' to get back to what I considered to be "trunk" before adding a
trunk tag ... I then used a series of 'merge --cherrypick' and 'commit'
operations to move the individual wanted checkins back to trunk. I then
closed the last leaf in the testing branch, and hid the branch.

Thanks to all who responded! The solution ended up being much less messy
than I anticipated, and was solved much quicker as well. This is a great
community.

[Warren Young]

The solution ended up being much less messy than I anticipated

Yes; while Fossil will let you create awful messes, this is mitigated by several design choices:

1. It’s really hard to make Fossil actually lose data. It can be done, but it takes enough effort that you’re highly unlikely to do it by accident.

2. If you have a mess with no data loss, recovery within the existing repository is usually simple enough that restoring from a backup copy and replaying your work is almost never the best option.

3. Once bitten this way, the reason why you were bitten and the right way to avoid it is usually clear. Contrast <cough> other systems where you can be told how you screwed up and how to fix it and still be at risk of doing it again because the right way doesn’t “click”.

This is a great community.

Fossil is worth fighting for.