Re: To graft or not to graft... (Re: Recovering from repository corruption)

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <git@...>
Cc: Linus Torvalds <torvalds@...>, Stephen R. van den Berg <srb@...>, Denis Bueno <dbueno@...>
Date: Thursday, June 12, 2008 - 3:14 am

On Thursday 12 June 2008, Linus Torvalds wrote:

AFAICS, there's already a perfectly fine way to distribute grafted history:
1. Add a grafts file
2. Run git-filter-branch
3. Remove grafts file
4. Distribute repo
5. Profit!

Since git-filter-branch turns grafted parentage into _real_ parentage,
there's no point in ever having a grafts file at all (except transiently
for telling git-filter-branch what to do).

I suggest we make commit walkers NOT obey the grafts file by default, but
instead require a --follow-grafts option to restore the current behaviour.
Then, we teach git-filter-branch to obey the grafts file (probably by
employing said --follow-grafts option).

For those who want to hang on to the current behaviour, they can create
some config option that is equivalent to always running with
--follow-grafts.


The following is ugly, untested, undocumented, and obviously unfit for
inclusion:


diff --git a/commit.c b/commit.c
index 94d5b3d..3e9ebf7 100644
--- a/commit.c
+++ b/commit.c
@@ -7,6 +7,7 @@
 #include "revision.h"
 
 int save_commit_buffer = 1;
+int use_grafts = 0;
 
 const char *commit_type = "commit";
 
@@ -242,7 +243,7 @@ int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size)
 	char *bufptr = buffer;
 	unsigned char parent[20];
 	struct commit_list **pptr;
-	struct commit_graft *graft;
+	struct commit_graft *graft = NULL;
 	unsigned n_refs = 0;
 
 	if (item->object.parsed)
@@ -260,7 +261,8 @@ int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size)
 	bufptr += 46; /* "tree " + "hex sha1" + "\n" */
 	pptr = &item->parents;
 
-	graft = lookup_commit_graft(item->object.sha1);
+	if (use_grafts)
+		graft = lookup_commit_graft(item->object.sha1);
 	while (bufptr + 48 < tail && !memcmp(bufptr, "parent ", 7)) {
 		struct commit *new_parent;
 
diff --git a/commit.h b/commit.h
index 2d94d41..3e30aa0 100644
--- a/commit.h
+++ b/commit.h
@@ -22,6 +22,7 @@ struct commit {
 };
 
 extern int save_commit_buffer;
+extern int use_grafts;
 extern const char *commit_type;
 
 /* While we can decorate any object with a name, it's only used for commits.. */
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index d04c346..5ebe7cd 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -230,11 +230,11 @@ mkdir ../map || die "Could not create map/ directory"
 case "$filter_subdir" in
 "")
 	git rev-list --reverse --topo-order --default HEAD \
-		--parents "$@"
+		--follow-grafts --parents "$@"
 	;;
 *)
 	git rev-list --reverse --topo-order --default HEAD \
-		--parents "$@" -- "$filter_subdir"
+		--follow-grafts --parents "$@" -- "$filter_subdir"
 esac > ../revs || die "Could not get the commits"
 commits=$(wc -l <../revs | tr -d " ")
 
diff --git a/revision.c b/revision.c
index 5a1a948..ca98815 100644
--- a/revision.c
+++ b/revision.c
@@ -1059,6 +1059,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
 				revs->first_parent_only = 1;
 				continue;
 			}
+			if (!strcmp(arg, "--follow-grafts")) {
+				use_grafts = 1;
+				continue;
+			}
 			if (!strcmp(arg, "--reflog")) {
 				handle_reflog(revs, flags);
 				continue;
-- 
1.5.6.rc2.128.gf64ae


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Recovering from repository corruption, Denis Bueno, (Tue Jun 10, 1:26 pm)
Re: Recovering from repository corruption, Nicolas Pitre, (Tue Jun 10, 3:40 pm)
Re: Recovering from repository corruption, Denis Bueno, (Tue Jun 10, 3:42 pm)
Re: Recovering from repository corruption, Jakub Narebski, (Tue Jun 10, 1:55 pm)
Re: Recovering from repository corruption, Denis Bueno, (Tue Jun 10, 3:38 pm)
Re: Recovering from repository corruption, Jakub Narebski, (Tue Jun 10, 3:59 pm)
Re: Recovering from repository corruption, Denis Bueno, (Tue Jun 10, 4:03 pm)
Re: Recovering from repository corruption, Linus Torvalds, (Tue Jun 10, 4:23 pm)
Re: Recovering from repository corruption, Denis Bueno, (Tue Jun 10, 4:28 pm)
Re: Recovering from repository corruption, Linus Torvalds, (Tue Jun 10, 5:09 pm)
To graft or not to graft... (Re: Recovering from repository ..., Stephen R. van den Berg, (Wed Jun 11, 7:21 pm)
Re: To graft or not to graft... (Re: Recovering from reposit..., Johan Herland, (Thu Jun 12, 3:14 am)
Re: To graft or not to graft... (Re: Recovering from reposit..., Stephen R. van den Berg, (Thu Jun 12, 8:20 am)
Re: Recovering from repository corruption, Junio C Hamano, (Tue Jun 10, 6:52 pm)
Re: Recovering from repository corruption, Denis Bueno, (Tue Jun 10, 5:27 pm)
Re: Recovering from repository corruption, Denis Bueno, (Tue Jun 10, 5:22 pm)
Re: Recovering from repository corruption, Linus Torvalds, (Tue Jun 10, 5:48 pm)
Re: Recovering from repository corruption, Denis Bueno, (Tue Jun 10, 6:09 pm)
Re: Recovering from repository corruption, Linus Torvalds, (Tue Jun 10, 6:45 pm)
Re: Recovering from repository corruption, Nicolas Pitre, (Tue Jun 10, 8:43 pm)
Re: Recovering from repository corruption, Linus Torvalds, (Tue Jun 10, 9:39 pm)
Re: Recovering from repository corruption, Nicolas Pitre, (Tue Jun 10, 9:47 pm)
Re: Recovering from repository corruption, Linus Torvalds, (Tue Jun 10, 7:00 pm)
Re: Recovering from repository corruption, Tarmigan, (Tue Jun 10, 6:25 pm)
Re: Recovering from repository corruption, Denis Bueno, (Tue Jun 10, 6:41 pm)
Re: Recovering from repository corruption, Jakub Narebski, (Tue Jun 10, 4:14 pm)
Re: Recovering from repository corruption, Denis Bueno, (Tue Jun 10, 4:35 pm)