Re: [lmi] Branching to replace XSL-FO

[Vadim Zeitlin]

On Fri, 3 Nov 2017 13:53:14 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-10-28 00:56, Vadim Zeitlin wrote:
GC> > On Sat, 28 Oct 2017 00:27:32 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > just do, when you're on your branch:
GC> > 
GC> >   $ git checkout vz-no-xslfo '*.mst'
GC> >   $ git commit -m 'Create template files'
GC> [...]
GC> > GC> I can check out your branch:
GC> > GC>   git checkout vz-no-xslfo
GC> 
GC> AFAICT, git-checkout does starkly different things in different contexts:

 Yes. This is one of the most confusing git commands and a poster child of
Git poor UI.

GC> $git checkout gwc-no-xslfo
GC> This switches from one branch to another, without changing any contents.
GC> 
GC> $git checkout vz-no-xslfo '*.mst'
GC> This takes some files from the named branch and puts them in the current
GC> branch, without switching branches.
GC> 
GC> There are two concepts here that are utterly distinct in my mind:

 I could try to justify why are they not so different from the
implementation point of view, but why bother when you're obviously right
and they should clearly have been different commands.

GC> Maybe this make sense if we think of git-checkout as fundamentally
GC> meaning "change the working copy":
GC> 
GC> (a) git checkout X.txt
GC> Replace working copy of named file with last commit.
GC> 
GC> (b) git checkout X.branch
GC> Replace entire working copy with the set of files a branch contains.
GC> 
GC> (c) git checkout X.branch X.txt
GC> Replace working copy of named file with the version last committed on
GC> named branch.

 I think this explanation is not quite right. Switching branches in git
consists in 2 steps:

1. Update the working tree with the contents of the (tree associated to
   the) commit corresponding to the new branch pointer.
2. Update HEAD to point to the new branch.

Now you can kind of imagine, if you squint a little, that if you want to
update only some parts of the working tree, e.g. only "*.mst" files, then
you can still do (1), limited to these files only, but you can't really do
(2) because then you'd end up in a state where all the _other_ files would
be modified (compared to the branch you would now be on, as they were not
updated) while the files you specified on the command line would be (the
only ones) unchanged. As this doesn't make any sense at all, Git does the
next best thing: after partially doing (1), it doesn't do (2) at all. So
you end up with just the files you specified being updated, but HEAD is
unchanged.

 As I wrote above, it kind of makes sense from the implementation point of
view, but it doesn't justify this leaking into the interface level, of
course.

GC> Apparently it has multiple meanings, by deliberate design...

 I'm not sure if you can really call it "design", I think in the early days
of Git things mostly "just happened". But I wasn't there, so I don't know
how did it really happen.

GC> https://git-scm.com/docs/git-checkout
GC> "Switch branches or restore working tree files"

 The second part probably refers to using "git checkout -- filespec" to
revert the changes in the working copy by checking out the file from the
index. I.e. this description doesn't even cover what we're discussing here.

GC> ....and, as with C++'s 'static' keyword, we must simply accept a
GC> conflation of orthogonal concepts.

 I'm afraid we must indeed. Some other Git UI was improved, even at the
price of incompatible changes sometimes, but "git checkout" is such an
often used command, that I'm almost sure it's never going to change now.

 I hesitate to mention it, but you may easily create your own aliases for
it, e.g. you could use "git switch <branch>" for changing branches and
"checkout" for everything else. Or on the contrary use "git get-file
<branch> <files>" and "git checkout" for switching branches. But I think
that in the long term it's easier to just get used to this command
behaviour, illogical as it is.

 Sorry if this isn't the reply you hoped for, but it's the only one I could
write,
VZ