Re: [JGIT PATCH 1/1] jgit: create a tag command

Previous thread: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch by Brian Gernhardt on Sunday, July 6, 2008 - 2:22 pm. (1 message)

Next thread: [JGIT PATCH 1/1] Fix local transport to invoke git-upload-pack during fetch by Shawn O. Pearce on Sunday, July 6, 2008 - 4:31 pm. (1 message)
From: Robin Rosenberg
Date: Sunday, July 6, 2008 - 3:41 pm

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, ...
From: Robin Rosenberg
Date: Sunday, July 6, 2008 - 4:16 pm

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 ...
From: Mike Ralphson
Date: Thursday, July 10, 2008 - 8:31 am

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
--

From: Robin Rosenberg
Date: Thursday, July 10, 2008 - 11:02 am

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
--

From: Jakub Narebski
Date: Friday, July 11, 2008 - 3:50 am

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
--

From: Shawn O. Pearce
Date: Thursday, July 10, 2008 - 7:05 pm

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.
--

From: Robin Rosenberg
Date: Friday, July 11, 2008 - 1:28 am

I've come to that conclusion too, but not yet to the code :)

-- robin
--

From: Mike Ralphson
Date: Friday, July 11, 2008 - 1:45 am

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
--

From: Shawn O. Pearce
Date: Friday, July 11, 2008 - 8:01 pm

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.
--

From: Shawn O. Pearce
Date: Friday, July 11, 2008 - 8:42 pm

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.
--

From: Robin Rosenberg
Date: Thursday, July 17, 2008 - 2:31 pm

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
--

From: Shawn O. Pearce
Date: Thursday, July 17, 2008 - 2:45 pm

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.
--

From: Robin Rosenberg
Date: Thursday, July 17, 2008 - 3:24 pm

Ok, then. Go ahead.

-- robin
--

Previous thread: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch by Brian Gernhardt on Sunday, July 6, 2008 - 2:22 pm. (1 message)

Next thread: [JGIT PATCH 1/1] Fix local transport to invoke git-upload-pack during fetch by Shawn O. Pearce on Sunday, July 6, 2008 - 4:31 pm. (1 message)