Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>> 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.
