> 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