* [RFC/PATCH 2/7] refs: add a "for_each_replace_ref" function
From: Christian Couder @ 2009-01-12 17:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This is some preparation work for the following patches that are using
the "refs/replace/" ref namespace.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
refs.c | 5 +++++
refs.h | 1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/refs.c b/refs.c
index 33ced65..042106d 100644
--- a/refs.c
+++ b/refs.c
@@ -632,6 +632,11 @@ int for_each_remote_ref(each_ref_fn fn, void *cb_data)
return do_for_each_ref("refs/remotes/", fn, 13, cb_data);
}
+int for_each_replace_ref(each_ref_fn fn, void *cb_data)
+{
+ return do_for_each_ref("refs/replace/", fn, 13, cb_data);
+}
+
/*
* Make sure "ref" is something reasonable to have under ".git/refs/";
* We do not like it if:
diff --git a/refs.h b/refs.h
index 06ad260..8d2ee5a 100644
--- a/refs.h
+++ b/refs.h
@@ -23,6 +23,7 @@ extern int for_each_ref(each_ref_fn, void *);
extern int for_each_tag_ref(each_ref_fn, void *);
extern int for_each_branch_ref(each_ref_fn, void *);
extern int for_each_remote_ref(each_ref_fn, void *);
+extern int for_each_replace_ref(each_ref_fn, void *);
/*
* Extra refs will be listed by for_each_ref() before any actual refs
--
1.6.1.83.g16e5
^ permalink raw reply related
* Re: [JGIT] Blame functionality for jgit
From: Shawn O. Pearce @ 2009-01-12 17:42 UTC (permalink / raw)
To: Manuel Woelker; +Cc: Robin Rosenberg, git
In-Reply-To: <3d045c7e0901111223j43a69402s28a59612212943f3@mail.gmail.com>
Manuel Woelker <manuel.woelker@gmail.com> wrote:
> Over the weekend I have been hacking the jgit sources a little to see
> if I can add blame/praise/annotate functionality to it. The results
> can be found at http://github.com/manuel-woelker/egit/tree/blame . All
> work is in the blame branch in org.spearce.jgit.blame package.
Interesting.
> I largely ported the cgit blame algorithm described here
> https://kerneltrap.org/mailarchive/git/2006/10/12/224187 , the
> relevant file is builtin-blame.c cf.
> http://repo.or.cz/w/git.git?a=blob;f=builtin-blame.c;hb=HEAD
OK. Fortunately Junio has largely given his blessing to this code
being converted to Java under the BSD license.
> The blame algorithm needs to use a diff algorithm to find common parts
> in files. AFAICT there is no diff implementation in jgit at the
> moment. I used the incava java-diff library, (see
> http://www.incava.org/projects/java/java-diff ), but I introduced an
> interface that should make it possible to swap implementations with a
> minimum of effort. To compile I just create a new eclipse project with
> the java-diff sources.
Unfortunately I can't reach incava.org to download java-diff, but
its entry on sourceforge says it uses an LGPL license. Within JGit
we do want to stick to BSD and BSD dependencies, so bringing in
java-diff as a new dependency isn't something we really want to do.
Fortunately Dscho has been working on a Java diff implementation for
JGit, and is considering releasing it under a BSD license so we can
include it.
The interface is still to be decided, but in general we have
found that running against a byte[] is much faster than running
against String. We're probably going to want the diff library to
take a byte[] and an IntList (as created by RawParseUtils.lineMap)
and let it work against the byte array ranges directly, without any
additional allocations, except where it needs to build up its hash
of records.
> I would like to hear your thoughts on a couple of topics:
> - Merge/patch/diff/blame functionality needs a diff implementation,
> what are our options within technical and license constraints?
I'm open to a plugin interface like you have done with the IDiff
API to hide java-diff, but for that to work we cannot have the
java-diff code as part of the JGit classpath. It needs to be
something added externally by the user, in a different context,
so the user can easily load their preferred diff implementation.
If that happents to be the LGPL java-diff, that's the user's choice.
We can provide the shim needed to get it to load, and the adapter,
but IMHO we shouldn't distribute the LGPL code, and we shouldn't
make it required in order to make the library compile or work.
Eclipes has its own LCS implementation, we should also be able
to have the Eclipse plugin provide its own shim to link to the
Eclipse EPL licensed LCS, so Eclipse can avoid java-diff entirely.
I'm not sure if NetBeans has an LCS available that the NetBeans
plugin could easily link to. It probably does.
I think eventually we'll have a BSD licensed LCS that will come with
JGit, which would eliminate the need for such a shim. I'd like
to see that happen before blame gets added, but if blame is ready
and the shim is reasonably well done, I'm inclined to bring blame
in early.
> - What is the roadmap for these features?
There isn't one. Its whatever gets contributed in a state that is
ready for inclusion. :-)
Since you are submitting this work, I'd say its on you to get
blame added.
> - Can you see this blame effort getting integrated upstream?
Yes.
> I would love to contribute more effort to egit and the blame
> functionality in particular. To me, "blame" is one of the killer
> features of modern SCMs.
I agree, I use git blame fairly often myself...
> Last no least, kudos to the git and egit teams for their hard work on
> making git such a great piece of software.
Thanks.
Now for some comments about your blame branch.
- Don't use @author tags, we don't use them anywhere else.
- Please include copyright headers on all new files.
- I think the IDiff, IDifference should be in a ".diff" package so
we can reuse them for other diff applications. Especially if we
wind up using a shim to link to different LCS implementations.
- I think the API for BlameEngine should be more like:
public class BlameEngine {
private final RevWalk rw;
public BlameEngine(final Repository repo) {
this(new RevWalk(repo));
}
public BlameEngine(final RevWalk walk) {
rw = walk;
}
public RevWalk getRevWalk() {
return rw;
}
public List<BlameEntry> blame(RevCommit c, String path);
}
One reason for this style of API is we can have the engine cache
blame records. This can make a GUI navigator much more efficient
as it jumps around between commits and asks for blames over the
same data.
- Internally you should *always* use RevCommit, not Commit.
The RevCommit class can be orders of magnitude faster than Commit.
- Internally you should always use RevTree and TreeWalk to locate
blob IDs. Its orders of magnitude faster than Tree and TreeEntry.
- Don't use new String(loader.getBytes()) (e.g. in Origin.getData)
to get the data for a file. We want to do raw diffs, so that the
character encoding is considered as part of the blame. E.g. if
a file switches character encodings, the blame has to go to the
commit that introduced the new encoding. This is a huge reason
to use byte[] and IntList over an array of String.
- RawParseUtils.lineMap will be faster than a Pattern of "^(.*)$".
Otherwise, I'm finding your code to be quite clear, and converted
rather nicely from C. I'd love to see this integrated into the
JGit project.
--
Shawn.
^ permalink raw reply
* [RFC/PATCH 3/7] replace_object: add mechanism to replace objects found in "refs/replace/"
From: Christian Couder @ 2009-01-12 17:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The code implementing this mechanism has been copied from the commit
graft code.
This mechanism is used in "read_sha1_file". sha1 passed to this
function that match a ref name in "refs/replace/" are replaced by
the sha1 that has been read in the ref.
We "die" if the replacement recursion depth is too high or if we
can't read the replacement object.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Makefile | 1 +
commit.h | 2 +
replace_object.c | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
sha1_file.c | 14 +++++-
4 files changed, 130 insertions(+), 3 deletions(-)
create mode 100644 replace_object.c
diff --git a/Makefile b/Makefile
index dee97c1..7cf5d9a 100644
--- a/Makefile
+++ b/Makefile
@@ -471,6 +471,7 @@ LIB_OBJS += read-cache.o
LIB_OBJS += reflog-walk.o
LIB_OBJS += refs.o
LIB_OBJS += remote.o
+LIB_OBJS += replace_object.o
LIB_OBJS += rerere.o
LIB_OBJS += revision.o
LIB_OBJS += run-command.o
diff --git a/commit.h b/commit.h
index 3a7b06a..37aa763 100644
--- a/commit.h
+++ b/commit.h
@@ -122,6 +122,8 @@ struct commit_graft *read_graft_line(char *buf, int len);
int register_commit_graft(struct commit_graft *, int);
struct commit_graft *lookup_commit_graft(const unsigned char *sha1);
+const unsigned char *lookup_replace_object(const unsigned char *sha1);
+
extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2, int cleanup);
extern struct commit_list *get_merge_bases_many(struct commit *one, int n, struct commit **twos, int cleanup);
extern struct commit_list *get_octopus_merge_bases(struct commit_list *in);
diff --git a/replace_object.c b/replace_object.c
new file mode 100644
index 0000000..25b3ef3
--- /dev/null
+++ b/replace_object.c
@@ -0,0 +1,116 @@
+#include "cache.h"
+#include "refs.h"
+
+static struct replace_object {
+ unsigned char sha1[2][20];
+} **replace_object;
+
+static int replace_object_alloc, replace_object_nr;
+
+static int replace_object_pos(const unsigned char *sha1)
+{
+ int lo, hi;
+ lo = 0;
+ hi = replace_object_nr;
+ while (lo < hi) {
+ int mi = (lo + hi) / 2;
+ struct replace_object *rep = replace_object[mi];
+ int cmp = hashcmp(sha1, rep->sha1[0]);
+ if (!cmp)
+ return mi;
+ if (cmp < 0)
+ hi = mi;
+ else
+ lo = mi + 1;
+ }
+ return -lo - 1;
+}
+
+static int register_replace_object(struct replace_object *replace,
+ int ignore_dups)
+{
+ int pos = replace_object_pos(replace->sha1[0]);
+
+ if (0 <= pos) {
+ if (ignore_dups)
+ free(replace);
+ else {
+ free(replace_object[pos]);
+ replace_object[pos] = replace;
+ }
+ return 1;
+ }
+ pos = -pos - 1;
+ if (replace_object_alloc <= ++replace_object_nr) {
+ replace_object_alloc = alloc_nr(replace_object_alloc);
+ replace_object = xrealloc(replace_object,
+ sizeof(*replace_object) *
+ replace_object_alloc);
+ }
+ if (pos < replace_object_nr)
+ memmove(replace_object + pos + 1,
+ replace_object + pos,
+ (replace_object_nr - pos - 1) *
+ sizeof(*replace_object));
+ replace_object[pos] = replace;
+ return 0;
+}
+
+static int register_replace_ref(const char *refname,
+ const unsigned char *sha1,
+ int flag, void *cb_data)
+{
+ /* Get sha1 from refname */
+ const char *slash = strrchr(refname, '/');
+ const char *hash = slash ? slash + 1 : refname;
+ struct replace_object * repl_obj = xmalloc(sizeof(*repl_obj));
+
+ if (strlen(hash) != 40 || get_sha1_hex(hash, repl_obj->sha1[0])) {
+ free(repl_obj);
+ warning("bad replace ref name: %s", refname);
+ }
+
+ /* Copy sha1 from the read ref */
+ hashcpy(repl_obj->sha1[1], sha1);
+
+ /* Register new object */
+ if (register_replace_object(repl_obj, 1))
+ warning("duplicate replace ref: %s", refname);
+
+ return 0;
+}
+
+static void prepare_replace_object(void)
+{
+ static int replace_object_prepared;
+
+ if (replace_object_prepared)
+ return;
+
+ for_each_replace_ref(register_replace_ref, NULL);
+ replace_object_prepared = 1;
+}
+
+/* We allow "recursive" replacement. Only within reason, though */
+#define MAXREPLACEDEPTH 5
+
+const unsigned char *lookup_replace_object(const unsigned char *sha1)
+{
+ int pos, depth = MAXREPLACEDEPTH;
+ const unsigned char *cur = sha1;
+
+ prepare_replace_object();
+
+ /* Try to recursively replace the object */
+ do {
+ if (--depth < 0)
+ die("replace depth too high for object %s",
+ sha1_to_hex(sha1));
+
+ pos = replace_object_pos(cur);
+ if (0 <= pos)
+ cur = replace_object[pos]->sha1[1];
+ } while (0 <= pos);
+
+ return cur;
+}
diff --git a/sha1_file.c b/sha1_file.c
index f08493f..4f2fd10 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2163,10 +2163,18 @@ static void *read_object(const unsigned char *sha1, enum object_type *type,
void *read_sha1_file(const unsigned char *sha1, enum object_type *type,
unsigned long *size)
{
- void *data = read_object(sha1, type, size);
+ const unsigned char *repl = lookup_replace_object(sha1);
+ void *data = read_object(repl, type, size);
+
+ /* die if we replaced an object with one that does not exist */
+ if (!data && repl != sha1)
+ die("replacement %s not found for %s",
+ sha1_to_hex(repl), sha1_to_hex(sha1));
+
/* legacy behavior is to die on corrupted objects */
- if (!data && (has_loose_object(sha1) || has_packed_and_bad(sha1)))
- die("object %s is corrupted", sha1_to_hex(sha1));
+ if (!data && (has_loose_object(repl) || has_packed_and_bad(repl)))
+ die("object %s is corrupted", sha1_to_hex(repl));
+
return data;
}
--
1.6.1.83.g16e5
^ permalink raw reply related
* Re: [RFC PATCH 2/3] Add specification of git-vcs helpers
From: Daniel Barkalow @ 2009-01-12 17:46 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <496AFB8D.4000803@viscovery.net>
On Mon, 12 Jan 2009, Johannes Sixt wrote:
> Daniel Barkalow schrieb:
> > +NAME
> > +----
> > +git-vcs-* - Helper programs for interoperation with foreign systems
> > +
> > +SYNOPSIS
> > +--------
> > +'git vcs-<system>' <command> [options] [arguments]
>
> The current rule is that helper programs have double-dash in the name:
> git-rebase--interactive, git-web--browse, etc.
I'm not entirely sure if these are helper programs in that sense, or
really what the distinction is between these and regular plumbing.
Multiple programs will be calling them, and they'll have a specified API,
in any case. (I think the double-dash programs are ones where all of the
call sites are internal, so both the API and all the users can be changed
together.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Shawn O. Pearce @ 2009-01-12 17:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, git
In-Reply-To: <alpine.DEB.1.00.0901121811301.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 12 Jan 2009, Shawn O. Pearce wrote:
>
> > This year I may not be able to be a mentor for GSoC.
>
> Pity. But you started the preparation for the new application, thank you
> very much. Will you be able to be administrator again?
Yes, I can certainly do the administrative functions again this year,
and would be more than happy to do it. Most of it happens before the
students start work, and thus before any theoretical intern would
also join me at day-job. To be honest I spend most of the time on
the org application itself; its all down hill from there.
--
Shawn.
^ permalink raw reply
* [RFC/PATCH 4/7] sha1_file: add a "read_sha1_file_repl" function
From: Christian Couder @ 2009-01-12 17:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This new function will replace "read_sha1_file". This latter function
becoming just a stub to call the former will a NULL "replacement"
argument.
This new function is needed because sometimes we need to use the
replacement sha1.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
cache.h | 6 +++++-
sha1_file.c | 9 +++++++--
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index 8e1af26..1b34381 100644
--- a/cache.h
+++ b/cache.h
@@ -625,7 +625,11 @@ int longest_ancestor_length(const char *path, const char *prefix_list);
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
extern int sha1_object_info(const unsigned char *, unsigned long *);
-extern void * read_sha1_file(const unsigned char *sha1, enum object_type *type, unsigned long *size);
+extern void *read_sha1_file_repl(const unsigned char *sha1, enum object_type *type, unsigned long *size, const unsigned char **replacement);
+static inline void *read_sha1_file(const unsigned char *sha1, enum object_type *type, unsigned long *size)
+{
+ return read_sha1_file_repl(sha1, type, size, NULL);
+}
extern int hash_sha1_file(const void *buf, unsigned long len, const char *type, unsigned char *sha1);
extern int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned char *return_sha1);
extern int pretend_sha1_file(void *, unsigned long, enum object_type, unsigned char *);
diff --git a/sha1_file.c b/sha1_file.c
index 4f2fd10..ea89ce5 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2160,8 +2160,10 @@ static void *read_object(const unsigned char *sha1, enum object_type *type,
return read_packed_sha1(sha1, type, size);
}
-void *read_sha1_file(const unsigned char *sha1, enum object_type *type,
- unsigned long *size)
+void *read_sha1_file_repl(const unsigned char *sha1,
+ enum object_type *type,
+ unsigned long *size,
+ const unsigned char **replacement)
{
const unsigned char *repl = lookup_replace_object(sha1);
void *data = read_object(repl, type, size);
@@ -2175,6 +2177,9 @@ void *read_sha1_file(const unsigned char *sha1, enum object_type *type,
if (!data && (has_loose_object(repl) || has_packed_and_bad(repl)))
die("object %s is corrupted", sha1_to_hex(repl));
+ if (replacement)
+ *replacement = repl;
+
return data;
}
--
1.6.1.83.g16e5
^ permalink raw reply related
* [RFC/PATCH 5/7] object: call "check_sha1_signature" with the replacement sha1
From: Christian Couder @ 2009-01-12 17:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Otherwise we get a "sha1 mismatch" error for replaced objects.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
object.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/object.c b/object.c
index 50b6528..217bee9 100644
--- a/object.c
+++ b/object.c
@@ -187,17 +187,18 @@ struct object *parse_object(const unsigned char *sha1)
unsigned long size;
enum object_type type;
int eaten;
- void *buffer = read_sha1_file(sha1, &type, &size);
+ const unsigned char *repl;
+ void *buffer = read_sha1_file_repl(sha1, &type, &size, &repl);
if (buffer) {
struct object *obj;
- if (check_sha1_signature(sha1, buffer, size, typename(type)) < 0) {
+ if (check_sha1_signature(repl, buffer, size, typename(type)) < 0) {
free(buffer);
- error("sha1 mismatch %s\n", sha1_to_hex(sha1));
+ error("sha1 mismatch %s\n", sha1_to_hex(repl));
return NULL;
}
- obj = parse_object_buffer(sha1, type, size, buffer, &eaten);
+ obj = parse_object_buffer(repl, type, size, buffer, &eaten);
if (!eaten)
free(buffer);
return obj;
--
1.6.1.83.g16e5
^ permalink raw reply related
* [RFC/PATCH 6/7] replace_object: add a test case
From: Christian Couder @ 2009-01-12 17:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In this patch the setup code is very big, but this will be used in
test cases that will be added later.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t6050-replace.sh | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 75 insertions(+), 0 deletions(-)
create mode 100755 t/t6050-replace.sh
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
new file mode 100755
index 0000000..0a585ec
--- /dev/null
+++ b/t/t6050-replace.sh
@@ -0,0 +1,75 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Christian Couder
+#
+test_description='Tests replace refs functionality'
+
+exec </dev/null
+
+. ./test-lib.sh
+
+add_and_commit_file()
+{
+ _file="$1"
+ _msg="$2"
+
+ git add $_file || return $?
+ test_tick || return $?
+ git commit --quiet -m "$_file: $_msg"
+}
+
+HASH1=
+HASH2=
+HASH3=
+HASH4=
+HASH5=
+HASH6=
+HASH7=
+
+test_expect_success 'set up buggy branch' '
+ echo "line 1" >> hello &&
+ echo "line 2" >> hello &&
+ echo "line 3" >> hello &&
+ echo "line 4" >> hello &&
+ add_and_commit_file hello "4 lines" &&
+ HASH1=$(git rev-parse --verify HEAD) &&
+ echo "line BUG" >> hello &&
+ echo "line 6" >> hello &&
+ echo "line 7" >> hello &&
+ echo "line 8" >> hello &&
+ add_and_commit_file hello "4 more lines with a BUG" &&
+ HASH2=$(git rev-parse --verify HEAD) &&
+ echo "line 9" >> hello &&
+ echo "line 10" >> hello &&
+ add_and_commit_file hello "2 more lines" &&
+ HASH3=$(git rev-parse --verify HEAD) &&
+ echo "line 11" >> hello &&
+ add_and_commit_file hello "1 more line" &&
+ HASH4=$(git rev-parse --verify HEAD) &&
+ sed -e "s/BUG/5/" hello > hello.new &&
+ mv hello.new hello &&
+ add_and_commit_file hello "BUG fixed" &&
+ HASH5=$(git rev-parse --verify HEAD) &&
+ echo "line 12" >> hello &&
+ echo "line 13" >> hello &&
+ add_and_commit_file hello "2 more lines" &&
+ HASH6=$(git rev-parse --verify HEAD)
+ echo "line 14" >> hello &&
+ echo "line 15" >> hello &&
+ echo "line 16" >> hello &&
+ add_and_commit_file hello "again 3 more lines" &&
+ HASH7=$(git rev-parse --verify HEAD)
+'
+
+test_expect_success 'replace the author' '
+ git cat-file commit $HASH2 | grep "author A U Thor" &&
+ R=$(git cat-file commit $HASH2 | sed -e "s/A U/O/" | git hash-object -t commit --stdin -w) &&
+ git cat-file commit $R | grep "author O Thor" &&
+ git update-ref refs/replace/$HASH2 $R &&
+ git show HEAD~5 | grep "O Thor" &&
+ git show $HASH2 | grep "O Thor"
+'
+
+#
+#
+test_done
--
1.6.1.83.g16e5
^ permalink raw reply related
* [RFC/PATCH 7/7] mktag: call "check_sha1_signature" with the replacement sha1
From: Christian Couder @ 2009-01-12 17:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Otherwise we get a "sha1 mismatch" error for replaced objects.
While at it, this patch makes the first argument of "verify_object"
const.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
mktag.c | 7 ++++---
t/t6050-replace.sh | 11 +++++++++++
2 files changed, 15 insertions(+), 3 deletions(-)
Note that I am not sure at all that this is a good change.
It may be that we should just refuse to tag a replaced object. But
in this case we should probably give a meaningfull error message
instead of "sha1 mismatch".
Otherwise I checked the 2 other calls to "check_sha1_signature" and
they look like they don't need any change.
diff --git a/mktag.c b/mktag.c
index ba3d495..ac812e5 100644
--- a/mktag.c
+++ b/mktag.c
@@ -18,16 +18,17 @@
/*
* We refuse to tag something we can't verify. Just because.
*/
-static int verify_object(unsigned char *sha1, const char *expected_type)
+static int verify_object(const unsigned char *sha1, const char *expected_type)
{
int ret = -1;
enum object_type type;
unsigned long size;
- void *buffer = read_sha1_file(sha1, &type, &size);
+ const unsigned char *repl;
+ void *buffer = read_sha1_file_repl(sha1, &type, &size, &repl);
if (buffer) {
if (type == type_from_string(expected_type))
- ret = check_sha1_signature(sha1, buffer, size, expected_type);
+ ret = check_sha1_signature(repl, buffer, size, expected_type);
free(buffer);
}
return ret;
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 0a585ec..697e0f6 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -70,6 +70,17 @@ test_expect_success 'replace the author' '
git show $HASH2 | grep "O Thor"
'
+cat >tag.sig <<EOF
+object $HASH2
+type commit
+tag mytag
+tagger T A Gger <> 0 +0000
+
+EOF
+
+test_expect_success 'tag replaced commit' \
+ 'git mktag <tag.sig >.git/refs/tags/mytag 2>message'
+
#
#
test_done
--
1.6.1.83.g16e5
^ permalink raw reply related
* Pragmatic Git Book
From: Tim Visher @ 2009-01-12 18:00 UTC (permalink / raw)
To: git
Hello Everyone,
Any of you had a chance to look through the Pragmatic book about our
beloved SCM tool? Is it any good?
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [RFC PATCH 3/3] Support fetching from foreign VCSes
From: Daniel Barkalow @ 2009-01-12 18:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20090112154224.GD10179@spearce.org>
On Mon, 12 Jan 2009, Shawn O. Pearce wrote:
> Daniel Barkalow <barkalow@iabervon.org> wrote:
> > On Sun, 11 Jan 2009, Junio C Hamano wrote:
> > > Daniel Barkalow <barkalow@iabervon.org> writes:
> > > > This supports a useful subset of the usual fetch logic, mostly in the
> > > > config file.
> > >
> > > I like the direction this series is going. In the longer term, it would
> > > be nice if we can have git-svn and git-cvsimport replaced with something
> > > like this.
>
> The series seems to require that the foreign tool speak fast-import. I've
> tried to get git-svn to use it, but its currently not possible because the
> git-svn process needs to be able to read objects it has written during this
> session. Those objects are stored in the output pack, where only the active
> fast-import process can get to them. Thus git-svn can't use fast-import.
>
> As import as the git-p4 stuff is, git-svn is our "killer feature" when it
> comes to foreign system integration. I think we need to make SVN work for
> this foreign vcs thing to work.
I think fast-import should be made sufficient for git-svn, rather than
having the integration about to speak other things. As you say, git-svn is
the killer feature, and I'd like to have it using (and therefore
contributing to the testing of) all of the applicable tools.
Maybe fast-import should be able to run with a bi-directional connection
to its input, so it can acknowledge checkpoints? When the pipeline is set
up in the main git code, it should be easy enough to do this sort of
complicated stuff.
> > > Is the current foreign vcs interface sufficiently rich to support git as a
> > > foreign scm by using fast-import and fast-export?
> >
> > I think so, although it would be pretty strange, since it would generally
> > have a whole lot of local data (a complete clone of any remote
> > repository).
>
> It might not be that bad. If the foreign system is git and the
> local system is git, we should have a massive amount of object reuse.
> At least all of the blobs from the foreign system should be reused
> by the local system, and that's like 80-90% of most project's
> object state.
The part I think is weird is that the helper would be first going to the
network to get all of the data, and then extracting the history from it
locally in a separate process (that is, passing data to it only through
the filesystem). Other systems generally get the data on demand, which
sort of makes more sense for the case where you will then run exactly one
command (fast-export) to it. I suppose sticking the data into the
destination object store would make this not so strange.
> If the import is flawless (no mangling of commit messages or history)
> then you should get 100% object reuse and the git-git import would
> give you the same SHA-1, but just slower than going over git://.
>
> Its strange only because it would be sucking more CPU time on the
> client than is necessary to do the fetch. But if something like
> a filter-branch tool existed to massage a fast-import stream, it
> might be useful to fetch someone else's tree, massage it a bit,
> and then import it with a subtree merge. :-)
That is true, and would be a good actual use for this. It would make it
possible for Wine to have a remote for the upstream Kconfig repository
(that being a filtering of the linux-2.6 repository).
That is, a git repository can be "foreign" in that it disagrees with you
over the project layout or contents.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC PATCH 4/3] Add example git-vcs-p4
From: Daniel Barkalow @ 2009-01-12 18:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0901120346x79772846p6e5097028fc9720c@mail.gmail.com>
On Mon, 12 Jan 2009, Alex Riesen wrote:
> 2009/1/11 Daniel Barkalow <barkalow@iabervon.org>:
> > diff --git a/Makefile b/Makefile
> >
> > +LIB_OBJS += p4client.o
> > +LIB_OBJS += vcs-p4.o
> > +
> >
> > +extern int cmd_p4(int argc, const char **argv, const char *prefix);
> > +
>
> Why is your foreign VCS importer built-in? The majority wont ever need it,
> yet they have to pay the price for its text being in git executable.
Purely for convenience in the RFC version. The real one will probably need
to be linked separately, since it will want to have the option of using
the terrible C++ API to the
closed-source-but-you-can-download-it-from-them library.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC PATCH 3/3] Support fetching from foreign VCSes
From: Johannes Schindelin @ 2009-01-12 19:09 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0901121246320.19665@iabervon.org>
Hi,
On Mon, 12 Jan 2009, Daniel Barkalow wrote:
> Maybe fast-import should be able to run with a bi-directional connection
> to its input, so it can acknowledge checkpoints?
Whoa.
fast-import was first and foremost a very simple way to get stuff done.
Is it absolutely necessary to complicate that?
I mean, I don't know about git-svn, but shouldn't it be
relatively easy to use fast-import to import from Subversion once the
information is extracted from Subversion?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] grep: don't call regexec() for fixed strings
From: René Scharfe @ 2009-01-12 19:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <81b0412b0901120732t1bd1978awdc4be47767e02863@mail.gmail.com>
Alex Riesen schrieb:
> 2009/1/10 René Scharfe <rene.scharfe@lsrfire.ath.cx>:
>> +static int isregexspecial(int c)
>> +{
>> + return isspecial(c) || c == '$' || c == '(' || c == ')' || c == '+' ||
>> + c == '.' || c == '^' || c == '{' || c == '|';
>> +}
>> +
>> +static int is_fixed(const char *s)
>> +{
>> + while (!isregexspecial(*s))
>> + s++;
>> + return !*s;
>> +}
>
> strchr?
Oh, yes, that would look nicer.
Another option is to extend ctype.c and implement isregexspecial() --
and while we're at it islowerxdigit() (builtin-name-rev.c::ishex()) and
iswordchar() (config.c::iskeychar(), grep.c::word_char()), too -- as
table lookups. I.e., something like the following (untested).
Which of the mentioned functions are really worth of this promotion?
The isregexspecial() char class has more members than isspecial(), but
it's not performance critical (unless you have a lot of patterns and
only a small amount of data to grep :).
Are there more candidates for ctype-ification?
René
ctype.c | 14 ++++++++++----
git-compat-util.h | 6 ++++++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/ctype.c b/ctype.c
index 9208d67..1a76586 100644
--- a/ctype.c
+++ b/ctype.c
@@ -10,20 +10,26 @@
#undef AA
#undef DD
#undef GS
+#undef RR
+#undef US
+#undef Ah
#define SS GIT_SPACE
#define AA GIT_ALPHA
#define DD GIT_DIGIT
#define GS GIT_SPECIAL /* \0, *, ?, [, \\ */
+#define RR GIT_REGEX_SPECIAL /* $, (, ), +, ., ^, {, | */
+#define US GIT_UNDERSCORE
+#define Ah (GIT_ALPHA | GIT_LOWER_XDIGIT)
unsigned char sane_ctype[256] = {
GS, 0, 0, 0, 0, 0, 0, 0, 0, SS, SS, 0, 0, SS, 0, 0, /* 0-15 */
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 16-15 */
- SS, 0, 0, 0, 0, 0, 0, 0, 0, 0, GS, 0, 0, 0, 0, 0, /* 32-15 */
+ SS, 0, 0, 0, RR, 0, 0, 0, RR, RR, GS, RR, 0, 0, RR, 0, /* 32-15 */
DD, DD, DD, DD, DD, DD, DD, DD, DD, DD, 0, 0, 0, 0, 0, GS, /* 48-15 */
0, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, /* 64-15 */
- AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, GS, GS, 0, 0, 0, /* 80-15 */
- 0, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, /* 96-15 */
- AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, 0, 0, 0, 0, 0, /* 112-15 */
+ AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, GS, GS, 0, RR, US, /* 80-15 */
+ 0, Ah, Ah, Ah, Ah, Ah, Ah, AA, AA, AA, AA, AA, AA, AA, AA, AA, /* 96-15 */
+ AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, RR, RR, 0, 0, 0, /* 112-15 */
/* Nothing in the 128.. range */
};
diff --git a/git-compat-util.h b/git-compat-util.h
index e20b1e8..5eaa662 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -328,12 +328,18 @@ extern unsigned char sane_ctype[256];
#define GIT_DIGIT 0x02
#define GIT_ALPHA 0x04
#define GIT_SPECIAL 0x08
+#define GIT_REGEX_SPECIAL 0x10
+#define GIT_UNDERSCORE 0x20
+#define GIT_LOWER_XDIGIT 0x40
#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
#define isspace(x) sane_istest(x,GIT_SPACE)
#define isdigit(x) sane_istest(x,GIT_DIGIT)
#define isalpha(x) sane_istest(x,GIT_ALPHA)
#define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
#define isspecial(x) sane_istest(x,GIT_SPECIAL)
+#define isregexspecial(x) sane_istest(x,GIT_SPECIAL | GIT_REGEX_SPECIAL)
+#define iswordchar(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT | GIT_UNDERSCORE)
+#define islowerxdigit(x) sane_istest(x,GIT_DIGIT | GIT_LOWER_XDIGIT)
#define tolower(x) sane_case((unsigned char)(x), 0x20)
#define toupper(x) sane_case((unsigned char)(x), 0)
^ permalink raw reply related
* checking out by date
From: David Bryson @ 2009-01-12 19:30 UTC (permalink / raw)
To: git
Hi All,
I have a very large repository that imported into git from CVS with
about 5 years worth of history.
Today I decided to checkout some code from the past:
$ git checkout master@{"Mon Dec 31 2007"}
warning: Log for 'master' only goes back to Tue, 2 Dec 2008 16:57:15
-0800.
Then proceeds to checkout a code snapshot from 2 Dec. To work around
this I checked out a specific commit id, by looking at the log:
commit 3771ec1d6ccf329da378b7633fdef60474eac4b7
Author: XXXXXXXXXXXXXXX
Date: Mon Dec 31 23:25:17 2007 +0000
BugId: none
correct wrong commit
$ git checkout 3771ec1d6ccf329da378b7633fdef60474eac4b7
...
HEAD is now at 3771ec1... BugId: none correct wrong commit
So what has caused git to be unable to process the date information,
even though the information is clearly in the history ? Did I miss
something ?
Dave
^ permalink raw reply
* Re: [RFC PATCH 3/3] Support fetching from foreign VCSes
From: Daniel Barkalow @ 2009-01-12 19:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901122007070.3586@pacific.mpi-cbg.de>
On Mon, 12 Jan 2009, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 12 Jan 2009, Daniel Barkalow wrote:
>
> > Maybe fast-import should be able to run with a bi-directional connection
> > to its input, so it can acknowledge checkpoints?
>
> Whoa.
>
> fast-import was first and foremost a very simple way to get stuff done.
> Is it absolutely necessary to complicate that?
>
> I mean, I don't know about git-svn, but shouldn't it be
> relatively easy to use fast-import to import from Subversion once the
> information is extracted from Subversion?
I assume that git-svn's problem is that it would need to store too much of
the information (rather than being able to discard it) if it couldn't get
the information back from the git object database.
Actually, I think it might be actually simplify programs using fast-import
if they could ask it for data from before, and I think that would have to
be necessary in order to have a reasonable non-git-specific incremental
importer without duplicating the storage of a lot of information that
previously went into fast-import.
I know I found it helpful in my p4 one to be able to pick up the
incremental state by looking at what refs exist and the information in
commits they point to, rather than trying to get the information from the
perforce client state or custom storage.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Lightweight tag ?
From: Junio C Hamano @ 2009-01-12 19:52 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Francis Moreau, git
In-Reply-To: <496B59A3.2080507@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
>> That's not what Junio said:
>>
>> Don't use explicit --tags blindly. It says "no matter what kind of tag,
>> transfer everything under refs/tags". Otherwise you won't see a
>> difference.
>>
>> So I interpret this like don't use --tags otherwise lightweight and annoted tags
>> are the same.
>
> I don't see a difference between lightweight tags and tag objects
> regarding the question of automatic tag following, see my parenthetical
> request for correction (below) in case I'm wrong.
It was me who was confused on two points.
(1) push does not do autofollow and you always have to be explicit
(including saying "--tags" which is to push all refs/tags/*); I
somehow thought the question was about fetch;
(2) if you explicitly ask to fetch tags, there won't be any difference
(which was my "don't say --tags explicitly because you won't see a
difference if you did so").
On the other hand, the autofollowing during the fetch originally
followed only annotated tags (it was partly by design, so that people
can use lightweight tags for local stuff without worrying about
contaminating others' tag namespace with many of them) and I somehow
thought this was still the case.
But it is not the case anymore since 6c96c0f (git-fetch: follow
lightweight tags as well, 2006-11-18).
So, sorry for the noise.
^ permalink raw reply
* Re: checking out by date
From: Boyd Stephen Smith Jr. @ 2009-01-12 19:58 UTC (permalink / raw)
To: David Bryson; +Cc: git
In-Reply-To: <20090112193039.GO25823@eratosthenes.cryptobackpack.org>
[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]
On Monday 2009 January 12 13:30:39 David Bryson wrote:
>I have a very large repository that imported into git from CVS with
>about 5 years worth of history.
>
>Today I decided to checkout some code from the past:
>
>$ git checkout master@{"Mon Dec 31 2007"}
>warning: Log for 'master' only goes back to Tue, 2 Dec 2008 16:57:15
>-0800.
>
>Then proceeds to checkout a code snapshot from 2 Dec. To work around
>this I checked out a specific commit id, by looking at the log:
>
>commit 3771ec1d6ccf329da378b7633fdef60474eac4b7
>Author: XXXXXXXXXXXXXXX
>Date: Mon Dec 31 23:25:17 2007 +0000
>
>$ git checkout 3771ec1d6ccf329da378b7633fdef60474eac4b7
>...
>HEAD is now at 3771ec1... BugId: none correct wrong commit
>
>So what has caused git to be unable to process the date information,
>even though the information is clearly in the history ? Did I miss
>something ?
The ref@{date} format uses the reflogs which are expired regularly, IIRC.
Also, I don't think reflogs are built by cvsimport, so they would only go
back to the import date.
While there is date information in the output of 'git log', some of those
commits may never have been pointed to by the named ref, so they wouldn't
satisfy the semantics of "$ref as it was on $date". With a linear history,
this "only" puts you in the middle of a fast-forward, which isn't *that* bad.
However, with a non-linear history, taking the ancestor with the latest commit
date before the given date might end up checking out a topic branch that
hadn't yet been merged on that date, which could be incredibly confusing.
It should be possible to introduce a commit "spelling" to enable
checkout-by-date, but I don't know of one currently. Something
like "commitish~{date}" meaning "commitish~n where n is the largest value
s.t. commit_date(commitish~n) <= date", intentionally taking the first parent
on any merge to discard the merge event.
If this is a feature we feel is valuable, I don't think it would be that hard
to code.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Update bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-12 19:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
In bash, "set -u" gives an error when a variable is unbound. In this
case, the bash completion script included in the git/contrib directory
produces several errors.
The attached patch replaces things like
if [ -z "$1" ]
with
if [ -z "${1-}" ]
so that the unbound variable returns an empty value. Hence, the
completion script will now work even "set -u" set.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
contrib/completion/git-completion.bash | 68
++++++++++++++++----------------
1 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 7b074d7..50e345f 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -52,25 +52,25 @@ esac
__gitdir ()
{
- if [ -z "$1" ]; then
- if [ -n "$__git_dir" ]; then
+ if [ -z "${1-}" ]; then
+ if [ -n "${__git_dir-}" ]; then
echo "$__git_dir"
elif [ -d .git ]; then
echo .git
else
git rev-parse --git-dir 2>/dev/null
fi
- elif [ -d "$1/.git" ]; then
- echo "$1/.git"
+ elif [ -d "${1-}/.git" ]; then
+ echo "${1-}/.git"
else
- echo "$1"
+ echo "${1-}"
fi
}
__git_ps1 ()
{
local g="$(git rev-parse --git-dir 2>/dev/null)"
- if [ -n "$g" ]; then
+ if [ -n "${g-}" ]; then
local r
local b
if [ -d "$g/rebase-apply" ]
@@ -111,8 +111,8 @@ __git_ps1 ()
fi
fi
- if [ -n "$1" ]; then
- printf "$1" "${b##refs/heads/}$r"
+ if [ -n "${1-}" ]; then
+ printf "${1-}" "${b##refs/heads/}$r"
else
printf " (%s)" "${b##refs/heads/}$r"
fi
@@ -122,11 +122,11 @@ __git_ps1 ()
__gitcomp_1 ()
{
local c IFS=' '$'\t'$'\n'
- for c in $1; do
- case "$c$2" in
- --*=*) printf %s$'\n' "$c$2" ;;
- *.) printf %s$'\n' "$c$2" ;;
- *) printf %s$'\n' "$c$2 " ;;
+ for c in ${1-}; do
+ case "$c${2-}" in
+ --*=*) printf %s$'\n' "$c${2-}" ;;
+ *.) printf %s$'\n' "$c${2-}" ;;
+ *) printf %s$'\n' "$c${2-} " ;;
esac
done
}
@@ -135,7 +135,7 @@ __gitcomp ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
if [ $# -gt 2 ]; then
- cur="$3"
+ cur="${3-}"
fi
case "$cur" in
--*=)
@@ -143,8 +143,8 @@ __gitcomp ()
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P "$2" \
- -W "$(__gitcomp_1 "$1" "$4")" \
+ COMPREPLY=($(compgen -P "${2-}" \
+ -W "$(__gitcomp_1 "${1-}" "${4-}")" \
-- "$cur"))
;;
esac
@@ -152,13 +152,13 @@ __gitcomp ()
__git_heads ()
{
- local cmd i is_hash=y dir="$(__gitdir "$1")"
+ local cmd i is_hash=y dir="$(__gitdir "${1-}")"
if [ -d "$dir" ]; then
git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
refs/heads
return
fi
- for i in $(git ls-remote "$1" 2>/dev/null); do
+ for i in $(git ls-remote "${1-}" 2>/dev/null); do
case "$is_hash,$i" in
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -170,13 +170,13 @@ __git_heads ()
__git_tags ()
{
- local cmd i is_hash=y dir="$(__gitdir "$1")"
+ local cmd i is_hash=y dir="$(__gitdir "${1-}")"
if [ -d "$dir" ]; then
git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
refs/tags
return
fi
- for i in $(git ls-remote "$1" 2>/dev/null); do
+ for i in $(git ls-remote "${1-}" 2>/dev/null); do
case "$is_hash,$i" in
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -188,7 +188,7 @@ __git_tags ()
__git_refs ()
{
- local i is_hash=y dir="$(__gitdir "$1")"
+ local i is_hash=y dir="$(__gitdir "${1-}")"
local cur="${COMP_WORDS[COMP_CWORD]}" format refs
if [ -d "$dir" ]; then
case "$cur" in
@@ -221,7 +221,7 @@ __git_refs ()
__git_refs2 ()
{
local i
- for i in $(__git_refs "$1"); do
+ for i in $(__git_refs "${1-}"); do
echo "$i:$i"
done
}
@@ -229,11 +229,11 @@ __git_refs2 ()
__git_refs_remotes ()
{
local cmd i is_hash=y
- for i in $(git ls-remote "$1" 2>/dev/null); do
+ for i in $(git ls-remote "${1-}" 2>/dev/null); do
case "$is_hash,$i" in
n,refs/heads/*)
is_hash=y
- echo "$i:refs/remotes/$1/${i#refs/heads/}"
+ echo "$i:refs/remotes/${1-}/${i#refs/heads/}"
;;
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -264,7 +264,7 @@ __git_remotes ()
__git_merge_strategies ()
{
- if [ -n "$__git_merge_strategylist" ]; then
+ if [ -n "${__git_merge_strategylist-}" ]; then
echo "$__git_merge_strategylist"
return
fi
@@ -350,7 +350,7 @@ __git_complete_revlist ()
__git_all_commands ()
{
- if [ -n "$__git_all_commandlist" ]; then
+ if [ -n "${__git_all_commandlist-}" ]; then
echo "$__git_all_commandlist"
return
fi
@@ -368,7 +368,7 @@ __git_all_commandlist="$(__git_all_commands
2>/dev/null)"
__git_porcelain_commands ()
{
- if [ -n "$__git_porcelain_commandlist" ]; then
+ if [ -n "${__git_porcelain_commandlist-}" ]; then
echo "$__git_porcelain_commandlist"
return
fi
@@ -473,7 +473,7 @@ __git_aliases ()
__git_aliased_command ()
{
local word cmdline=$(git --git-dir="$(__gitdir)" \
- config --get "alias.$1")
+ config --get "alias.${1-}")
for word in $cmdline; do
if [ "${word##-*}" ]; then
echo $word
@@ -488,7 +488,7 @@ __git_find_subcommand ()
while [ $c -lt $COMP_CWORD ]; do
word="${COMP_WORDS[c]}"
- for subcommand in $1; do
+ for subcommand in ${1-}; do
if [ "$subcommand" = "$word" ]; then
echo "$subcommand"
return
@@ -599,7 +599,7 @@ _git_bisect ()
local subcommands="start bad good skip reset visualize replay log run"
local subcommand="$(__git_find_subcommand "$subcommands")"
- if [ -z "$subcommand" ]; then
+ if [ -z "${subcommand-}" ]; then
__gitcomp "$subcommands"
return
fi
@@ -1371,7 +1371,7 @@ _git_remote ()
{
local subcommands="add rm show prune update"
local subcommand="$(__git_find_subcommand "$subcommands")"
- if [ -z "$subcommand" ]; then
+ if [ -z "${subcommand-}" ]; then
__gitcomp "$subcommands"
return
fi
@@ -1500,7 +1500,7 @@ _git_stash ()
{
local subcommands='save list show apply clear drop pop create branch'
local subcommand="$(__git_find_subcommand "$subcommands")"
- if [ -z "$subcommand" ]; then
+ if [ -z "${subcommand-}" ]; then
__gitcomp "$subcommands"
else
local cur="${COMP_WORDS[COMP_CWORD]}"
@@ -1552,7 +1552,7 @@ _git_svn ()
proplist show-ignore show-externals
"
local subcommand="$(__git_find_subcommand "$subcommands")"
- if [ -z "$subcommand" ]; then
+ if [ -z "${subcommand-}" ]; then
__gitcomp "$subcommands"
else
local remote_opts="--username= --config-dir= --no-auth-cache"
@@ -1672,7 +1672,7 @@ _git ()
c=$((++c))
done
- if [ -z "$command" ]; then
+ if [ -z "${command-}" ]; then
case "${COMP_WORDS[COMP_CWORD]}" in
--*=*) COMPREPLY=() ;;
--*) __gitcomp "
--
1.6.1.87.g15624
^ permalink raw reply related
* [PATCH] Fix Dcoumentation typos surrounding the word 'handful'.
From: Jon Loeliger @ 2009-01-12 20:02 UTC (permalink / raw)
To: git; +Cc: Jon Loeliger
Some instances replaced by "handful of", others use
the word "few", a couple get a slight rewording.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Junio,
I wasn't sure that fixing the release notes was important.
I can hit those too if you would like.
jdl
Documentation/diff-options.txt | 2 +-
Documentation/git-describe.txt | 2 +-
Documentation/git-ls-files.txt | 2 +-
Documentation/git-ls-tree.txt | 2 +-
Documentation/gitcore-tutorial.txt | 8 ++++----
Documentation/githooks.txt | 2 +-
.../howto/rebase-from-internal-branch.txt | 2 +-
Documentation/pretty-options.txt | 2 +-
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 671f533..43793d7 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -116,7 +116,7 @@ endif::git-format-patch[]
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
name in diff-raw format output and diff-tree header
- lines, show only handful hexdigits prefix. This is
+ lines, show only a partial prefix. This is
independent of --full-index option above, which controls
the diff-patch output format. Non default number of
digits can be specified with --abbrev=<n>.
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 3d79f05..a99b4ef 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -87,7 +87,7 @@ With something like git.git current tree, I get:
v1.0.4-14-g2414721
i.e. the current head of my "parent" branch is based on v1.0.4,
-but since it has a handful commits on top of that,
+but since it has a few commits on top of that,
describe has added the number of additional commits ("14") and
an abbreviated object name for the commit itself ("2414721")
at the end.
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 9f85d60..057a021 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -126,7 +126,7 @@ OPTIONS
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
- lines, show only handful hexdigits prefix.
+ lines, show only a partial prefix.
Non default number of digits can be specified with --abbrev=<n>.
\--::
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index 4c7262f..b345f4d 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -59,7 +59,7 @@ OPTIONS
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
- lines, show only handful hexdigits prefix.
+ lines, show only a partal prefix.
Non default number of digits can be specified with --abbrev=<n>.
--full-name::
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index e4dd551..7ba5e58 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1243,10 +1243,10 @@ $ git ls-files --stage
------------
In our example of only two files, we did not have unchanged
-files so only 'example' resulted in collapsing, but in real-life
-large projects, only small number of files change in one commit,
-and this 'collapsing' tends to trivially merge most of the paths
-fairly quickly, leaving only a handful the real changes in non-zero
+files so only 'example' resulted in collapsing. But in real-life
+large projects, when only a small number of files change in one commit,
+this 'collapsing' tends to trivially merge most of the paths
+fairly quickly, leaving only a handful of real changes in non-zero
stages.
To look at only non-zero stages, use `\--unmerged` flag:
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index cfdae1e..e4d61d5 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -15,7 +15,7 @@ DESCRIPTION
Hooks are little scripts you can place in `$GIT_DIR/hooks`
directory to trigger action at certain points. When
-'git-init' is run, a handful example hooks are copied in the
+'git-init' is run, a handful of example hooks are copied into the
`hooks` directory of the new repository, but by default they are
all disabled. To enable a hook, rename it by removing its `.sample`
suffix.
diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt
index d214d4b..74a1c0c 100644
--- a/Documentation/howto/rebase-from-internal-branch.txt
+++ b/Documentation/howto/rebase-from-internal-branch.txt
@@ -27,7 +27,7 @@ the kind of task StGIT is designed to do.
I just have done a simpler one, this time using only the core
GIT tools.
-I had a handful commits that were ahead of master in pu, and I
+I had a handful of commits that were ahead of master in pu, and I
wanted to add some documentation bypassing my usual habit of
placing new things in pu first. At the beginning, the commit
ancestry graph looked like this:
diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
index 6d66c74..5f21efe 100644
--- a/Documentation/pretty-options.txt
+++ b/Documentation/pretty-options.txt
@@ -10,7 +10,7 @@ configuration (see linkgit:git-config[1]).
--abbrev-commit::
Instead of showing the full 40-byte hexadecimal commit object
- name, show only handful hexdigits prefix. Non default number of
+ name, show only a partial prefix. Non default number of
digits can be specified with "--abbrev=<n>" (which also modifies
diff output, if it is displayed).
+
--
1.6.0.4.761.g47577
^ permalink raw reply related
* Re: [PATCH] stgit namelength is an integer
From: Karl Hasselström @ 2009-01-12 20:13 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20090105190354.GA8295@osc.edu>
Thanks, but the test suite fails unless I apply this first:
Return None instead of crashing on undefined integer config items
Signed-off-by: Karl Hasselström <kha@treskal.com>
diff --git a/stgit/config.py b/stgit/config.py
index 8934445..5b47580 100644
--- a/stgit/config.py
+++ b/stgit/config.py
@@ -65,7 +65,9 @@ class GitConfig:
def getint(self, name):
value = self.get(name)
- if value.isdigit():
+ if value == None:
+ return None
+ elif value.isdigit():
return int(value)
else:
raise GitConfigException, 'Value for "%s" is not an integer: "%s"' % (name, value)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply related
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Boyd Stephen Smith Jr. @ 2009-01-12 20:35 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git
In-Reply-To: <496BA0E4.2040607@tedpavlic.com>
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
On Monday 2009 January 12 13:58:28 you wrote:
>In bash, "set -u" gives an error when a variable is unbound. In this
>case, the bash completion script included in the git/contrib directory
>produces several errors.
>
>The attached patch replaces things like
>
> if [ -z "$1" ]
>
>with
>
> if [ -z "${1-}" ]
That looks ugly to me. Any reason we shouldn't just "set +u" at the top of
the script?
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Adeodato Simó @ 2009-01-12 20:40 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Ted Pavlic, git
In-Reply-To: <200901121435.35547.bss@iguanasuicide.net>
* Boyd Stephen Smith Jr. [Mon, 12 Jan 2009 14:35:35 -0600]:
> >The attached patch replaces things like
> > if [ -z "$1" ]
> >with
> > if [ -z "${1-}" ]
> That looks ugly to me. Any reason we shouldn't just "set +u" at the top of
> the script?
`set +u` affects the shell globally, not just to the sourced file. If
you do that, you must be aware that you'll be preventing people from
running their shell in `set -u` mode. (Merely stating a fact here, not
giving any opinion.)
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
The problem I have with making an intelligent statement is that some
people then think that it's not an isolated occurrance.
-- Simon Travaglia
^ permalink raw reply
* Re: Lightweight tag ?
From: Francis Moreau @ 2009-01-12 20:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <496B59A3.2080507@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
>> Perhaps it needs documents which are more user friendly: I don't know where
>> the 'lightweight' word is coming from (perhaps from the implementation) but
>> I would expect that the _local_ term appears in the git-tag manual.
>
> It's the other way round. "lightweight" is in the first few lines of the
> man, "local" nowhere. In fact I don't see it anywhere in the docs.
Sorry my previous reply wasn't clear, I meant that the word
'lightweight' appears in the man page of git-tag but I don't see why
such term is used, well now I can see but it's implementation detail
so useless (or worth: confusing) for a dumb user (me).
In contrary I would have expected to find the 'local' word if git
support local tags.
>> I just need to create a local tag where I'm sure it won't be seen by others
>> whatever the git operations I'm doing, normally a simple "git tag" switch
>> should be enough...
>
> Taking "whatever" literally this is impossible, of course.
>
>
> Taking it /cum grano salis/ it's still impossible within the same repo:
> If others have read access they can "ls-remote" and "fetch" happily what
> they want. The sane and easy way is to use a private repo for your local
> work and all your "local tags", then to push to a public (i.e.
> publically readable) repo those branches and tags which you want to be seen.
>
This is how things are currently implemented but if lightweight is
really useless and local tags are somehow missing in Git then I'm
pretty sure it's possible to create such tags that are not seen by
git-{pull,push,fetch] operations.
>
> Are you a Mercurial user by any chance?
Nope.
> "hg tag -l" creates local tags which are stored in an unversioned,
> private file, whereas "hg tag" creates (and commits) a tag entry in
> a versioned file, which is the source of some confusion and problems
> with hg tags ("hg co sometag" does not contain sometag etc.). Maybe
> you want the behaviour of "hg tag -l"?
Yes, It sounds that 'hg tag -l' is what I'm looking for in git...
Thanks
--
Francis
^ permalink raw reply
* [PATCH v2] git-web--browse: don't add start as candidate on Ubuntu
From: Ramsay Jones @ 2009-01-12 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, Petr Baudis, GIT Mailing-list
In-Reply-To: <7vljtr33sb.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
>> Le jeudi 1 janvier 2009, Ramsay Jones a écrit :
>> ...
>>> Does anybody else see this issue and can someone test the patch?
>> Petr, as you added support for using /bin/start on MinGW, could you test?
>>
>> diff --git a/git-web--browse.sh b/git-web--browse.sh
>> index 78d236b..7ed0fad 100755
>> --- a/git-web--browse.sh
>> +++ b/git-web--browse.sh
>> @@ -115,7 +115,7 @@ if test -z "$browser" ; then
>> browser_candidates="open $browser_candidates"
>> fi
>> # /bin/start indicates MinGW
>> - if test -n /bin/start; then
>> + if test -x /bin/start; then
>> browser_candidates="start $browser_candidates"
>> fi
>
> In any case, the original test is simply bogus. 'test -n "$foo"' is to
> see if $foo is an empty string, and giving a constant /bin/start always
> yields true.
>
> As an old timer, I tend to prefer "test -f" in this context, as anybody
> sane can expect that the directory /bin will contain executables and
> nothing else. Another reason is purely stylistic. Historically "-f" has
> been much more portable than "-x" (which came from SVID), even though it
> wouldn't make much difference in practice in the real world these days.
Sorry for the late reply; if this has already been resolved, then sorry for
the noise.
I was expecting to be castigated for having /sbin in my $PATH. Indeed, I was
a bit surprised... So, I checked my initialization files and then the system
initialization files and could not find where it was being set...
$ strings /bin/bash | grep sbin
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ strings /bin/sh | grep sbin
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
So I don't think it's anything I'm doing...
Anyway, I've changed the patch as you suggested. It would still be good
if someone on MinGW could test it.
ATB,
Ramsay Jones
git-web--browse.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-web--browse.sh b/git-web--browse.sh
index 78d236b..c5e62a6 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -115,7 +115,7 @@ if test -z "$browser" ; then
browser_candidates="open $browser_candidates"
fi
# /bin/start indicates MinGW
- if test -n /bin/start; then
+ if test -f /bin/start; then
browser_candidates="start $browser_candidates"
fi
--
1.6.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox