* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-26 16:21 UTC (permalink / raw)
To: Vincent Ladeuil; +Cc: bazaar-ng, git
In-Reply-To: <87k62n5ahp.fsf@alplog.fr>
On Thu, 26 Oct 2006, Vincent Ladeuil wrote:
> >>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
>
> Linus> Commits are defined by a _combination_ of:
>
> Linus> - the tree they commit (which is recursive, so the
> Linus> commit name indirectly includes information EVERY
> Linus> SINGLE BIT in the whole tree, in every single file)
>
> And here you keep that separate from any SCM related info,
> right ?
I don't understand that question.
The commits contain the tree information. A raw commit in git (this is the
true contents of the current top commit in my kernel tree, just added
indentation and an empty line between the command I used to generate it
and the output, to make it stand out better in the email) looks something
like this:
[torvalds@g5 linux]$ git-cat-file commit HEAD
tree ba1ed8c744654ca91ee2b71b7cdee149c8edbef1
parent 2a4f739dfc59edd52eaa37d63af1bd830ea42318
parent 012d64ff68f304df1c35ce5902f5023dc14b643f
author Linus Torvalds <torvalds@g5.osdl.org> 1161873881 -0700
committer Linus Torvalds <torvalds@g5.osdl.org> 1161873881 -0700
Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SPARC64]: Fix memory corruption in pci_4u_free_consistent().
[SPARC64]: Fix central/FHC bus handling on Ex000 systems.
where the _name_ of the commit is
[torvalds@g5 linux]$ git-rev-parse HEAD
e80391500078b524083ba51c3df01bbaaecc94bb
ie the commit itself contains the exact tree name (and the name of the
parents), and the name of the commit is literally the SHA1 of the contents
of the commit (plus a git-specific header).
> >> Trees are defined by their content only ?
>
> Linus> Where "contents" does include names and
> Linus> permissions/types (eg execute bit and symlink etc).
>
> Which can also be expressed as: "Everything the user can
> manipulate outside the SCM context", right ?
Again, I'm not sure what you mean by that. The SCM does not track
_everything_. It does not track user names and inode numbers, so in a
sense a developer can change things that the SCM simply doesn't _care_
about and never tracks. But yes, the tree contents uniquely identify the
exact contents that the user cares about.
> Linus> If you compare the commit name, and they are equal,
> Linus> you automatically know
>
> Linus> - the trees are 100% identical
> Linus> - the histories are 100% identical
>
> And that's the only info you can get, no ordering here.
No, there is ordering there too. But yes, the ordering is not in the name
itself, you have to go look at the actual commit history to see it.
The name is just an identifier.
> Linus> If you only care about the actual tree, you compare
> Linus> the tree name for equality, ie you can do
>
> Linus> git-rev-parse commit1^{tree} commit2^{tree}
>
> Linus> and compare the two: if and only if they are equal are
> Linus> the actual contents 100% equal.
>
> Actually, that's backwards:
>
> "their actual contents are equal" implies "their signatures are
> equal".
No.
If the signatures are equal, the contents are equal, and vice versa. It
really is a two-way thing.
> But, two totally different trees can have the same signature.
No. Don't even think that way. That just confuses you. The hash is
cryptographic, and large enough, that you really can equate the contents
with the hash. Anything else is just not even interesting.
^ permalink raw reply
* Re: VCS comparison table
From: David Lang @ 2006-10-26 16:30 UTC (permalink / raw)
To: Andreas Ericsson
Cc: David Rientjes, Jeff King, Linus Torvalds, Lachlan Patrick,
bazaar-ng, git
In-Reply-To: <454098EC.8040406@op5.se>
On Thu, 26 Oct 2006, Andreas Ericsson wrote:
>>
>> There are _not_ scalability improvements. There may be some slight
>> performance improvements, but definitely not scalability. If you have ever
>> tried to use git to manage terabytes of data, you will see this becomes
>> very clear. And "rebasing with 3-way merge" is not something often used in
>> industry anyway if you've followed the more common models for revision
>> control within large companies with thousands of engineers. Typically they
>> all work off mainline.
>>
>
> Actually, I don't see why git shouldn't be perfectly capable of handling a
> repo containing several terabytes of data, provided you don't expect it to
> turn up the full history for the project in a couple of seconds and you don't
> actually *change* that amount of data in each revision. If you want a vcs
> that handles that amount with any kind of speed, I think you'll find rsync
> and raw rvs a suitable solution.
actually, there are some real problems in this area. the git pack format can't
be larger then 4G, and I wouldn't be surprised if there were other issues with
files larger then 4G (these all boil down to 32 bit limits). once these limits
are dealt with then you will be right.
^ permalink raw reply
* Re: StGIT and rerere
From: Catalin Marinas @ 2006-10-26 16:34 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200610210039.10215.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> It seems stgit does not use git-rerere, so why not? Any reason other
> than it hasn't been done yet?
I didn't know it exists. I've been thinking at a way to avoid
duplicating the conflict fixing but haven't got to any results. This
looks like a good idea.
> I abuse stgit heavily, by frequently reording patches, which for
> some patches result in re-occuring conflicts. git-rerere seems to be
> the solution.
My problem was with maintaining a public branch where re-basing
patches is not welcomed but I would still like to use StGIT in my
development branch. When pulling from upstream in my devel branch, I
get conflicts in some patches. The problem is that I get the same
conflicts in the patches already merged in the public branch where the
patches were previously checked in.
Another case is several branches with common patches that generate
conflicts.
> What's the "rules" for when to invoke rerere? It seems it is mostly
> automatic in git, but since only the porcelainish commands use it,
> that means StGIT doesn't.
It could probably be invoked by stgit.git.merge() if the git-read-tree
(and maybe the diff3 merge) failed (BTW, I replaced git-read-tree with
git-recursive-merge in my local tree and seems to detect renames
properly; I'll push it once I'm convinced there are no problems).
Note, however, that I haven't looked at how git-rerere works and I
might have misunderstood its functionality.
> So here is what I *think* needs to be done. Seems simple enough.
>
> stg push, stg pick, stg import, stg goto, stg fold, stg float do
> what push does and invoke git-rerere at the end whether the push
> ends with conflicts or not
the git.merge() function handles all the merges.
> stg pop
> nothing, or do I need to remove rr-cache/MERGE_RR, like
> git-reset does?
I think pop shouldn't do anything.
> stg status --reset, stg push --undo
> remove rr-cache/MERGE_RR ?
Yes (not sure for push --undo).
> stg refresh
> do what stgit does normally and then invoke git-rerere
Why should it invoke git-rerere? This just creates a commit. Or is it
needed for storing rerere ids?
> stg resolved:
> do what stgit does normally and then invoke git-rerere
No need to call rerere here since resolved is an StGIT-only function,
it doesn't affect the repository (it just unmarks the conflict files
so that stgit allows you to refresh).
> stg clean, stge delete:
> remove rr-cache/MERGE_RR ?
That's not needed. Delete can act like pop for the top patch.
--
^ permalink raw reply
* [PATCH (amend)] gitweb: Slight visual improvements to commitdiff view
From: Jakub Narebski @ 2006-10-26 16:43 UTC (permalink / raw)
To: git
In-Reply-To: <200610261813.12567.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This amend fixes regression which caused signoff lines
to be not highlighted as such.
gitweb/gitweb.css | 16 ++++++++++++++--
gitweb/gitweb.perl | 18 ++++++++++--------
2 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 0eda982..83d900d 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -100,7 +100,7 @@ span.age {
font-style: italic;
}
-div.page_body span.signoff {
+span.signoff {
color: #888888;
}
@@ -114,7 +114,7 @@ div.log_link {
width: 136px;
}
-div.list_head {
+div.diff_tree_head {
padding: 6px 8px 4px;
border: solid #d9d8d1;
border-width: 1px 0px 0px;
@@ -128,6 +128,18 @@ div.author_date {
font-style: italic;
}
+div.commitdiff_log {
+ padding: 8px;
+ border: solid #d9d8d1;
+ border-width: 0px 0px 1px 0px;
+}
+
+div.patchset {
+ padding-top: 8px;
+ border: solid #d9d8d1;
+ border-width: 1px 0px 0px 0px;
+}
+
a.list {
text-decoration: none;
color: #000000;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0d2ea72..044a47d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1844,11 +1844,11 @@ sub git_print_tree_entry {
sub git_difftree_body {
my ($difftree, $hash, $parent) = @_;
- print "<div class=\"list_head\">\n";
if ($#{$difftree} > 10) {
+ print "<div class=\"list_head\">\n";
print(($#{$difftree} + 1) . " files changed:\n");
+ print "</div>\n";
}
- print "</div>\n";
print "<table class=\"diff_tree\">\n";
my $alternate = 1;
@@ -2053,9 +2053,9 @@ sub git_patchset_body {
}
$patch_idx++;
- # for now, no extended header, hence we skip empty patches
- # companion to next LINE if $in_header;
- if ($diffinfo->{'from_id'} eq $diffinfo->{'to_id'}) { # no change
+ # for now we skip empty patches
+ if ($diffinfo->{'from_id'} eq $diffinfo->{'to_id'}) {
+ # no change, empty patch
$in_header = 1;
next LINE;
}
@@ -3486,13 +3486,15 @@ sub git_commitdiff {
git_print_page_nav('commitdiff','', $hash,$co{'tree'},$hash, $formats_nav);
git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash);
git_print_authorship(\%co);
- print "<div class=\"page_body\">\n";
+
if (@{$co{'comment'}} > 1) {
- print "<div class=\"log\">\n";
+ print "<div class=\"commitdiff_log\">\n";
git_print_log($co{'comment'}, -final_empty_line=> 1, -remove_title => 1);
- print "</div>\n"; # class="log"
+ print "</div>\n"; # class="commitdiff_log"
}
+ print "<div class=\"page_body\">\n";
+
} elsif ($format eq 'plain') {
my $refs = git_get_references("tags");
my $tagname = git_get_rev_name_tags($hash);
--
1.4.3.3
^ permalink raw reply related
* Rationale for the "Never commit to the right side of a Pull line" rule
From: Jerome Lovy @ 2006-10-26 16:47 UTC (permalink / raw)
To: git
Hi,
Could someone please point me to / give me the rationale for the "Never
commit to the right side of a Pull line" rule ?
I found the rule in the second Note of the git-fetch man-page (eg
http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html).
It's been taken over in _bold letters_ by X.Org/freedesktop.org in their
"UsingGit" document (http://freedesktop.org/wiki/UsingGit).
In both places though, I don't see any explanation, but rather a
commandment ;-) . Am I missing the ovious ?
My candid thoughts: to me the practice recommended here seems
subjectively "cleaner" indeed, but is it objectively better or even
essential? Why?
TIA
Jérôme
^ permalink raw reply
* [PATCH] Make git-cherry handle root trees
From: Rene Scharfe @ 2006-10-26 16:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
This patch on top of 'next' makes built-in git-cherry handle root
commits.
It moves the static function log-tree.c::diff_root_tree() to
tree-diff.c and makes it more similar to diff_tree_sha1() by
shuffling around arguments and factoring out the call to
log_tree_diff_flush(). Consequently the name is changed to
diff_root_tree_sha1(). It is a version of diff_tree_sha1() that
compares the empty tree (= root tree) against a single 'real' tree.
This function is then used in get_patch_id() to compute patch IDs
for initial commits instead of SEGFAULTing, as the current code
does if confronted with parentless commits.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Example for testing: 'git-cherry v0.99.1 v0.99.2' in the git repo
hits root trees.
builtin-log.c | 7 +++++--
diff.h | 2 ++
log-tree.c | 26 ++++----------------------
tree-diff.c | 18 ++++++++++++++++++
4 files changed, 29 insertions(+), 24 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index fc5e476..fedb013 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -171,8 +171,11 @@ static void reopen_stdout(struct commit
static int get_patch_id(struct commit *commit, struct diff_options *options,
unsigned char *sha1)
{
- diff_tree_sha1(commit->parents->item->object.sha1, commit->object.sha1,
- "", options);
+ if (commit->parents)
+ diff_tree_sha1(commit->parents->item->object.sha1,
+ commit->object.sha1, "", options);
+ else
+ diff_root_tree_sha1(commit->object.sha1, "", options);
diffcore_std(options);
return diff_flush_patch_id(options, sha1);
}
diff --git a/diff.h b/diff.h
index ce3058e..ac7b21c 100644
--- a/diff.h
+++ b/diff.h
@@ -102,6 +102,8 @@ extern int diff_tree(struct tree_desc *t
const char *base, struct diff_options *opt);
extern int diff_tree_sha1(const unsigned char *old, const unsigned char *new,
const char *base, struct diff_options *opt);
+extern int diff_root_tree_sha1(const unsigned char *new, const char *base,
+ struct diff_options *opt);
struct combine_diff_path {
struct combine_diff_path *next;
diff --git a/log-tree.c b/log-tree.c
index fbe1399..8787df5 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -252,26 +252,6 @@ int log_tree_diff_flush(struct rev_info
return 1;
}
-static int diff_root_tree(struct rev_info *opt,
- const unsigned char *new, const char *base)
-{
- int retval;
- void *tree;
- struct tree_desc empty, real;
-
- tree = read_object_with_reference(new, tree_type, &real.size, NULL);
- if (!tree)
- die("unable to read root tree (%s)", sha1_to_hex(new));
- real.buf = tree;
-
- empty.buf = "";
- empty.size = 0;
- retval = diff_tree(&empty, &real, base, &opt->diffopt);
- free(tree);
- log_tree_diff_flush(opt);
- return retval;
-}
-
static int do_diff_combined(struct rev_info *opt, struct commit *commit)
{
unsigned const char *sha1 = commit->object.sha1;
@@ -297,8 +277,10 @@ static int log_tree_diff(struct rev_info
/* Root commit? */
parents = commit->parents;
if (!parents) {
- if (opt->show_root_diff)
- diff_root_tree(opt, sha1, "");
+ if (opt->show_root_diff) {
+ diff_root_tree_sha1(sha1, "", &opt->diffopt);
+ log_tree_diff_flush(opt);
+ }
return !opt->loginfo;
}
diff --git a/tree-diff.c b/tree-diff.c
index 7e2f4f0..37d235e 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -215,6 +215,24 @@ int diff_tree_sha1(const unsigned char *
return retval;
}
+int diff_root_tree_sha1(const unsigned char *new, const char *base, struct diff_options *opt)
+{
+ int retval;
+ void *tree;
+ struct tree_desc empty, real;
+
+ tree = read_object_with_reference(new, tree_type, &real.size, NULL);
+ if (!tree)
+ die("unable to read root tree (%s)", sha1_to_hex(new));
+ real.buf = tree;
+
+ empty.size = 0;
+ empty.buf = "";
+ retval = diff_tree(&empty, &real, base, opt);
+ free(tree);
+ return retval;
+}
+
static int count_paths(const char **paths)
{
^ permalink raw reply related
* Re: VCS comparison table
From: Nicolas Pitre @ 2006-10-26 17:03 UTC (permalink / raw)
To: David Lang
Cc: Andreas Ericsson, David Rientjes, Jeff King, Linus Torvalds,
Lachlan Patrick, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0610260929040.2424@qynat.qvtvafvgr.pbz>
On Thu, 26 Oct 2006, David Lang wrote:
> On Thu, 26 Oct 2006, Andreas Ericsson wrote:
>
> > >
> > > There are _not_ scalability improvements. There may be some slight
> > > performance improvements, but definitely not scalability. If you have
> > > ever tried to use git to manage terabytes of data, you will see this
> > > becomes very clear. And "rebasing with 3-way merge" is not something
> > > often used in industry anyway if you've followed the more common models
> > > for revision control within large companies with thousands of engineers.
> > > Typically they all work off mainline.
> > >
> >
> > Actually, I don't see why git shouldn't be perfectly capable of handling a
> > repo containing several terabytes of data, provided you don't expect it to
> > turn up the full history for the project in a couple of seconds and you
> > don't actually *change* that amount of data in each revision. If you want a
> > vcs that handles that amount with any kind of speed, I think you'll find
> > rsync and raw rvs a suitable solution.
>
> actually, there are some real problems in this area. the git pack format can't
> be larger then 4G, and I wouldn't be surprised if there were other issues with
> files larger then 4G (these all boil down to 32 bit limits). once these limits
> are dealt with then you will be right.
There is no such limit on the pack format. A pack itself can be as
large as you want. The 4G limit is in the tool not the format.
The actual pack limits are as follows:
- a pack can have infinite size
- a pack cannot have more than 4294967296 objects
- each non-delta objects can be of infinite size
- delta objects can be of infinite size themselves but...
- current delta encoding can use base objects no larger than 4G
The _code_ is currently limited to 4G though, especially on 32-bit
architectures. The delta issue could be resolved in a backward
compatible way but it hasn't been formalized yet.
The pack index is actually limited to 32-bits meaning it can cope with
packs no larger than 4G. But the pack index is a local matter and not
part of the protocol so this is not a big issue to define a new index
format and automatically convert existing indexes at that point.
^ permalink raw reply
* Re: VCS comparison table
From: David Lang @ 2006-10-26 17:04 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Andreas Ericsson, David Rientjes, Jeff King, Linus Torvalds,
Lachlan Patrick, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0610261247420.12418@xanadu.home>
On Thu, 26 Oct 2006, Nicolas Pitre wrote:
> On Thu, 26 Oct 2006, David Lang wrote:
>
>> On Thu, 26 Oct 2006, Andreas Ericsson wrote:
>>
>>>>
>>>> There are _not_ scalability improvements. There may be some slight
>>>> performance improvements, but definitely not scalability. If you have
>>>> ever tried to use git to manage terabytes of data, you will see this
>>>> becomes very clear. And "rebasing with 3-way merge" is not something
>>>> often used in industry anyway if you've followed the more common models
>>>> for revision control within large companies with thousands of engineers.
>>>> Typically they all work off mainline.
>>>>
>>>
>>> Actually, I don't see why git shouldn't be perfectly capable of handling a
>>> repo containing several terabytes of data, provided you don't expect it to
>>> turn up the full history for the project in a couple of seconds and you
>>> don't actually *change* that amount of data in each revision. If you want a
>>> vcs that handles that amount with any kind of speed, I think you'll find
>>> rsync and raw rvs a suitable solution.
>>
>> actually, there are some real problems in this area. the git pack format can't
>> be larger then 4G, and I wouldn't be surprised if there were other issues with
>> files larger then 4G (these all boil down to 32 bit limits). once these limits
>> are dealt with then you will be right.
>
> There is no such limit on the pack format. A pack itself can be as
> large as you want. The 4G limit is in the tool not the format.
>
> The actual pack limits are as follows:
>
> - a pack can have infinite size
>
> - a pack cannot have more than 4294967296 objects
>
> - each non-delta objects can be of infinite size
>
> - delta objects can be of infinite size themselves but...
>
> - current delta encoding can use base objects no larger than 4G
>
> The _code_ is currently limited to 4G though, especially on 32-bit
> architectures. The delta issue could be resolved in a backward
> compatible way but it hasn't been formalized yet.
>
> The pack index is actually limited to 32-bits meaning it can cope with
> packs no larger than 4G. But the pack index is a local matter and not
> part of the protocol so this is not a big issue to define a new index
> format and automatically convert existing indexes at that point.
the offset within a pack for the starting location of an object cannot be larger
then 4G.
^ permalink raw reply
* Re: Rationale for the "Never commit to the right side of a Pull line" rule
From: Linus Torvalds @ 2006-10-26 17:11 UTC (permalink / raw)
To: Jerome Lovy; +Cc: git
In-Reply-To: <ehqp1u$j4$1@sea.gmane.org>
On Thu, 26 Oct 2006, Jerome Lovy wrote:
>
> Could someone please point me to / give me the rationale for the "Never commit
> to the right side of a Pull line" rule ?
It's not a technical rule per se.
It's just a way to avoid what will almost inevitably otherwise be a
horribly horribly confusing situation.
I say "almost inevitably", because if you really have worked with git
enough, and understand how it works on a very fundamental level, there are
actually no problems at all with doing so, and maybe you could have
perfectly fine reasons to break the rule, and commit to a branch that is
officially "maintained in another repository" and then push it out.
But it's a good rule in general, just because it makes a certain common
workflow explicit. In fact, we really probably should start to always use
the "refs/remote/origin/HEAD" kind of syntax by default, where you can't
even _switch_ to the branch maintained in the remote repository, because
it's not a real branch locally.
So normally you should consider the "origin" branch to be a pointer to
WHAT YOU FETCHED LAST - and that implies that you shouldn't commit to it,
because then it loses that meaning (now it's "what you fetched last and
then committed your own work on top of", which is something totally
different).
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-26 17:16 UTC (permalink / raw)
To: David Lang
Cc: Nicolas Pitre, Andreas Ericsson, David Rientjes, Jeff King,
Lachlan Patrick, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0610261003290.2424@qynat.qvtvafvgr.pbz>
On Thu, 26 Oct 2006, David Lang wrote:
>
> the offset within a pack for the starting location of an object cannot be
> larger then 4G.
Well, strictly speaking, even that isn't actually a limit on the _pack_
format itself. It's really just the (totally separate) index that
currently uses 32-bit offsets.
For example, you can actually use the pack-file to transfer more than 4GB
of data over the network. You'd not need to change the format at all. Only
the local _index_ of the result needs to change - but we never transfer
that at all (it's always generated locally), so that's really a separate
issue.
It's not even hard to fix. It's just that right now, the biggest
repository that we know about (mozilla) is not even close to the limit.
And it took them ten years to get there. So if the mozilla people switch
to git, and keep going at the same rate, we have about 70 years left
before we need to fix the indexing ;)
(Of course, other projects, like the kernel, seem to grow faster, so it
might be "only" a decade or two - but since the index format is a local
thing, even that won't be too painful, since we don't really need a global
flag-day once we decide to start supporting larger offsets in the index)
^ permalink raw reply
* Re: [PATCH] gitweb: Check git base URLs before generating URL from it
From: Junio C Hamano @ 2006-10-26 17:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610261226.44960.jnareb@gmail.com>
Wouldn't this be simpler and more to the point, I wonder?
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5a81b8f..aceaeb7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -80,7 +80,7 @@ our $strict_export = "++GITWEB_STRICT_EX
# list of git base URLs used for URL to where fetch project from,
# i.e. full URL is "$git_base_url/$project"
-our @git_base_url_list = ("++GITWEB_BASE_URL++");
+our @git_base_url_list = grep { $_ ne '' } ("++GITWEB_BASE_URL++");
# default blob_plain mimetype and default charset for text/plain blob
our $default_blob_plain_mimetype = 'text/plain';
^ permalink raw reply related
* Re: StGIT and rerere
From: Junio C Hamano @ 2006-10-26 17:21 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnxu01r2fzv.fsf@arm.com>
Catalin Marinas <catalin.marinas@arm.com> writes:
> I didn't know it exists. I've been thinking at a way to avoid
> duplicating the conflict fixing but haven't got to any results. This
> looks like a good idea.
> ...
> My problem was with maintaining a public branch where re-basing
> patches is not welcomed but I would still like to use StGIT in my
> development branch. When pulling from upstream in my devel branch, I
> get conflicts in some patches. The problem is that I get the same
> conflicts in the patches already merged in the public branch where the
> patches were previously checked in.
>
> Another case is several branches with common patches that generate
> conflicts.
> ...
> Note, however, that I haven't looked at how git-rerere works and I
> might have misunderstood its functionality.
I think Documentation/git-rerere.txt describes its operation in
enough details for the end user, but if there is anything
unclear please ask away.
There are two details that are not mentoined in the end-user
documentation.
* Identifying "same" conflicts.
This is done by hashing the text inside the conflict markers:
<<<<<<<
a
=======
b
>>>>>>>
Each conflicted section like the above are first canonicalized
so that section "a" sorts alphabetically earlier than section
"b" (in other words, if the conflict were <<< b === a >>> then
they are swapped to read <<< a === b >>>), concatenated and fed
into SHA-1 digest. The final digest after conflicted file is
read as a whole becomes the name of the conflict, and naming is
done per file.
The reason for this canonicalization is because the order in the
conflicted section depends on the direction of the merge (if
you pull test into master you get the conflict marked the other
way from the case you pulled master into test).
* rerere's resolution can affect outside conflict markers.
If an earlier conflict read like this:
...
z
<<<<<<<
a
=======
b
>>>>>>>
c
d
e
f
g
...
and your earlier resolution was like this:
...
w
b
dd
e
f
g
...
That is what rerere records (i.e. including removal of c and
change from z to w).
Then, when you see the same conflict like this (notice that g is
now h):
...
z
<<<<<<<
a
=======
b
>>>>>>>
c
d
e
f
h
...
it is resolved like this:
...
w
b
d
e
f
h
...
This is often useful when e.g. a <<< === >>> section changes
function signature of a (static) function; parts outside the
conflicted section needs matching changes to adjust to it and
that is recorded and replayed by rerere.
^ permalink raw reply
* Re: [PATCH] Improve git-prune -n output
From: Junio C Hamano @ 2006-10-26 17:21 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610261138.24761.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> prune_object() in show_only mode would previously just show the path to the
> object that would be deleted. The path the object is stored in shouldn't be
> shown to users, they only know about sha1 identifiers so show that instead.
I do not have an objection to what this does, except I wonder if
somebody's script relies on parsing this output already.
> Further, the sha1 alone isn't that useful for examining what is going to be
> deleted. This patch also adds the object type to the output, which makes it
> easy to pick out, say, the commits and use git-show to display them.
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
It is customary to have one empty line before the S-o-b: line.
> ---
> builtin-prune.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-prune.c b/builtin-prune.c
> index 7290e6d..e3bcf5f 100644
> --- a/builtin-prune.c
> +++ b/builtin-prune.c
> @@ -16,8 +16,13 @@ static struct rev_info revs;
>
> static int prune_object(char *path, const char *filename, const unsigned char *sha1)
> {
> + char type[20];
> +
> if (show_only) {
> - printf("would prune %s/%s\n", path, filename);
> + if (sha1_object_info(sha1, type, NULL)) {
> + strcpy( type, "unknown type" );
> + }
> + printf("would prune %s %s\n", sha1_to_hex( sha1 ), type );
Style.
- We do not leave blank inside () pairs.
- We do not enclose a single statement in {}.
Perhaps an extra variable of type "char *" that initially point
at type[] but later points at the "unknown" might be more
efficient, but that being on the error path I do not think
saving one strcpy() that way is worth it.
So, just the style and a slight worry that this _might_ break
people's scripts.
Objections?
^ permalink raw reply
* Re: VCS comparison table
From: Nicolas Pitre @ 2006-10-26 17:24 UTC (permalink / raw)
To: David Lang
Cc: Andreas Ericsson, David Rientjes, Jeff King, Linus Torvalds,
Lachlan Patrick, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0610261003290.2424@qynat.qvtvafvgr.pbz>
On Thu, 26 Oct 2006, David Lang wrote:
> On Thu, 26 Oct 2006, Nicolas Pitre wrote:
>
> > The pack index is actually limited to 32-bits meaning it can cope with
> > packs no larger than 4G.
>
> the offset within a pack for the starting location of an object cannot be
> larger then 4G.
To be more exact, yes. But I don't think we'll ever consider use
scenarios with packs > 4G with the current index format. There is
simply no point.
^ permalink raw reply
* Re: Rationale for the "Never commit to the right side of a Pull line" rule
From: Karl Hasselström @ 2006-10-26 17:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jerome Lovy, git
In-Reply-To: <Pine.LNX.4.64.0610261003590.3962@g5.osdl.org>
On 2006-10-26 10:11:50 -0700, Linus Torvalds wrote:
> But it's a good rule in general, just because it makes a certain
> common workflow explicit. In fact, we really probably should start
> to always use the "refs/remote/origin/HEAD" kind of syntax by
> default, where you can't even _switch_ to the branch maintained in
> the remote repository, because it's not a real branch locally.
Seconded. I really like having remote branches in their own namespace
where I can't confuse them with my local branches by mistake -- and
that the branches of different remotes end up in different separate
namespaces.
> So normally you should consider the "origin" branch to be a pointer
> to WHAT YOU FETCHED LAST - and that implies that you shouldn't
> commit to it, because then it loses that meaning (now it's "what you
> fetched last and then committed your own work on top of", which is
> something totally different).
Defaulting to --use-separate-remotes would mean not having to explain
this to every single confused new user. :-)
It feels like the right thing to do, because it reduces the amount of
things a user has to know about git internals. Until you get to the
level where you can do brain surgery on your repo, the remotes/
branches will really _be_ your local read-only mirror of remote
branches, and you don't have to be aware of the possibility that they
could get out of sync because of local commits.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: What's in git.git
From: Andy Whitcroft @ 2006-10-26 17:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk62npipb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I did not hear any comments on the left-right stuff; perhaps
> it is not needed, or it is not useful as its current shape (it
> could be enhanced to say which starting commits each of the
> commit is reachable from, by borrowing much of show-branch
> code).
That was the stuff which kinda did cherry in rev-list. It seemed to
produce interesting output, but nothing I couldn't do with cherry.
Still interesting tho. The sort of thing that if it was in there
someone would find a use for, think lazers.
^ permalink raw reply
* Re: Rationale for the "Never commit to the right side of a Pull line" rule
From: Jakub Narebski @ 2006-10-26 17:30 UTC (permalink / raw)
To: git
In-Reply-To: <ehqp1u$j4$1@sea.gmane.org>
Jerome Lovy wrote:
> Could someone please point me to / give me the rationale for the "Never
> commit to the right side of a Pull line" rule ?
>
> I found the rule in the second Note of the git-fetch man-page (eg
> http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html).
Because git refuses to fetch into branch on top of which there are changes
which are not present in the branch you fetch from (if it is not
fast-forward case). So commitiing to tracking branches breaks the most
typical workflow, i.e. fetch when you want, push when you are ready.
git-clone --use-separate-remotes takes care of that by putting tracking
branches in refs/remotes/, i.e. outside refs/heads/, so you cannot commit
there, at least not by accident.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Improve git-prune -n output
From: Andy Whitcroft @ 2006-10-26 17:33 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610261138.24761.andyparkins@gmail.com>
Andy Parkins wrote:
> prune_object() in show_only mode would previously just show the path to the
> object that would be deleted. The path the object is stored in shouldn't be
> shown to users, they only know about sha1 identifiers so show that instead.
>
> Further, the sha1 alone isn't that useful for examining what is going to be
> deleted. This patch also adds the object type to the output, which makes it
> easy to pick out, say, the commits and use git-show to display them.
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> ---
> builtin-prune.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-prune.c b/builtin-prune.c
> index 7290e6d..e3bcf5f 100644
> --- a/builtin-prune.c
> +++ b/builtin-prune.c
> @@ -16,8 +16,13 @@ static struct rev_info revs;
>
> static int prune_object(char *path, const char *filename, const unsigned char *sha1)
> {
> + char type[20];
> +
> if (show_only) {
> - printf("would prune %s/%s\n", path, filename);
> + if (sha1_object_info(sha1, type, NULL)) {
> + strcpy( type, "unknown type" );
> + }
> + printf("would prune %s %s\n", sha1_to_hex( sha1 ), type );
> return 0;
> }
> unlink(mkpath("%s/%s", path, filename));
If we are changing the format would it not make more sense to be in the
same order as the tool that lets you use it?
I thought that was git cat-file <type> <commit-ish>
^ permalink raw reply
* Re: [PATCH] gitweb: Check git base URLs before generating URL from it
From: Jakub Narebski @ 2006-10-26 17:39 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6wvkn66.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Wouldn't this be simpler and more to the point, I wonder?
> -our @git_base_url_list = ("++GITWEB_BASE_URL++");
> +our @git_base_url_list = grep { $_ ne '' } ("++GITWEB_BASE_URL++");
Yes, that would be cartainly better.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Improve git-prune -n output
From: Andy Parkins @ 2006-10-26 17:37 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vlkn3kn65.fsf@assigned-by-dhcp.cox.net>
On Thursday 2006, October 26 18:21, Junio C Hamano wrote:
> I do not have an objection to what this does, except I wonder if
> somebody's script relies on parsing this output already.
I did think of that, but the existing output looked pretty non-useful for easy
parsing because of the fact that filenames where being printed instead of
hashes. If I were given free reign I think I'd want to drop the "would
prune" message as well.
> It is customary to have one empty line before the S-o-b: line.
I didn't do it. Git did :-) I'll keep an eye out for it from now on.
Apologies (as usual)
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-26 17:45 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <Pine.LNX.4.64.0610261247420.12418@xanadu.home>
Nicolas Pitre wrote:
> On Thu, 26 Oct 2006, David Lang wrote:
>
>> actually, there are some real problems in this area. the git pack format can't
>> be larger then 4G, and I wouldn't be surprised if there were other issues with
>> files larger then 4G (these all boil down to 32 bit limits). once these limits
>> are dealt with then you will be right.
>
> There is no such limit on the pack format. A pack itself can be as
> large as you want. The 4G limit is in the tool not the format.
[...]
> The _code_ is currently limited to 4G though, especially on 32-bit
> architectures. The delta issue could be resolved in a backward
> compatible way but it hasn't been formalized yet.
>
> The pack index is actually limited to 32-bits meaning it can cope with
> packs no larger than 4G. But the pack index is a local matter and not
> part of the protocol so this is not a big issue to define a new index
> format and automatically convert existing indexes at that point.
If I remember correctly those issues are under development:
1. There is work on 64-bit index
2. There is work that would allow to have multiple packs, repack only one
of packs and treat the rest as 'archive packs' (which can be more
aggresively packed). This solution is to split pack into multiple packs.
3. There is work on mmaping only part of pack, which would avoid 4G limit
even on 32-bit machines, if I understand it correctly.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Question about git-for-each-ref format
From: Jakub Narebski @ 2006-10-26 18:12 UTC (permalink / raw)
To: git
What kind of extra substitution besides %(field) and %% -> % gets
git-for-each-ref format? I've checked that %00 -> \0, is it generic or only
this value? It is not documented, I've remembered it from discussion on git
mailing list...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* latest git and git.kernel.org
From: Aneesh Kumar K.V @ 2006-10-26 18:41 UTC (permalink / raw)
To: git
I am getting lot of errors with git.kernel.org in the last few days. Is it something to do with the latest git
client that i am using or due to issues with git.kernel.org ?
-aneesh
^ permalink raw reply
* [PATCH qgit] Remove obsoleted includes
From: Marco Costalba @ 2006-10-26 18:47 UTC (permalink / raw)
To: Git Mailing List
Also small code cleanup
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
Still unable to push to public repo :(
src/listview.cpp | 239 ++++++++++++++++++++++++++----------------------------
src/listview.h | 4 +-
2 files changed, 115 insertions(+), 128 deletions(-)
diff --git a/src/listview.cpp b/src/listview.cpp
index 1e33ac0..84a2b4c 100644
--- a/src/listview.cpp
+++ b/src/listview.cpp
@@ -6,13 +6,9 @@
Copyright: See COPYING file that comes with this distribution
*/
-#include <qlistview.h>
#include <qpainter.h>
-#include <qbitmap.h>
#include <qapplication.h>
-#include <qstatusbar.h>
#include <qheader.h>
-#include <qpopupmenu.h>
#include <qdragobject.h>
#include "common.h"
#include "domain.h"
@@ -406,145 +402,138 @@ void ListViewItem::setDiffTarget(bool b)
/* Draw graph part for a lane
*/
void ListViewItem::paintGraphLane(QPainter* p, int type, int x1, int x2,
- const QColor& col, const QBrush& back) {
+ const QColor& col, const QBrush& back) {
- int h = height();
- int r = (x2-x1)/3;
+ int h = height() / 2;
+ int m = (x1 + x2) / 2;
+ int r = (x2 - x1) / 3;
+ int d = 2 * r;
-#define P_CENTER (x1+x2)/2, h/2
-#define P_0 x2, h/2
-#define P_90 (x1+x2)/2, 0
-#define P_180 x1, h/2
-#define P_270 (x1+x2)/2, h
-#define R_CENTER (x1+x2)/2-r, h/2-r, 2*r, 2*r
+ #define P_CENTER m , h
+ #define P_0 x2, h
+ #define P_90 m , 0
+ #define P_180 x1, h
+ #define P_270 m , 2 * h
+ #define R_CENTER m - r, h - r, d, d
- p->setPen(QPen(col, 2));
+ p->setPen(QPen(col, 2));
// vertical line
switch (type) {
- case ACTIVE:
- case NOT_ACTIVE:
- case MERGE_FORK:
- case MERGE_FORK_R:
- case MERGE_FORK_L:
- case JOIN:
- case JOIN_R:
- case JOIN_L:
- p->drawLine(P_90, P_270);
- break;
- case HEAD:
- case HEAD_R:
- case HEAD_L:
- case BRANCH:
- p->drawLine(P_CENTER, P_270);
- break;
- case TAIL:
- case TAIL_R:
- case TAIL_L:
- case INITIAL:
- case BOUNDARY:
- case BOUNDARY_C:
- case BOUNDARY_R:
- case BOUNDARY_L:
- p->drawLine(P_90, P_CENTER);
- break;
- default:
- break;
+ case ACTIVE:
+ case NOT_ACTIVE:
+ case MERGE_FORK:
+ case MERGE_FORK_R:
+ case MERGE_FORK_L:
+ case JOIN:
+ case JOIN_R:
+ case JOIN_L:
+ p->drawLine(P_90, P_270);
+ break;
+ case HEAD:
+ case HEAD_R:
+ case HEAD_L:
+ case BRANCH:
+ p->drawLine(P_CENTER, P_270);
+ break;
+ case TAIL:
+ case TAIL_R:
+ case TAIL_L:
+ case INITIAL:
+ case BOUNDARY:
+ case BOUNDARY_C:
+ case BOUNDARY_R:
+ case BOUNDARY_L:
+ p->drawLine(P_90, P_CENTER);
+ break;
+ default:
+ break;
}
// horizontal line
switch (type) {
- case MERGE_FORK:
- case JOIN:
- case HEAD:
- case TAIL:
- case CROSS:
- case CROSS_EMPTY:
- case BOUNDARY_C:
- p->drawLine(P_180, P_0);
- break;
- case MERGE_FORK_R:
- case JOIN_R:
- case HEAD_R:
- case TAIL_R:
- case BOUNDARY_R:
- p->drawLine(P_180, P_CENTER);
- break;
- case MERGE_FORK_L:
- case JOIN_L:
- case HEAD_L:
- case TAIL_L:
- case BOUNDARY_L:
- p->drawLine(P_CENTER, P_0);
- break;
- default:
- break;
+ case MERGE_FORK:
+ case JOIN:
+ case HEAD:
+ case TAIL:
+ case CROSS:
+ case CROSS_EMPTY:
+ case BOUNDARY_C:
+ p->drawLine(P_180, P_0);
+ break;
+ case MERGE_FORK_R:
+ case JOIN_R:
+ case HEAD_R:
+ case TAIL_R:
+ case BOUNDARY_R:
+ p->drawLine(P_180, P_CENTER);
+ break;
+ case MERGE_FORK_L:
+ case JOIN_L:
+ case HEAD_L:
+ case TAIL_L:
+ case BOUNDARY_L:
+ p->drawLine(P_CENTER, P_0);
+ break;
+ default:
+ break;
}
// center symbol, e.g. rect or ellipse
switch (type) {
- case ACTIVE:
- case INITIAL:
- case BRANCH:
- p->setPen(Qt::NoPen);
- p->setBrush(col);
- p->drawEllipse(R_CENTER);
- break;
- case MERGE_FORK:
- case MERGE_FORK_R:
- case MERGE_FORK_L:
- p->setPen(Qt::NoPen);
- p->setBrush(col);
- p->drawRect(R_CENTER);
- break;
-
- case UNAPPLIED:
- // Red minus sign
- p->setPen(Qt::NoPen);
- p->setBrush(red);
- p->drawRect( (x1+x2)/2-r, h/2 - 1, 2*r, 2);
- break;
-
- case APPLIED:
- // Green plus sign
- p->setPen(Qt::NoPen);
- p->setBrush(DARK_GREEN);
- p->drawRect( (x1+x2)/2-r, h/2 - 1, 2*r, 2);
- p->drawRect( (x1+x2)/2-1, h/2-r, 2, 2*r);
- break;
-
- case BOUNDARY:
- p->setBrush(back);
- p->drawEllipse(R_CENTER);
- break;
-
- case BOUNDARY_C:
- case BOUNDARY_R:
- case BOUNDARY_L:
- p->setBrush(back);
- p->drawRect(R_CENTER);
- break;
-
- default:
- break;
+ case ACTIVE:
+ case INITIAL:
+ case BRANCH:
+ p->setPen(Qt::NoPen);
+ p->setBrush(col);
+ p->drawEllipse(R_CENTER);
+ break;
+ case MERGE_FORK:
+ case MERGE_FORK_R:
+ case MERGE_FORK_L:
+ p->setPen(Qt::NoPen);
+ p->setBrush(col);
+ p->drawRect(R_CENTER);
+ break;
+ case UNAPPLIED:
+ // Red minus sign
+ p->setPen(Qt::NoPen);
+ p->setBrush(red);
+ p->drawRect(m - r, h - 1, d, 2);
+ break;
+ case APPLIED:
+ // Green plus sign
+ p->setPen(Qt::NoPen);
+ p->setBrush(DARK_GREEN);
+ p->drawRect(m - r, h - 1, d, 2);
+ p->drawRect(m - 1, h - r, 2, d);
+ break;
+ case BOUNDARY:
+ p->setBrush(back);
+ p->drawEllipse(R_CENTER);
+ break;
+ case BOUNDARY_C:
+ case BOUNDARY_R:
+ case BOUNDARY_L:
+ p->setBrush(back);
+ p->drawRect(R_CENTER);
+ break;
+ default:
+ break;
}
-
-#undef P_CENTER
-#undef P_0
-#undef P_90
-#undef P_180
-#undef P_270
-#undef R_CENTER
-
+ #undef P_CENTER
+ #undef P_0
+ #undef P_90
+ #undef P_180
+ #undef P_270
+ #undef R_CENTER
}
-void ListViewItem::paintGraph(const Rev& c, QPainter* p,
- const QColorGroup& cg, int width) {
-
- static QColor colors[COLORS_NUM] = { Qt::black, Qt::red, DARK_GREEN,
- Qt::blue, Qt::darkGray, BROWN,
- Qt::magenta, ORANGE };
+void ListViewItem::paintGraph(const Rev& c, QPainter* p, const
QColorGroup& cg, int width) {
+ static const QColor colors[COLORS_NUM] = { Qt::black, Qt::red, DARK_GREEN,
+ Qt::blue, Qt::darkGray, BROWN,
+ Qt::magenta, ORANGE };
QListView* lv = listView();
if (!lv)
return;
diff --git a/src/listview.h b/src/listview.h
index b1f1011..28d9f60 100644
--- a/src/listview.h
+++ b/src/listview.h
@@ -8,7 +8,6 @@
#include <qobject.h>
#include <qlistview.h>
-#include <qptrvector.h>
#include "common.h"
class QFont;
@@ -20,7 +19,7 @@ class FileHistory;
class ListViewItem: public QListViewItem {
public:
ListViewItem(QListView* p, ListViewItem* a, Git* g, SCRef sha,
- const int& w, bool e, unsigned long t, FileHistory* f);
+ const int& w, bool e, unsigned long t, FileHistory* f);
SCRef sha() const { return sha_; }
int getLaneType(uint pos) const;
@@ -102,4 +101,3 @@ private:
};
#endif
-
--
^ permalink raw reply related
* gitweb.cgi and git instaweb
From: Aneesh Kumar K.V @ 2006-10-26 18:49 UTC (permalink / raw)
To: git
I am getting errors as below with git instaweb.
kvaneesh@satan:/home/opensource/vanilla/linux-2.6-git$ git instaweb
2006-10-27 00:12:56: (log.c.75) server started
kvaneesh@satan:/home/opensource/vanilla/linux-2.6-git$ [Fri Oct 27 00:12:57 2006] gitweb.cgi: "our" variable $stylesheet masks earlier declaration in same scope at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 59.
[Fri Oct 27 00:13:21 2006] gitweb.cgi: "our" variable $stylesheet masks earlier declaration in same scope at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 59.
[Fri Oct 27 00:13:37 2006] gitweb.cgi: "our" variable $stylesheet masks earlier declaration in same scope at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 59.
[Fri Oct 27 00:13:58 2006] gitweb.cgi: "our" variable $stylesheet masks earlier declaration in same scope at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 59.
[Fri Oct 27 00:14:08 2006] gitweb.cgi: "our" variable $stylesheet masks earlier declaration in same scope at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 59.
[Fri Oct 27 00:14:08 2006] gitweb.cgi: Use of uninitialized value in open at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 1118.
fatal: ambiguous argument '': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
[Fri Oct 27 00:14:16 2006] gitweb.cgi: "our" variable $stylesheet masks earlier declaration in same scope at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 59.
^ 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