* 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: [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: 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
* 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
* [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
* [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 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 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
* 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
* 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
* [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: [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 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
* [RFC/PATCH 1/7] sha1_file: make "read_object" static
From: Christian Couder @ 2009-01-12 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This function is only used from "sha1_file.c".
And as we want to add a "replace_object" hook in "read_sha1_file",
we must not let people bypass the hook using something other than
"read_sha1_file".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
cache.h | 3 ---
sha1_file.c | 7 +++++--
2 files changed, 5 insertions(+), 5 deletions(-)
Here is a new patch series. This time the hook is in "read_sha1_file".
There are still many things to do and to check after this, it's just a start.
But I try to follow the advise we give to GSoC student so I release early
and often :-)
diff --git a/cache.h b/cache.h
index 231c06d..8e1af26 100644
--- a/cache.h
+++ b/cache.h
@@ -631,9 +631,6 @@ extern int write_sha1_file(void *buf, unsigned long len, const char *type, unsig
extern int pretend_sha1_file(void *, unsigned long, enum object_type, unsigned char *);
extern int force_object_loose(const unsigned char *sha1, time_t mtime);
-/* just like read_sha1_file(), but non fatal in presence of bad objects */
-extern void *read_object(const unsigned char *sha1, enum object_type *type, unsigned long *size);
-
/* global flag to enable extra checks when accessing packed objects */
extern int do_check_packed_object_crc;
diff --git a/sha1_file.c b/sha1_file.c
index 52d1ead..f08493f 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1700,6 +1700,9 @@ static void add_delta_base_cache(struct packed_git *p, off_t base_offset,
delta_base_cache_lru.prev = &ent->lru;
}
+static void *read_object(const unsigned char *sha1, enum object_type *type,
+ unsigned long *size);
+
static void *unpack_delta_entry(struct packed_git *p,
struct pack_window **w_curs,
off_t curpos,
@@ -2130,8 +2133,8 @@ int pretend_sha1_file(void *buf, unsigned long len, enum object_type type,
return 0;
}
-void *read_object(const unsigned char *sha1, enum object_type *type,
- unsigned long *size)
+static void *read_object(const unsigned char *sha1, enum object_type *type,
+ unsigned long *size)
{
unsigned long mapsize;
void *map, *buf;
--
1.6.1.83.g16e5
^ permalink raw reply related
* Re: [RFC PATCH 1/3] Add "vcs" config option in remotes
From: Daniel Barkalow @ 2009-01-12 17:25 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git, Junio C Hamano
In-Reply-To: <36ca99e90901120152t7756e6d4n19521cbb7336c5fb@mail.gmail.com>
On Mon, 12 Jan 2009, Bert Wesarg wrote:
> On Sun, Jan 11, 2009 at 21:12, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > diff --git a/builtin-push.c b/builtin-push.c
> > index 122fdcf..3fdedba 100644
> > --- a/builtin-push.c
> > +++ b/builtin-push.c
> > @@ -53,6 +53,9 @@ static int do_push(const char *repo, int flags)
> > int i, errs;
> > struct remote *remote = remote_get(repo);
> >
> > + if (remote->foreign_vcs)
> > + die("Pushing with foreign VCSes not supported.");
> > +
> > if (!remote)
> > die("bad repository '%s'", repo);
> >
> Use of remote before NULL check.
Good catch, thanks.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Johannes Schindelin @ 2009-01-12 17:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andreas Ericsson, git
In-Reply-To: <20090112153322.GA10179@spearce.org>
Hi,
On Mon, 12 Jan 2009, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Mon, 12 Jan 2009, Andreas Ericsson wrote:
> >
> > > Just chiming in that I can probably help mentoring whoever goes with
> > > libgit2. I do not have enough spare time for me to promise that I
> > > can be there as much as I think is necessary and proper, but I'll
> > > gladly help out.
> >
> > I don't know if I like co-mentoring; I always had the impression that
> > this does not work all that well.
>
> I haven't tried it myself, so I can't comment. I thought though that
> Daniel and Christian's mentoring went rather well, but maybe that's just
> me.
That impression came from a few conversations at the mentor summit, BTW.
I cannot really comment on C & D... as Christian pointed out, they are
still a bit secretive, even long after the official end of the project.
However, I have to mention that some projects (SIP communicator for
example) made it a _requirement_ to have pairs of mentors. But then, they
had the "disappearing mentor" syndrome already, so who can blame them for
that.
> 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?
> Heh. I'd wager the most successful GSoC project was Marek's push
> support for JGit. Having ObjectWriter available has opened up the doors
> to support a lot of code in JGit, like the full protocol suite, and
> bundles. Without it I wouldn't have gotten as far as I did in Gerrit.
>
> In terms of value, to me as a contributor, Marek's work gave me a
> foundation we could build on and get stuff done. Miklos' merge is
> great, but I don't think we gained nearly as many features as we did
> with Marek's contribution.
>
> Anyway, I don't want to get into a "my student was better!" contest.
Hehe. I am very proud that we are able to hold such a contest.
> I just think that we had a very successful year this year, with a
> few really great projects being contributed to the community as a
> result of our students' hard work.
>
> > The _communication_ should be open, and much of it on the mailing list, I
> > agree, but _only_ after the student is familiar enough with the aspects of
> > her project (including some familiarity with the source code).
> >
> > I will _not_ force a student to ask questions openly that he finds
> > embarassing.
>
> I agree. The first few weeks are really critical to the student. They
> are still trying to find their way around the code base and don't want
> to look like an idiot. Nobody wants to look like an idiot, especially
> in public, and especially when they have been "hired" to do a particular
> job.
>
> But... part of the reason GSoC exists is to get students involved
> in open source. The rest of us don't come to Git with mentors we
> can ask the "stupid" questions to. We come here and have to ask
> what we need to ask, on the public mailing list, complete with
> archives for the rest of time. As mentors we should be trying to
> encourage our students to work in this, or any other, open source
> community.
I do not think that both of your paragraphs contradict each other. Many
students need a bit of hand-holding until they realize that everybody is
cooking with water. At the end of the day, everybody has some brilliant
and some stupid ideas.
But it takes some getting used to to voice ideas in public, risking some
friendly jokes about your mental state or the quality of your smokables.
I actually see a lot of value in GSoC as a tools to get more students
through that period, especially students from parts of this planet whose
culture is so different from the "Western" culture shaped by
TV, consumism and the lack of physical insecurity, that they are rather
intimidated by the ways of Open Source.
> GSoC is about getting these folks _involved_, so that 40 years from now,
> open source is just as viable as it is today.
It will probably take over even more of our world.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH EGIT Allow for git config to not error when lines have '/r' in them.]
From: Shawn O. Pearce @ 2009-01-12 17:10 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Ryan Alberts, git
In-Reply-To: <200901102134.05652.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> torsdag 08 januari 2009 04:10:05 skrev Ryan Alberts:
> > I have attached a small fix for when a git config has /r lines in the file.
> > I have to admit that I do not usually submit patches to the open source
> > community and I am not very familiar with the process :-) Please, please,
> > let me know if I can do something different next time!
>
> Back to the patch. I think we should only ignore \r (not /r, but could say CR in
> a comment) before an LF.
I disagree; ignoring CR anyplace in the file should be fine, unless
it is within a double quoted value, in which case it should use
the same rule that \n would use within the same region.
' ', \n, \t all act the same with regards to being (mostly) ignored
whitespace. \r is no different. Especially for anyone crazy enough
to still be using a Mac style formatted file, with only CRs in it.
--
Shawn.
^ permalink raw reply
* Re: [EGIT PATCH 1/3] Support viewing all changes in a single compare editor
From: Shawn O. Pearce @ 2009-01-12 16:54 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1231550077-1057-2-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> Instead of having to click on every file listed as a diff
> an extra diff entry is inserted at the top. Double clicking
> on it will launch a compare editor for all changed files.
Nice.
> diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitFileDiffViewer.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitFileDiffViewer.java
> index ebec261..7549aa4 100644
> --- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitFileDiffViewer.java
> +++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitFileDiffViewer.java
> @@ -124,13 +149,16 @@ void doCopy() {
...
> + else
> + r.append(((RevDiff)o).left.getChildren().length + " files");
This should use the NLS framework for translation.
> diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/FileDiffLabelProvider.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/FileDiffLabelProvider.java
> index 60b3a5a..c78ba6e 100644
> --- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/FileDiffLabelProvider.java
> +++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/FileDiffLabelProvider.java
> @@ -14,12 +14,49 @@
> class FileDiffLabelProvider extends BaseLabelProvider implements
...
> + StringBuilder b = new StringBuilder();
> + if (add > 0) {
> + b.append(add + " added");
> + }
> + if (mod > 0) {
> + if (b.length() > 0)
> + b.append(", ");
> + b.append(mod + " changed");
> + }
> + if (del > 0) {
> + if (b.length() > 0)
> + b.append(", ");
> + b.append(del + " deleted");
Again, NLS.
> diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/RevDiff.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/RevDiff.java
> new file mode 100644
> index 0000000..020ec73
> --- /dev/null
> +++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/RevDiff.java
> +class DiffSide implements ITypedElement, IStructureComparator {
...
> + public String getName() {
> + return "EGit diff";
> + }
Should this have NLS applied to it?
--
Shawn.
^ permalink raw reply
* Re: [EGIT PATCH 7/7] Create an automatic UI test for the Git Import Wizard
From: Shawn O. Pearce @ 2009-01-12 16:45 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200901081957.20591.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
>
> We could hold onto this patch. It might be better if we start the built in git daemon and clone
> from it, or from file, instread of jgit.org, but please try it out and see if it looks like a good a approach to
> use SWTBot for UI tests.
I'm not applying this patch for two reasons:
1) I spent 30 minutes trying to get SWTBot installed and running,
I gave up. It doesn't want to run in my Eclipse. Heck, I didn't
even get as far as running, I couldn't get it to install far enough
to get the project to compile.
2) I really want to avoid remote network access during JUnit tests.
Now that we have our own server process we can run it over a pipe
or something to do this test. Or at worst, bind to a random port
on the loopback and have the client clone from that port.
--
Shawn.
^ permalink raw reply
* Re: "git diff --stat" doesn't show added empty file
From: Linus Torvalds @ 2009-01-12 16:13 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320901111936h6343e51fo94750d83e95743dc@mail.gmail.com>
On Mon, 12 Jan 2009, Ping Yin wrote:
> $ git diff --stat HEAD^..
> 0 files changed, 0 insertions(+), 0 deletions(-)
In the kernel, we use "git diff --stat --summary" for exactly this reason.
Well, not exactly.
The thing is, even if the file is _not_ empty, there's a huge difference
between "added 100 lines to an already-existing file" and "created a new
100-line file". Which is exactly what "--summary" adds.
And it sometimes even makes sense to show the summary without the
diffstat. If you're _only_ interested in create/delete/rename information,
you can do "git show --summary <cmit>". It won't give you line counts, but
it will give you information about any changes to filenames, eg in the
kernel archive, you could see an example of this with
git show -M --summary 95b482a8d31116f3f5c2a5089569393234d06385
where you have a combination of renames, creates and deletes.
So I think it's already better than what you ask for.
Linus
^ permalink raw reply
* Re: [RFC PATCH 3/3] Support fetching from foreign VCSes
From: Shawn O. Pearce @ 2009-01-12 15:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0901120041260.19665@iabervon.org>
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.
> > 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.
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. :-)
--
Shawn.
^ permalink raw reply
* Re: "git diff --stat" doesn't show added empty file
From: Michael J Gruber @ 2009-01-12 15:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ping Yin, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0901121319210.3586@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 01/12/09 13:19:
> Hi,
>
> On Mon, 12 Jan 2009, Ping Yin wrote:
>
>> $ git --version
>> git version 1.6.1.9.g97c34
>> $ mkdir test && cd test && git init && git commit --allow-empty -m
>> "Initial commit"
>> $ touch .gitignore && git add .gitignore && git commit -m "Add empty .gitignore"
>> $ git diff --stat HEAD^..
>> 0 files changed, 0 insertions(+), 0 deletions(-)
>>
>> May be the following is better?
>>
>> .gitignore | 0 +
>> 1 files changed, 0 insertions(+), 0 deletions(-)
>
> Have fun coding that.
Removing 5 lines from diff.c does the job, except for the " +" after 0,
but I don't know if that output is really better. Is the
addition/removal of an empty file a file change? It's certainly a change
of the containing dir, which git does not track. I don't see how to
distinguish addition from removal of an empty file at that point in the
code yet. This might be the "fun" part...
Michael
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Shawn O. Pearce @ 2009-01-12 15:37 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <496B2690.2010902@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Just chiming in that I can probably help mentoring whoever goes
> with libgit2. I do not have enough spare time for me to promise
> that I can be there as much as I think is necessary and proper,
> but I'll gladly help out.
Thanks. I'd love to see a libgit2 project this summer.
If we do have such a thing, and if I'm still wearing the maintainer
hat for libgit2, I think it would be improper for me to be the mentor
for the student. Just as Junio abstains from mentoring any students
in GSoC, to prevent potential bias during patch review, I probably
should abstain in the case of libgit2. Or at least move the project
to a dual-maintainer approach like we use with JGit, so the other
maintainer is the one doing the actual review and patch acceptance.
--
Shawn.
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Shawn O. Pearce @ 2009-01-12 15:35 UTC (permalink / raw)
To: Christian Couder; +Cc: Andreas Ericsson, git
In-Reply-To: <200901121420.25420.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> wrote:
> Le lundi 12 janvier 2009, Andreas Ericsson a écrit :
> > From previous years experience, successful
> > projects are those that the list sees code from within a week
> > or two after the project's started, while the projects that are
> > kept in the dark rarely (if ever?) finish successfully.
>
> I don't think things are so simple.
Nope, they aren't. But the pattern is generally there, when you
look at all GSoC projects in aggregate.
Students who are involved with their community are far more likely
to have a successful project. In most communities, getting code
posted on the discussion list and actually discussing it is a very
important part of that involvement.
--
Shawn.
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Shawn O. Pearce @ 2009-01-12 15:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, git
In-Reply-To: <alpine.DEB.1.00.0901121421530.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 12 Jan 2009, Andreas Ericsson wrote:
>
> > Just chiming in that I can probably help mentoring whoever goes with
> > libgit2. I do not have enough spare time for me to promise that I can be
> > there as much as I think is necessary and proper, but I'll gladly help
> > out.
>
> I don't know if I like co-mentoring; I always had the impression that this
> does not work all that well.
I haven't tried it myself, so I can't comment. I thought though
that Daniel and Christian's mentoring went rather well, but maybe
that's just me.
This year I may not be able to be a mentor for GSoC. Even assuming
we are selected again we're likely to only have two students, given
the size of the program and the size of our organization's community.
I will most likely be hosting an intern at day-job, and I do want
to maintain some sort of contribution to Git, without hurting my
day job performance... so my time this summer is probably going to
be somewhat limited.
> > On a side-note, I think all mentors should urge the students in the
> > strongest possible terms to deliver their work to git@vger as soon as
> > possible. From previous years experience, successful projects are those
> > that the list sees code from within a week or two after the project's
> > started, while the projects that are kept in the dark rarely (if ever?)
> > finish successfully.
>
> Nope, that is just plainly incorrect.
>
> The most successful GSoC project we had was Miklos' builtin-merge, but the
> code had to grow to a state that both him and me were comfortable with a
> submission to git@vger.
Heh. I'd wager the most successful GSoC project was Marek's push
support for JGit. Having ObjectWriter available has opened up
the doors to support a lot of code in JGit, like the full protocol
suite, and bundles. Without it I wouldn't have gotten as far as
I did in Gerrit.
In terms of value, to me as a contributor, Marek's work gave me a
foundation we could build on and get stuff done. Miklos' merge is
great, but I don't think we gained nearly as many features as we
did with Marek's contribution.
Anyway, I don't want to get into a "my student was better!" contest.
I just think that we had a very successful year this year, with a
few really great projects being contributed to the community as a
result of our students' hard work.
> The _communication_ should be open, and much of it on the mailing list, I
> agree, but _only_ after the student is familiar enough with the aspects of
> her project (including some familiarity with the source code).
>
> I will _not_ force a student to ask questions openly that he finds
> embarassing.
I agree. The first few weeks are really critical to the student. They
are still trying to find their way around the code base and don't want
to look like an idiot. Nobody wants to look like an idiot, especially
in public, and especially when they have been "hired" to do a particular
job.
But... part of the reason GSoC exists is to get students involved
in open source. The rest of us don't come to Git with mentors we
can ask the "stupid" questions to. We come here and have to ask
what we need to ask, on the public mailing list, complete with
archives for the rest of time. As mentors we should be trying to
encourage our students to work in this, or any other, open source
community. GSoC is about getting these folks _involved_, so that
40 years from now, open source is just as viable as it is today.
--
Shawn.
^ permalink raw reply
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