Should I parse git status or use gitsharp?

问题:

I'd like to integrate git into production pipeline to stage 3dsmax files. While it is alright to work with git through TortoiseGit, I'd like to communicate with it from the Maxscript to add custom menu commands to 3dsmax.

Should I parse git status output text to determine folder status or should I use some wrapping tool to correctly communicate with git?

I was thinking about gitsharp since it is easy to call dotNet objects from Maxscript, but I didn't use external dotNet programs.

回答1:

My own attempt to solve this resulted in parsing git status. Seems cleaner and easier to implement. On the other hand i'am looking forword to create an special crafted XML File to get the needed Information in a more "clean" Way.

回答2:

Since git version 1.7.0, there has been a --porcelain option for git status. The output of:

git status --porcelain

... is designed for use by scripts - a compact representation of the output whose format will remain consistent across versions. As the man page says:

Porcelain Format

The porcelain format is similar to the short format, but is guaranteed not to change in a backwards-incompatible way between git versions or based on user configuration. This makes it ideal for parsing by scripts. The description of the short format above also describes the porcelain format, with a few exceptions:

1. The user’s color.status configuration is not respected; color will always be off.
2. The user’s status.relativePaths configuration is not respected; paths shown will always be relative to the repository root.

There is also an alternate -z format recommended for machine parsing. In that format, the status field is the same, but some other things change. First, the -> is omitted from rename entries and the field order is reversed (e.g from -> to becomes to from). Second, a NUL (ASCII 0) follows each filename, replacing space as a field separator and the terminating newline (but a space still separates the status field from the first filename). Third, filenames containing special characters are not specially formatted; no quoting or backslash-escaping is performed.

So, as that says, you may also want to consider using:

git status -z

... for an even more robust output format.

回答3:

git generally contains "porcelain", high level commands designed for everyday user interaction, and "plumbing" which are low level commands which have simple, stable interfaces to build more porcelain. You can find a list in the git man page. To use sergo's example, git ls-files is the plumbing for git status. Wrapping the plumbing is easier and safer than the porcelain, though it may require some puzzling to figure out what set of plumbing maps to what porcelain.

回答4:

I've discovered git ls-files and I'm totally satisfied with its output format. git status was too human-oriented for parsing.

I would prefer Mercurial to git with its clear status command, but with large binary files it seems that git works better for me.

回答5:

I don't know nothing about maxscript but if you figure out how to call .net assemblies then you can use gitsharp and I think it would be the best and easiest option!

have a look at the unit tests of the gitsharp API. they show how to get the Status and other high level operations such as committing, switching branches, checking out, viewing changes of a commit and so on.

-- henon

回答6:

A lot of max is already using .NET assemblies. That should be the easiest thing to develop on. Besides parsing text.... is so fragile. I'd just forget about parsing text.