* Re: [PATCH] We do not like "HEAD" as a new branch name
From: Johannes Schindelin @ 2005-12-15 16:40 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git, junkio
In-Reply-To: <43A19962.2000202@zytor.com>
Hi,
On Thu, 15 Dec 2005, H. Peter Anvin wrote:
> Johannes Schindelin wrote:
> > This makes git-check-ref-format fail for "HEAD". Since the check is only
> > executed when creating refs, the existing symbolic ref is safe.
>
> > diff --git a/refs.c b/refs.c
> > index bda45f7..293bfe7 100644
> > --- a/refs.c
> > +++ b/refs.c
> > @@ -332,6 +332,11 @@ int check_ref_format(const char *ref)
> > if (ch == '.' || bad_ref_char(ch))
> > return -1;
> > + /* do not allow "HEAD" as ref name */
> > + if (ch == 'H' && (!strcmp(cp, "EAD") ||
> > + !strncmp(cp, "EAD/", 4)))
> > + return -1;
> > +
> > /* scan the rest of the path component */
> > while ((ch = *cp++) != 0) {
>
> If you're have to open-code it, you might want to just do it all the way:
>
> if (ch == 'H' && cp[0] == 'E' && cp[1] == 'A' && cp[2] == 'D' &&
> (cp[3] == '\0' || cp[3] == '/'))
;-)
I don't really care. I could have used !strcmp(cp - 1, "HEAD"), just as
well...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] We do not like "HEAD" as a new branch name
From: H. Peter Anvin @ 2005-12-15 16:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0512151244230.22400@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> This makes git-check-ref-format fail for "HEAD". Since the check is only
> executed when creating refs, the existing symbolic ref is safe.
> diff --git a/refs.c b/refs.c
> index bda45f7..293bfe7 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -332,6 +332,11 @@ int check_ref_format(const char *ref)
> if (ch == '.' || bad_ref_char(ch))
> return -1;
>
> + /* do not allow "HEAD" as ref name */
> + if (ch == 'H' && (!strcmp(cp, "EAD") ||
> + !strncmp(cp, "EAD/", 4)))
> + return -1;
> +
> /* scan the rest of the path component */
> while ((ch = *cp++) != 0) {
If you're have to open-code it, you might want to just do it all the way:
if (ch == 'H' && cp[0] == 'E' && cp[1] == 'A' && cp[2] == 'D' &&
(cp[3] == '\0' || cp[3] == '/'))
-hpa
^ permalink raw reply
* [PATCH] small cleanup for diff-delta.c
From: Nicolas Pitre @ 2005-12-15 16:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch removes unused remnants of the original xdiff source.
No functional change. Possible tiny speed improvement.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/diff-delta.c b/diff-delta.c
index b2ae7b5..890986e 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -84,20 +84,15 @@ typedef struct s_chanode {
} chanode_t;
typedef struct s_chastore {
- chanode_t *head, *tail;
int isize, nsize;
chanode_t *ancur;
- chanode_t *sncur;
- int scurr;
} chastore_t;
static void cha_init(chastore_t *cha, int isize, int icount)
{
- cha->head = cha->tail = NULL;
cha->isize = isize;
cha->nsize = icount * isize;
- cha->ancur = cha->sncur = NULL;
- cha->scurr = 0;
+ cha->ancur = NULL;
}
static void *cha_alloc(chastore_t *cha)
@@ -111,12 +106,7 @@ static void *cha_alloc(chastore_t *cha)
if (!ancur)
return NULL;
ancur->icurr = 0;
- ancur->next = NULL;
- if (cha->tail)
- cha->tail->next = ancur;
- if (!cha->head)
- cha->head = ancur;
- cha->tail = ancur;
+ ancur->next = cha->ancur;
cha->ancur = ancur;
}
@@ -127,7 +117,7 @@ static void *cha_alloc(chastore_t *cha)
static void cha_free(chastore_t *cha)
{
- chanode_t *cur = cha->head;
+ chanode_t *cur = cha->ancur;
while (cur) {
chanode_t *tmp = cur;
cur = cur->next;
@@ -142,7 +132,6 @@ typedef struct s_bdrecord {
} bdrecord_t;
typedef struct s_bdfile {
- const unsigned char *data, *top;
chastore_t cha;
unsigned int fphbits;
bdrecord_t **fphash;
@@ -152,7 +141,7 @@ static int delta_prepare(const unsigned
{
unsigned int fphbits;
int i, hsize;
- const unsigned char *base, *data, *top;
+ const unsigned char *data, *top;
bdrecord_t *brec;
bdrecord_t **fphash;
@@ -165,13 +154,12 @@ static int delta_prepare(const unsigned
fphash[i] = NULL;
cha_init(&bdf->cha, sizeof(bdrecord_t), hsize / 4 + 1);
- bdf->data = data = base = buf;
- bdf->top = top = buf + bufsize;
- data += (bufsize / BLK_SIZE) * BLK_SIZE;
+ top = buf + bufsize;
+ data = buf + (bufsize / BLK_SIZE) * BLK_SIZE;
if (data == top)
data -= BLK_SIZE;
- for ( ; data >= base; data -= BLK_SIZE) {
+ for ( ; data >= buf; data -= BLK_SIZE) {
brec = cha_alloc(&bdf->cha);
if (!brec) {
cha_free(&bdf->cha);
@@ -208,7 +196,7 @@ void *diff_delta(void *from_buf, unsigne
{
int i, outpos, outsize, inscnt, csize, msize, moff;
unsigned int fp;
- const unsigned char *data, *top, *ptr1, *ptr2;
+ const unsigned char *ref_data, *ref_top, *data, *top, *ptr1, *ptr2;
unsigned char *out, *orig;
bdrecord_t *brec;
bdfile_t bdf;
@@ -224,6 +212,8 @@ void *diff_delta(void *from_buf, unsigne
return NULL;
}
+ ref_data = from_buf;
+ ref_top = from_buf + from_size;
data = to_buf;
top = to_buf + to_size;
@@ -253,7 +243,7 @@ void *diff_delta(void *from_buf, unsigne
i = HASH(fp, bdf.fphbits);
for (brec = bdf.fphash[i]; brec; brec = brec->next) {
if (brec->fp == fp) {
- csize = bdf.top - brec->ptr;
+ csize = ref_top - brec->ptr;
if (csize > top - data)
csize = top - data;
for (ptr1 = brec->ptr, ptr2 = data;
@@ -262,7 +252,7 @@ void *diff_delta(void *from_buf, unsigne
csize = ptr1 - brec->ptr;
if (csize > msize) {
- moff = brec->ptr - bdf.data;
+ moff = brec->ptr - ref_data;
msize = csize;
if (msize >= 0x10000) {
msize = 0x10000;
^ permalink raw reply related
* Re: Now what: multiple HEAD refs
From: Alex Riesen @ 2005-12-15 15:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0512151638260.3104@wbgn013.biozentrum.uni-wuerzburg.de>
On 12/15/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > not make any sense to me; I am puzzled ... what are you trying
> > > to achieve with "git pull . ref1:HEAD"?
> >
> > merge branch ref1 into current. Is that not a correct refspec?
>
> No, it is not correct. To pull means that you want to merge the fetched
> ref (your ref1), and store the result in the current branch.
>
> But if you write "ref1:HEAD", you pretend that you want to fast-forward
> the local branch "HEAD" to ref1, and get an error if it is not
> forwardable.
>
> In your case, I guess, "git pull ref1" is what you meant.
I did, I guess...
Confused now.
^ permalink raw reply
* Re: Now what: multiple HEAD refs
From: Johannes Schindelin @ 2005-12-15 15:40 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <81b0412b0512150654o49e1edacu67b88df6347736d2@mail.gmail.com>
Hi,
On Thu, 15 Dec 2005, Alex Riesen wrote:
> > not make any sense to me; I am puzzled ... what are you trying
> > to achieve with "git pull . ref1:HEAD"?
>
> merge branch ref1 into current. Is that not a correct refspec?
No, it is not correct. To pull means that you want to merge the fetched
ref (your ref1), and store the result in the current branch.
But if you write "ref1:HEAD", you pretend that you want to fast-forward
the local branch "HEAD" to ref1, and get an error if it is not
forwardable.
In your case, I guess, "git pull ref1" is what you meant.
Hth,
Dscho
^ permalink raw reply
* gitk: (un)interesting files/hunks diffs
From: Santi Béjar @ 2005-12-15 15:24 UTC (permalink / raw)
To: Git Mailing List
Hello *,
when viewing a merge diff in gitk it discards all files that merge
cleanly (the whole file). It could be usefull to list the files in the
file list with the color of the corresponding "winning" parent.
Another thing that could be usefull is to make the (un)interesting
test at the hunk level, so you could clearly see only the edits
made manually during the merge.
Thanks.
Santi
--
Looking for signature...
Looking for signature...done
^ permalink raw reply
* Re: Now what: multiple HEAD refs
From: Alex Riesen @ 2005-12-15 15:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0daphmf.fsf@assigned-by-dhcp.cox.net>
On 12/15/05, Junio C Hamano <junkio@cox.net> wrote:
> >> I think the reason why my trial here worked correctly while you
> >> had trouble with it is because I have the send-pack fix from
> >> Pasky last night.
> >
> > yes, probably. It cleanups a reference if there was an error, right?
>
> Not really. send-pack does not have anything to do with this
> (it is involved in git-push not git-pull). Care to see how
> yours gets broken when you do "sh -x git-pull.sh . ref1 HEAD"?
I tried. Interesting: no refs/heads/HEAD. But, then I tried "ref1:HEAD":
broken-HEAD /d/download/git2 [822]
PATH=".:$PATH" sh -x git-pull . lf-usage:HEAD
+ . git-sh-setup
++ unset CDPATH
++ : .git
++ : .git/objects
++ GIT_DIR=.git
++ git-var GIT_AUTHOR_IDENT
+ strategy_args=
+ no_summary=
+ no_commit=
+ break
++ git-rev-parse --verify HEAD
+ orig_head=5a0b59da20d832fcfdf864b522718acbc2171525
+ git-fetch --update-head-ok . lf-usage:HEAD
* refs/heads/HEAD: storing branch 'lf-usage' of .
++ git-rev-parse --verify HEAD
git-rev-parse: fatal: Needed a single revision
+ curr_head=
+ test '' '!=' 5a0b59da20d832fcfdf864b522718acbc2171525
+ echo 'Warning: fetch updated the current branch head.'
Warning: fetch updated the current branch head.
+ echo 'Warning: fast forwarding your working tree.'
Warning: fast forwarding your working tree.
+ git-read-tree -u -m 5a0b59da20d832fcfdf864b522718acbc2171525 ''
usage: git-read-tree (<sha> | -m [-u | -i] <sha1> [<sha2> [<sha3>]])
+ die 'You need to first update your working tree.'
+ echo 'You need to first update your working tree.'
You need to first update your working tree.
+ exit 1
And of course, there was refs/heads/HEAD now.
So it seems that I _had_ typed it with a colon (though I'm very sure I
did it with a space as well). Sorry for the whole confusion, but that
reveals that other problem, which Johannes' patch partially helps
with.
^ permalink raw reply
* gitk: color in the merge diffs
From: Santi Béjar @ 2005-12-15 15:13 UTC (permalink / raw)
To: Git Mailing List
Hello *,
In the diff of a merge it is used some colors for the parents, red
for the first parent, blue for the second, then green, purple,
brown, and the rest are grey. It would help to remember this code
if the Parent's line in the comments used the same colors.
Parent: 2db8aaeca1dca4e940829b87d1164e5b42ff49b4 (rebase: ....)
Parent: b3f041fb0f7de167dbb6711b0a231d36c4b5de08 (git-am ...)
^^^^ in red the first and blue the second...
Thanks.
^ permalink raw reply
* Re: Now what: multiple HEAD refs
From: Alex Riesen @ 2005-12-15 14:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkymph4f.fsf@assigned-by-dhcp.cox.net>
On 12/15/05, Junio C Hamano <junkio@cox.net> wrote:
> >> >
> >> > $ git pull . ref1 HEAD (notice the space!)
> >>
> >> If you were too used to git merge, you would have wrote
> >> HEAD before ref1, so that does not sound plausible ;-).
> >
> > no, that I have remembered. What I constantly forget is the
> > space-vs-colon difference.
>
> That statement sounds as if "git pull . ref1:HEAD" makes some
> sense and you typed it without colon by mistake. But it does
exactly.
> not make any sense to me; I am puzzled ... what are you trying
> to achieve with "git pull . ref1:HEAD"?
merge branch ref1 into current. Is that not a correct refspec?
^ permalink raw reply
* Re: Now what: multiple HEAD refs
From: Junio C Hamano @ 2005-12-15 14:30 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0512150216w295a5943ma66522befe381529@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> On 12/15/05, Junio C Hamano <junkio@cox.net> wrote:
>
>> >
>> > $ git pull . ref1 HEAD (notice the space!)
>>
>> If you were too used to git merge, you would have wrote
>> HEAD before ref1, so that does not sound plausible ;-).
>
> no, that I have remembered. What I constantly forget is the
> space-vs-colon difference.
That statement sounds as if "git pull . ref1:HEAD" makes some
sense and you typed it without colon by mistake. But it does
not make any sense to me; I am puzzled ... what are you trying
to achieve with "git pull . ref1:HEAD"?
The patch from Johannes feels right but I haven't had caffeine
yet, so..
^ permalink raw reply
* Re: Now what: multiple HEAD refs
From: Junio C Hamano @ 2005-12-15 14:19 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0512150216w295a5943ma66522befe381529@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> On 12/15/05, Junio C Hamano <junkio@cox.net> wrote:
>> I think the reason why my trial here worked correctly while you
>> had trouble with it is because I have the send-pack fix from
>> Pasky last night.
>
> yes, probably. It cleanups a reference if there was an error, right?
Not really. send-pack does not have anything to do with this
(it is involved in git-push not git-pull). Care to see how
yours gets broken when you do "sh -x git-pull.sh . ref1 HEAD"?
If .git/refs/heads/HEAD exists in the first place then I would
understand it would not fail with the error message I quoted,
but the original message from you indicated that "git pull" is
the one that creates the breakage, and I am trying to see how.
^ permalink raw reply
* [PATCH] We do not like "HEAD" as a new branch name
From: Johannes Schindelin @ 2005-12-15 11:46 UTC (permalink / raw)
To: git, junkio
This makes git-check-ref-format fail for "HEAD". Since the check is only
executed when creating refs, the existing symbolic ref is safe.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This patch was triggered by Alex' mail. Even if it should be a
rare case, it could catch some bad errors: Just try to run
git checkout -b HEAD
and imagine what a regular git user makes of the error
message...
refs.c | 5 +++++
t/t3300-funny-names.sh | 2 ++
2 files changed, 7 insertions(+), 0 deletions(-)
04d60f0bf743f91d03e03acebf123db527cb7507
diff --git a/refs.c b/refs.c
index bda45f7..293bfe7 100644
--- a/refs.c
+++ b/refs.c
@@ -332,6 +332,11 @@ int check_ref_format(const char *ref)
if (ch == '.' || bad_ref_char(ch))
return -1;
+ /* do not allow "HEAD" as ref name */
+ if (ch == 'H' && (!strcmp(cp, "EAD") ||
+ !strncmp(cp, "EAD/", 4)))
+ return -1;
+
/* scan the rest of the path component */
while ((ch = *cp++) != 0) {
if (bad_ref_char(ch))
diff --git a/t/t3300-funny-names.sh b/t/t3300-funny-names.sh
index 897c378..8ebd896 100755
--- a/t/t3300-funny-names.sh
+++ b/t/t3300-funny-names.sh
@@ -139,4 +139,6 @@ test_expect_success 'git-apply non-git d
git-apply --stat | sed -e "s/|.*//" -e "s/ *\$//" >current &&
diff -u expected current'
+test_expect_failure 'HEAD is special' 'git checkout -b HEAD'
+
test_done
--
0.99.9.GIT
^ permalink raw reply related
* Re: Now what: multiple HEAD refs
From: Alex Riesen @ 2005-12-15 10:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xumr9mw.fsf@assigned-by-dhcp.cox.net>
On 12/15/05, Junio C Hamano <junkio@cox.net> wrote:
> > just a heads-up for everyone tried "git pull" after using "git merge" too much:
> >
> > $ git pull . ref1 HEAD (notice the space!)
>
> If you were too used to git merge, you would have wrote
> HEAD before ref1, so that does not sound plausible ;-).
no, that I have remembered. What I constantly forget is the
space-vs-colon difference.
> $ git pull . maint HEAD
> error: no such remote ref refs/heads/HEAD
> Fetch failure: .
> $ echo $?
> 1
>
> But worse yet, the above syntax is to create an Octopus, and you
> probably did not mean that.
no, of course not.
> I think the reason why my trial here worked correctly while you
> had trouble with it is because I have the send-pack fix from
> Pasky last night.
yes, probably. It cleanups a reference if there was an error, right?
^ permalink raw reply
* Re: Now what: multiple HEAD refs
From: Junio C Hamano @ 2005-12-15 9:29 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0512150105p5bacd6a1j938824ae2ab96858@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> just a heads-up for everyone tried "git pull" after using "git merge" too much:
>
> $ git pull . ref1 HEAD (notice the space!)
If you were too used to git merge, you would have wrote
HEAD before ref1, so that does not sound plausible ;-).
$ git pull . maint HEAD
error: no such remote ref refs/heads/HEAD
Fetch failure: .
$ echo $?
1
But worse yet, the above syntax is to create an Octopus, and you
probably did not mean that.
I think the reason why my trial here worked correctly while you
had trouble with it is because I have the send-pack fix from
Pasky last night.
^ permalink raw reply
* Now what: multiple HEAD refs
From: Alex Riesen @ 2005-12-15 9:05 UTC (permalink / raw)
To: git
Hi,
just a heads-up for everyone tried "git pull" after using "git merge" too much:
$ git pull . ref1 HEAD (notice the space!)
will happily create refs/heads/HEAD. What happens next is not easily
to understand: all files suddenly declared "New" by "git status", "git
checkout" does not work, reporting "Need a single revision" (which is
actually _the_ hint here).
The solution is simple: remove .git/refs/heads/HEAD
Maybe "git fsck-object" can hint on multiple HEADS?
^ permalink raw reply
* Re: [PATCH] \n usage in stderr output
From: Alex Riesen @ 2005-12-15 8:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Junio C Hamano
In-Reply-To: <20051215085242.GO22159@pasky.or.cz>
On 12/15/05, Petr Baudis <pasky@suse.cz> wrote:
> > fprintf and die sometimes have missing/excessive "\n" in their arguments,
> > correct the strings where I think it would be appropriate.
>
> Why don't we just error() or die() at those places anyway?
>
I don't know.
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.16.2
From: Petr Baudis @ 2005-12-15 8:56 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200512150657.53622.alan@chandlerfamily.org.uk>
Dear diary, on Thu, Dec 15, 2005 at 07:57:52AM CET, I got a letter
where Alan Chandler <alan@chandlerfamily.org.uk> said that...
> On Wednesday 14 December 2005 23:10, Petr Baudis wrote:
> ...
> > Also, Cogito is now very ineffective when cloning big-packed
> > repositories over the git protocol or over ssh, since git-fetch-pack
> > unpacks the objects on the local side, which bogs things down a lot and
> > makes the repository grow into enormous proportions - I'm not yet sure
> > if I will backport the fix to 0.16 since I want to be maximally careful
> > not to gravely break anything again and keep 0.16 as stable as possible.
> > (Hm. Call this "the Debian dilemma". ;-)
>
> Note sure what your Debian dilemma is.
Well, I meant this in a general sense - in the stable Debian branch,
there's also this dilemma about how grave bugfixes to still merge,
without risking another bug induced by those.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] \n usage in stderr output
From: Petr Baudis @ 2005-12-15 8:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0512142347o6e9aaef8s227ad749f3e2a475@mail.gmail.com>
Dear diary, on Thu, Dec 15, 2005 at 08:47:30AM CET, I got a letter
where Alex Riesen <raa.lkml@gmail.com> said that...
> fprintf and die sometimes have missing/excessive "\n" in their arguments,
> correct the strings where I think it would be appropriate.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Why don't we just error() or die() at those places anyway?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Tracking files across tree reorganizations
From: H. Peter Anvin @ 2005-12-15 8:12 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90512142138x77e57850ib095c1d68ecdfd13@mail.gmail.com>
Martin Langhoff wrote:
> On 12/15/05, H. Peter Anvin <hpa@zytor.com> wrote:
>
>>Did anything ever happen with that?
>
> Perhaps I'm slow today, but git-merge -s recursive was supposed to do
> it transparently (automagically). At least it was merged into git with
> that excuse ;-)
>
> Does it not work for you or am I missing something?
>
I'll try it.
-hpa
^ permalink raw reply
* [PATCH] \n usage in stderr output
From: Alex Riesen @ 2005-12-15 7:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 267 bytes --]
fprintf and die sometimes have missing/excessive "\n" in their arguments,
correct the strings where I think it would be appropriate.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
It is always stderr, so I can hope I am not breaking anyones script...
[-- Attachment #2: 0001-n-usage-in-stderr-output-fprintf-and-die-correct-where-appropriate.txt --]
[-- Type: text/plain, Size: 3796 bytes --]
Subject: [PATCH] \n usage in stderr output (fprintf and die), correct where appropriate
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
---
config.c | 2 +-
git.c | 2 +-
receive-pack.c | 2 +-
sha1_file.c | 8 ++++----
show-branch.c | 4 ++--
5 files changed, 9 insertions(+), 9 deletions(-)
ef105f6fe8c86d9191db8c25a70abdf272fa35db
diff --git a/config.c b/config.c
index 5b5a9a2..992e988 100644
--- a/config.c
+++ b/config.c
@@ -487,7 +487,7 @@ int git_config_set_multivar(const char*
store.value_regex = (regex_t*)malloc(sizeof(regex_t));
if (regcomp(store.value_regex, value_regex,
REG_EXTENDED)) {
- fprintf(stderr, "Invalid pattern: %s",
+ fprintf(stderr, "Invalid pattern: %s\n",
value_regex);
free(store.value_regex);
return 6;
diff --git a/git.c b/git.c
index c26cac6..5939edf 100644
--- a/git.c
+++ b/git.c
@@ -264,7 +264,7 @@ int main(int argc, char **argv, char **e
if (*exec_path != '/') {
if (!getcwd(git_command, sizeof(git_command))) {
fprintf(stderr,
- "git: cannot determine current directory");
+ "git: cannot determine current directory\n");
exit(1);
}
len = strlen(git_command);
diff --git a/receive-pack.c b/receive-pack.c
index cbe37e7..92878ec 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -79,7 +79,7 @@ static int run_update_hook(const char *r
case -ERR_RUN_COMMAND_WAITPID_WRONG_PID:
die("waitpid is confused");
case -ERR_RUN_COMMAND_WAITPID_SIGNAL:
- fprintf(stderr, "%s died of signal", update_hook);
+ fprintf(stderr, "%s died of signal\n", update_hook);
return -1;
case -ERR_RUN_COMMAND_WAITPID_NOEXIT:
die("%s died strangely", update_hook);
diff --git a/sha1_file.c b/sha1_file.c
index fa22e9c..8db5074 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1274,7 +1274,7 @@ int move_temp_to_file(const char *tmpfil
unlink(tmpfile);
if (ret) {
if (ret != EEXIST) {
- fprintf(stderr, "unable to write sha1 filename %s: %s", filename, strerror(ret));
+ fprintf(stderr, "unable to write sha1 filename %s: %s\n", filename, strerror(ret));
return -1;
}
/* FIXME!!! Collision check here ? */
@@ -1313,7 +1313,7 @@ int write_sha1_file(void *buf, unsigned
}
if (errno != ENOENT) {
- fprintf(stderr, "sha1 file %s: %s", filename, strerror(errno));
+ fprintf(stderr, "sha1 file %s: %s\n", filename, strerror(errno));
return -1;
}
@@ -1321,7 +1321,7 @@ int write_sha1_file(void *buf, unsigned
fd = mkstemp(tmpfile);
if (fd < 0) {
- fprintf(stderr, "unable to create temporary sha1 filename %s: %s", tmpfile, strerror(errno));
+ fprintf(stderr, "unable to create temporary sha1 filename %s: %s\n", tmpfile, strerror(errno));
return -1;
}
@@ -1410,7 +1410,7 @@ int write_sha1_to_fd(int fd, const unsig
size = write(fd, buf + posn, objsize - posn);
if (size <= 0) {
if (!size) {
- fprintf(stderr, "write closed");
+ fprintf(stderr, "write closed\n");
} else {
perror("write ");
}
diff --git a/show-branch.c b/show-branch.c
index ab158eb..f3522b7 100644
--- a/show-branch.c
+++ b/show-branch.c
@@ -303,7 +303,7 @@ static int append_ref(const char *refnam
return 0;
if (MAX_REVS <= ref_name_cnt) {
fprintf(stderr, "warning: ignoring %s; "
- "cannot handle more than %d refs",
+ "cannot handle more than %d refs\n",
refname, MAX_REVS);
return 0;
}
@@ -535,7 +535,7 @@ int main(int ac, char **av)
if (MAX_REVS <= num_rev)
die("cannot handle more than %d revs.", MAX_REVS);
if (get_sha1(ref_name[num_rev], revkey))
- die("'%s' is not a valid ref.\n", ref_name[num_rev]);
+ die("'%s' is not a valid ref.", ref_name[num_rev]);
commit = lookup_commit_reference(revkey);
if (!commit)
die("cannot find commit %s (%s)",
--
0.99.9.GIT
^ permalink raw reply related
* Re: [ANNOUNCE] Cogito-0.16.2
From: Alan Chandler @ 2005-12-15 6:57 UTC (permalink / raw)
To: git
In-Reply-To: <20051214231019.GK22159@pasky.or.cz>
On Wednesday 14 December 2005 23:10, Petr Baudis wrote:
...
> Also, Cogito is now very ineffective when cloning big-packed
> repositories over the git protocol or over ssh, since git-fetch-pack
> unpacks the objects on the local side, which bogs things down a lot and
> makes the repository grow into enormous proportions - I'm not yet sure
> if I will backport the fix to 0.16 since I want to be maximally careful
> not to gravely break anything again and keep 0.16 as stable as possible.
> (Hm. Call this "the Debian dilemma". ;-)
Note sure what your Debian dilemma is. Right now, Debian (Unstable) seems
broken, because cogito is still at 0.16.0 and hickups on the bash 3.1 issue
discussed in an earlier thread. Having updated to the debian version from my
earlier self built version earlier this week, I immediately found I couldn't
commit.
After waiting a day for the next release to filter through and it not doing
so, I had to rebuild my own version again - and as far as I am aware, despite
a new version of git-core arriving on my "update" this morning, there has
been no new cogito package.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: How to clone-pack the HEAD?
From: Junio C Hamano @ 2005-12-15 6:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vpsnzq66x.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Also I might want to give --keep option to fetch-pack as well;
> clone-pack has some static functions that we can extract out to
> a common file to link to both.
And this is the second installment, on top of the previous one.
I am a bit reluctant about this one only because of its size,
but I suspect it may be much easier to use for your purpose.
I'll keep this in the proposed updates branch for now (the other
one goes to master tonight), so if you like this one, please
holler, test out and ack.
-- >8 --
Subject: [PATCH] fetch-pack: -k option to keep downloaded pack.
Split out the functions that deal with the socketpair after
finishing git protocol handshake to receive the packed data into
a separate file, and use it in fetch-pack to keep/explode the
received pack data. We earlier had something like that on
clone-pack side once, but the list discussion resulted in the
decision that it makes sense to always keep the pack for
clone-pack, so unpacking option is not enabled on the clone-pack
side, but we later still could do so easily if we wanted to with
this change.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-fetch-pack.txt | 7 +-
Makefile | 1
cache.h | 5 +
clone-pack.c | 136 ------------------------------
fetch-clone.c | 172 ++++++++++++++++++++++++++++++++++++++
fetch-pack.c | 58 +++++--------
6 files changed, 206 insertions(+), 173 deletions(-)
create mode 100644 fetch-clone.c
32cf3b780b1cf77cf2fa7042d31dfe969ad0b9b9
diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
index ea6faab..b507e9b 100644
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@@ -8,7 +8,7 @@ git-fetch-pack - Receive missing objects
SYNOPSIS
--------
-git-fetch-pack [-q] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...]
+git-fetch-pack [-q] [-k] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...]
DESCRIPTION
-----------
@@ -29,6 +29,11 @@ OPTIONS
Pass '-q' flag to 'git-unpack-objects'; this makes the
cloning process less verbose.
+-k::
+ Do not invoke 'git-unpack-objects' on received data, but
+ create a single packfile out of it instead, and store it
+ in the object database.
+
--exec=<git-upload-pack>::
Use this to specify the path to 'git-upload-pack' on the
remote side, if is not found on your $PATH.
diff --git a/Makefile b/Makefile
index d494ad4..9fd2ed3 100644
--- a/Makefile
+++ b/Makefile
@@ -175,6 +175,7 @@ LIB_OBJS = \
quote.o read-cache.o refs.o run-command.o \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
tag.o tree.o usage.o config.o environment.o ctype.o copy.o \
+ fetch-clone.o \
$(DIFF_OBJS)
LIBS = $(LIB_FILE)
diff --git a/cache.h b/cache.h
index c78d8ae..cb87bec 100644
--- a/cache.h
+++ b/cache.h
@@ -338,4 +338,9 @@ extern char git_default_name[MAX_GITNAME
extern char git_commit_encoding[MAX_ENCODING_LENGTH];
extern int copy_fd(int ifd, int ofd);
+
+/* Finish off pack transfer receiving end */
+extern int receive_unpack_pack(int fd[2], const char *me, int quiet);
+extern int receive_keep_pack(int fd[2], const char *me);
+
#endif /* CACHE_H */
diff --git a/clone-pack.c b/clone-pack.c
index b5ce5d3..03dbc2e 100644
--- a/clone-pack.c
+++ b/clone-pack.c
@@ -1,7 +1,6 @@
#include "cache.h"
#include "refs.h"
#include "pkt-line.h"
-#include <sys/wait.h>
static const char clone_pack_usage[] =
"git-clone-pack [--exec=<git-upload-pack>] [<host>:]<directory> [<heads>]*";
@@ -112,139 +111,6 @@ static void write_refs(struct ref *ref)
free(head_path);
}
-static int finish_pack(const char *pack_tmp_name)
-{
- int pipe_fd[2];
- pid_t pid;
- char idx[PATH_MAX];
- char final[PATH_MAX];
- char hash[41];
- unsigned char sha1[20];
- char *cp;
- int err = 0;
-
- if (pipe(pipe_fd) < 0)
- die("git-clone-pack: unable to set up pipe");
-
- strcpy(idx, pack_tmp_name); /* ".git/objects/pack-XXXXXX" */
- cp = strrchr(idx, '/');
- memcpy(cp, "/pidx", 5);
-
- pid = fork();
- if (pid < 0)
- die("git-clone-pack: unable to fork off git-index-pack");
- if (!pid) {
- close(0);
- dup2(pipe_fd[1], 1);
- close(pipe_fd[0]);
- close(pipe_fd[1]);
- execlp("git-index-pack","git-index-pack",
- "-o", idx, pack_tmp_name, NULL);
- error("cannot exec git-index-pack <%s> <%s>",
- idx, pack_tmp_name);
- exit(1);
- }
- close(pipe_fd[1]);
- if (read(pipe_fd[0], hash, 40) != 40) {
- error("git-clone-pack: unable to read from git-index-pack");
- err = 1;
- }
- close(pipe_fd[0]);
-
- for (;;) {
- int status, code;
- int retval = waitpid(pid, &status, 0);
-
- if (retval < 0) {
- if (errno == EINTR)
- continue;
- error("waitpid failed (%s)", strerror(retval));
- goto error_die;
- }
- if (WIFSIGNALED(status)) {
- int sig = WTERMSIG(status);
- error("git-index-pack died of signal %d", sig);
- goto error_die;
- }
- if (!WIFEXITED(status)) {
- error("git-index-pack died of unnatural causes %d",
- status);
- goto error_die;
- }
- code = WEXITSTATUS(status);
- if (code) {
- error("git-index-pack died with error code %d", code);
- goto error_die;
- }
- if (err)
- goto error_die;
- break;
- }
- hash[40] = 0;
- if (get_sha1_hex(hash, sha1)) {
- error("git-index-pack reported nonsense '%s'", hash);
- goto error_die;
- }
- /* Now we have pack in pack_tmp_name[], and
- * idx in idx[]; rename them to their final names.
- */
- snprintf(final, sizeof(final),
- "%s/pack/pack-%s.pack", get_object_directory(), hash);
- move_temp_to_file(pack_tmp_name, final);
- chmod(final, 0444);
- snprintf(final, sizeof(final),
- "%s/pack/pack-%s.idx", get_object_directory(), hash);
- move_temp_to_file(idx, final);
- chmod(final, 0444);
- return 0;
-
- error_die:
- unlink(idx);
- unlink(pack_tmp_name);
- exit(1);
-}
-
-static int clone_without_unpack(int fd[2])
-{
- char tmpfile[PATH_MAX];
- int ofd, ifd;
-
- ifd = fd[0];
- snprintf(tmpfile, sizeof(tmpfile),
- "%s/pack/tmp-XXXXXX", get_object_directory());
- ofd = mkstemp(tmpfile);
- if (ofd < 0)
- return error("unable to create temporary file %s", tmpfile);
-
- while (1) {
- char buf[8192];
- ssize_t sz, wsz, pos;
- sz = read(ifd, buf, sizeof(buf));
- if (sz == 0)
- break;
- if (sz < 0) {
- error("error reading pack (%s)", strerror(errno));
- close(ofd);
- unlink(tmpfile);
- return -1;
- }
- pos = 0;
- while (pos < sz) {
- wsz = write(ofd, buf + pos, sz - pos);
- if (wsz < 0) {
- error("error writing pack (%s)",
- strerror(errno));
- close(ofd);
- unlink(tmpfile);
- return -1;
- }
- pos += wsz;
- }
- }
- close(ofd);
- return finish_pack(tmpfile);
-}
-
static int clone_pack(int fd[2], int nr_match, char **match)
{
struct ref *refs;
@@ -257,7 +123,7 @@ static int clone_pack(int fd[2], int nr_
}
clone_handshake(fd, refs);
- status = clone_without_unpack(fd);
+ status = receive_keep_pack(fd, "git-clone-pack");
if (!status) {
if (nr_match == 0)
diff --git a/fetch-clone.c b/fetch-clone.c
new file mode 100644
index 0000000..2b2aa15
--- /dev/null
+++ b/fetch-clone.c
@@ -0,0 +1,172 @@
+#include "cache.h"
+#include <sys/wait.h>
+
+static int finish_pack(const char *pack_tmp_name, const char *me)
+{
+ int pipe_fd[2];
+ pid_t pid;
+ char idx[PATH_MAX];
+ char final[PATH_MAX];
+ char hash[41];
+ unsigned char sha1[20];
+ char *cp;
+ int err = 0;
+
+ if (pipe(pipe_fd) < 0)
+ die("%s: unable to set up pipe", me);
+
+ strcpy(idx, pack_tmp_name); /* ".git/objects/pack-XXXXXX" */
+ cp = strrchr(idx, '/');
+ memcpy(cp, "/pidx", 5);
+
+ pid = fork();
+ if (pid < 0)
+ die("git-clone-pack: unable to fork off git-index-pack");
+ if (!pid) {
+ close(0);
+ dup2(pipe_fd[1], 1);
+ close(pipe_fd[0]);
+ close(pipe_fd[1]);
+ execlp("git-index-pack","git-index-pack",
+ "-o", idx, pack_tmp_name, NULL);
+ error("cannot exec git-index-pack <%s> <%s>",
+ idx, pack_tmp_name);
+ exit(1);
+ }
+ close(pipe_fd[1]);
+ if (read(pipe_fd[0], hash, 40) != 40) {
+ error("%s: unable to read from git-index-pack", me);
+ err = 1;
+ }
+ close(pipe_fd[0]);
+
+ for (;;) {
+ int status, code;
+ int retval = waitpid(pid, &status, 0);
+
+ if (retval < 0) {
+ if (errno == EINTR)
+ continue;
+ error("waitpid failed (%s)", strerror(retval));
+ goto error_die;
+ }
+ if (WIFSIGNALED(status)) {
+ int sig = WTERMSIG(status);
+ error("git-index-pack died of signal %d", sig);
+ goto error_die;
+ }
+ if (!WIFEXITED(status)) {
+ error("git-index-pack died of unnatural causes %d",
+ status);
+ goto error_die;
+ }
+ code = WEXITSTATUS(status);
+ if (code) {
+ error("git-index-pack died with error code %d", code);
+ goto error_die;
+ }
+ if (err)
+ goto error_die;
+ break;
+ }
+ hash[40] = 0;
+ if (get_sha1_hex(hash, sha1)) {
+ error("git-index-pack reported nonsense '%s'", hash);
+ goto error_die;
+ }
+ /* Now we have pack in pack_tmp_name[], and
+ * idx in idx[]; rename them to their final names.
+ */
+ snprintf(final, sizeof(final),
+ "%s/pack/pack-%s.pack", get_object_directory(), hash);
+ move_temp_to_file(pack_tmp_name, final);
+ chmod(final, 0444);
+ snprintf(final, sizeof(final),
+ "%s/pack/pack-%s.idx", get_object_directory(), hash);
+ move_temp_to_file(idx, final);
+ chmod(final, 0444);
+ return 0;
+
+ error_die:
+ unlink(idx);
+ unlink(pack_tmp_name);
+ exit(1);
+}
+
+int receive_unpack_pack(int fd[2], const char *me, int quiet)
+{
+ int status;
+ pid_t pid;
+
+ pid = fork();
+ if (pid < 0)
+ die("%s: unable to fork off git-unpack-objects", me);
+ if (!pid) {
+ dup2(fd[0], 0);
+ close(fd[0]);
+ close(fd[1]);
+ execlp("git-unpack-objects", "git-unpack-objects",
+ quiet ? "-q" : NULL, NULL);
+ die("git-unpack-objects exec failed");
+ }
+ close(fd[0]);
+ close(fd[1]);
+ while (waitpid(pid, &status, 0) < 0) {
+ if (errno != EINTR)
+ die("waiting for git-unpack-objects: %s",
+ strerror(errno));
+ }
+ if (WIFEXITED(status)) {
+ int code = WEXITSTATUS(status);
+ if (code)
+ die("git-unpack-objects died with error code %d",
+ code);
+ return 0;
+ }
+ if (WIFSIGNALED(status)) {
+ int sig = WTERMSIG(status);
+ die("git-unpack-objects died of signal %d", sig);
+ }
+ die("git-unpack-objects died of unnatural causes %d", status);
+}
+
+int receive_keep_pack(int fd[2], const char *me)
+{
+ char tmpfile[PATH_MAX];
+ int ofd, ifd;
+
+ ifd = fd[0];
+ snprintf(tmpfile, sizeof(tmpfile),
+ "%s/pack/tmp-XXXXXX", get_object_directory());
+ ofd = mkstemp(tmpfile);
+ if (ofd < 0)
+ return error("unable to create temporary file %s", tmpfile);
+
+ while (1) {
+ char buf[8192];
+ ssize_t sz, wsz, pos;
+ sz = read(ifd, buf, sizeof(buf));
+ if (sz == 0)
+ break;
+ if (sz < 0) {
+ error("error reading pack (%s)", strerror(errno));
+ close(ofd);
+ unlink(tmpfile);
+ return -1;
+ }
+ pos = 0;
+ while (pos < sz) {
+ wsz = write(ofd, buf + pos, sz - pos);
+ if (wsz < 0) {
+ error("error writing pack (%s)",
+ strerror(errno));
+ close(ofd);
+ unlink(tmpfile);
+ return -1;
+ }
+ pos += wsz;
+ }
+ }
+ close(ofd);
+ return finish_pack(tmpfile, me);
+}
diff --git a/fetch-pack.c b/fetch-pack.c
index 58ba209..2528053 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -3,13 +3,12 @@
#include "pkt-line.h"
#include "commit.h"
#include "tag.h"
-#include <time.h>
-#include <sys/wait.h>
+static int keep_pack;
static int quiet;
static int verbose;
static const char fetch_pack_usage[] =
-"git-fetch-pack [-q] [-v] [--exec=upload-pack] [host:]directory <refs>...";
+"git-fetch-pack [-q] [-v] [-k] [--exec=upload-pack] [host:]directory <refs>...";
static const char *exec = "git-upload-pack";
#define COMPLETE (1U << 0)
@@ -363,7 +362,6 @@ static int fetch_pack(int fd[2], int nr_
struct ref *ref;
unsigned char sha1[20];
int status;
- pid_t pid;
get_remote_heads(fd[0], &ref, 0, NULL, 0);
if (server_supports("multi_ack")) {
@@ -381,40 +379,22 @@ static int fetch_pack(int fd[2], int nr_
}
if (find_common(fd, sha1, ref) < 0)
fprintf(stderr, "warning: no common commits\n");
- pid = fork();
- if (pid < 0)
- die("git-fetch-pack: unable to fork off git-unpack-objects");
- if (!pid) {
- dup2(fd[0], 0);
- close(fd[0]);
- close(fd[1]);
- execlp("git-unpack-objects", "git-unpack-objects",
- quiet ? "-q" : NULL, NULL);
- die("git-unpack-objects exec failed");
- }
- close(fd[0]);
- close(fd[1]);
- while (waitpid(pid, &status, 0) < 0) {
- if (errno != EINTR)
- die("waiting for git-unpack-objects: %s", strerror(errno));
- }
- if (WIFEXITED(status)) {
- int code = WEXITSTATUS(status);
- if (code)
- die("git-unpack-objects died with error code %d", code);
-all_done:
- while (ref) {
- printf("%s %s\n",
- sha1_to_hex(ref->old_sha1), ref->name);
- ref = ref->next;
- }
- return 0;
- }
- if (WIFSIGNALED(status)) {
- int sig = WTERMSIG(status);
- die("git-unpack-objects died of signal %d", sig);
+
+ if (keep_pack)
+ status = receive_keep_pack(fd, "git-fetch-pack");
+ else
+ status = receive_unpack_pack(fd, "git-fetch-pack", quiet);
+
+ if (status)
+ die("git-fetch-pack: fetch failed.");
+
+ all_done:
+ while (ref) {
+ printf("%s %s\n",
+ sha1_to_hex(ref->old_sha1), ref->name);
+ ref = ref->next;
}
- die("Sherlock Holmes! git-unpack-objects died of unnatural causes %d!", status);
+ return 0;
}
int main(int argc, char **argv)
@@ -440,6 +420,10 @@ int main(int argc, char **argv)
quiet = 1;
continue;
}
+ if (!strcmp("-k", arg)) {
+ keep_pack = 1;
+ continue;
+ }
if (!strcmp("-v", arg)) {
verbose = 1;
continue;
--
0.99.9n
^ permalink raw reply related
* [PATCH] svnimport: exit cleanly when we are up to date
From: Martin Langhoff @ 2005-12-15 6:26 UTC (permalink / raw)
To: smurf, git; +Cc: Martin Langhoff
Now we detect that the SVN repo does not have new commits for us and exit
cleanly, removing the lockfile. With this, svnimport supports being run
on a cronjob to maintain a SVN2GIT gateway.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
git-svnimport.perl | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
0116ebb61f1e11b3c43d4e80ac899d81f24a62d4
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 65868a9..cb241d1 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -736,6 +736,13 @@ sub commit_all {
}
$opt_l = $svn->{'maxrev'} if not defined $opt_l or $opt_l > $svn->{'maxrev'};
+
+if ($svn->{'maxrev'} < $current_rev) {
+ print "Up to date: no new revisions to fetch!\n" if $opt_v;
+ unlink("$git_dir/SVN2GIT_HEAD");
+ exit;
+}
+
print "Fetching from $current_rev to $opt_l ...\n" if $opt_v;
my $pool=SVN::Pool->new;
--
0.99.9.GIT
^ permalink raw reply related
* Re: git-svnimport usage with different SVN repo layouts
From: Martin Langhoff @ 2005-12-15 5:54 UTC (permalink / raw)
To: Git Mailing List, Matthias Urlichs
In-Reply-To: <46a038f90512142047n1cf9c927ye26af2c7f77f9b63@mail.gmail.com>
On 12/15/05, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Example:
>
> # this gives me a small repo with 40 commits
> svn co svn://elgg.net/devel
>
> # but I could not get any of this to go
> git-svnimport svn://elgg.net/devel
At last -- success with
git-svnimport -t releases -T devel -b branches svn://elgg.net
and success (at least apparently) with
git-svnimport -v -b branches svn://svn.berlios.de/rtnet
cheers.
martin
^ permalink raw reply
* Re: Tracking files across tree reorganizations
From: Martin Langhoff @ 2005-12-15 5:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: H. Peter Anvin, Linus Torvalds, Git Mailing List
In-Reply-To: <20051215014453.GN22159@pasky.or.cz>
On 12/15/05, Petr Baudis <pasky@suse.cz> wrote:
> in the next few days, consequently making it trivial to add the
> on-the-fly automatic renames detection to per-file cg-log.
Does it matter? Who makes a big file reorg and doesn't put "big tree
reorganization" in the commit message, and can we shoot him?
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