> fossil update would report "Already up-to-date", until I noticed that
> I was on the wrong branch.

Yeah,  it's  possible  that  the   output  from  "fossil  update"  isn't
sufficient to  provide you  with proper  situational awareness.  It does
include the branch that you're on in "tags:"

tags:         trunk
changes:      None. Already up-to-date

But maybe people don't bother looking at all the output and only look at
the "changes:" line. In which case, maybe we should instead have changes
also include  a statement about  which branch  the changes were  on. For
example:

changes:      No changes on <branch>.  Already up-to-date

Then when  the branch changes,  and you think  you're on trunk  (or some
other branch), you  would recognize it immediately, instead  of a couple
of weeks later?


Andy

I opted to go with updating the  "changes:" line. I played with having a
separate line of output, but I think  I prefer the same line over having
yet another line of  output to deal with. I've committed  it to a branch
for now for  comments just in case  some object to changing  a line that
already exists.  I know that  we don't  make promises in  Fossil command
output but wanted to also discuss it.

https://www.fossil-scm.org/home/info/bb9150c403e78db3

Demonstration:

$ fossil status
repository:   /tmp/once.fossil
local-root:   /tmp/once/
config-db:    /home/amb/.fossil
checkout:     8555051cdd35046ba9c8d13bc39e2a07ad83b755 2024-11-24 03:57:15 UTC
parent:       ba98361edb8bc0c45ec479bec77ef9dc19cec671 2024-11-24 03:01:00 UTC
tags:         trunk
comment:      wait (user: amb)


In another clone  and working checkout I decide that  this commit should
be in a different branch:

$ fossil amend 8555051cdd35 --branch newfeature
hash:         8555051cdd35046ba9c8d13bc39e2a07ad83b755 2024-11-24 03:57:15 UTC
tags:         newfeature
comment:      wait (user: amb)


Now, when I update, it will show  me that there are no changes, but also
that the branch was renamed:

$ fossil update
Pull from file:///tmp/new.fossil
Round-trips: 2   Artifacts sent: 0  received: 1
Pull done, wire bytes sent: 701  received: 3086  remote: 
-------------------------------------------------------------------------------
checkout:     8555051cdd35046ba9c8d13bc39e2a07ad83b755 2024-11-24 03:57:15 UTC
tags:         newfeature
comment:      wait (user: amb)
changes:      None. Already up-to-date.  Branch changed from trunk to newfeature.

However, now  that I look at  the output, I'm  not sure I like  the fact
that it has to  wrap on a standard terminal size.  Clearly the length of
this also depends on the length  of branch names. This might indeed lend
itself more towards being on a separate line.


And again, if no changes, there is no additional output:

$ fossil update
Pull from file:///tmp/new.fossil
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, wire bytes sent: 331  received: 1490  remote: 
-------------------------------------------------------------------------------
checkout:     8555051cdd35046ba9c8d13bc39e2a07ad83b755 2024-11-24 03:57:15 UTC
tags:         newfeature
comment:      wait (user: amb)
changes:      None. Already up-to-date.

I didn't think  it would be good to always  output the "branch:" because
that information will almost always  likely be redundant given what's in
"tags:".

Perhaps conditionally output something like:

changes:      None. Already up-to-date.
achtung:      Branch changed from trunk to newfeature.

Something else?

Andy

> I  don't think  any change  in the  output is  necessary, really.  The
> information is already there in the tags

Normally I  would agree that no  additional output is necessary,  but in
this  case it  comes up  often  enough that  I  think at  least a  small
change  is warranted.  Also, I  think  it even  surprises veteran  users
occasionally, so  this might help  minimize confusion. If they  miss the
additional output,  then I don't know  to say. My only  question at this
point is whether the information can be presented better?

I think  this is now  ready to  go in if  someone wants to  "review" it.
Basically it  will append "Branch changed  from X to Y."  if your update
switched branches and you did *not* provide a VERSION argument:

https://www.fossil-scm.org/home/timeline?r=show-branch-change

Andy

> FWIW, i really like your src:2ef47b81 tweak. That's a nice idea.

Yeah, as I thought about it, I  didn't really want to see it everytime I
switched  branches and  I figured  that  most people  know what  they're
getting if they provide a 3rd argument.

Also, thanks for the demonstration---I  wondered how to do that src:HASH
trick. I knew it  could be done, but didn't want  to bother scouring the
source to figure it out.

I'll merge this later today (or tomorrow) if there are no objections.

Thanks,

Andy

> The change you are wanting to commit appears to be just a warning that
> "fossil  update" might  leave  you  on the  same  check-in,  but on  a
> different branch, due  to tags added by a third-party?  Do I have that
> right?

Yes, update  will update you to  the tip of whatever  current branch tag
you happen to be on, and if it changes you get additional output telling
you that this has happened. The intent was merely to keep the person who 
is running "fossil update" abreast of  a change that might impact future
work so there is less of a surprise later on.             

However, you also bring up some  other good points about what happens if
the tag changes  as part of an autosync while  committing. They will not
be  given the  opportunity  of correcting  or even  notice  that is  has
changed.

Before I merge this branch I'll look into your proposed idea that if the
tag  changes while  committing  that  it prompts  to  continue with  the
checkin. Right  now what it does  is automatically pull and  it does not
display any kind of warning (and  because the update command was not run
there is  no actual output  to show that  the branch changed).  The only
thing that might clue  me in is that while editing  my commit comment, I
might notice that suddenly the tags are different:

# Enter a commit message for this check-in. Lines beginning with # are ignored.
#
# user: amb
# tags: newbranch
#
# EDITED     file

I'll start looking at enhancing this.

Thanks for the idea.

Andy

> Then issue  a warning message  with a confirmation prompt,  similar to
> the way we do now if there is  an issue with line endings or a fork or
> a timestamp issue or other problem.

This is now implemented on the same branch:

https://www.fossil-scm.org/home/timeline?r=show-branch-change

Example:

$ fossil ci --no-prompt -m test
Pull from file:///tmp/master.fossil
Round-trips: 2   Artifacts sent: 0  received: 1
Pull done, wire bytes sent: 737  received: 3845  remote: 
parent check-in [c196dcaced] changed branch from 'trunk' to 'j'
Abandoning commit because branch has changed

It also works for interactive commits:

$ export EDITOR=ed
$ fossil ci
Pull from file:///tmp/master.fossil
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, wire bytes sent: 363  received: 1952  remote: 
ed ./ci-comment-CB666124B628.txt
131
1,$p
Prova.
# Enter a commit message for this check-in. Lines beginning with # are ignored.
#
# user: amb
# tags: l
#
# EDITED     file
1
Prova.
s/Prova/Prova Secondo/
w
139
q
Pull from file:///tmp/master.fossil
Round-trips: 2   Artifacts sent: 0  received: 1
Pull done, wire bytes sent: 739  received: 4079  remote: 
parent check-in [c196dcaced] changed branch from 'l' to 'm'
continue (y/N)? n
Abandoning commit because branch has changed


How does it look?

Andy

> Does and/or should the --force option disable the prompt?

It does now.  Thanks for the suggestion.

Andy

> I want it to detect a branch change that happens at any time prior to
> the commit.

Alright, let me see if I can figure that out. Also for clarification, do
you also mean that  if I run "fossil status" after  a previous "pull" or
"sync" operation has brought in a branch name change that applies to the
working checkout,  that it will  also issue a  warning then? Or  is this
a "commit" warning only?


> So, the  branch change might have  happened and have been  synced days
> before the commit, and the committer might be fully aware of it.

If  the branch  change was  synced  days ago,  then the  "state" of  the
repository has already changed. To detect the change "now" at the moment
of "commit",  are you suggesting  looking at  the tagxref table  for the
latest branch tag that is "newer"  than the current working checkout and
issuing a warning then?

Thanks,

Andy

> looking at the tagxref table for the latest branch tag that is "newer"
> than the current working checkout and issuing a warning then?

Or does the  tagxref table get updated during a  sync/pull, and the very
presence  of an  entry in  that table  for the  current checkout  rid is
evidence that the branch has changed? [seems that's not quite the case]
[but I might be able to use srcid and origid]

In which case, all that is needed to be done is find out the branch name
*before* that change happened. You did mention sorting out if there were
multiple changes and finding the name *before* all of those changes.

Let me know if I'm on the wrong track.

Thanks,

Andy

> To figure out the original name of the branch, look for the cancel tag
> on the symbol.

So it seems I  went a different direction in using  the tagxref table. I
wonder if it  would have been easier  to look for the cancel  tag as you
suggest.

This is what I've been testing:

https://www.fossil-scm.org/home/info/0aabb6bcacd627eb

Is this unncessarily complicated at this point? I'm not sure. Let me see
what it would take to instead use the cancel tag.

Thanks for the pointers.

Andy

> Here's an example of a bash prompt with changes against the checkin:

I'm not a  bash user, but I'll  admit that's a fun and  clever trick for
bash for those who are.

Andy

Kirill did say:

> and it takes two weeks for me to notice

That means that it would have emitted the warning two weeks ago, right?

With the changes you referenced  in the [show-branch-change] commits, it
would also  emit a  warning if  during a commit,  new changes  pulled in
during autosync cause  the branch to change, but I  don't know if that's
the  situation here.  [correction,  when attempting  to  commit and  the
branch changes it will actually halt]

My guess is that  this was simply a case where  the working checkout was
at  [8f509a5787] and  then  "fossil update"  was run  and  it emitted  a
warning about the branch change, but it went unnoticed.

> I  can't seem  to reproduce  in a  scenario with  two local  clones to
> trigger the message

It's a rare  thing to have happen in practice,  and challenging to cause
to happen on demand, but here's one way:

$ cd /tmp
$ fossil new project.fossil
$ fossil clone project.fossil clone.fossil
$ mkdir project; mkdir clone
$ fossil open project.fossil --workdir project
$ cd project
$ echo $RANDOM >> file 
$ fossil add file
ADDED  file

$ fossil ci -m first 
New_Version: 157b3ce7963aafb39018c80be54dd537756c69e431a22e6db7e05ba376b41caa

$ fossil pull -R ../clone.fossil 
Pull from file:///tmp/project.fossil
Round-trips: 2   Artifacts sent: 0  received: 2
Pull done, wire bytes sent: 665  received: 941  remote: 

$ fossil open ../clone.fossil 157b3ce7963a --workdir ../clone
$ fossil amend 157b3ce7963a --branch trial
hash:         157b3ce7963aafb39018c80be54dd537756c69e4 2025-12-12 18:04:04 UTC
tags:         trial
comment:      first (user: amb)

$ cd ../clone
$ echo $RANDOM >> file
$ fossil ci -m whoa
Pull from file:///tmp/project.fossil
Round-trips: 2   Artifacts sent: 0  received: 1
Pull done, wire bytes sent: 733  received: 1016  remote: 
parent check-in [157b3ce796] branch changed from 'trunk' to 'trial'
continue (y/N)?

> However, fossil up doesn't show me the message

That's odd, further up in this  thread I demonstrated that very behavior
to be  working, but  now I'm  not able  to get  it to  work as  you have
pointed out. I wonder if the change that I was making got lost somewhere
with other changes that were introduced. I'll take a look.

> > However, fossil up doesn't show me the message
>
> That's  odd,  further up  in  this  thread  I demonstrated  that  very
> behavior to be working,

Correction. What I demonstrated is that if you run "fossil update" which
initiates an  autosync that it will  detect the branch change,  which it
still handles correctly:

$ fossil status | grep tags
tags:         trunk

$ fossil up
Pull from file:///tmp/project.fossil
Round-trips: 2   Artifacts sent: 0  received: 1
Pull done, wire bytes sent: 632  received: 1779  remote: 
-------------------------------------------------------------------------------
checkout:     d5347c4516ab5fa13fa923ac37a7300dcfced3bb 2025-12-14 00:11:16 UTC
tags:         rugpull
comment:      ancora (user: amb)
changes:      None. Already up-to-date.  Branch changed from trunk to rugpull.
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I don't  think I  ever considered  the scenario  where one  runs "fossil
pull" followed by a "fossil update". The trouble is that by the time you
run "fossil update" the branch state has already changed:

$ fossil status | grep tags
tags:         trunk

$ fossil pull
Pull from file:///tmp/project.fossil
Round-trips: 2   Artifacts sent: 0  received: 1
Pull done, wire bytes sent: 632  received: 1400  remote: 

$ fossil status | grep tags
tags:         switcheroo

Notice that the branch changed even before I ran update.

In  other words,  I believe  this would  have to  be emitted  during the
"fossil pull", not  during the "fossil update" for it  to work, where in
my opinion it might be even less  likely to be noticed, but maybe not if
it's output in such  a way as to be noticed. I almost  never look at the
"fossil pull" output  unless there's an error. Is this  a good place for
such information?

If  instead we  want to  have "fossil  update" be  responsible for  this
condition,  then I  think we'll  have to  introduce some  kind of  state
tracking of branch names, the  functionality for which doesn't currently
exist in the local checkout DB. Perhaps a new key/value pair in the vvar
table, for example, that could keep track of which branch it's on:

sqlite> SELECT * FROM vvar;
"checkout" "16"
"checkout-hash" "ee60d8dfc985a8295234fa52055b284457470cce603ed1a4a27579597206e7d3"

Perhaps a key of "checkout-branch" could be used to track it? Some other
mechanism?

> Perhaps a  key of "checkout-branch"  could be  used to track  it? Some
> other mechanism?

Of course the option to do nothing does still exist. :-)

> In the case  discussed in this topic, I think  the tiny little feature
> is only half-baked, because it doesn't catch the case when autosync is
> off.

To be  fair, autosync  mode is the  default and is  actually one  of the
stated primary  features of  Fossil[1] so those  running without  it are
already more "expert"  and should be more aware of  the gotchas involved
in running in this way. I also think discarding the "feature" is fine if
we just improve the documentation.

If the  consensus is  to remove  the "feature", then so be it.

[1] https://fossil-scm.org/home/doc/trunk/www/index.wiki #6

> Perhaps a  key of "checkout-branch"  could be  used to track  it? Some
> other mechanism?

Actually, it could just be done by  looking at the tagxref table. In the
case that it is decided to handle offline modes.