Re: changing the experimental 'git switch'

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

So, it probably makes sense to be more selective that what are
sensibly copied and what are not.  Reflog most likely does not
belong to the "sensibly copyable" set.  Tracking info most likely
does.  Among various configuration in branch.OLD.*, there may be
things like description that are not sensibly copyable.

It is a bit weird, but the main problem is that we'll use it for UI such
as @{-1} or whatever in addition to things like "x days ago". So if you
copy a branch for some ad-hoc testing, and were just running such a
command you might expend it to work.

The event of new branch "creation" onward should be recorded to the
reflog of the newly created branch.  As of X days ago, the new
branch did not even exist, so that is not a good excuse to copy the
reflog.

Also @{-1} comes from the reflog of HEAD, which is different from
what we are discussing.

For a user it also maps nicely to the mental model you'd have if you
copied two directories with the "-p" option to "cp", i.e. you'll be able
to run a "find" command on that checking mtime of N days ago and the
like.

Maybe it still doesn't make sense for those cases just some thoughts on
UX edge cases.

To me, it makes no sense, with these analogies.  If I make a copy of
a file one month old with timestamp copied, I may appreciate that
the newly created copy hasn't yet been touched by looking at the old
timestamp, but that does not necessarily mean that I want to pretend
that the new file was there from that old date, or I want to pretend
that the last time the new file was edited before that was at an
even old time.

If I were renaming a branch, that is a totally different story.  In
the mental model, the "identity" of the branch did not change, only
the label that I use to refer to it (called "name") has changed.

But I do not expect copying to split and give half the identity of
the original to the new one.