* [PATCH] gitweb: Include a site name in page titles
From: Alp Toker @ 2006-07-11 20:10 UTC (permalink / raw)
To: git; +Cc: junkio, martin.langhoff
Tip Of The Day:
<title>: the most important element of a quality Web page.
This helps users tell one 'git' bookmark apart from the other in their
browser and improves the indexing of gitweb sites in Web search engines.
Defaults to the HTTP SERVER_NAME.
Signed-off-by: Alp Toker <alp@atoker.com>
---
gitweb/gitweb.cgi | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 2e87de4..be0a01d 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -46,6 +46,10 @@ if (! -d $git_temp) {
# target of the home link on top of all pages
our $home_link = $my_uri;
+# name of your site or organization to appear in page titles
+# replace this with something more descriptive for clearer bookmarks
+our $site_name = $ENV{'SERVER_NAME'} || "Untitled";
+
# html text to include at home page
our $home_text = "indextext.html";
@@ -280,7 +284,7 @@ sub git_header_html {
my $status = shift || "200 OK";
my $expires = shift;
- my $title = "git";
+ my $title = "$site_name git";
if (defined $project) {
$title .= " - $project";
if (defined $action) {
@@ -1760,7 +1764,7 @@ sub git_opml {
print "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n".
"<opml version=\"1.0\">\n".
"<head>".
- " <title>Git OPML Export</title>\n".
+ " <title>$site_name Git OPML Export</title>\n".
"</head>\n".
"<body>\n".
"<outline text=\"git RSS feeds\">\n";
--
1.4.1.g97c7-dirty
^ permalink raw reply related
* Re: [PATCH] gitweb: Use the git binary in the search path by default
From: Junio C Hamano @ 2006-07-11 19:56 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <11526131791902-git-send-email-alp@atoker.com>
Alp Toker <alp@atoker.com> writes:
> Introduce a sensible default for the location of the git binary used by
> gitweb. This means one less option to configure when deploying gitweb if
> git is in the search path.
While I think the part of the change to make things go through
the single "git" wrapper is a good idea, the comment to "our
$GIT" that says "absolute path is optional" makes this change
more like "assume PATH your webserver process uses is sensible",
not "introduce a sensible default".
So I would prefer to do that part like this:
-# location of the git-core binaries
-our $gitbin = "/usr/bin";
+# core git wrapper -- if your webserver runs with a sensible PATH
+# you can just say "git" without using absolute pathname here.
+our $GIT = "/usr/bin/git";
^ permalink raw reply
* Re: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Linus Torvalds @ 2006-07-11 19:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carl Baldwin, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0607112116270.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 11 Jul 2006, Johannes Schindelin wrote:
>
> > Or, more likely, the parse_sha1_header() function should just be changed
> > to check the binary format first (and then add your comment about why that
> > is safe).
>
> Yes, exactly.
Here's a newer verson of [2/3], with these issues fixed. It actually fixes
things twice: (a) by parsing the binary version first (which makes sense
for a totally independent reason - if that is going to be the "default"
version in the long run, we should just test it first anyway) and (b) by
making the ASCII version parser stricter too.
This did, btw, also fix the test failure, so the fact that the ASCII
header parser wasn't careful enough was actually a problem in real life.
So please throw away the old version.
Linus
---
From: Linus Torvalds <torvalds@osdl.org>
Subject: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
The pack-file format is slightly different from the traditional git
object format, in that it has a much denser binary header encoding.
The traditional format uses an ASCII string with type and length
information, which is somewhat wasteful.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
sha1_file.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++++-------
1 files changed, 82 insertions(+), 11 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 8734d50..15ccf5e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -697,9 +697,9 @@ static int unpack_sha1_header(z_stream *
return inflate(stream, 0);
}
-static void *unpack_sha1_rest(z_stream *stream, void *buffer, unsigned long size)
+static void *unpack_sha1_rest(z_stream *stream, void *buffer, unsigned long size, unsigned int hdrlen)
{
- int bytes = strlen(buffer) + 1;
+ int bytes = hdrlen;
unsigned char *buf = xmalloc(1+size);
memcpy(buf, (char *) buffer + bytes, stream->total_out - bytes);
@@ -720,25 +720,40 @@ static void *unpack_sha1_rest(z_stream *
* too permissive for what we want to check. So do an anal
* object header parse by hand.
*/
-static int parse_sha1_header(char *hdr, char *type, unsigned long *sizep)
+static int parse_ascii_sha1_header(char *hdr, char *type, unsigned long *sizep)
{
- int i;
+ int bytes = 0;
unsigned long size;
/*
* The type can be at most ten bytes (including the
* terminating '\0' that we add), and is followed by
* a space.
+ *
+ * We want at least three characters, and they should
+ * all be normal lower-case letters.
*/
- i = 10;
for (;;) {
- char c = *hdr++;
+ unsigned char c = *hdr++;
+ bytes++;
if (c == ' ')
break;
- if (!--i)
+ if (bytes >= 10)
return -1;
*type++ = c;
+
+ /*
+ * The high nybble must be 6 of 7, see
+ * parse_binary_header(). This covers
+ * all ASCII lowercase characters.
+ */
+ if (c < 0x60 || c > 0x7f)
+ return -1;
}
+
+ /* Minimum three letters and the space */
+ if (bytes < 4)
+ return -1;
*type = 0;
/*
@@ -746,6 +761,7 @@ static int parse_sha1_header(char *hdr,
* decimal format (ie "010" is not valid).
*/
size = *hdr++ - '0';
+ bytes++;
if (size > 9)
return -1;
if (size) {
@@ -754,6 +770,7 @@ static int parse_sha1_header(char *hdr,
if (c > 9)
break;
hdr++;
+ bytes++;
size = size * 10 + c;
}
}
@@ -762,20 +779,74 @@ static int parse_sha1_header(char *hdr,
/*
* The length must be followed by a zero byte
*/
- return *hdr ? -1 : 0;
+ bytes++;
+ return *hdr ? -1 : bytes;
+}
+
+/*
+ * We never confuse a binary header with an old ASCII one,
+ * because the ASCII one will always start with a lower-case
+ * letter, meaning that the first byte will be of the form
+ * 0x6? or 0x7?.
+ *
+ * That in turn would be parsed as object type 6 or 7, neither
+ * of which is valid for a unpacked object (object type 7 is
+ * a delta, and can only exist in a pack-file, while object type
+ * 6 is invalid).
+ */
+static int parse_binary_sha1_header(char *hdr, char *type, unsigned long *sizep)
+{
+ unsigned char c;
+ int bytes = 1;
+ unsigned long size;
+ unsigned object_type, bits;
+ static const char *typename[8] = {
+ NULL, /* OBJ_EXT */
+ "commit", "tree", "blob", "tag",
+ NULL, NULL, NULL
+ };
+
+ c = *hdr++;
+ object_type = (c >> 4) & 7;
+ if (!typename[object_type])
+ return -1;
+ strcpy(type, typename[object_type]);
+ size = c & 15;
+ bits = 4;
+ while (!(c & 0x80)) {
+ if (bits >= 8*sizeof(unsigned long))
+ return -1;
+ c = *hdr++;
+ size += (unsigned long) (c & 0x7f) << bits;
+ bytes++;
+ bits += 7;
+ }
+ *sizep = size;
+ return bytes;
+}
+
+static int parse_sha1_header(char *hdr, char *type, unsigned long *sizep)
+{
+ int retval = parse_binary_sha1_header(hdr, type, sizep);
+ if (retval < 0)
+ retval = parse_ascii_sha1_header(hdr, type, sizep);
+ return retval;
}
void * unpack_sha1_file(void *map, unsigned long mapsize, char *type, unsigned long *size)
{
- int ret;
+ int ret, hdrlen;
z_stream stream;
char hdr[8192];
ret = unpack_sha1_header(&stream, map, mapsize, hdr, sizeof(hdr));
- if (ret < Z_OK || parse_sha1_header(hdr, type, size) < 0)
+ if (ret < Z_OK)
+ return NULL;
+ hdrlen = parse_sha1_header(hdr, type, size);
+ if (hdrlen < 0)
return NULL;
- return unpack_sha1_rest(&stream, hdr, *size);
+ return unpack_sha1_rest(&stream, hdr, *size, hdrlen);
}
/* forward declaration for a mutually recursive function */
^ permalink raw reply related
* Re: [PATCH] gitweb: Include a site name in page titles
From: Junio C Hamano @ 2006-07-11 19:48 UTC (permalink / raw)
To: Alp Toker; +Cc: git, Martin Langhoff
In-Reply-To: <46a038f90607110448p40fd8984ke3e15639cf5ecf46@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
>> +# name of your site or organization to appear in page titles
>> +our $site_name = "Untitled";
>
> I generally agree, but as a default, $ENV{SERVER_NAME} should be better.
Sounds like a good suggestion.
^ permalink raw reply
* Re: Re : 2 questions on git-send-email usage
From: Junio C Hamano @ 2006-07-11 19:22 UTC (permalink / raw)
To: Franck; +Cc: git
In-Reply-To: <44B37893.5090501@innova-card.com>
Franck Bui-Huu <vagabon.xyz@gmail.com> writes:
> Maybe that patch does what you want.
>
> -- >8 --
>
> Subject: [PATCH] Add a newline before appending "Signed-off-by:"
>
> It looks nicer.
>
> Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com>
Haven't checked the code around the patch yet, but does it work
when the original commit log message ends with a blank line and
existing signed-off-by lines by other people? You do not want
an extra blank lines there.
^ permalink raw reply
* Re: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Johannes Schindelin @ 2006-07-11 19:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Carl Baldwin, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607111153170.5623@g5.osdl.org>
Hi,
On Tue, 11 Jul 2006, Linus Torvalds wrote:
> On Tue, 11 Jul 2006, Johannes Schindelin wrote:
>
> > You might want to add a comment saying "since the type is lowercase in
> > ascii format, object_type must be 6 or 7, which is an invalid object
> > type." It took me a little to figure that out...
>
> It's not even correct in my version - I check the ASCII header _first_, so
> by the time it looks at the binary one, it already knows it's not ascii.
Just realized it all by myself...
> Or, more likely, the parse_sha1_header() function should just be changed
> to check the binary format first (and then add your comment about why that
> is safe).
Yes, exactly.
> > > + bits = 4;
> > > + while (!(c & 0x80)) {
> > > + if (bits >= 8*sizeof(unsigned long))
> > > + return -1;
> > > + c = *hdr++;
> > > + size += (unsigned long) (c & 0x7f) << bits;
> > > + bytes++;
> > > + bits += 7;
> > > + }
> >
> > Are you not losing the last byte by putting the "while" _before_ instead
> > of _after_ the loop?
>
> No. The very first byte can have the 0x80 end marker, when the size was
> between 0..15.
Yes, I understand now. I was a little confused by the way it is written...
Thanks for the clarification,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Linus Torvalds @ 2006-07-11 18:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carl Baldwin, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0607112031150.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 11 Jul 2006, Johannes Schindelin wrote:
>
> Why not just say
>
> return *hdr ? -1 : bytes;
Hey, whatever works. I rewrote more, and edited some of my changes down
again..
> You might want to add a comment saying "since the type is lowercase in
> ascii format, object_type must be 6 or 7, which is an invalid object
> type." It took me a little to figure that out...
It's not even correct in my version - I check the ASCII header _first_, so
by the time it looks at the binary one, it already knows it's not ascii.
The problematic case is actually the other way around: my
"parse_ascii_sha1_header()" isn't strict enough.
Or, more likely, the parse_sha1_header() function should just be changed
to check the binary format first (and then add your comment about why that
is safe).
> > + bits = 4;
> > + while (!(c & 0x80)) {
> > + if (bits >= 8*sizeof(unsigned long))
> > + return -1;
> > + c = *hdr++;
> > + size += (unsigned long) (c & 0x7f) << bits;
> > + bytes++;
> > + bits += 7;
> > + }
>
> Are you not losing the last byte by putting the "while" _before_ instead
> of _after_ the loop?
No. The very first byte can have the 0x80 end marker, when the size was
between 0..15.
> > int sha1_object_info(const unsigned char *sha1, char *type, unsigned long *sizep)
> > {
> > - int status;
> > + int status, hdrlen;
> > unsigned long mapsize, size;
> > void *map;
> > z_stream stream;
>
> This hunk is unnecessary, right?
Yeah, never mind. That function didn't actually need the hdrlen, it only
cared about the SHA1.
Linus
^ permalink raw reply
* [PATCH] tests: Set EDITOR=: and VISUAL=: globally
From: Eric Wong @ 2006-07-11 19:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkr04i4p.fsf@assigned-by-dhcp.cox.net>
This way we don't have to remember to set it for each test; and
if we forget, we won't cause interactive editors to be spawned
for non-interactive tests.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > I have VISUAL set in my environment, and it caused git-commit to
> > spawn my editor during the test.
>
> I think it would be better to remove "EDITOR=: VISUAL=:"
> settings from annotate-tests.sh, t1400-update-ref.sh and
> t4013-diff-various.sh, and move that to test-lib.sh; there is no
> point overriding them differently in each of these automated
> tests.
I've been under the impression this has already been set, but it turns
it that was only the case in my config.mak on a different machine :)
t/annotate-tests.sh | 2 +-
t/t1400-update-ref.sh | 1 -
t/t4013-diff-various.sh | 2 +-
t/test-lib.sh | 3 +++
4 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh
index 1148b02..b6a2edd 100644
--- a/t/annotate-tests.sh
+++ b/t/annotate-tests.sh
@@ -94,7 +94,7 @@ test_expect_success \
test_expect_success \
'merge-setup part 4' \
'echo "evil merge." >>file &&
- EDITOR=: VISUAL=: git commit -a --amend'
+ git commit -a --amend'
test_expect_success \
'Two lines blamed on A, one on B, two on B1, one on B2, one on A U Thor' \
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 6a3515d..04fab26 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -190,7 +190,6 @@ test_expect_success \
GIT_COMMITTER_DATE="2005-05-26 23:41" git-commit -F M -a &&
h_OTHER=$(git-rev-parse --verify HEAD) &&
echo FIXED >F &&
- EDITOR=true \
GIT_AUTHOR_DATE="2005-05-26 23:44" \
GIT_COMMITTER_DATE="2005-05-26 23:44" git-commit --amend &&
h_FIXED=$(git-rev-parse --verify HEAD) &&
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 06837d1..36658fb 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -70,7 +70,7 @@ test_expect_success setup '
for i in 1 2; do echo $i; done >>dir/sub &&
git update-index file0 dir/sub &&
- EDITOR=: VISUAL=: git commit --amend &&
+ git commit --amend &&
git show-branch
'
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 05f6e79..b0d7990 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -9,6 +9,8 @@ LC_ALL=C
PAGER=cat
TZ=UTC
export LANG LC_ALL PAGER TZ
+EDITOR=:
+VISUAL=:
unset AUTHOR_DATE
unset AUTHOR_EMAIL
unset AUTHOR_NAME
@@ -30,6 +32,7 @@ unset SHA1_FILE_DIRECTORIES
unset SHA1_FILE_DIRECTORY
export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
+export EDITOR VISUAL
# Each test should start with something like this, after copyright notices:
#
--
1.4.1.g710d
^ permalink raw reply related
* Re: [PATCH] Install built-ins as symlinks
From: Petr Baudis @ 2006-07-11 18:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alp Toker, git
In-Reply-To: <Pine.LNX.4.63.0607111951350.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Tue, Jul 11, 2006 at 08:02:53PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> The consistency is a non-issue, because the Makefile rules Do The Right
> Thing.
once in a while, a Git command disappears, it has already happenned
several times (git-rename, git-octopus, git-apply-patch-script, I'm sure
I'd find some more if I looked better; looking into future, I'm not sure
about the further life expectancy of e.g. git-resolve or git-ssh-fetch).
> I happen to run git without installing it, mainly because I like to fiddle
> around with git. Now, if "git" does not compile for some reason, with
> symlinks I lose git-diff, git-ls-files, etc.
If "git" doesn't compile nothing overwrites your previous "git" binary
and things stay working. If "git" did compile but is broken, the
Makefile already rehardlinked the other files anyway so you are still
screwed.
> And -- just maybe -- I _did_ mention a single reason to keep hard links:
> It works now. So why change it?
The original patch mentioned why hardlinks are bad, so if you argue
that the raised points are moot, you should give some substance to your
argument.
> > If you don't have the technical background to review a certain patch, please
> > don't add to the noise.
>
> It is not nice to tell a dumb man how dumb he is. Mommy! I am so sorry
> that I lack the technical background. Please apologize for the noise.
Please help to maintain the very friendly nature of this list we
have been enjoying so far.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Johannes Schindelin @ 2006-07-11 18:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Carl Baldwin, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607111010320.5623@g5.osdl.org>
Hi,
On Tue, 11 Jul 2006, Linus Torvalds wrote:
> @@ -762,20 +765,65 @@ static int parse_sha1_header(char *hdr,
> /*
> * The length must be followed by a zero byte
> */
> - return *hdr ? -1 : 0;
> + bytes++;
> + if (*hdr)
> + bytes = -1;
> + return bytes;
Why not just say
return *hdr ? -1 : bytes;
> +}
> +
> +static int parse_binary_sha1_header(char *hdr, char *type, unsigned long *sizep)
> +{
> + unsigned char c;
> + int bytes = 1;
> + unsigned long size;
> + unsigned object_type, bits;
> + static const char *typename[8] = {
> + NULL, /* OBJ_EXT */
> + "commit", "tree", "blob", "tag",
> + NULL, NULL, NULL
> + };
> +
> + c = *hdr++;
> + object_type = (c >> 4) & 7;
> + if (!typename[object_type])
> + return -1;
You might want to add a comment saying "since the type is lowercase in
ascii format, object_type must be 6 or 7, which is an invalid object
type." It took me a little to figure that out...
> + strcpy(type, typename[object_type]);
> + size = c & 15;
Just a nit here: I think 0xf is easier to read with boolean operations.
> + bits = 4;
> + while (!(c & 0x80)) {
> + if (bits >= 8*sizeof(unsigned long))
> + return -1;
> + c = *hdr++;
> + size += (unsigned long) (c & 0x7f) << bits;
> + bytes++;
> + bits += 7;
> + }
Are you not losing the last byte by putting the "while" _before_ instead
of _after_ the loop?
> @@ -1192,7 +1240,7 @@ struct packed_git *find_sha1_pack(const
>
> int sha1_object_info(const unsigned char *sha1, char *type, unsigned long *sizep)
> {
> - int status;
> + int status, hdrlen;
> unsigned long mapsize, size;
> void *map;
> z_stream stream;
> -
This hunk is unnecessary, right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Install built-ins as symlinks
From: Petr Baudis @ 2006-07-11 18:36 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <11526131792377-git-send-email-alp@atoker.com>
Dear diary, on Tue, Jul 11, 2006 at 12:19:38PM CEST, I got a letter
where Alp Toker <alp@atoker.com> said that...
> diff --git a/Makefile b/Makefile
> index 5b7bac8..cb5a5cc 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -538,7 +538,7 @@ git$X: git.c common-cmds.h $(BUILTIN_OBJ
> builtin-help.o: common-cmds.h
>
> $(BUILT_INS): git$X
> - rm -f $@ && ln git$X $@
> + ln -sf git$X $@
>
> common-cmds.h: Documentation/git-*.txt
> ./generate-cmdlist.sh > $@+
Doesn't the git$X dependency become pointless at this point?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [PATCH] Install built-ins as symlinks
From: Johannes Schindelin @ 2006-07-11 18:02 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <44B3BC94.3000204@atoker.com>
Hi,
On Tue, 11 Jul 2006, Alp Toker wrote:
> Johannes Schindelin wrote:
> > > Doing this now will save headache in the long run, avoiding mismatched
> > > versions of installed utilities and dangling copies of removed or
> > > renamed git commands that still appear to work. It also makes screwups
> > > when packaging git or making system backups less likely.
> >
> > Could we please fix things, which are broken? Not things which work?
>
> There are maybe a dozen arguments for and against the use of symlinks here,
> some of which Andreas has helpfully explained in his reply. You, on the other
> hand, have managed not to mention a single one of them.
Yes. That is correct. I hoped I did not need to.
The consistency is a non-issue, because the Makefile rules Do The Right
Thing.
I happen to run git without installing it, mainly because I like to fiddle
around with git. Now, if "git" does not compile for some reason, with
symlinks I lose git-diff, git-ls-files, etc.
And -- just maybe -- I _did_ mention a single reason to keep hard links:
It works now. So why change it?
> If you don't have the technical background to review a certain patch, please
> don't add to the noise.
It is not nice to tell a dumb man how dumb he is. Mommy! I am so sorry
that I lack the technical background. Please apologize for the noise.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Mention the [user@] part in documentation of ssh:// urls.
From: Yakov Lerner @ 2006-07-11 21:02 UTC (permalink / raw)
To: git; +Cc: iler.ml
Mention the [user@] part in documentation of ssh:// urls.
Signed-off-by: Yakov Lerner <iler.ml@gmail.com>
---
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -10,9 +10,9 @@
- https://host.xz/path/to/repo.git/
- git://host.xz/path/to/repo.git/
- git://host.xz/~user/path/to/repo.git/
-- ssh://host.xz/path/to/repo.git/
-- ssh://host.xz/~user/path/to/repo.git/
-- ssh://host.xz/~/path/to/repo.git
+- ssh://[user@]host.xz/path/to/repo.git/
+- ssh://[user@]host.xz/~user/path/to/repo.git/
+- ssh://[user@]host.xz/~/path/to/repo.git
===============================================================
SSH Is the default transport protocol and also supports an
^ permalink raw reply
* Re: [RFC]: Pack-file object format for individual objects (Was: Revisiting large binary files issue.)
From: Linus Torvalds @ 2006-07-11 18:00 UTC (permalink / raw)
To: sf; +Cc: git
In-Reply-To: <44B371FB.2070800@b-i-t.de>
[ I read my personal mailbox first, so I didn't see this one until after I
had already written my version.. ]
On Tue, 11 Jul 2006, sf wrote:
>
> I just stumbled over the same fact and asked myself why there are still
> two formats. Wouldn't it make more sense to use the pack-file object
> format for individual objects as well?
Yes, see the git list for a series of patches that try to do this.
> As it happens individual objects all start with nibble 7 (deflated with
> default _zlib_ window size of 32K) whereas in the pack-file object
> format nibble 7 indicates delta entries which never occur as individual
> files.
I didn't actually do it that way, but it would be better to make the
"parse_ascii_sha1_header()" more strict, and only accept the old names.
Right now my patch-series could in theory accept something that is _not_
an ASCII header (eg it would be a binary header that just happened to have
the format "x n\0", where "n" was a valid number).
> Step 1. When reading individual objects from disk check the first nibble
> and decode accordingly (see above).
Check more than that, but yes, this should be tightened up in my
series.
> Step 2. When writing individual objects to disk write them in pack-file
> object format. Make that optional (config-file parameter, command line
> option etc.)?
Done.
> Step 3. Remove code for (old) individual object disk format.
Well, I'm not sure how necessary that even is. We actually do have to
generate the old header regardless, if for no other reason than the fact
that we generate the SHA1 names based on it (even if we then write a
new-style dense binary header to disk and discard the ASCII header).
Having it there means that you can always just get a new version of git,
and never worry about how old the archive you're working with is.
(And then doing a "git repack -a -d" will make any archive also work with
an old-style git, since the pack-file format didn't change, and a "git
repack" thus ends up always creating something that is readable by
anybody, including old clients).
Linus
^ permalink raw reply
* [PATCH 3/3] Enable the new binary header format for unpacked objects
From: Linus Torvalds @ 2006-07-11 17:16 UTC (permalink / raw)
To: Carl Baldwin, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607111004360.5623@g5.osdl.org>
Enable the new binary header format for unpacked objects
This makes unpacked objects use the same header encoding as the packed
objects do, which should eventually allow us to be able to re-use the
object data directly when creating pack-files (rather than having to
decode and re-encode the data when inserting it in a pack).
It's enabled by default, but can be disabled with
[core]
BinaryHeaders = false
in the config file.
We can read both formats, of course, so you can have a mixed archive.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This should _not_ be applied to the main git sources, at least not
with the default being "use_binary_headers = 1".
But if you change that initial assignment to 0, this should be reasonably
good.
Not extensively tested, of course. It fails t9102-git-svn-deep-rmdir.sh
for me for some reason, I didn't really look at it yet, since this whole
thing is more for Carl Baldwin to play with right now.
Documentation/config.txt | 5 ++++
cache.h | 1 +
config.c | 5 ++++
environment.c | 1 +
sha1_file.c | 65 ++++++++++++++++++++++++++++++++++++++++------
5 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0b434c1..bc95416 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -97,6 +97,11 @@ core.compression::
compression, and 1..9 are various speed/size tradeoffs, 9 being
slowest.
+core.binaryheaders::
+ A boolean, that if set to false, disables the use of the
+ new-style binary objects headers that share the same format with
+ the headers in a pack file.
+
alias.*::
Command aliases for the gitlink:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
diff --git a/cache.h b/cache.h
index d433d46..756d89f 100644
--- a/cache.h
+++ b/cache.h
@@ -176,6 +176,7 @@ extern int commit_lock_file(struct lock_
extern void rollback_lock_file(struct lock_file *);
/* Environment bits from configuration mechanism */
+extern int use_binary_headers;
extern int trust_executable_bit;
extern int assume_unchanged;
extern int prefer_symlink_refs;
diff --git a/config.c b/config.c
index 8445f7d..2497447 100644
--- a/config.c
+++ b/config.c
@@ -289,6 +289,11 @@ int git_default_config(const char *var,
return 0;
}
+ if (!strcmp(var, "core.binaryheaders")) {
+ use_binary_headers = git_config_bool(var, value);
+ return 0;
+ }
+
if (!strcmp(var, "user.name")) {
strlcpy(git_default_name, value, sizeof(git_default_name));
return 0;
diff --git a/environment.c b/environment.c
index 43823ff..340214d 100644
--- a/environment.c
+++ b/environment.c
@@ -11,6 +11,7 @@ #include "cache.h"
char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
+int use_binary_headers = 1;
int trust_executable_bit = 1;
int assume_unchanged = 0;
int prefer_symlink_refs = 0;
diff --git a/sha1_file.c b/sha1_file.c
index ca5f0c0..700f455 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -699,11 +699,14 @@ static int unpack_sha1_header(z_stream *
static void *unpack_sha1_rest(z_stream *stream, void *buffer, unsigned long size, unsigned int hdrlen)
{
- int bytes = hdrlen;
+ unsigned long bytes = hdrlen, n;
unsigned char *buf = xmalloc(1+size);
- memcpy(buf, (char *) buffer + bytes, stream->total_out - bytes);
- bytes = stream->total_out - bytes;
+ n = stream->total_out - bytes;
+ if (n > size)
+ n = size;
+ memcpy(buf, (char *) buffer + bytes, n);
+ bytes = n;
if (bytes < size) {
stream->next_out = buf + bytes;
stream->avail_out = size - bytes;
@@ -1240,7 +1243,7 @@ struct packed_git *find_sha1_pack(const
int sha1_object_info(const unsigned char *sha1, char *type, unsigned long *sizep)
{
- int status, hdrlen;
+ int status;
unsigned long mapsize, size;
void *map;
z_stream stream;
@@ -1349,24 +1352,70 @@ void *read_object_with_reference(const u
}
}
+static int write_binary_header(unsigned char *hdr, enum object_type type, unsigned long len)
+{
+ int hdr_len;
+ unsigned char c;
+
+ c = (type << 4) | (len & 15);
+ len >>= 4;
+ hdr_len = 1;
+ while (len) {
+ *hdr++ = c;
+ hdr_len++;
+ c = (len & 0x7f);
+ len >>= 7;
+ }
+ *hdr = c | 0x80;
+ return hdr_len;
+}
+
+static int generate_binary_header(unsigned char *hdr, const char *type, unsigned long len)
+{
+ int obj_type;
+
+ if (!strcmp(type, blob_type))
+ obj_type = OBJ_BLOB;
+ else if (!strcmp(type, tree_type))
+ obj_type = OBJ_TREE;
+ else if (!strcmp(type, commit_type))
+ obj_type = OBJ_COMMIT;
+ else if (!strcmp(type, tag_type))
+ obj_type = OBJ_TAG;
+ else
+ die("trying to generate bogus object of type '%s'", type);
+ return write_binary_header(hdr, obj_type, len);
+}
+
char *write_sha1_file_prepare(void *buf,
unsigned long len,
const char *type,
unsigned char *sha1,
unsigned char *hdr,
- int *hdrlen)
+ int *hdrlenp)
{
SHA_CTX c;
+ int hdr_len;
- /* Generate the header */
- *hdrlen = sprintf((char *)hdr, "%s %lu", type, len)+1;
+ /*
+ * Generate the header.
+ *
+ * NOTE! Regardless of whether we end up using the ASCII
+ * or binary header, we always generate the SHA1 of the
+ * file as if we had the ASCII header.
+ */
+ hdr_len = sprintf((char *)hdr, "%s %lu", type, len)+1;
/* Sha1.. */
SHA1_Init(&c);
- SHA1_Update(&c, hdr, *hdrlen);
+ SHA1_Update(&c, hdr, hdr_len);
SHA1_Update(&c, buf, len);
SHA1_Final(sha1, &c);
+ if (use_binary_headers)
+ hdr_len = generate_binary_header(hdr, type, len);
+ *hdrlenp = hdr_len;
+
return sha1_file_name(sha1);
}
^ permalink raw reply related
* [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Linus Torvalds @ 2006-07-11 17:12 UTC (permalink / raw)
To: Carl Baldwin, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607111004360.5623@g5.osdl.org>
The pack-file format is slightly different from the traditional git
object format, in that it has a much denser binary header encoding.
The traditional format uses an ASCII string with type and length
information, which is somewhat wasteful.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This should probably be applied to the main tree asap if we think
this is at all a worthwhile exercise. But somebody should verify that I
got the format right first!
sha1_file.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 57 insertions(+), 9 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 8734d50..ca5f0c0 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -697,9 +697,9 @@ static int unpack_sha1_header(z_stream *
return inflate(stream, 0);
}
-static void *unpack_sha1_rest(z_stream *stream, void *buffer, unsigned long size)
+static void *unpack_sha1_rest(z_stream *stream, void *buffer, unsigned long size, unsigned int hdrlen)
{
- int bytes = strlen(buffer) + 1;
+ int bytes = hdrlen;
unsigned char *buf = xmalloc(1+size);
memcpy(buf, (char *) buffer + bytes, stream->total_out - bytes);
@@ -720,9 +720,9 @@ static void *unpack_sha1_rest(z_stream *
* too permissive for what we want to check. So do an anal
* object header parse by hand.
*/
-static int parse_sha1_header(char *hdr, char *type, unsigned long *sizep)
+static int parse_ascii_sha1_header(char *hdr, char *type, unsigned long *sizep)
{
- int i;
+ int i, bytes = 0;
unsigned long size;
/*
@@ -733,6 +733,7 @@ static int parse_sha1_header(char *hdr,
i = 10;
for (;;) {
char c = *hdr++;
+ bytes++;
if (c == ' ')
break;
if (!--i)
@@ -746,6 +747,7 @@ static int parse_sha1_header(char *hdr,
* decimal format (ie "010" is not valid).
*/
size = *hdr++ - '0';
+ bytes++;
if (size > 9)
return -1;
if (size) {
@@ -754,6 +756,7 @@ static int parse_sha1_header(char *hdr,
if (c > 9)
break;
hdr++;
+ bytes++;
size = size * 10 + c;
}
}
@@ -762,20 +765,65 @@ static int parse_sha1_header(char *hdr,
/*
* The length must be followed by a zero byte
*/
- return *hdr ? -1 : 0;
+ bytes++;
+ if (*hdr)
+ bytes = -1;
+ return bytes;
+}
+
+static int parse_binary_sha1_header(char *hdr, char *type, unsigned long *sizep)
+{
+ unsigned char c;
+ int bytes = 1;
+ unsigned long size;
+ unsigned object_type, bits;
+ static const char *typename[8] = {
+ NULL, /* OBJ_EXT */
+ "commit", "tree", "blob", "tag",
+ NULL, NULL, NULL
+ };
+
+ c = *hdr++;
+ object_type = (c >> 4) & 7;
+ if (!typename[object_type])
+ return -1;
+ strcpy(type, typename[object_type]);
+ size = c & 15;
+ bits = 4;
+ while (!(c & 0x80)) {
+ if (bits >= 8*sizeof(unsigned long))
+ return -1;
+ c = *hdr++;
+ size += (unsigned long) (c & 0x7f) << bits;
+ bytes++;
+ bits += 7;
+ }
+ *sizep = size;
+ return bytes;
+}
+
+static int parse_sha1_header(char *hdr, char *type, unsigned long *sizep)
+{
+ int retval = parse_ascii_sha1_header(hdr, type, sizep);
+ if (retval < 0)
+ retval = parse_binary_sha1_header(hdr, type, sizep);
+ return retval;
}
void * unpack_sha1_file(void *map, unsigned long mapsize, char *type, unsigned long *size)
{
- int ret;
+ int ret, hdrlen;
z_stream stream;
char hdr[8192];
ret = unpack_sha1_header(&stream, map, mapsize, hdr, sizeof(hdr));
- if (ret < Z_OK || parse_sha1_header(hdr, type, size) < 0)
+ if (ret < Z_OK)
+ return NULL;
+ hdrlen = parse_sha1_header(hdr, type, size);
+ if (hdrlen < 0)
return NULL;
- return unpack_sha1_rest(&stream, hdr, *size);
+ return unpack_sha1_rest(&stream, hdr, *size, hdrlen);
}
/* forward declaration for a mutually recursive function */
@@ -1192,7 +1240,7 @@ struct packed_git *find_sha1_pack(const
int sha1_object_info(const unsigned char *sha1, char *type, unsigned long *sizep)
{
- int status;
+ int status, hdrlen;
unsigned long mapsize, size;
void *map;
z_stream stream;
^ permalink raw reply related
* [PATCH 1/3] Make the unpacked object header functions static to sha1_file.c
From: Linus Torvalds @ 2006-07-11 17:10 UTC (permalink / raw)
To: Carl Baldwin, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607111004360.5623@g5.osdl.org>
Nobody else uses them, and I'm going to start changing them.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
cache.h | 2 --
sha1_file.c | 4 ++--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/cache.h b/cache.h
index b5e3f8f..d433d46 100644
--- a/cache.h
+++ b/cache.h
@@ -219,8 +219,6 @@ int safe_create_leading_directories(char
char *enter_repo(char *path, int strict);
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
-extern int unpack_sha1_header(z_stream *stream, void *map, unsigned long mapsize, void *buffer, unsigned long size);
-extern int parse_sha1_header(char *hdr, char *type, unsigned long *sizep);
extern int sha1_object_info(const unsigned char *, char *, unsigned long *);
extern void * unpack_sha1_file(void *map, unsigned long mapsize, char *type, unsigned long *size);
extern void * read_sha1_file(const unsigned char *sha1, char *type, unsigned long *size);
diff --git a/sha1_file.c b/sha1_file.c
index 459430a..8734d50 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -684,7 +684,7 @@ static void *map_sha1_file_internal(cons
return map;
}
-int unpack_sha1_header(z_stream *stream, void *map, unsigned long mapsize, void *buffer, unsigned long size)
+static int unpack_sha1_header(z_stream *stream, void *map, unsigned long mapsize, void *buffer, unsigned long size)
{
/* Get the data stream */
memset(stream, 0, sizeof(*stream));
@@ -720,7 +720,7 @@ static void *unpack_sha1_rest(z_stream *
* too permissive for what we want to check. So do an anal
* object header parse by hand.
*/
-int parse_sha1_header(char *hdr, char *type, unsigned long *sizep)
+static int parse_sha1_header(char *hdr, char *type, unsigned long *sizep)
{
int i;
unsigned long size;
^ permalink raw reply related
* Re: Revisiting large binary files issue.
From: Linus Torvalds @ 2006-07-11 17:09 UTC (permalink / raw)
To: Carl Baldwin, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <20060711145527.GA32468@hpsvcnb.fc.hp.com>
On Tue, 11 Jul 2006, Carl Baldwin wrote:
>
> I'd like to get my hands dirty and see for myself where the issue lies.
> I hope to have some time next week to devote to this. Is it reasonable
> to hope for a solution that is at least a lot lighter weight than the
> current status quo?
Ok, I decided to see how nasty an object database change would be.
It doesn't look too bad. The following three patches implement what looks
like a workable model.
NOTE NOTE NOTE! It makes the new "binary headers" the default, and that
will mean that unless you have applied the first two patches, any
repository that has had objects added with the new git version WILL NOT BE
READABLE BY AN OLDER GIT VERSION!
So I think that the first two patches can be added to the main git branch
pretty much immediately (after people have tested this all a _bit_ more,
of course), because the first two patches just add the capability to
_read_ a mixed-format repository.
The third patch is the one that actually starts _writing_ new-format repo.
It should be applied with extreme care, although it can basically be
de-fanged by setting the default initial value of the "use_binary_headers"
to 0, which will make it not write the binary headers by default.
I have _not_ verified that the actual object format is identical to the
pack-file one, but it should be. It's simple enough.
The three patches will be sent as replies to this email.
Linus
^ permalink raw reply
* Re: [PATCH] Install built-ins as symlinks
From: Alp Toker @ 2006-07-11 14:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607111614550.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>> Doing this now will save headache in the long run, avoiding mismatched
>> versions of installed utilities and dangling copies of removed or
>> renamed git commands that still appear to work. It also makes screwups
>> when packaging git or making system backups less likely.
>
> Could we please fix things, which are broken? Not things which work?
There are maybe a dozen arguments for and against the use of symlinks
here, some of which Andreas has helpfully explained in his reply. You,
on the other hand, have managed not to mention a single one of them.
If you don't have the technical background to review a certain patch,
please don't add to the noise.
^ permalink raw reply
* Re: Revisiting large binary files issue.
From: Carl Baldwin @ 2006-07-11 14:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607101623230.5623@g5.osdl.org>
I'd like to get my hands dirty and see for myself where the issue lies.
I hope to have some time next week to devote to this. Is it reasonable
to hope for a solution that is at least a lot lighter weight than the
current status quo?
Carl
On Mon, Jul 10, 2006 at 04:28:24PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 10 Jul 2006, Carl Baldwin wrote:
> >
> > When I set the window to 0 I one more issue. Even though the blobs are
> > already compressed on disk I still seem to pay the penalty of inflating
> > them into memory and then deflating them into the pack. When the window
> > size is 0 this is just wasted cycles. With large binary files these
> > wasted cycles slow down the push/fetch operation considerably. Couldn't
> > the compressed blobs be copied into the pack without first deflating
> > them in this 0 window case?
>
> The problem is that the individual object disk format isn't actually the
> same as the pack-file object format for one object. The header is
> different: a pack-file uses a very dense bit packing, while the individual
> object format is a bit less dense.
>
> Sad, really, but it means that right now you can only re-use data that was
> already packed (when the format matches).
>
> Linus
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin RADCAD (R&D CAD)
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: Revisiting large binary files issue.
From: Peter Baumann @ 2006-07-11 6:20 UTC (permalink / raw)
To: git
In-Reply-To: <7v7j2l833o.fsf@assigned-by-dhcp.cox.net>
On 2006-07-10, Junio C Hamano <junkio@cox.net> wrote:
> Carl Baldwin <cnb@fc.hp.com> writes:
>
>> First, I would like to be able to set the packing window to 0 for all of
>> the git commands. It would be nice if I could set this in a
>> per-repository config file so that any push/fetch operation would honor
>> this window. Is there currently a way to do this?
>
> Should not be hard to add.
>
>> Second, I would like to not pay the penalty to inflate and then deflate
>> the objects into the pack when I use a window of 0. How hard would this
>> be? I am a capable programmer and wouldn't mind getting my hands dirty
>> in the code to implement this if someone could point me in the right
>> direction.
>
> The problem is that unpacked objects have the single line header
> (type followed by its inflated size in decimal) which starts the
> deflated stream, while in-pack representation of non-delta does
> not.
>
> There was an attempt to help doing this, but I haven't pursued it.
>
> http://article.gmane.org/gmane.comp.version-control.git/17368
>
>
Wouldn't it make more sense to convert the unpacked object reprasentation
to the one which is used in the pack files?
This would make it really easy to just copy the object in the non-delta
case to the pack and avoid the inflate/deflate calls.
Peter Baumann
^ permalink raw reply
* Re: merge-base: update the clean-up postprocessing
From: Johannes Schindelin @ 2006-07-11 14:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, A Large Angry SCM
In-Reply-To: <7vpsgc4kze.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 11 Jul 2006, Junio C Hamano wrote:
> * The difference in processing time for 941 two-head merges
> with both versions is lost within margin of error.
You convinced me.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Install built-ins as symlinks
From: Johannes Schindelin @ 2006-07-11 14:16 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <11526131792377-git-send-email-alp@atoker.com>
Hi,
On Tue, 11 Jul 2006, Alp Toker wrote:
> Doing this now will save headache in the long run, avoiding mismatched
> versions of installed utilities and dangling copies of removed or
> renamed git commands that still appear to work. It also makes screwups
> when packaging git or making system backups less likely.
Could we please fix things, which are broken? Not things which work?
Ciao,
Dscho
^ permalink raw reply
* Re: Why doesn't git-rerere automatically commit a resolution?
From: Shawn Pearce @ 2006-07-11 13:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xn06310.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Not merging the index after rerere re-applies a previous
> resolution to the working tree file is a deliberate design
> decision. During conflict resolution, "git diff" against
> unmerged index file is the second most useful command to check
> your hand-merge result, and running update-index on these path
> automatically robs this useful tool from the user. So, in order
> to help more disciplined workflow, a bit of convenience for
> lazier people is sacrficed here.
OK, I agree with all of the above. Except in the following case:
git update-ref BACKUP HEAD
git pull . sp/topicA
git pull . sp/topicB
..fix conflicts..
git commit -F .git/MERGE_MSG
git reset --hard BACKUP
git pull . sp/topicA
git pull . sp/topicB
..ah, come on!..
By pulling the exact same two heads together in the exact same
order I would expect the exact same merge result. And since I
have git-rerere enabled I would expect it to autocommit the result
of the merge as I have already checked it before and verified its
correct when I first fixed the conflicts.
After reading your message I agree with you however that pulling in
the reverse direction (e.g. topicB then topicA) shouldn't autocommit
the merge result as I haven't hand verified it to be correct - yet.
However if I do and I merge it again later with the same two commits
then it should still be correct.
Further if I alter sp/topicA by changing a file path which wasn't
conflicted in the merge with sp/topicB I would expect it to
carry out the merge assuming the conflicts were remembered as-is.
Because that's what a trivial in-index merge would do and that will
commit despite conflicts possibly existing between files.
I guess what I'm saying is maybe git-rerere (or git-merge in general)
could benefit from a slightly higher level cache. Store 4 sets
of (mode, sha1) tuples: stage1 stage2 stage3 result in a cache
somewhere. If you get a conflicted merge which has been previously
fixed by hand wherein all 3 stages in the index are found in the
cache then update the index and working directory with the result
(mode, sha1) tuple.
If any of the 3 stages differs then fall back to git-rerere and
attempt a file level merge, stopping before commit to allow the
user to verify (and possibly correct) the resulting merge.
One advantage of this higher level cache is it can be used for
binary files which `merge` can't normally process, as well as for
structual conflicts.
Thoughts? I can prototype this higher level cache into git-rerere
later tonight after I get home from work.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] gitweb: Include a site name in page titles
From: Martin Langhoff @ 2006-07-11 11:48 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <1152613179634-git-send-email-alp@atoker.com>
> +# name of your site or organization to appear in page titles
> +our $site_name = "Untitled";
I generally agree, but as a default, $ENV{SERVER_NAME} should be better.
cheers,
martin
^ 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