* Re: Two gitweb feature requests
From: Jakub Narebski @ 2006-04-29 7:27 UTC (permalink / raw)
To: git
It would be nice if gitweb provided for the GIT repository description
which doesn't fit the "Description" column and is shortened, and any
other text which doesn't fit it's own column, full text of said field
as the "title" attribute for the cell 'td' element, or encompasing
'span' element. It would result in having full, not shortened text of
said field (e.g. repository description) in the pop-up on mouse hover
over said field. To simplify things it could be provided
unconditionally, regardless whether the field needs shortening or not.
By the way, would it be possible for the repository without provided
description to stand out more, perhaps by changing formatting of
default description:
"Unnamed repository; edit this file to name it for gitweb."
to use ALL CAPS for attention, like that:
"UNNAMED REPOSITORY; edit this file to name it for gitweb."
or perhaps if possible use HTML formatting [additionally] for that.
--
Jakub Narebski
Poland
^ permalink raw reply
* [ANNOUNCE] qgit-1.2
From: Marco Costalba @ 2006-04-29 7:54 UTC (permalink / raw)
To: git, linux-kernel
This is qgit-1.2
With qgit you will be able to browse revisions history, view patch content
and changed files, graphically following different development branches.
FEATURES
- View revisions, diffs, files history, files annotation, archive tree.
- Commit changes visually cherry picking modified files.
- Apply or format patch series from selected commits, drag and
drop commits between two instances of qgit.
- qgit implements a GUI for the most common StGIT commands like push/pop
and apply/format patches. You can also create new patches or refresh
current top one using the same semantics of git commit, i.e. cherry
picking single modified files.
NEW IN THIS RELEASE
A lot of work has been done from 1.1
Main new features:
*Add support for code range filtering*
To filter a mouse selected code text across all revisions file history,
this is very useful to quick search for revisions that modified a given
chunk of code.
*Much improved graph for partial repos views*
Thanks to new --boundary git-rev-list option graphs for partial repo
views are now much more clear and easy to follow.
*Support for launching an external diff viewer*
Useful, as example, to view the diffs in a 'tiled pane' mode. Default
is kompare, but it is easily user settable.
*Show stat info in patch viewer*
Use new --patch-with-stat git-diff-tree option to prepend stat info in
patch viewer.
*Adjustable font size in revision list view*
To squeeze revision graph without compromise patch and file content views.
*Key bindings for scrolling patch and revision logs*
Same keyboard navigation map of gitk. See help (F1) for details.
*Support for 'working dir' pseudo-tree in tree view*
To browse working dir changes and files in a tree like view. This is useful
for people coming from others SCM systems.
*Loading speed improvements*
Heavy optimization work to speed-up start up times, about 20%-30% from
qgit 1.1.1
NOTE: interface change.
Browsing file history revisions in annotate window does not update main view
anymore. Double click is now required to update main view. This makes qgit
less 'jumpy' and let browse file history without loosing main view selection.
Please note that you will need git 1.3.0 or newer.
DOWNLOAD
Tarball is at
http://prdownloads.sourceforge.net/qgit/qgit-1.2.tar.bz2?download
Git archive is at
http://digilander.libero.it/mcostalba/scm/qgit.git
See http://digilander.libero.it/mcostalba/ for detailed download information.
INSTALLATION
git 1.3.0 is required.
To install from tarball:
./configure
make
make install-strip
To install from git archive:
autoreconf -i
./configure
make
make install-strip
Or check the shipped README for detailed information.
CHANGELOG from 1.2rc2
- do not update main view when browsing file history: double click is
now required
- show "working dir" pseudo rev also when there is no change
- add support for 'working dir' pseudo-tree in tree view
- add key bindings for scrolling patch and revision logs views
- add support for adjustable font size in revision list view
- add "revision diff" entry in context menu
- support lane mouse selection also for not free lanes
- help view should not be a top level window
- restore selection when removing code filtering
- fix a bad crash in diff viewer window
- fix a inconsistency in spinbox in annotation view
- fix an off by one bug that creates invalid pixmaps
- fix highlighting of selected revision if a reference name is used
- small GUI tweaks
For a complete changelog see shipped ChangeLog file or git repository
revision's history
Marco
^ permalink raw reply
* [PATCH] built-in diff: assorted updates.
From: Junio C Hamano @ 2006-04-29 9:29 UTC (permalink / raw)
To: git
In-Reply-To: <7virosalxb.fsf@assigned-by-dhcp.cox.net>
"git diff(n)" without --base, --ours, etc. defaults to --cc,
which usually is the same as -p unless you are in the middle of
a conflicted merge, just like the shell script version.
"git diff(n) blobA blobB path" complains and dies.
"git diff(n) tree0 tree1 tree2...treeN" does combined diff that
shows a merge of tree1..treeN to result in tree0.
Giving "-c" option to any command that defaults to "--cc" turns
off dense-combined flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Comes on top of the previous "built-in diff" patch.
Now I think this is more or less what Linus envisioned when
he started converting the rev related option parsing to use
setup_revisions(), including the exotic combinations the
shell script "git diff" does not support:
git diff(n) HEAD~10:Makefile Makefile ; blob vs any file
git diff(n) HEAD~10:Makefile HEAD~20:Makefile ; two blobs
git diff(n) v1.0.0 v1.0.0^1 v1.0.0^2 ; combine 'em
The normal ones are also supported:
git diff(n) -- Documentation ; index vs working
git diff(n) --cached ; tree vs index
git diff(n) HEAD ; tree vs working
git diff(n) HEAD~10 HEAD~8 ; two trees
git diff(n) HEAD:arch/i386 HEAD:arch/x86_64 ; two trees
builtin-diff.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++---------
combine-diff.c | 47 ++++++++++++++++++++++++++++++-----------------
diff.h | 2 ++
revision.c | 1 +
4 files changed, 79 insertions(+), 26 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index 1968212..c543105 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -47,13 +47,17 @@ static int builtin_diff_files(struct rev
}
/*
* Make sure there are NO revision (i.e. pending object) parameter,
- * rev.max_count is reasonable (0 <= n <= 3),
- * there is no other revision filtering parameters.
+ * specified rev.max_count is reasonable (0 <= n <= 3), and
+ * there is no other revision filtering parameter.
*/
if (revs->pending_objects ||
revs->min_age != -1 ||
- revs->max_age != -1)
+ revs->max_age != -1 ||
+ 3 < revs->max_count)
usage(builtin_diff_usage);
+ if (revs->max_count < 0 &&
+ (revs->diffopt.output_format == DIFF_FORMAT_PATCH))
+ revs->combine_merges = revs->dense_combined_merges = 1;
/*
* Backward compatibility wart - "diff-files -s" used to
* defeat the common diff option "-s" which asked for
@@ -178,9 +182,6 @@ static int builtin_diff_tree(struct rev_
int argc, const char **argv,
struct object_list *ent)
{
- /* We saw two trees, ent[0] and ent[1].
- * unless ent[0] is unintesting, they are swapped
- */
const unsigned char *(sha1[2]);
int swap = 1;
while (1 < argc) {
@@ -191,6 +192,10 @@ static int builtin_diff_tree(struct rev_
usage(builtin_diff_usage);
argv++; argc--;
}
+
+ /* We saw two trees, ent[0] and ent[1].
+ * unless ent[0] is unintesting, they are swapped
+ */
if (ent[0].item->flags & UNINTERESTING)
swap = 0;
sha1[swap] = ent[0].item->sha1;
@@ -200,6 +205,33 @@ static int builtin_diff_tree(struct rev_
return 0;
}
+static int builtin_diff_combined(struct rev_info *revs,
+ int argc, const char **argv,
+ struct object_list *ent,
+ int ents)
+{
+ const unsigned char (*parent)[20];
+ int i;
+
+ while (1 < argc) {
+ const char *arg = argv[1];
+ if (!strcmp(arg, "--raw"))
+ revs->diffopt.output_format = DIFF_FORMAT_RAW;
+ else
+ usage(builtin_diff_usage);
+ argv++; argc--;
+ }
+ if (!revs->dense_combined_merges && !revs->combine_merges)
+ revs->dense_combined_merges = revs->combine_merges = 1;
+ parent = xmalloc(ents * sizeof(*parent));
+ /* Again, the revs are all reverse */
+ for (i = 0; i < ents; i++)
+ memcpy(parent + i, ent[ents - 1 - i].item->sha1, 20);
+ diff_tree_combined(parent[0], parent + 1, ents - 1,
+ revs->dense_combined_merges, revs);
+ return 0;
+}
+
static void add_head(struct rev_info *revs)
{
unsigned char sha1[20];
@@ -215,7 +247,7 @@ static void add_head(struct rev_info *re
int cmd_diff(int argc, const char **argv, char **envp)
{
struct rev_info rev;
- struct object_list *list, ent[2];
+ struct object_list *list, ent[100];
int ents = 0, blobs = 0, paths = 0;
const char *path = NULL;
struct blobinfo blob[2];
@@ -273,8 +305,9 @@ int cmd_diff(int argc, const char **argv
if (!strcmp(obj->type, commit_type))
obj = &((struct commit *)obj)->tree->object;
if (!strcmp(obj->type, tree_type)) {
- if (2 <= ents)
- die("more than two trees given: '%s'", name);
+ if (ARRAY_SIZE(ent) <= ents)
+ die("more than %d trees given: '%s'",
+ ARRAY_SIZE(ent), name);
obj->flags |= flags;
ent[ents].item = obj;
ent[ents].name = name;
@@ -316,6 +349,8 @@ int cmd_diff(int argc, const char **argv
return builtin_diff_b_f(&rev, argc, argv, blob, path);
break;
case 2:
+ if (paths)
+ usage(builtin_diff_usage);
return builtin_diff_blobs(&rev, argc, argv, blob);
break;
default:
@@ -328,5 +363,7 @@ int cmd_diff(int argc, const char **argv
return builtin_diff_index(&rev, argc, argv);
else if (ents == 2)
return builtin_diff_tree(&rev, argc, argv, ent);
+ else
+ return builtin_diff_combined(&rev, argc, argv, ent, ents);
usage(builtin_diff_usage);
}
diff --git a/combine-diff.c b/combine-diff.c
index ca36f5d..8a8fe38 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -831,15 +831,16 @@ void show_combined_diff(struct combine_d
}
}
-void diff_tree_combined_merge(const unsigned char *sha1,
- int dense, struct rev_info *rev)
+void diff_tree_combined(const unsigned char *sha1,
+ const unsigned char parent[][20],
+ int num_parent,
+ int dense,
+ struct rev_info *rev)
{
struct diff_options *opt = &rev->diffopt;
- struct commit *commit = lookup_commit(sha1);
struct diff_options diffopts;
- struct commit_list *parents;
struct combine_diff_path *p, *paths = NULL;
- int num_parent, i, num_paths;
+ int i, num_paths;
int do_diffstat;
do_diffstat = (opt->output_format == DIFF_FORMAT_DIFFSTAT ||
@@ -849,17 +850,8 @@ void diff_tree_combined_merge(const unsi
diffopts.with_stat = 0;
diffopts.recursive = 1;
- /* count parents */
- for (parents = commit->parents, num_parent = 0;
- parents;
- parents = parents->next, num_parent++)
- ; /* nothing */
-
/* find set of paths that everybody touches */
- for (parents = commit->parents, i = 0;
- parents;
- parents = parents->next, i++) {
- struct commit *parent = parents->item;
+ for (i = 0; i < num_parent; i++) {
/* show stat against the first parent even
* when doing combined diff.
*/
@@ -867,8 +859,7 @@ void diff_tree_combined_merge(const unsi
diffopts.output_format = DIFF_FORMAT_DIFFSTAT;
else
diffopts.output_format = DIFF_FORMAT_NO_OUTPUT;
- diff_tree_sha1(parent->object.sha1, commit->object.sha1, "",
- &diffopts);
+ diff_tree_sha1(parent[i], sha1, "", &diffopts);
diffcore_std(&diffopts);
paths = intersect_paths(paths, i, num_parent);
@@ -907,3 +898,25 @@ void diff_tree_combined_merge(const unsi
free(tmp);
}
}
+
+void diff_tree_combined_merge(const unsigned char *sha1,
+ int dense, struct rev_info *rev)
+{
+ int num_parent;
+ const unsigned char (*parent)[20];
+ struct commit *commit = lookup_commit(sha1);
+ struct commit_list *parents;
+
+ /* count parents */
+ for (parents = commit->parents, num_parent = 0;
+ parents;
+ parents = parents->next, num_parent++)
+ ; /* nothing */
+
+ parent = xmalloc(num_parent * sizeof(*parent));
+ for (parents = commit->parents, num_parent = 0;
+ parents;
+ parents = parents->next, num_parent++)
+ memcpy(parent + num_parent, parents->item->object.sha1, 20);
+ diff_tree_combined(sha1, parent, num_parent, dense, rev);
+}
diff --git a/diff.h b/diff.h
index 7150b90..b3b2c4d 100644
--- a/diff.h
+++ b/diff.h
@@ -75,6 +75,8 @@ #define combine_diff_path_size(n, l) \
extern void show_combined_diff(struct combine_diff_path *elem, int num_parent,
int dense, struct rev_info *);
+extern void diff_tree_combined(const unsigned char *sha1, const unsigned char parent[][20], int num_parent, int dense, struct rev_info *rev);
+
extern void diff_tree_combined_merge(const unsigned char *sha1, int, struct rev_info *);
extern void diff_addremove(struct diff_options *,
diff --git a/revision.c b/revision.c
index f2a9f25..4381d45 100644
--- a/revision.c
+++ b/revision.c
@@ -664,6 +664,7 @@ int setup_revisions(int argc, const char
}
if (!strcmp(arg, "-c")) {
revs->diff = 1;
+ revs->dense_combined_merges = 0;
revs->combine_merges = 1;
continue;
}
--
1.3.1.ga0c5
^ permalink raw reply related
* [PATCH/RFC] Extended SHA1 -- "rev^#" syntax to mean "all parents"
From: Junio C Hamano @ 2006-04-29 9:45 UTC (permalink / raw)
To: git
In-Reply-To: <7virosalxb.fsf@assigned-by-dhcp.cox.net>
A short-hand "rev^#" is understood to be "all parents of the
named commit" with this patch. So you can do
git show v1.0.0^#
to view the parents of a merge commit,
gitk ^v1.0.0^# v1.0.4
to view the log between two revs (including the bottom one), and
git diff --cc v1.1.0 v1.0.0^#
to inspect what got changed from the merge parents of v1.0.0 to v1.1.0.
This might be just my shiny new toy that is not very useful in
practice. I needed it to do the multi-tree diff on Len's
infamous 12-way Octopus; typing "diff --cc funmerge funmerge^1
funmerge^2 funmerge^3 ..." was too painful.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
revision.c | 37 +++++++++++++++++++++++++++++++++++++
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/revision.c b/revision.c
index f2a9f25..194f35b 100644
--- a/revision.c
+++ b/revision.c
@@ -477,6 +477,36 @@ static void handle_all(struct rev_info *
for_each_ref(handle_one_ref);
}
+static int add_parents_only(struct rev_info *revs, const char *arg, int flags)
+{
+ unsigned char sha1[20];
+ struct object *it;
+ struct commit *commit;
+ struct commit_list *parents;
+
+ if (*arg == '^') {
+ flags ^= UNINTERESTING;
+ arg++;
+ }
+ if (get_sha1(arg, sha1))
+ return 0;
+ while (1) {
+ it = get_reference(revs, arg, sha1, 0);
+ if (strcmp(it->type, tag_type))
+ break;
+ memcpy(sha1, ((struct tag*)it)->tagged->sha1, 20);
+ }
+ if (strcmp(it->type, commit_type))
+ return 0;
+ commit = (struct commit *)it;
+ for (parents = commit->parents; parents; parents = parents->next) {
+ it = &parents->item->object;
+ it->flags |= flags;
+ add_pending_object(revs, it, arg);
+ }
+ return 1;
+}
+
void init_revisions(struct rev_info *revs)
{
memset(revs, 0, sizeof(*revs));
@@ -746,6 +776,13 @@ int setup_revisions(int argc, const char
}
*dotdot = '.';
}
+ dotdot = strstr(arg, "^#");
+ if (dotdot && !dotdot[2]) {
+ *dotdot = 0;
+ if (add_parents_only(revs, arg, flags))
+ continue;
+ *dotdot = '^';
+ }
local_flags = 0;
if (*arg == '^') {
local_flags = UNINTERESTING;
--
1.3.1.ga0c5
^ permalink raw reply related
* Re: Two gitweb feature requests
From: Jakub Narebski @ 2006-04-29 11:16 UTC (permalink / raw)
To: git
In-Reply-To: <1146144425.11909.450.camel@pmac.infradead.org>
It would be nice if gitweb provided for the GIT repository description which
doesn't fit the "Description" column and is shortened, and any other text
which doesn't fit it's own column, full text of said field as the "title"
attribute for the cell 'td' element, or encompasing 'span' element. It
would result in having full, not shortened text of said field (e.g.
repository description) in the pop-up on mouse hover over said field. To
simplify things it could be provided unconditionally, regardless whether
the field needs shortening or not.
By the way, would it be possible for the repository without provided
description to stand out more, perhaps by changing formatting of default
description:
"Unnamed repository; edit this file to name it for gitweb."
to use ALL CAPS for attention, like that:
"UNNAMED REPOSITORY; edit this file to name it for gitweb."
or perhaps if possible use HTML formatting [additionally] for that.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: fatal: git-write-tree: not able to write tree
From: colin @ 2006-04-29 13:23 UTC (permalink / raw)
To: junkio; +Cc: git
diff --git a/git-am.sh b/git-am.sh
index eab4aa8..872145b 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -376,6 +376,13 @@ do
echo "No changes - did you forget update-index?"
stop_here $this
fi
+ unmerged=$(git-ls-files -u)
+ if test -n "$unmerged"
+ then
+ echo "You still have unmerged paths in your index"
+ echo "did you forget update-index?"
+ stop_here $this
+ fi
apply_status=0
;;
esac
Er... it's very non-obvious to me why you'd want to stick a workaround
here when you could instead fix git-write-tree to do it. That seems
like The Right Thing.
(It would also be helpful to mention at least one unmerged file by name.)
^ permalink raw reply related
* Features ask for git-send-email
From: Bertrand Jacquin @ 2006-04-29 13:30 UTC (permalink / raw)
To: Git Mailing List
Hi,
Could it be possible to add a features in git-send-email.perl to
accept a differrent charset as iso-8859-1 ? I would like to send
fr_FR.utf8 mail as I use git to manager a latex files tree which are
written in utf8.
Any objection ?
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: cg-clone not fetching all tags?
From: Wolfgang Denk @ 2006-04-29 14:00 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20060427105251.AA4B2353DAC@atlas.denx.de>
[Repost because there was zero response, not even somebody telling me
to RTFM or so.]
Hi,
it seems that "cg-clone" does not fetch all tags any more - only the
most recent ones (modiufied in the last N days?) seem to be fetched?
[Eventually the "N days" might correspond to "changing tools to
version X", but I have no way to find out.]
This happens only when using HTTP; using ssh or rsync works fine.
Also, if we follow the "cg-clone" by a "git-fetch -t" command, this
will load the missing tags.
Is this intentional, or am I doing anything wrong?
[For testing, try "cg-clone http://www.denx.de/git/u-boot.git"]
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
In theory, there is no difference between theory and practice. In
practice, however, there is.
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Jakub Narebski @ 2006-04-29 14:59 UTC (permalink / raw)
To: git
In-Reply-To: <e2kset$lk2$1@sea.gmane.org>
Jakub Narebski wrote:
> Junio C Hamano wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> Actually, this can be resolved using automatic history grafts to the
>>> remote repository we pulled from, if the commit is not present on local
>>> side (and removing graft when commit appears on local side).
>>
>> You do not even need history grafts. The "cherry-pick source"
>> was a bad example. Maybe using "related" as a way to implement
>> "bind" would have been a better example -- we want inter-commit
>> relationship that requires connectivity but without ancestry for
>> them.
>>
>> You can just have two kinds of 'related'. One that means
>> connectivity, the other that does not.
>
> Good idea.
>
> Another problem for core git, but I think orthogonal to the
> "related"/"note" distinction is if the relation (or note) should be used
> as helper in merges, perhaps by some agreed upon convention on the
> comment/description/value part (e.g. "mergehelper" or "mergeinfo").
Scratch that. It would be better for merge strategy just to check for
defined set of "links" and "notes", e.g. "prior" (pu-prior) and
"original" (cherrypick).
But there would be problem with connectivity provided by "link" relations,
namely info/grafts file, which deal only with parents. For example when we
cauterize history using grafts (e.g. for shallow clone) the "link" like
"prior" reaching to the cut-off part of the history might make your day ;-)
Well, we could always drop all the connectivity, and make
link sha1 description...
shortcut for
note link sha1 description...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH/RFC] Extended SHA1 -- "rev^#" syntax to mean "all parents"
From: Johannes Schindelin @ 2006-04-29 15:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaca490ln.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 29 Apr 2006, Junio C Hamano wrote:
> A short-hand "rev^#" is understood to be "all parents of the
> named commit" with this patch.
Just my 2/100: Why not "rev^*"? I could remember that more easily.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-format-patch: Use rfc2822 compliant date.
From: Huw Davies @ 2006-04-29 15:50 UTC (permalink / raw)
Signed-off-by: Huw Davies <huw@codeweavers.com>
---
git-format-patch.sh | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
fa12b0e43a0559101551d697866c01a92778c67f
diff --git a/git-format-patch.sh b/git-format-patch.sh
index c7133bc..c077f44 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -205,11 +205,10 @@ sub show_date {
}
my $t = $time + $minutes * 60;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday) = gmtime($t);
- return sprintf("%s %s %d %02d:%02d:%02d %d %+05d",
- $weekday_names[$wday],
- $month_names[$mon],
- $mday, $hour, $min, $sec,
- $year+1900, $tz);
+ return sprintf("%s, %d %s %d %02d:%02d:%02d %+05d",
+ $weekday_names[$wday], $mday,
+ $month_names[$mon], $year+1900,
+ $hour, $min, $sec, $tz);
}
print "From nobody Mon Sep 17 00:00:00 2001\n";
--
1.3.0
^ permalink raw reply related
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: linux @ 2006-04-29 16:51 UTC (permalink / raw)
To: git
Boy, this is an interesting discussion!
On the one hand, it seems "obvious" to me that extra links might be
useful. But Linus's minimalist points have a lot of merit.
I have to agree, it's important to think of a single practical use before
adding the feature. So let's do a little brainstorming...
For just referring to another commit, there's no problem putting
it in the body. A sensible porcelain GUI will, when it seems something
that looks like an object identifier in a comment, and that object
identifier exists, make it a clickable link. So a comment like:
"This fixes the same problem as <commit>, but is a cleaner
(albeit more invasive) fix."
Would do the right thing: the user reading it could easily jump
to the other comment. A "header" link as opposed to a "comment"
link just has the property of being unambiguous. No heuristic
will guess that a link should exist when there isn't.
So, what is that property useful for?
Now, one thing that porcelains provide, in addition to "parent" links,
is "child" links. Useful. But it could be done with commit comment
links as well, and it's not clear that having the link in the commit
header as opposed to the comment would help much. You still have to
find and uncompress part of each commit to generate the history
tree. Does uncompressing the rest of it and running a heuristic
over the text for really cost that much?
I'm not convinced it's needed for that feature. (I'd sooner argue for
never compressing commit objects in packs on the grounds that the
repeated uncompression while browsing is worth saving more than the
relatively minor disk space.)
So to be valuable, and inadvisable to express with a specially
formatted comment, it has to be something that would be Very Bad
to get wrong. What qualifies?
Maybe some merge algorithm information? If the merge could be told that
this change "is the same" as that change, so it can be skipped when
cherry-picking that branch, and the information was wrong, that could
cause lots of problems.
But given that git-cherry already uses (imperfect) heuristics to
detect already-merged patches, and they seem to work well enough, is
that a strong enough argument? Is there some other merge application
where it would help?
Now, the "this other object should exist in the repository, and it's an
error if you can't fetch it" link obviously needs to be unambiguously
distinguished from, say, a reference to the (Linux kernel) dodecapus merge
in a git tree checkin comment. But, as Linus says, what reason is there
for including it? What do you need the commit in the repository for?
Well, the only reason that you need ANY commit in the repository is
because it's part of history, and comparing it with other versions is
meaningful. So what trees, not already in the ancestry graph of a
given commit, are useful to compare to? In particular, useful for some
automated process; manual comparisons can always be done manually.
Nothing's jumping out at me. Any suggestions?
^ permalink raw reply
* Re: [PATCH/RFC] Extended SHA1 -- "rev^#" syntax to mean "all parents"
From: Linus Torvalds @ 2006-04-29 16:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0604291737390.25093@wbgn013.biozentrum.uni-wuerzburg.de>
On Sat, 29 Apr 2006, Johannes Schindelin wrote:
>
> > A short-hand "rev^#" is understood to be "all parents of the
> > named commit" with this patch.
>
> Just my 2/100: Why not "rev^*"? I could remember that more easily.
Yeah, that (or ^@ - to match shell "$1" "$2" .. "$@") was my reaction too.
The "rev^#" thing should to my mind return the _number_ of parents, the
same way "$#" does in shell. I actually pronounce that '#' character
mentally as "number", but maybe that's just because I'm totally mentally
damaged by shell programming, and everybody else probably calls it "hash"
(and some people apparently call it "pound", for some really sick reason).
So "rev^#" literally reads as "revision parent number" to me. Useful?
Maybe. Maybe not.
Linus
^ permalink raw reply
* Re: cg-clone not fetching all tags?
From: Petr Baudis @ 2006-04-29 17:05 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Git Mailing List
In-Reply-To: <20060429140042.1FB37353DAC@atlas.denx.de>
Hi,
Dear diary, on Sat, Apr 29, 2006 at 04:00:42PM CEST, I got a letter
where Wolfgang Denk <wd@denx.de> said that...
> it seems that "cg-clone" does not fetch all tags any more - only the
> most recent ones (modiufied in the last N days?) seem to be fetched?
> [Eventually the "N days" might correspond to "changing tools to
> version X", but I have no way to find out.]
>
> This happens only when using HTTP; using ssh or rsync works fine.
> Also, if we follow the "cg-clone" by a "git-fetch -t" command, this
> will load the missing tags.
>
> Is this intentional, or am I doing anything wrong?
>
> [For testing, try "cg-clone http://www.denx.de/git/u-boot.git"]
you need to run git-update-server-info every time you add or update a
tag (or best every time you push). See the NOTES section of
cg-admin-setuprepo documentation for details on how to set it up to be
called automagically at every push.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Linus Torvalds @ 2006-04-29 17:35 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060429165151.2570.qmail@science.horizon.com>
On Sat, 29 Apr 2006, linux@horizon.com wrote:
>
> Well, the only reason that you need ANY commit in the repository is
> because it's part of history, and comparing it with other versions is
> meaningful. So what trees, not already in the ancestry graph of a
> given commit, are useful to compare to? In particular, useful for some
> automated process; manual comparisons can always be done manually.
>
> Nothing's jumping out at me. Any suggestions?
The only thing that I've ever wondered about is the "base commit of a
merge".
Now, the thing is, we can always compute it. That's true _iff_ we've
merged using the standard merge mechanism, but it wasn't always true
historically (eg the original merges were computed with the original
"git-merge-base" algorithm, which just picked the _first_ merge base it
would find, while these days we use multiple ones for criss-cross merges).
So I would not totally object if a merge algorithm added a
merge-base <sha1>
notation. But while it _could_ be just a "note merge-base <sha1>", it
should _not_ be a "link <sha1> merge-base".
Let me explain why I think there are differences between those three
options, and why I actually think that two of them are "valid" ideas,
while the third one is not.
- Case 1: the
merge-base <sha1>
is a "valid" idea (where there might of course be more than one <sha1>,
and possibly more than one "merge-base" line: you'd have to have some
rule for what happens for a recursive merge), although it has the
generally big down-side of being redundant information in all current
setups.
It's redundant, but at the same time it's information that in _theory_
might not be redundant, because I can see a situation where a merge was
forced by manually specifying a merge base (eg a special merge like the
original "gitk" merge, merging two initially unrelated projects
together).
In theory. So it could be real information for a merge commit. And we'd
enforce some kind of real semantics for it - and it would have a really
solid technical meaning: assuming we define the multi-merge-base
semantics properly it would NEVER have any question about "what are
best practices?" or "what does this mean?".
So this "case 1" actually has technical consequences, but you can, for
example, actually _check_ them. You can make fsck literally complain if
the merge base doesn't make sense. There's a clear "technical
violation", which might not be entirely trivial to figure out, but
thanks to it having a good meaning and a strict definition, it's
_there_.
Now, in all honesty, I don't think "case 1" is a _good_ thing to do. I'm
just saying that I wouldn't be as upset about it as I've been over this
"link" discussion. The reason I think "case 1" sucks is simply that I
think you can in _practice_ get all the benefits much better with "case
2", even if that one doesn't imply any actual git semantics:
- Case 2: the
note merge-base <sha1>
thing is _also_ a perfectly valid idea, because now it's also very
well-defined: the "note" part tells you that git doesn't actually
impose any semantics what-so-ever on it, so it's really just a comment,
and as in case 1 above, once you see it as a comment, the _meaning_ of
it is immediately clear. It's literally just a note from the merge
algorithm saying "I used this as a merge base".
The "note" syntax actually has a huge advantage. When you see it as a
comment from the merge algorithm, you immediately think it might also
be a good idea to add a few other notes. So a merge commit might
actually have
note merge-algorithm recursive
note merge-conflicts none
note merge-base <sha1>
all make total sense. It's telling you what the algorithm used was, and
that it didn't neen any manual fixups. It's also telling you that none
of this has _any_ impact what-so-ever from a "git semantics" angle, and
that this is nothing but a note for anybody who starts digging into it.
So now I've shown _two_ examples of some kind of header that I think
actually makes sense, and that I would not argue against on those grounds.
Especially the "note" thing I think is fine. So why, oh why, do I hate the
"link" thing so much?
- Case 3: the
link <sha1> merge-base
thing is a horrible and nasty thing that we should never ever support.
Why? Because it's literally designed to both have some semantic meaning
("git will fetch the <sha1> and use it for connectivity analysis")
_and_ at the same time the whole syntax it's designed to _not_ have any
real meaning ("you can have any kind of link, and I don't know what
it actually means from a conceptual standpoint").
So it has a meaning from an _implementation_ angle, but at the same
time it does not have a "higher cause". That is EVIL. When they say
"The road to hell is paved with good intentions", the implication there
is not that good intentions is bad per se, but that you should
understand that there are "Unintended Consequences".
And if you cannot limit the thing to a very _specific_ higher-level
meaning, you by definition will have those "unintended consequences".
In short, the difference between three headers that on the face of it say
exactly the same thing: "merge-base <sha1>", "note merge-base <sha1>", and
"link merge-base <sha1>" is not that they have different syntax (hey, even
the syntax itself is almost identical), but exactly the fact that they
have different implications and _meaning_.
Two of the three have no unintended consequences. One ("note") has no
technical "consequences" at _all_, by definition. The other "merge-base"
has no technical "unintended" at all, because it's throught through, and
has been fully defined.
The third? "unintended consequences". It doesn't have a clear definition
("It's cool. You can use it for any link you want"). So pretty much BY
DESIGN, it's set up so that you don't know what the consequences of it
will be for a project.
And that's why "case 3" it's bad. Even though it looks very much like the
two other ones.
Linus
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Jakub Narebski @ 2006-04-29 18:07 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0604291006270.3701@g5.osdl.org>
Linus Torvalds wrote:
> - Case 1: the
>
> merge-base <sha1>
[...]
> - Case 2: the
>
> note merge-base <sha1>
[...]
> - Case 3: the
>
> link <sha1> merge-base
[...]
> In short, the difference between three headers that on the face of it say
> exactly the same thing: "merge-base <sha1>", "note merge-base <sha1>", and
> "link merge-base <sha1>" is not that they have different syntax (hey, even
> the syntax itself is almost identical), but exactly the fact that they
> have different implications and _meaning_.
>
> Two of the three have no unintended consequences. One ("note") has no
> technical "consequences" at _all_, by definition. The other "merge-base"
> has no technical "unintended" at all, because it's throught through, and
> has been fully defined.
>
> The third? "unintended consequences". It doesn't have a clear definition
> ("It's cool. You can use it for any link you want"). So pretty much BY
> DESIGN, it's set up so that you don't know what the consequences of it
> will be for a project.
>
> And that's why "case 3" it's bad. Even though it looks very much like the
> two other ones.
IF (and that is big if) git commit header will be extended to have some
extra "link" (enforcing connectivity) headers, like proposed "bind" for
subprojects, "prev" for pu-like union branches, "merge-base" for merges,
there would be repeated work on enforcing connectivity. Hence generic
"link" header (formerly "related") proposal. Having fsck report broken
links (or not), having purge removing commits (objects) reachable only via
"link" headers, having pull download commits via "link" headers... have I
forgot anything? It _seems_ that this part is common, and does not depend
on semantics.
But with "links" (connectivity headers) there always would be some other
consequences. For example info/grafts deals for now only with commit
parents, and extending the format could be difficult.
And of course if we want connectivity, this is for some reason, so the
"link" has some other consequences, for example "prev" and "merge-base" for
merging, "bind" for checkout, merge (but differently), etc.
I think that if it is 'helper' information (i.e. information which is
helpful, but we can do without it) and of no real importance to user then
use "note". If it is of importance to user (for example "cherrypick" or
"reverted") and of use to git, then repeat such info in "note" header to
avoid relying on parsing free-form part aka. commit comment. If
connectivity is needed... hmmm...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Jakub Narebski @ 2006-04-29 18:27 UTC (permalink / raw)
To: git
In-Reply-To: <20060429165151.2570.qmail@science.horizon.com>
On Sat, 29 Apr 2006, linux@horizon.com wrote:
>
> Well, the only reason that you need ANY commit in the repository is
> because it's part of history, and comparing it with other versions is
> meaningful. So what trees, not already in the ancestry graph of a
> given commit, are useful to compare to? In particular, useful for some
> automated process; manual comparisons can always be done manually.
>
> Nothing's jumping out at me. Any suggestions?
See below.
Not necessary all those require connectivity.
Most of them are not my ideas.
* "prior" - heads that represent topic branch merges
This is the "pu" branch case, where the head is a merge of several
topic branches that is continually moved forward.
topic branches head
,___. ,___.
| TA1 | | TB1 |
`---' `---' ,__.
^\_____^\____| H1 |
`--'
+ some topic branch changes and a republish:
,___. ,___.
| TA1 | | TB1 |
`---' `---'^ ,__.
|^\_____^\____| H1 |
| | `--'
,_|_. ,_|_. P
| TA2 | | TB2 | |
`---' `---'^ |
^ ^ |
,_|_. | |
| TA3 | | |
`---' | ,__.
^\______\____| H2 |
`--'
key: ^ = parent P = prior
* "bind" - for subprojects
bind links from master project commit to externally managed embedded
third-party project, for example Linux kernel for some mainly userspace
project, or library or engine for some application. Additionally it
provides root dir where to attach subproject.
* "original" for rebase
before rebase:
A---B---C topic
/
/
/
D---E---F---G master
after rebase
------A---B---C
/ ^ ^ ^
/ : : :
/ A'--B'--C' topic
/ /
D---E---F---G master
where ':' denotes "original" link. Note that old branch is not pointed by
any head, and would be pruned without connectivity
* "original" or "cherrypick" for cherry-picking
A--------B---C bugfix
/ ^
/ :
D---E---F---G---B'---H main
* "revert" for reverting commits
--
Jakub Narebski
^ permalink raw reply
* Re: fatal: git-write-tree: not able to write tree
From: Junio C Hamano @ 2006-04-29 18:34 UTC (permalink / raw)
To: colin; +Cc: junkio, git
In-Reply-To: <20060429132324.31638.qmail@science.horizon.com>
colin@horizon.com writes:
> diff --git a/git-am.sh b/git-am.sh
> index eab4aa8..872145b 100755
> --- a/git-am.sh
> +++ b/git-am.sh
> @@ -376,6 +376,13 @@ do
> echo "No changes - did you forget update-index?"
> stop_here $this
> fi
> + unmerged=$(git-ls-files -u)
> + if test -n "$unmerged"
> + then
> + echo "You still have unmerged paths in your index"
> + echo "did you forget update-index?"
> + stop_here $this
> + fi
> apply_status=0
> ;;
> esac
>
> Er... it's very non-obvious to me why you'd want to stick a workaround
> here when you could instead fix git-write-tree to do it. That seems
> like The Right Thing.
As I said in an earlier message in the thread, I've considered
it, but that is a very risky thing to do, and write-tree is
definitely a wrong place to do it. If we wanted to, the right
way would be to update-index using the output of "ls-files -u".
However, it would invite the user to mistakenly say --resolved
before resolving all paths.
> (It would also be helpful to mention at least one unmerged file by name.)
That is true.
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Junio C Hamano @ 2006-04-29 19:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e309vq$m2r$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> IF (and that is big if) git commit header will be extended to have some
> extra "link" (enforcing connectivity) headers, like proposed "bind" for
> subprojects, "prev" for pu-like union branches, "merge-base" for merges,
> there would be repeated work on enforcing connectivity. Hence generic
> "link" header (formerly "related") proposal.
The "link <sha1> <type> <meta>" header extension was done
primarily for that reason this way. I carried it in my "pu"
branch for a few days but Linus convinced me privately that it
was a bad idea, so it is not merged in "pu" anymore. Just to
make it easy for people to view what we are discussing, I pushed
the branch head to jc/bind-2 topic branch, but the code will
_not_ be merged.
The code in commit.c to recognize and link the releated objects
pointed by the "link" header to the commit looked like below
(see 11bbee26 commit on that branch):
+ optr = &item->links;
+ while (!memcmp(bufptr, "link ", 5)) {
+ struct object *object;
+
+ if (!get_sha1_hex(bufptr + 5, parent) &&
+ bufptr[45] == ' ' &&
+ (object = lookup_unknown_object(parent)) != NULL) {
+ struct object_list *l = xmalloc(sizeof(*l));
+ l->item = object;
+ l->next = *optr;
+ l->name = NULL;
+ *optr = l;
+ optr = &l->next;
+ n_refs++;
+ bufptr += 45;
+ }
+ else
+ return error("bad link in commit %s",
+ sha1_to_hex(item->object.sha1));
+ while (*bufptr++ != '\n')
+ ; /* skip over subdirectory name */
+ }
But if your are going to introduce "merge-base" and similar
headers that have impact to connectivity traversal code, you can
easily change the !memcmp(buptr, "link ", 5) with a sequence of
"memcmp(foo) || memcmp(bar) || ...", and use the "l->name" field
to point at the header itself, so that the user of the resulting
commit object can easily tell what kind of link-like header it
is, and enforce further semantics that are specific to each kind
of such header on it. The revision traversal change that was
done in a later commit (7091fd commit) does not have to change.
The code sharing aspect you brought up is a very important
issue. This is revision traversal, which is really the central
part of git and needs deep thought to touch without breaking, so
we would like to avoid risking breaking it by repeatedly
touching it. But that can be done without making the recorded
header something like "link <sha1> <type> <metainfo>" which is
too generic.
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Junio C Hamano @ 2006-04-29 20:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e30b48$ovk$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> * "prior" - heads that represent topic branch merges
This is not any different from usual "parent" at all (but you
have to think about it a bit to realize it).
Before talking about making a new commit object that links to
other related commits, let's first talk about what it means to
update the branch head ($GIT_DIR/refs/heads/<branch>) from
commit A to commit B. Understanding what it means is more
fundamental.
A git "branch" points at the tip of one possible history of a
development. As the often-used word "topic branch" tells you, a
"branch", i.e. that history, has a specific purpose. The
purpose of my "master" branch is to give reasonably stable new
feature set and bugfixes, "next" to give testable ones, and "pu"
to collect remaining bits that are worthy of discussion.
When your branch head points at commit A and you update the head
to point at a different commit B, you are making this statement:
The commit B suits the purpose of the branch better
than the commit A.
Notice there may or may not be ancestry relation between these
two commits at this point of the discussion. B may be a direct
child of commit A, a merge that has A as its first parent, a
merge that has A as its one of its parent (but not necessarily
the first), or a Nth-generation descendant if the update was a
fast forward merge from another branch. It might even be an
ancestor if the update rewinds the history.
Among the above cases (and there may be others), in only two
cases you actually create a new commit to record that
statement [*1*].
The simplest case is when commit B is a direct, single-parent
child of commit A, and that statement is in your commit log
message. "I started out from the commit A, and the result is
this tree. The result suits what I am doing better than the
previous commit and I made the world a better place." -- the "I
started out from the commit A" part is on the parent header and
the rest is in the free-text.
When you are creating a merge of N parents, the principle is the
same. Although in pure core-git terms all parents are equal, in
practice, the first parent has somewhat special meaning to you.
When the parents of commit B are A and X, you started out from
the commit A. Then what are other parents? You can read such a
commit this way:
I started out from commit A and came up with this tree,
which suits my purpose better. While doing so, I have
also considered what X has; and this result, commit B,
suits my purpose better than X, too.
This is why a later merge with another branch that further
builds on top of X works so well.
----A----B
/
----X----Y
If somebody built Y on X independently from us, when we merge
with Y, we say the merge base is X because B says "I've already
considered what X has" to do a 3-way merge. While that is what
happens at the mechanical level, what is happening at the
philosophical level is we are taking "I consider that B is
better than X", part of the message seriously, which means "I
want to keep changes I made between X B". Also the other person
who made Y made a similar statement that she considers Y is
better than X, and we try to preserve the changes between X and
Y in the automated part of the merge while preparing the tree to
commit the merge between B and Y.
Once you start reading the commit parent to mean " considering
what all of these commits have, what this new commit has suits
my purpose better", it becomes clear that the "previous" pointer
for a branch like my "pu" is just another "parent".
I rebuild "pu" from the tip of then-current "next", and merge
other topics in, and discard the previous "pu". So it results
in this kind of graph:
o---o---o---o---o (updated "pu")
/ / / /
---o---o---o---o
\ \ \ \ \
o---------------o---o---o---o (previous "pu")
But theoretically, I could include the previous "pu" tip as one
of the parents of the updated "pu" branch.
At the mechanical level, I start from then-current "next" and
merge each topic branch one-by-one on top of it. But at the
philosophical level, what I am doing is to publish material that
shows a set of proposed changes that are more appropriate for
review by the curious than the previous round of "pu" head used
to have. So the previous "pu" _is_ in the consideration while I
publish the updated "pu", although it is _not_ recorded anywhere.
After I come up with a fully merged tree, I could make a fake
Octopus that has the previous "pu" as its first parent and each
of the topic branch heads merged as second and subsequent
parents, with the resulting tree. That would be more "honest"
at the philosophical level.
I am not going to actually suggest anybody doing this as a good
practice, but we can make such a commit with the current tool
like this:
git checkout pu
git tag -f prev-pu ;# remember where we were
git reset --hard next ;# start at next
git pull . topic-1 ;# merge all remaining topics
git pull . topic-2 ;# ...
git pull . topic-3
...
git tag -f next-pu ;# this tree is what we want
git reset --hard prev-pu ;# start from previous
git pull --no-commit -s ours . next topic-1 topic-2 ...
git read-tree -m -u next-pu ;# record a merge whose first
git commit ;# parent is previous pu and
;# has all the topics merged.
[Footnote]
*1* IOW, we _are_ losing some information by not recording the
fact that fast-forward was done while doing so.
That record should _not_ be in the commit chain. At the
mechanical level, recording that in the commit chain means two
criss-crossing branches never converge at the commit chain
level, which is already bad. At the philosophical level, the
commit chain is a mesh of many possible "global" histories, and
the record that somebody (a particular branch in a particular
repository) was at what point in the mesh at given time does not
belong there.
But from the repository-owner's point of view, that _might_ be a
useful information to keep. I am just saying this preemptively
so that if somebody wants to record it, that should not be
recorded in the commit object.
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Jakub Narebski @ 2006-04-29 20:58 UTC (permalink / raw)
To: git
In-Reply-To: <7viros1585.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> * "prior" - heads that represent topic branch merges
>
> This is not any different from usual "parent" at all (but you
> have to think about it a bit to realize it).
[cut]
Thanks for an explanation.
I would say that "prior" is not THAT different from usual "parent",
rather than it is not ANY different.
My doubts about recording previous head of a "union" (pu-like) branch
is that for merge (e.g. 'pu' to 'next', cherrypick to/from 'pu', 'pu'
rebase) is that for merge algorithm all parents are equivalent, with
eventual exception of first which can be treated special ('ours').
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Two gitweb feature requests
From: David Woodhouse @ 2006-04-29 21:38 UTC (permalink / raw)
To: Ben Clifford; +Cc: Kay Sievers, git
In-Reply-To: <Pine.LNX.4.64.0604272250420.4963@mundungus.clifford.ac>
On Thu, 2006-04-27 at 22:54 +0000, Ben Clifford wrote:
> HTML has a <link> element which can be used to indicate alternate forms of
> a page. Gitweb already generates one already to point people at the RSS
> feeds.
>
> Kinda messy to make all the git tools learn how to read HTML, though...
They wouldn't necessarily need to. git-clone and git-pull attempt to use
URLs which wouldn't be used in normal gitweb usage -- for example, any
attempt to fetch http://git.infradead.org/?p=mtd-2.6.git/HEAD or
http://git.infradead.org/?p=mtd-2.6.git/refs/heads can be assumed to be
an attempt to clone or pull with git. So gitweb could be modified to
detect those URLs and give a simple textual redirect which the git tools
could understand.
--
dwmw2
^ permalink raw reply
* Re: cg-clone not fetching all tags?
From: Johannes Sixt @ 2006-04-29 21:42 UTC (permalink / raw)
To: git
In-Reply-To: <20060429170542.GJ27689@pasky.or.cz>
On Saturday 29 April 2006 19:05, Petr Baudis wrote:
> Hi,
>
> Dear diary, on Sat, Apr 29, 2006 at 04:00:42PM CEST, I got a letter
> where Wolfgang Denk <wd@denx.de> said that...
>
> > it seems that "cg-clone" does not fetch all tags any more - only the
> > most recent ones (modiufied in the last N days?) seem to be fetched?
> > [Eventually the "N days" might correspond to "changing tools to
> > version X", but I have no way to find out.]
> >
> > This happens only when using HTTP; using ssh or rsync works fine.
> > Also, if we follow the "cg-clone" by a "git-fetch -t" command, this
> > will load the missing tags.
> >
> > Is this intentional, or am I doing anything wrong?
> >
> > [For testing, try "cg-clone http://www.denx.de/git/u-boot.git"]
>
> you need to run git-update-server-info every time you add or update a
> tag (or best every time you push). See the NOTES section of
> cg-admin-setuprepo documentation for details on how to set it up to be
> called automagically at every push.
There are two types of tags: They can point to
1. a commit object
2. a proper tag object (which in turn references the commit)
git-update-server-info seems to generate info only for case 2, and so are the
only ones that http can fetch.
-- Hannes
^ permalink raw reply
* [PATCH] cg-admin-rewritehist: Seed the commit map with the parents specified with -r.
From: Johannes Sixt @ 2006-04-29 21:45 UTC (permalink / raw)
When the first commit is manufactured, its parents are looked up in the
commit map. However, without this patch the map is always empty at that time.
If the entire history is rewritten, this is no problem because the first
commit does not have any parents anyway. However, if -r is used to constrain
rewriting to only part of the history, this first commit is manufactured
incorrectly without parents because 'cat' fails.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
cg-admin-rewritehist | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
977fc81815877a1e72040355b221fe8d62593eb7
diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
index 9fa4c2a..7dd83cf 100755
--- a/cg-admin-rewritehist
+++ b/cg-admin-rewritehist
@@ -141,6 +141,7 @@ _git_requires_root=1
tempdir=.git-rewrite
startrev=
+startrevparents=
filter_env=
filter_tree=
filter_index=
@@ -152,6 +153,7 @@ while optparse; do
tempdir="$OPTARG"
elif optparse -r=; then
startrev="^$OPTARG^ $OPTARG $startrev"
+ startrevparents="$OPTARG^ $startrevparents"
elif optparse --env-filter=; then
filter_env="$OPTARG"
elif optparse --tree-filter=; then
@@ -186,6 +188,12 @@ ret=0
mkdir ../map # map old->new commit ids for rewriting parents
+# seed with identity mappings for the parents where we start off
+for commit in $startrevparents; do
+ commit="$(git-rev-parse $commit)"
+ echo $commit > ../map/$commit
+done
+
git-rev-list --topo-order HEAD $startrev | tac >../revs
commits=$(cat ../revs | wc -l)
--
1.3.1.gaa6b
^ permalink raw reply related
* [PATCH] cg-admin-rewritehist: fix reappearing files with --filter-tree.
From: Johannes Sixt @ 2006-04-29 21:45 UTC (permalink / raw)
With --filter-tree a working copy is checked out for each commit.
However, if a file is removed by a commit, the file is _not_ removed
from the working copy by git-checkout-index. This must be done explicitly,
otherwise the file becomes added back again.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
cg-admin-rewritehist | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
26bb71a2d3d583d9eee10f4e950ff1b7d400e975
diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
index 7dd83cf..13ffb5d 100755
--- a/cg-admin-rewritehist
+++ b/cg-admin-rewritehist
@@ -213,10 +213,13 @@ while read commit; do
if [ "$filter_tree" ]; then
git-checkout-index -f -u -a
+ # files that $commit removed are now still in the working tree;
+ # remove them, else they would be added again
+ git-ls-files -z --others | xargs -0 rm -f
eval "$filter_tree"
git-diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \
xargs -0 git-update-index --add --replace --remove
- git-ls-files --others | tr '\n' '\0' | \
+ git-ls-files -z --others | \
xargs -0 git-update-index --add --replace --remove
fi
--
1.3.1.gaa6b
^ 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