This command allows us to create simple or annotated tags using the jgit command line. PGP signed tags are not yet supported. Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> --- I ned this for tagging self-jgit-managed automated builds of the Eclipse plugin. I could do with an Ant task, but this will work too. -- robin org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java | 96 ++++++++++++++++++++ 1 files changed, 96 insertions(+), 0 deletions(-) create mode 100644 org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java diff --git a/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java new file mode 100644 index 0000000..a9377f5 --- /dev/null +++ b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java @@ -0,0 +1,96 @@ +/* + * Copyright (C) 2008, Robin Rosenberg <robin.rosenberg@dewire.com> + * + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or + * without modification, are permitted provided that the following + * conditions are met: + * + * - Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * - Redistributions in binary form must reproduce the above + * copyright notice, this list of conditions and the following + * disclaimer in the documentation and/or other materials provided + * with the distribution. + * + * - Neither the name of the Git Development Community nor the + * names of its contributors may be used to endorse or promote + * products derived from this software without specific prior + * written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND + * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, + * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR + * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, ...
This command allows us to create simple or annotated tags. PGP signed tags are not yet supported. Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> --- org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java | 102 ++++++++++++++++++++ 1 files changed, 102 insertions(+), 0 deletions(-) create mode 100644 org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java An obvious omission was not to allow the user to tag anything but HEAD. diff --git a/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java new file mode 100644 index 0000000..110db6b --- /dev/null +++ b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java @@ -0,0 +1,102 @@ +/* + * Copyright (C) 2008, Robin Rosenberg <robin.rosenberg@dewire.com> + * + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or + * without modification, are permitted provided that the following + * conditions are met: + * + * - Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * - Redistributions in binary form must reproduce the above + * copyright notice, this list of conditions and the following + * disclaimer in the documentation and/or other materials provided + * with the distribution. + * + * - Neither the name of the Git Development Community nor the + * names of its contributors may be used to endorse or promote + * products derived from this software without specific prior + * written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND + * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, + * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR + * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT ...
Apologies this will be whitespace damaged, but it's trivial.
diff --git a/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
index 110db6b..a215fbd 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
@@ -47,6 +47,8 @@ class Tag extends TextBuiltin {
String message = null;
String ref = "HEAD";
boolean force = false;
+ if (args.length == 0)
+ usage();
for (int i = 0; i < args.length; ++i) {
if (args[i].equals("-f")) {
force = true;
@@ -97,6 +99,6 @@ class Tag extends TextBuiltin {
}
private void usage() {
- throw die("Usage: -m message tag [head]");
+ throw die("Usage: [-m message] [-f] tag [head]");
}
}
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Loving the make_jgit stuff.
Mike
--
Don't do like that again : Had to use patch -l to apply this. Why doesn't git am have that? Anyway thanks for the fix. -- robin --
It is not git-am that should have implemented -l / --ignore-whitespace option, but git-apply... well, beside passing it to git-apply of course. I tried to look up how git-apply is implemented (builtin-apply.c), but it looks like it implements patching itself, and I am not familiar at all with this code... BTW. why applying patch is not left to xdiff code? It would be nice if git-apply implemented larger subset of GNU patch options, for example --dry-run (which is similar but I think not exactly the same as --check), --fuzz=<num> (how it differs from -C<n>?) --strip=<num> as equivalent to -p<n>, -l / --ignore-whitespace, --reject-file=<rejectfile> together with --reject... -- Jakub Narebski Poland ShadeHawk on #git --
So making jgit a single stand-alone, portable shell script for command line usage was a good idea? ;-) I think we are at the point where we need to either write a #@!*(!@(! command line option parser, import one, or stop writing command line programs. I would certainly appreciate any opinion you might have on the matter. -- Shawn. --
I've come to that conclusion too, but not yet to the code :) -- robin --
It certainly seems so to me. It's a nice quick way of seeing what's implemented (I was toying with adding a jgit help command which would reflect over the TextBuiltins). I'm not sure which if any platforms would eventually be better off a) is a distraction, c) is a backwards step, so maybe b) wins. I don't know what the state of the art of Java option parsers is but there is a port of GNU getopt [1] which might drop in quite easily. Mike PS apologies for the patch format, I'm stuck with Outlook or gmail, and a recalcitrant firewall for the moment. [1] http://www.urbanophile.com/arenn/hacking/download.html --
Yea, sadly our builtins don't register themselves into a table so its a bit difficult to enumerate them at this time. But it probably would not be a difficult thing to change at all, and since we don't have a Not all platforms can compile c git, e.g. they are missing a c compiler, but have a JRE handy. Odd, I know, but sometimes that's how it goes. Or maybe you have a JRE handy, and want to just download the single stand-alone jgit jar to get some sort of a basic git implementation available, so you can clone and build the real thing direct from Junio's sources. Or maybe you are using a transport (Amazon S3) that C Git just So I looked at GNU getopt and its at least smaller than Apache Commons, and doesn't have this damned-if-you-do, damned-if-you-do version selection choice they offer their end-users. But it really makes building something like an automatic --help difficult if not impossible, and certainly makes handling numeric vs. ObjectId vs. String vs. File arguments annoying. I'd almost rather just do a). It wouldn't take long to get something small rolled out and working. We don't need to support every goddamn Some people are terrified of that system of tubes. I feel for you. -- Shawn. --
Probably the state-of-the-arg is args4j: https://args4j.dev.java.net/ It uses Java 5 annotations to setup the argument parsing: public class SampleMain { @Option(name="-r",usage="recursively run something") private boolean recursive; @Option(name="-o",usage="output to this file",metaVar="OUTPUT") private File out = new File("."); @Option(name="-str") // no usage private String str = "(default value)"; ... I'm usually not a big fan of reflection, but it may make sense to take advantage of it in a case like this, and just import args4j into our command line tools. args4j is provided under the MIT license. -- Shawn. --
But it doesn't use GNU getOpt's long/short style parsing which is a BIG loss. Maybe we could contribute it? Or at least not design options incompatible with such an option parser. -- robin --
I'm already using long style options, "--git-dir", "$path" works, and I taught a subclass wrapper to split "--git-dir=$path" into the two argument format so we can handle the GNU style long options. Short style options are harder. You can alias "-h" to "--help" and have both respond, but you cannot get option clusters like "-ar" to expand to "-a","-r" and then parse. I could have the same wrapper handle splitting "-ar" into "-a","-r" but it cannot handle "-C80r" as "-C80","-r" as it doesn't have any information about what options take values, and which don't. Getting "--" to terminate the end of options is supported, but making it handle `git log ref -- path` was interesting. I had to make "--" actually an option name, and have it eat all values after "--" as path specs to implement git-log style arguments. Looking at the code further its fairly simple. I don't think it would be difficult for us to tweak what we need, and try to push patches upstream. Well worthwhile actually. The parser made our pgm package shorter, and we didn't have to waste time writing our own. Its well built, and was (mostly) easily extended to handle fully transparent String->RevCommit or String->RevTree parsing. So its worth the few minutes to improve it further. -- Shawn. --
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable wor |
