Re: [PATCH v2] Add script for importing bits-and-pieces to Git.

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 25, 2009, 20:42 UTC
Message-ID: <7v3a7foca9.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.2.00.0908251953480.19406@ds9.cixit.se>

Peter Krefting <peter@softwolves.pp.se> writes:

Show 10 quoted lines

>> You might want to mention that this format is different from what
>> git uses for its .git/config and .gitmodules files, and none of the
>> rules apply to them (namely, two/three-level names, case
>> sensitivity, allowed letters in variable names, stripping of
>> whitespaces around values, and value quoting) described in 'git help
>> config' apply to this file.
>
> A quick question on that: Is it possible to use the git-config parser
> stand-alone from a script like this? Then that note wouldn't need to
> apply.

Yes, but then you have to update your data language, because some of the section names and variables names you would want to use in your script are illegal in "git config" configuration language. Values and the second level name in two level section names are more-or-less free form (they need to be quoted as appropriately), but the first-level section names and the variable names are case insensitive, do not allow SPs and funnies, and there is no escaping. You cannot have "source.c" as the variable name, for example.

I'd recommend against re-using the git config format for that reason.

Another possibility would be to use something that does not even resemble the git config format, say, YAML as your data language. There is no risk of confusion from the end users if you did so, and we wouldn't need the note either.

Show 7 quoted lines

>> As you seem to be supporting merges, you might want to say
>> topologically instead of chronologically---this is minor, as you
>> give more precise definition "all parents must come before a child"
>> in that sentence later.
>
> I'm not sure I get the distinction here. Could you be a bit more
> specific (or point me to what I have missed in the Git manual)?

Your history could be in this shape (numbers are timestamps recorded in commit):

             1--4
            /    \
	0--3--6---9--12

when somebody with a skewed clock forked the project at commit 3, worked on a side branch to create two commits 1 and 4, which are pulled back to the mainline at commit 9.

Chronological listing would mean 0 1 3 4 6 9 12. Topological listing would be either 0 3 1 4 6 9 12 or 0 3 6 1 4 9 12 or 0 3 1 6 4 9 12.