lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Branching to replace XSL-FO


From: Vadim Zeitlin
Subject: Re: [lmi] Branching to replace XSL-FO
Date: Sat, 28 Oct 2017 02:56:16 +0200

On Sat, 28 Oct 2017 00:27:32 +0000 Greg Chicares <address@hidden> wrote:

GC> Suppose I now want to bring all the new '*.mst' files into my branch:
GC> only them, and nothing more.

 Before explaining how to do it, let me say for one last time that I don't
consider it to be a good idea to do it like this. IMO it doesn't make much
sense to have a commit adding unused files, as you plan to do. It also will
complicate things later: it's not that difficult to bring just these files
into your branch, but this means that you will need to combine multiple
commits touching the C++ code too later too because you won't be able to
use earlier commits, using old .mst file names, unchanged. So you will be
making life more difficult for yourself in the (near) future. Is it really
worth it?


GC> I can imagine various ways of doing that,
GC> as follows; which is best?

 I don't know what is the criterion for being "best". The simplest is to
just do, when you're on your branch:

        $ git checkout vz-no-xslfo '*.mst'
        $ git commit -m 'Create template files'

The first command gets all the files matching the given Git pathspec (note
that it's _not_ the shell wildcard expansion, hence the quotes around it)
into the index and the second just commits them.

 Of course, this loses all the history of the changes to these files,
including their renaming (granted, this is not very important), but you
probably don't care about this anyhow (in this branch, at least).

GC> (1) Find the latest SHA1 for all these files. To identify the commits,
GC> I can check out your branch:
GC>   git checkout vz-no-xslfo
GC> and search for '\.mst' here:
GC>   git log --stat
GC> It appears that these two commits should cover all '*.mst' files:
GC>   982c9f0 Remove consecutive blank lines from a Mustache template
GC>   2fd6a11 Use shorter and more consistent names for external templates

 No, there are many more commits touching these files, even just doing
(still from your own branch)

        $ git lg ..vz-no-xslfo '*.mst'

shows a few more of them:

        982c9f0d9 Remove consecutive blank lines from a Mustache template
        2fd6a11c1 Use shorter and more consistent names for external templates
        0ba1c320a Consistently use "curr" as abbreviation of "current"
        7c0ff8822 Add copyright notices to all .mst template files
        a0a167ec1 Rename "compliance_tracking_number" template to "imprimatur"
        cc7fc05fb Change template file extension from .mustache to .mst

But you need to also take into account the earlier commits changing the
.mustache files and there are too many of them:

        $ git lg ..vz-no-xslfo '*.mst' | wc -l
        46

 So this approach is rather hopeless.


GC> (2) Instead, maybe I should just import everything from your branch,
GC> all at once, creating a complete copy; and then work on it as I would
GC> normally work on 'master'. In effect, I'd still be doing my work
GC> linearly as always, except on a different line.

 I don't see how does it really help solve the problem ("bring only *.mst
files in your branch and only them")...

GC> (3) Alternatively, suppose I just put your branch into a subdirectory
GC> of master, and then gradually move files into the main directory? If I
GC> did that with 'git mv', would git be smart enough to recognize them,
GC> so that their (your) history would be preserved? This way, we'd never
GC> even need to do a 'git merge'.

 No, no, no, we will definitely need to do "git merge", otherwise the
history of my changes will be lost. We don't do the merge to merge the
contents (we had decided that we're going to take your version of them),
but to merge the two histories together. So unless you cherry-pick all
commits of my branch in order (which you don't plan to do at all), the
merge is required.

 "git mv" won't help you at all because when you "put my branch into a
subdirectory", it presumably won't be under git control at all, so it's
just like a variant of (2).


 Anyhow, I think my method in the very beginning should satisfy your
requirements -- but please let me know if it doesn't.

 Regards,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]