Closed tomasherman closed 11 years ago
Thanks for this; the functionality is certainly important. Specifying files using a Python regex is unconventional for a Git user. How about passing a git ls-files
pattern or, for more precise users, a list of files on stdin? Also, a basic test would be appreciated. (I'm planning to convert the few tests to use sharness. The current script is cruddy, but at least it shows something.)
Yeah, using git ls-files
makes more sense. I will use that instead and check out the sharness too.
Maybe the api could be: git fat pull 'pattern1' 'pattern2'
etc? What do you think?
I'm planning to convert the few tests to use sharness
git-fat being primarily written in python, is there any particular reason for not choosing a python testing framework like py.test or nose?
re: API: just my 2 cents here, I think it makes very much sense to match the git API as closely as possible to minimize the potential for surprises and to minimize friction losses when learning git-fat.
I rewrote the thing using ls-files. I'm not really sure how to test the behavior. I can add some unit tests, though, if you decide to use python testing.
@bilderbuchi We had this discussion on gitifyhg, which is migrating from py.test
and sh
to sharness
. Since the primary interface is command line, python testing ended up being "obfuscated shell scripting", with more effort involved to translate between discovering a problem and creating a test to demonstrate it. Also, since sharness
is git.git's testing system, it would make eventual upstreaming of git-fat
easier.
so basically we are going to assume there will be:
git fat pull followed by - and -- prefixed values followed by patterns
is that what you want? Yeah i will squish the commits when we have something you like :)
I wouldn't try to interpret anything before the stand-alone --
since that makes the intent unambiguous. Git has many commands that require --
in general, though some of them will try without --
in simple cases.
See e.g. man git add (cause it also can select files based upon a pattern) as to how the argument structure looks like. Also note that --
is optional and not always needed, as jed points out.
re sharness/py.test: thanks, that makes sense.
Oh ok, i think i understand now (sorry i'm quite a noob ;))
3rd time's the charm, maybe? :)
I squashed all the commits together too.
I merged as c23422388b975f13867457c86c78361dfdf8036e (cosmetic clean-up: default argument, eliminate trailing whitespace, pass pattern as list instead of concatenating). I also added a demonstration to test.sh (separate commit).
I wish github pull requests had a "superseded" feature, but I can't update the PR because it comes from your branch.
Cool, thanks
I'm not sure if you are interested in this functionality, but I needed to be able to specify only a subset of files to be downloaded.
Usage is
and it should only download and restore files matching the regex