top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

GIT argument parsing...Parse --o in format-patch

0 votes
260 views

I don't quite manage to figure out gits argv parsing and would need some help on the way.

I want:
git format-patch -o outdir HEAD~

Work exactly the way it does now, setting output_directory to outdir. But I also want
git format-patch -o HEAD~

to set output_directory with a NULL value so that I can assign a default value to it. Is that even possible with the current argv-parsing implementation?

The currect argv parser is using OPTION_CALLBACK so I thought that that callback should be able to determine if there was an outdir supplied or not.

Or is the correct solution to also add a bolean type OPTION_BOOLEAN for -o?

posted Jun 28, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

It's possible to have an "optional" argument by using the PARSE_OPT_OPTARG flag. However, it is not backwards compatible from the user's perspective, as they must use the "sticked" form:

git format-patch -ooutdir ...

to specify the argument. Otherwise, it is not clear in:

 git format-patch -o outdir HEAD~

whether "outdir" is the argument to "-o", or if it is simply the next argument.

However, if you are just interested in "turning off" a previously given argument, we usually spell that with the "--no-" prefix to the long option (e.g., "--no-output-directory" in this case).

I'm not clear how that interacts with your example, though. Your example tries to use "-o" to set output_directory to NULL. But it is already NULL if you do not specify any "-o" at all.

answer Jun 28, 2013 by anonymous
Similar Questions
0 votes

I'm new to using Git and I'm a little confused. I'm trying to patch a module and I've gone to terminal and gone to the folder I need to patch via FTP.

I've been following this tutorial
http://www.youtube.com/watch?v=i-oe7_qHreY

but whenever I add the apply git command I get 'invalid command'. Does Git only apply patches locally? What am I dong wrong?

0 votes

After switching from svn/hg to git and getting some experience, I feel I'm ready to figure out which questions aren't too obvious. My feeling is the current question isn't.

Today I was hacking away, only to discover that I was really working on too much stuff at once. I wanted to stash away a sub-set of my changes, and leave the rest to focus on first. So I did a 'git stash --patch', selected the patches I wanted to move away for now. Only to discover that I stashed away 2 patches too many .... Bummer.

Alas: I kind of hoped I could do something like 'git stash apply --patch stash@{1}'...... but that didn't quite work: I just got the full stash applied on top of the working directory (to be verbose: this was done after stashing the remaining patches).
I hope my situation was explained clearly enough. My question is not about how to recover. That's easy by redoing the original stash command, but properly this time. My question is more about learning something more about git, in case I end up in the same, or a similar situation in the future:
* is there a way to force 'git stash --patch' to create a separate stash for each patch that I select? This would make it possible to apply each patch again afterwards, and would have been a perfect solution in my case as well
* otherwise, is there a way to achieve the result I had hoped for when running 'git stash apply --patch', namely to selectively apply hunks

In case the answer to both of these is 'No', what would be the proper way and/or place to suggest such a feature?

+1 vote

In my local clone of git.git, currently with the v1.8.4-rc2 tag checked out and built (and installed on the system), starting up gitk yields an empty window, with a dialog in front of it:

 error    
 Can't parse git log output: { }

Has anyone else seen this, and know what might have happened? I do not get the behavior in other repositories (including other clones of git.git), only this particular one.

–1 vote

Running "git rev-parse --show-toplevel" doesn't print anything when it is run inside .git dir (on all levels)

+1 vote

When using argparse, is there a way to specify in what order arguments get parsed? I am writing a script whose parameters can be modified in the following order:

Defaults -> config file -> command-line switches.

However, I want to give the option of specifying a config file using a command line switch as well, so logically, that file should be parsed before any other arguments are applied. However, it seems that parse_args() parses arguments in the order they're given, so if the config file switch is not given first, the config file will overwrite whatever was in the command-line switches, which should have higher priority.

...