* Re: quick bare clones taking longer?
From: David Miller @ 2007-05-10 0:29 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <7v7irhr08y.fsf@assigned-by-dhcp.cox.net>
From: Junio C Hamano <junkio@cox.net>
Date: Wed, 09 May 2007 17:27:41 -0700
> Side note. Earlier you said:
>
> master.kernel.org just upgraded to git-1.5.1.4 and I notice
> that doing something like this:
>
> git clone --bare -n -l -s ../torvalds/linux-2.6.git test-2.6.git
>
> is no longer an instantaneous operation, it seems to be doing a lot
> of stuff now:
>
> But I do not see any difference between v1.5.1.3 and v1.5.1.4 in
> this area. In fact, that get_repo_base() shell function has not
> changed since v0.99.
Correct. I happened to create and start using that symlink
around the same time they upgraded, that's why I made that
(false) connection.
There is no connection between git version and this problem, it's just
the symlink thing.
^ permalink raw reply
* Re: quick bare clones taking longer?
From: Junio C Hamano @ 2007-05-10 0:27 UTC (permalink / raw)
To: David Miller; +Cc: junkio, git
In-Reply-To: <7vd519r10c.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Junio C Hamano <junkio@cox.net> writes:
>
>> David Miller <davem@davemloft.net> writes:
>>
>>> From: Junio C Hamano <junkio@cox.net>
>>> Date: Wed, 09 May 2007 15:59:23 -0700
>>>
>>>> The above sequence is called before we create the new directory
>>>> and chdir to it. Maybe pwd has funny behaviour (e.g. $PWD) and
>>>> we need to explicitly say /bin/pwd or somesuch...
>>>
>>> Indeed:
>>>
>>> [davem@hera ~]$ pwd
>>> /home/davem
>>> [davem@hera ~]$ cd git
>>> [davem@hera git]$ pwd
>>> /home/davem/git
>>> [davem@hera git]$ /bin/pwd
>>> /home/ftp/pub/scm/linux/kernel/git/davem
>>> [davem@hera git]$
>>
>> Thanks.
>
> This would fix it, but I find this kind of ugly.
Side note. Earlier you said:
master.kernel.org just upgraded to git-1.5.1.4 and I notice
that doing something like this:
git clone --bare -n -l -s ../torvalds/linux-2.6.git test-2.6.git
is no longer an instantaneous operation, it seems to be doing a lot
of stuff now:
But I do not see any difference between v1.5.1.3 and v1.5.1.4 in
this area. In fact, that get_repo_base() shell function has not
changed since v0.99.
^ permalink raw reply
* Re: quick bare clones taking longer?
From: Junio C Hamano @ 2007-05-10 0:11 UTC (permalink / raw)
To: David Miller; +Cc: junkio, git
In-Reply-To: <7vy7jxr35a.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> David Miller <davem@davemloft.net> writes:
>
>> From: Junio C Hamano <junkio@cox.net>
>> Date: Wed, 09 May 2007 15:59:23 -0700
>>
>>> The above sequence is called before we create the new directory
>>> and chdir to it. Maybe pwd has funny behaviour (e.g. $PWD) and
>>> we need to explicitly say /bin/pwd or somesuch...
>>
>> Indeed:
>>
>> [davem@hera ~]$ pwd
>> /home/davem
>> [davem@hera ~]$ cd git
>> [davem@hera git]$ pwd
>> /home/davem/git
>> [davem@hera git]$ /bin/pwd
>> /home/ftp/pub/scm/linux/kernel/git/davem
>> [davem@hera git]$
>
> Thanks.
This would fix it, but I find this kind of ugly.
-- >8 --
git-clone: don't get fooled by $PWD
If you have /home/me/git symlink pointing at /pub/git/mine,
trying to clone from /pub/git/his/ using relative path would not
work as expected:
$ cd /home/me
$ cd git
$ ls ../
his mine
$ git clone -l -s -n ../his/stuff.git
This is because "cd ../his/stuff.git" done inside git-clone to
check if the repository is local is confused by $PWD, which is
set to /home/me, and tries to go to /home/his/stuff.git which is
different from /pub/git/his/stuff.git.
We could probably say "set -P" (or "cd -P") instead, if we know
the shell is POSIX, but the way the patch is coded is probably
more portable.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-clone.sh b/git-clone.sh
index cad5c0c..c5852a2 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -18,7 +18,14 @@ usage() {
}
get_repo_base() {
- (cd "$1" && (cd .git ; pwd)) 2> /dev/null
+ (
+ cd "`/bin/pwd`" &&
+ cd "$1" &&
+ (
+ cd .git
+ pwd
+ )
+ ) 2>/dev/null
}
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
^ permalink raw reply related
* [PATCH] Fix documentation of tag in git-fast-import.txt
From: Richard P. Curnow @ 2007-05-09 22:13 UTC (permalink / raw)
To: git
The tag command does not take a trailing LF.
Signed-off-by: Richard P. Curnow <rc@rc0.org.uk>
---
Documentation/git-fast-import.txt | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index eaba6fd..8d06775 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -548,7 +548,6 @@ lightweight (non-annotated) tags see the `reset` command below.
'from' SP <committish> LF
'tagger' SP <name> SP LT <email> GT SP <when> LF
data
- LF
....
where `<name>` is the name of the tag to create.
--
1.5.1
^ permalink raw reply related
* Re: quick bare clones taking longer?
From: Junio C Hamano @ 2007-05-09 23:25 UTC (permalink / raw)
To: David Miller; +Cc: junkio, git
In-Reply-To: <20070509.162301.48802460.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Junio C Hamano <junkio@cox.net>
> Date: Wed, 09 May 2007 15:59:23 -0700
>
>> The above sequence is called before we create the new directory
>> and chdir to it. Maybe pwd has funny behaviour (e.g. $PWD) and
>> we need to explicitly say /bin/pwd or somesuch...
>
> Indeed:
>
> [davem@hera ~]$ pwd
> /home/davem
> [davem@hera ~]$ cd git
> [davem@hera git]$ pwd
> /home/davem/git
> [davem@hera git]$ /bin/pwd
> /home/ftp/pub/scm/linux/kernel/git/davem
> [davem@hera git]$
Thanks.
^ permalink raw reply
* Re: quick bare clones taking longer?
From: David Miller @ 2007-05-09 23:23 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <7v3b25siwk.fsf@assigned-by-dhcp.cox.net>
From: Junio C Hamano <junkio@cox.net>
Date: Wed, 09 May 2007 15:59:23 -0700
> The above sequence is called before we create the new directory
> and chdir to it. Maybe pwd has funny behaviour (e.g. $PWD) and
> we need to explicitly say /bin/pwd or somesuch...
Indeed:
[davem@hera ~]$ pwd
/home/davem
[davem@hera ~]$ cd git
[davem@hera git]$ pwd
/home/davem/git
[davem@hera git]$ /bin/pwd
/home/ftp/pub/scm/linux/kernel/git/davem
[davem@hera git]$
^ permalink raw reply
* Re: [RFC] Default options
From: Matthieu Moy @ 2007-05-09 23:14 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0705100106250.4167@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 9 May 2007, Dana How wrote:
>
>> I notice git supports "alias.*" config variables.
>> Would it be useful to also support "options.*" variables?
>
> I would not do it, for the same reason we do not allow to override
> builtins via aliases: it breaks scripts.
In any case, I find it a bit redundant with the alias section.
If I want to be able to quickly type "git-cmd --some --option", I'll
just alias it to something shorter.
--
Matthieu
^ permalink raw reply
* Re: [RFC] Default options
From: Johannes Schindelin @ 2007-05-09 23:07 UTC (permalink / raw)
To: Dana How; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <56b7f5510705091515l7c7090b9rd5599e8746642ef9@mail.gmail.com>
Hi,
On Wed, 9 May 2007, Dana How wrote:
> I notice git supports "alias.*" config variables.
> Would it be useful to also support "options.*" variables?
I would not do it, for the same reason we do not allow to override
builtins via aliases: it breaks scripts.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Optimized cvsexportcommit: calling 'cvs status' once instead of once per touched file.
From: Steffen Prohaska @ 2007-05-09 23:06 UTC (permalink / raw)
To: git; +Cc: robin.rosenberg.lists, Steffen Prohaska
In-Reply-To: <380B28A3-5CD0-4371-A717-1D2629E6302D@zib.de>
Runtime is now independent of the number of modified files.
The old implementation executed 'cvs status' for each file touched by the patch
to be applied. The new code calls 'cvs status' only once with all touched files
and parses cvs's output to collect all available status information.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-cvsexportcommit.perl | 45 ++++++++++++++++++++++++++++++---------------
1 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 6ed4719..21d49f6 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -160,36 +160,51 @@ foreach my $p (@afiles) {
}
}
+# ... check dirs,
foreach my $d (@dirs) {
if (-e $d) {
$dirty = 1;
warn "$d exists and is not a directory!\n";
}
}
-foreach my $f (@afiles) {
- # This should return only one value
- if ($f =~ m,(.*)/[^/]*$,) {
- my $p = $1;
- next if (grep { $_ eq $p } @dirs);
+
+# ... query status of all files that we have a directory for and parse output of 'cvs status' to %cvsstat.
+my @canstatusfiles;
+foreach my $f (@files) {
+ my $path = dirname $f;
+ next if (grep { $_ eq $path } @dirs);
+ push @canstatusfiles, $f;
+}
+
+my %cvsstat;
+if (@canstatusfiles) {
+ my @cvsoutput;
+ @cvsoutput= safe_pipe_capture(@cvs, 'status', @canstatusfiles);
+ my $matchcount = 0;
+ foreach my $l (@cvsoutput) {
+ chomp $l;
+ if ( $l =~ /^File:/ and $l =~ /Status: (.*)$/ ) {
+ $cvsstat{$canstatusfiles[$matchcount]} = $1;
+ $matchcount++;
+ }
}
- my @status = grep(m/^File/, safe_pipe_capture(@cvs, '-q', 'status' ,$f));
- if (@status > 1) { warn 'Strange! cvs status returned more than one line?'};
- if (-d dirname $f and $status[0] !~ m/Status: Unknown$/
- and $status[0] !~ m/^File: no file /) {
+}
+
+# ... validate new files,
+foreach my $f (@afiles) {
+ if (defined ($cvsstat{$f}) and $cvsstat{$f} ne "Unknown") {
$dirty = 1;
warn "File $f is already known in your CVS checkout -- perhaps it has been added by another user. Or this may indicate that it exists on a different branch. If this is the case, use -f to force the merge.\n";
- warn "Status was: $status[0]\n";
+ warn "Status was: $cvsstat{$f}\n";
}
}
-
+# ... validate known files.
foreach my $f (@files) {
next if grep { $_ eq $f } @afiles;
# TODO:we need to handle removed in cvs
- my @status = grep(m/^File/, safe_pipe_capture(@cvs, '-q', 'status' ,$f));
- if (@status > 1) { warn 'Strange! cvs status returned more than one line?'};
- unless ($status[0] =~ m/Status: Up-to-date$/) {
+ unless (defined ($cvsstat{$f}) and $cvsstat{$f} eq "Up-to-date") {
$dirty = 1;
- warn "File $f not up to date in your CVS checkout!\n";
+ warn "File $f not up to date but has status '$cvsstat{$f}' in your CVS checkout!\n";
}
}
if ($dirty) {
--
1.5.1.2
^ permalink raw reply related
* Re: quick bare clones taking longer?
From: Junio C Hamano @ 2007-05-09 22:59 UTC (permalink / raw)
To: David Miller; +Cc: junkio, git
In-Reply-To: <20070509.150256.59469756.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Junio C Hamano <junkio@cox.net>
> Date: Wed, 09 May 2007 14:48:38 -0700
>
>> > + no_checkout=yes
>> > + use_separate_remote=
>> > + test -z ''
>> > + origin=origin
>> > ++ get_repo_base ../torvalds/linux-2.6.git
>> > + base=
>>
>> This part puzzles me. The only way I could reproduce this was:
>>
>> $ ls -F victim victim.git
>> ls: victim: No such file or directory
>> victim.git:
>> ./ HEAD config description hooks/ lost-found/ refs/
>> ../ branches/ config~ gitcvs.master.sqlite info/ objects/ remotes/
>> $ mkdir j
>> $ cd j
>> $ git clone --bare -l -s -n ../victim new.git
>>
>> That is, I did not have ../victim but I did have ../victim.git/
>> repository, and I gave the former to "git clone".
>>
>> But that suggests that you do not have ../torvalds/linux-2.6.git
>> directory but instead have ../torvalds/linux-2.6.git.git/ which
>> sound a bit insane.
>>
>> Puzzled...
>
> This deeply puzzles me too.
>
> I'm just not going to go into my git directory using that
> symlink in my home directory any more. :-)
Ahhh, symlink!
get_repo_base does this:
get_repo_base() {
(cd "$1" && (cd .git ; pwd)) 2> /dev/null
}
and is used like this:
# Turn the source into an absolute path if
# it is local
if base=$(get_repo_base "$repo"); then
repo="$base"
local=yes
fi
That is, get_repo_base does:
* first try to cd to ../torvalds/linux-2.6.git; if it fails
then give up.
* then further cd down to .git if we can but do not worry about
it if we can't. Report where we are and succeed.
If the above "fails", the caller considers the cloned-from
repository a non-local one, and turns off -l -s optimization.
The above sequence is called before we create the new directory
and chdir to it. Maybe pwd has funny behaviour (e.g. $PWD) and
we need to explicitly say /bin/pwd or somesuch...
^ permalink raw reply
* Re: [PATCH] Optimized cvsexportcommit: calling 'cvs status' only once instead of once per changed file.
From: Steffen Prohaska @ 2007-05-09 22:45 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200705092230.16027.robin.rosenberg.lists@dewire.com>
On May 9, 2007, at 10:30 PM, Robin Rosenberg wrote:
> onsdag 09 maj 2007 skrev Steffen Prohaska:
>> The old implementation executed 'cvs status' for each file touched by
>> the patch
>> to be applied. The new code calls 'cvs status' only once and parses
>> cvs's
>> output to collect status information of all files contained in the
>> cvs working
>> copy.
>>
>> Runtime is now independent of the number of modified files. A
>> drawback is that
>> the new code retrieves status information for all files even if only
>> a few are
>> touched. The old implementation may be noticeably faster for small
>> patches to
>
> Ouch, lets see now. My working cvs checkout contains ~25k files and
> my typical commit touches 5-20 files.
>
> A quick (well....) test says cvs status on my checkout takes about
> five minutes to execute. Compare this with my typical exportcommit
> time of about ten seconds.
I tested with ~7k files using ssh to connect. Maybe something's wrong
with the server I'm connecting to but it takes some time for each
connect.
This alone kills the performance for a couple of files.
'cvs -z6 status' on the other hand took only 10 seconds.
> If you really need this, make a switch to select it.
I'll post a patch soon that takes the best of both: Call cvs status
once with the list of touched files and parse the output. Only one
connection is needed and only the minimal amount of status data is
transferred.
- Steffen
^ permalink raw reply
* Re: git rebase chokes on directory -> symlink -> directory
From: H. Peter Anvin @ 2007-05-09 22:44 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20070509213902.GA2593@steel.home>
Alex Riesen wrote:
>>>> Either way, it's still a bug that it stops for either checkin, ...
>>> Right. And because it is a bug, I'd like to have it fixed.
>>> So, what did you do in that fixup?
>> I'm sorry, I'm not sure I understand the question, in particular, I'm
>> getting the feeling I'm not sure what "that fixup" refers to.
>>
>
> From your original report:
>
> "git rebase dies horribly; on the first change it requires manual fixup,
> but it crashes on the second, with or without -m."
>
> You mentioned that on the first change (I assumed it is the first time
> git-rebase stopped, complained, and asked for your help) "it" requires
> a "manual fixup". Which I assume you did, as it crashed on "second"
> (stop?). The "manual fixup" from the original report, what was it?
> Can you remember or find the sequence of commands you did before "it
> crashed on second"?
Ah, I used your technique of removing everything manually when the
rebase failed, and then doing a "git checkout" of arch/x86_64/boot.
That seemed to work. I actually logged the commands, but threw out the
log after it worked, figuring it didn't tell you anything new :(
Trying to do a rebase again with 1.5.1.4 and see how it works gives only
one stop instead of two, so it's "halfway there":
: tazenda 14 ; git rebase stock
First, rewinding head to replay your work on top of it...
HEAD is now at a989705... Merge
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6
Applying 'x86 setup code rewrite: initial development snapshot'
Wrote tree bf3a4e990978bad7669dac117b0d482e53f1bcd7
Committed: f98b2dc7eff7f2ce9d039af794e7f0062cc42bf9
Applying 'MAINTAINERS: formally take responsibility for the i386 boot code'
Wrote tree 237806033e5c789752aa555a5aaba17c8b650c4c
Committed: e4fb08878f0fe2c2e72665315c35e698ece08101
Applying 'x86 setup: printf.c needs code16gcc.h'
Wrote tree 8be170c7240961ff47d13045412b2f8d66d54e20
Committed: 2a103e2db001d0d6a852861ea209b34ba97ffc6a
Applying 'x86 setup: in tty.c, actually tell it what character to print'
Wrote tree 0e487f781b874a8025e7fcd74e055abeee5ebe2e
Committed: da62daaf237756aab1330f8dc4842ca5e5fa4ac9
Applying 'build: setup sectors doesn't include the boot sector'
Wrote tree 66192f639721713010b65ddb6c40f0d7a1f51a0b
Committed: 5794cf95386551f0f97b7cae877845cbbb3ebfea
Applying 'x86 setup: segment descriptors need to be Present'
Wrote tree a3aa7db9741d1dc57007d97152a337b6532fc588
Committed: de616f57959c3b62a1ac544858a8bd41696d59dd
Applying 'x86 setup: make the video setup code actually do something...'
Wrote tree 9358db854ca73d9f6ac344c9dbc397a9913b4c86
Committed: 13a363f40ff51d61d5c553e529555c32425d7553
Applying 'x86 setup: fix missing semicolon in video-ati.c'
Wrote tree 0bbd82ef2e2bc2128c29ee8f8ca04399b86f8a98
Committed: d948a8ebb7f26f030264153fd801aca5dca47603
Applying 'x86 setup: fix memcmp_[fg]s()'
Wrote tree 368f27ee12eeeebfaad11bfabf6e087638e94b10
Committed: d5a63882787f4a927910307f2e8f3df0534643f6
Applying 'x86 setup: advance one e820 descriptor at a time...'
Wrote tree e7fb596232ed18cbddb6507ce8cb67e09a6326c9
Committed: ccfd63579f5df793701d44c46dd575629eabad85
Applying 'x86 setup: Call INT 15h AX=E820h properly'
Wrote tree bb010d0e1224ccbf4a0e201dab191448e84405d5
Committed: a84a8eab7e7d3708ad9cfdee67981eafe3a21b38
Applying 'x86 setup: remove assembly implementation of putchar and puts'
Wrote tree dc8d970b62d1be70175e04bed26dfa644f521cfd
Committed: 7356f51c11fc0e5f363a5f06df5274a7ccea73f5
Applying 'x86 setup: Sadly, Cirrus removed extended text modes from
their BIOS.'
Wrote tree 48560789f0ed319f77b529ea3f31e11126df6221
Committed: 06a5abda109eeadb34f3087b51e8a1f4cc69c3f3
Applying 'x86 setup: if no specific video mode ID is given, generate one'
Wrote tree 0366a71399c33ca08590aaa67df6438122529867
Committed: 56eb2476b71a917747bf6ea111568f9e5ba85e2c
Applying 'x86 setup: drop video mode range checking'
Wrote tree bd90ee84715e4eff9f1fafe7efc3c6440e6be69e
Committed: 668bf617eb273ddcefb007e3c5ec9bb4aa022894
Applying 'x86 setup: video.c: clean up unused stuff'
Wrote tree 1a2d47f784b5b64e7893a3364cbef1c8ba2a39cd
Committed: f38134d1296f5a09887b79cc6c4b13e34f77f293
Applying 'x86 setup: a20.c: make empty_8042() return status'
Adds trailing whitespace.
.dotest/patch:26:
warning: 1 line adds trailing whitespaces.
Wrote tree 0f46a1846afcaf61d7c4416d7f308ffd9d87d69c
Committed: 18a9e385504b85daa0e293e2a60309e34de4548e
Applying 'x86 setup: Modern ATI cards pass the probe but lacks the modes.'
Wrote tree 775608a82bd3783f5ba5dc00f7b4b7c39eb463ed
Committed: 0ed82f2809ec04d4db243d833e8cb5fcc029cd3e
Applying 'x86 setup: video.c: correct the handling of special mode numbers'
Wrote tree 9dae6d4dcc4bc2b98114a5a3ae6ff88bea7c60c3
Committed: af2b591e9c529b35b4cbb006b417cd6f16b87504
Applying 'x86 setup: remove references to obsolete probes'
Wrote tree f5605b2ab57ef0e52129c1809fa03c4b804b05cd
Committed: 30448725fe01982ab4ce7d28af609783c9d7eb32
Applying 'x86 setup: implement APM BIOS probe'
Wrote tree e46f5c4e318fa5f30ea221b90bdaa301876945cf
Committed: 293ae9fb21ebbfa6c834a016a20037a19b97bc5e
Applying 'x86 setup: clobber registers in keyboard BIOS call'
Wrote tree 98610c0970730f62d05412eaaadcec1528d94a98
Committed: 4b89273f6c78fe28b6f4aea161f64aa7ac2b8724
Applying 'x86 setup: tag functions noreturn; error message on A20 failure'
Adds trailing whitespace.
.dotest/patch:78:
warning: 1 line adds trailing whitespaces.
Wrote tree 605c96e3555b7bbbfd7b06306b225becff4ab09e
Committed: 72bd91360bbe365dc152e39f03229152c1e4f978
Applying 'x86 setup: whitespace cleanup'
Wrote tree 27230a23ba2f8b0aac3dddc264d7f4a28d18f8dc
Committed: 35f72771c466d83cc551bf81dfed22326048080e
Applying 'x86 setup: add CPU feature detect/abort on insufficient featurage'
Adds trailing whitespace.
.dotest/patch:20:setup-y += header.o main.o mca.o
memory.o pm.o pmjump.o
warning: 1 line adds trailing whitespaces.
Wrote tree 405fde3817d89e7aba618bda965d4bcc24e825d5
Committed: 18e25bde0d246d828931ebd6450c63a4091e0fc1
Applying 'x86 setup: whitespace cleanup'
Wrote tree 8124b48b7b985ae31062356df521462e4420f09a
Committed: 91d417b3def3b38aeba165282746fa82e6de0fad
Applying 'x86 setup: files missing from previous checkin (cpu.c, cpureq.c)'
Wrote tree 2be68b923f0b413701f5f57b93aaca42cc126e49
Committed: a312ada92fdff09e0ca6cf60724353f8f5d3578a
Applying 'x86 setup: remove unused verify_cpu.S'
Wrote tree 7f3ebf06770406f4936ace5aef8a1b20e2676563
Committed: 0eaf9d747d1e0677aef4c762333b8b1988fe5ce3
Applying 'x86 setup: compile with -DSETUP'
Wrote tree 475e43922e02adad5ff1e9e1c77df1ff26cbdcc6
Committed: b843ca098801e962fed08f20ee99fb2f5cbd18fd
Applying 'x86 setup: cpu detection cleanups'
Wrote tree d72cabf9f1812da55506c38ddd88ef5dcd42f535
Committed: 45adb1922193dc5204d5bf07de9e5a8939b2688c
Applying 'x86 setup: remove bogus "static"'
Wrote tree 17281ee44c7ce686366464985b8d1a436d6d7468
Committed: 79ed2a26f0de632d0fb9cf36ccd30d99267975a2
Applying 'x86 setup: use CONFIG_X86_MINIMUM_CPU_MODEL'
Wrote tree 1e3a29b3de3dd86c46d2900485ef8206f948a72d
Committed: ed41358ab168c7e7e9eb1ddff44d995eb339879e
Applying 'x86: Kconfig.cpu: the minimum CPU model is always 3;
WP_WORKS_OK = i486'
Wrote tree d174addf546223baf87598db7673872608f6cb2c
Committed: 84c13f3993b812efbc781ae106fecc0e7478809e
Applying 'x86: make the handling of required features consistent'
Wrote tree c96d44bd1b12f0b4090db2bc60ffec5c54c1c4da
Committed: 48091cdd868350c0c98b0b11592606e850058737
Applying 'x86 setup: use the required masks from <asm/required-features.h>'
Adds trailing whitespace.
.dotest/patch:145:
Adds trailing whitespace.
.dotest/patch:156:
Adds trailing whitespace.
.dotest/patch:190:
Adds trailing whitespace.
.dotest/patch:200:
Adds trailing whitespace.
.dotest/patch:248:
warning: squelched 1 whitespace error
warning: 6 lines add trailing whitespaces.
Wrote tree 7f53ccc902a878e6bdae0446147b79f693bbbfe3
Committed: 22f4301757277e2d542fab95529c664413225efe
Applying 'x86 setup: remove reference to obsolete cpureq.c'
Wrote tree c77da037a2247c8f577e5167d6bfed833484c3a5
Committed: ed056f881d6c0698c233ee888d9c4e798c8ba736
Applying 'x86 setup: apparently $(src) is insufficient, needs
$(srctree)/$(src)'
Wrote tree 53ed308ffc67dd7bbca326facb578bc56091855c
Committed: 530888f2f6f9dceb7a3d1d5e2e5a5c4d56606136
Applying 'x86 setup: bootlin is *so* dead...'
Wrote tree 65574110a6702b6d2616441ce74e5c02bd53cb6c
Committed: f20bb507355d38b871f4bb2034b9303f4b0742e0
Applying 'x86 setup: paranoia: clear the high half of %esp'
Adds trailing whitespace.
.dotest/patch:15:
warning: 1 line adds trailing whitespaces.
Wrote tree 52d253ca3ff8dd7f8394762720501c99614a1b83
Committed: f9040dd40db9f08650201f2f32f56186b31a7dcb
Applying 'x86 setup: add missing linker script'
Wrote tree f9dd325985592248b878c4df0646fbc430e9cdd6
Committed: 877594775c44a72c802f4e8cba9db5db63223aa4
Applying 'x86 setup: cleanups for compatibility with x86-64'
Adds trailing whitespace.
.dotest/patch:125:
warning: 1 line adds trailing whitespaces.
Wrote tree d83528199922e40076dc373cd9d24daba9a15516
Committed: 907963662ce663a8deb3594c6c7f9783de1cbe3b
Applying 'x86-64: add CONFIG_PHYSICAL_ALIGN to match i386'
Wrote tree f6d6abdee2fceed761eef217dcc1c7ed0de9877e
Committed: a015ea48164d9e6a8ab317c26cbe555c3032f699
Applying 'x86-64: <asm/segment.h>: add boot segment descriptors'
Wrote tree e3abd746b0f94b58ed510264a62b123e995f08b6
Committed: 8e00cfafbf108a2801fb0ec8b824962b1e073d55
Applying 'x86-64: fix compilation errors due to required-features.h change'
Wrote tree a1626723ccdd339ac8ef0764c77b2cdccdfb2f26
Committed: 355b0dc242a05f72c7bc1ad8f73fdc6e82a39afc
Applying 'x86-64: verify_cpu.S: use new masks'
Wrote tree 117fbd16776cc9b201a0f76c9f3910cc7c1f8fa6
Committed: 14b6bc6f64844958c7f923ee46ce4e2356e21c08
Applying 'x86: unify <asm/boot.h>'
Wrote tree ce269d002a4645b5ef54b1f8eef086a43498c81e
Committed: d84e3cc9eb73c7feb084b35303e45828917e3115
Applying 'x86: Complete <asm/cpufeature.h> with the union of i386 and
x86-64'
Wrote tree 3f40077f38ceb45312a780390f8d8d5eb98ffe17
Committed: 03d199b61342108a9f37978bec06626710284cd1
Applying 'x86-64: rearrange includes due to unifications and inclusion
from setup'
Space in indent is followed by a tab.
.dotest/patch:44: "661:\n\tlock; "
warning: 1 line adds trailing whitespaces.
Wrote tree 8f86e02ef672c98ae3519b9b3fabb3701a0ab1b9
Committed: 147328a824c71437259baf9a63fe03762bba74e0
Applying 'x86-64: Make arch/x86-64/boot a symlink to arch/i386/boot'
Wrote tree 9bc7ffd5d07a49c5a83fc8f9a680473995aa6c57
Committed: a859f67570bf62d2a602d27aa34a674e6645ca24
Applying 'x86: fix the definition of struct screen_info'
Wrote tree 258e5053597a572954943cb5b895e4462e6491fb
Committed: 951cf2086f5c2055e93b0db22c1064829bedc74e
Applying 'x86: fix differences between i386 and x86-64 <asm/e820.h>'
Wrote tree 6e4f4ed1de0a6736fb298d4e1adcae3b60f7a151
Committed: 3bec0726b8cfa624492b35659c5a13d484a1bc89
Applying 'i386: change %lu to %u in arch/i386/kernel/e820.h'
Wrote tree b05d8462dd9ce61fb32f61d2c9819877afe6be94
Committed: 7ab473d60f7bda2e7f7341bd9ca88610c5c440c5
Applying 'x86: move the bootparam structure definition into include/'
Wrote tree 3865d940f5be27cf70fe54aff3825b1f6c676a01
Committed: 3b5b95528bcf5487f79e659fe6346377955dd654
Applying 'x86 setup: E820MAX is a definitional constant; no need to use
sizeof hacks'
Wrote tree 6ba2914fb480e88633a7da7700dce60b1e619c22
Committed: 3db11fa860f9b06bf1b50f3fe698f0c6fb9e55ca
Applying 'x86 setup: boot_params.e820_map is just the map, not the
count; adjust'
Wrote tree 75308a18a561335d5a6a3613b51e130f43fcb00c
Committed: 4d6dea0f6c8ec5ac8580bcaee1c8d52f5d35e55a
Applying 'x86 setup: use 0x1e4 as scratch, instead of 0x3c'
Wrote tree 55fe315b3a931bdb3f1ea96ebc5098bcc24b0610
Committed: eca97ac06fa0f8d17b1ec974c890642afea62555
Applying 'x86-64: It appears MTRR isn't a required feature after all.'
Wrote tree 56fc138a5b01818142e200fa35921570270b53ac
Committed: 72c0fc6ecc2661245ae1fc42210a808a0ef63da1
Applying 'Revert "x86-64: Make arch/x86-64/boot a symlink to
arch/i386/boot"'
Adds trailing whitespace.
.dotest/patch:117:FDARGS =
Adds trailing whitespace.
.dotest/patch:350: * Page 0 is deliberately kept safe, since System
Management Mode code in
Adds trailing whitespace.
.dotest/patch:352: * useful for future device drivers that either access
the BIOS via VM86
Adds trailing whitespace.
.dotest/patch:648: *
Adds trailing whitespace.
.dotest/patch:649: * This is a collection of several routines from
gzip-1.0.3
error: arch/x86_64/boot/.gitignore: already exists in working directory
error: arch/x86_64/boot/Makefile: already exists in working directory
error: arch/x86_64/boot/compressed/Makefile: already exists in working
directory
error: arch/x86_64/boot/compressed/head.S: already exists in working
directory
error: arch/x86_64/boot/compressed/misc.c: already exists in working
directory
error: arch/x86_64/boot/compressed/vmlinux.lds: already exists in
working directory
error: arch/x86_64/boot/compressed/vmlinux.scr: already exists in
working directory
error: arch/x86_64/boot/install.sh: already exists in working directory
error: arch/x86_64/boot/mtools.conf.in: already exists in working directory
error: arch/x86_64/boot/tools/.gitignore: already exists in working
directory
error: arch/x86_64/boot/tools/build.c: already exists in working directory
Using index info to reconstruct a base tree...
Adds trailing whitespace.
<stdin>:117:FDARGS =
Adds trailing whitespace.
<stdin>:350: * Page 0 is deliberately kept safe, since System Management
Mode code in
Adds trailing whitespace.
<stdin>:352: * useful for future device drivers that either access the
BIOS via VM86
Adds trailing whitespace.
<stdin>:648: *
Adds trailing whitespace.
<stdin>:649: * This is a collection of several routines from gzip-1.0.3
warning: squelched 26 whitespace errors
warning: 31 lines add trailing whitespaces.
Falling back to patching base and 3-way merge...
fatal: Untracked working tree file
'arch/x86_64/boot/compressed/Makefile' would be overwritten by merge.
Failed to merge in the changes.
Patch failed at 0058.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
: tazenda 15 ; ls -ld arch/x86_64/boot
lrwxrwxrwx 1 hpa hpa 12 May 9 15:41 arch/x86_64/boot -> ../i386/boot/
: tazenda 16 ; rm -f arch/x86_64/boot
: tazenda 17 ; head -1 .dotest/0058
From cd312503f8e8a88895b12bf810677406284142e6 Mon Sep 17 00:00:00 2001
: tazenda 18 ; git checkout cd312503f8e8a88895b12bf810677406284142e6
arch/x86_64/boot
: tazenda 19 ; ls -ld arch/x86_64/boot
drwxrwxr-x 4 hpa hpa 4096 May 9 15:42 arch/x86_64/boot/
: tazenda 20 ; git rebase --continue
Applying 'Revert "x86-64: Make arch/x86-64/boot a symlink to
arch/i386/boot"'
Wrote tree 454be72b74038289064303704fa095e220539518
Committed: 7f942303bf26e31d10bf96b8d3fb3f1ee50a73a9
Applying 'x86-64: use 0x1b4 as the scratch area in boot_params, not 0x3c'
Wrote tree a9634c1b3aa7bdc5d7de6d8fcdafaef851181f2b
Committed: 3f23a6bd448bc9b00718b412170ee2ed752eec8f
Applying 'x86 setup: share code between i386 and x86-64'
Wrote tree 8397248a3723de8f0b31c6b5ed7f60d968c1631b
Committed: 72fe7620458f84e676dd40fdbe66835135e8a77c
Applying 'x86-64: remove -traditional from AFLAGS'
Wrote tree 5a27b91ebc542b2769347837734890e2043d1b4a
Committed: 2f8b9521f04effda7b8150c4302aff469245c5ef
Applying 'x86 setup: move all VESA-related code into video-vesa.c; add EDID'
Adds trailing whitespace.
.dotest/patch:86:
warning: 1 line adds trailing whitespaces.
Wrote tree e3289a29203434e4d683254f2aee077ddd4ae63c
Committed: f579842ed1a0dbabadc5359a7490c6a990bc7cb6
Applying 'x86 setup: allow setting of VESA graphics modes; cleanups'
Adds trailing whitespace.
.dotest/patch:68:
warning: 1 line adds trailing whitespaces.
Wrote tree 44eebedb0cb6cb40a10aec011103d0271a5e3fd3
Committed: e9cbeb161b71ac237d9bf8c8afd15f9a35eedb20
Applying 'x86 setup: whitespace cleanup'
Wrote tree eec8d62c5c9db76d918815f113d802a7a3d0d7f5
Committed: e3c55080c3db6dd3a9836fe7cd99bbdbb98bf84d
Applying 'x86 setup: implement screen contents save/restore'
Wrote tree f135c21ddd2b6af70f97c1380dbcd460267ec177
Committed: 53be00bc3919c2c565776bb408ecdc0ea5dbc261
Applying 'x86 setup: coppyright rPath, Inc.'
Wrote tree 47f7505f0436b527839190ee26029d520f17d25e
Committed: 2bf2c30e18fef98061ec0272e957d8faa387b6a0
Applying 'i386 boot protocol: boot loaders should allow more heap for
bzImage'
Wrote tree 4c5790a4a6ccf697e94729c3f5dec8d4d34a3dbc
Committed: 7439514e936c899639c6731f29a4988e7b66aa36
Applying 'x86 setup: actually check the end of the heap.'
Wrote tree 3ed25ec4913189031ccfd5368969cfd77a1fbece
Committed: ab7cd52538086dc095289a981c9177e956abf354
Applying 'x86 setup: when watching the setup size, take the stack into
account'
Wrote tree 34fa356d84aaa5241a281a8b01f04a059b5b353b
Committed: f3691d413e883e956213fc45cc132f7f76d7d3b7
Applying 'x86 setup: Factor out the environment-independent part of the
CPU check.'
Adds trailing whitespace.
.dotest/patch:239:
Adds trailing whitespace.
.dotest/patch:263:
warning: 2 lines add trailing whitespaces.
Wrote tree bae2277d4c4d40ba7b8fc11a25342ff4c023ef49
Committed: 85a238ecc2371cde07117d34524c71f9c96bc2f7
Applying 'x86 setup: be more paranoid about the stack setup in header.S'
Wrote tree 1b5fa9f3d37d361e6b47bb4e7142ecbe89eb552c
Committed: 58643e76ef2630ae5e7b0541c5fd0e8183141a10
Applying 'x86 setup: compile with -fomit-frame-pointer'
Wrote tree 3cd438bea06b27992940ce53fc56f16737d77c74
Committed: b36cd32f74a8be03dc23cd20b65c5c08dfae50ae
Applying 'x86 setup: remove double nesting of a20_test()'
Wrote tree 941b5ec12d8a1e82949ad0cd3932537f91eb5e8d
Committed: 53cdb8049013d6f72d3cfb5be0bd9999fbff2a97
Applying 'x86 setup: remove code moved from cpucheck.c -> cpu.c'
Wrote tree d83b020d216f92186026208576b5170b61ffd382
Committed: d5afa72f8eb28cc1e245b321dfa19fb620970900
Applying 'x86 setup: swap cpu.c and cpucheck.c; rename functions'
Adds trailing whitespace.
.dotest/patch:489:
Adds trailing whitespace.
.dotest/patch:512:
warning: 2 lines add trailing whitespaces.
Wrote tree 41d79ce765e1174464c47bff61c4330e23bf6382
Committed: f2c63bb8e16d9b3c67ad1fdbc7ae1f5e18286662
Applying 'x86 setup: add -fno-stack-protector; other Makefile fixes'
Wrote tree 65c5d385ff3bc54b65881629f72e4583c69a737e
Committed: 7ea7f8dbb4103d43b90fb6cc6f32c923b1f658e8
Applying 'x86 setup: add missing file "bitops.h" missing from previous
checkins'
Wrote tree 01beebe04609804ef88762e794fdd71daff89bf1
Committed: 7eaa98edb81e9937128ce342f626177ee8a68941
: tazenda 21 ;
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Pavel Roskin @ 2007-05-09 22:30 UTC (permalink / raw)
To: Karl Hasselström
Cc: Marco Costalba, Carl Worth, Michael Niedermayer, git
In-Reply-To: <20070506125938.GA19317@diana.vm.bytemark.co.uk>
Hello!
On Sun, 2007-05-06 at 14:59 +0200, Karl Hasselström wrote:
> configure.ac: 9: required file `./[config.h].in' not found
Sorry for being late with the comments, but it looks like some very old
Automake doesn't understand that the argument to AC_CONFIG_HEADER or
AM_CONFIG_HEADER can be quoted.
Regarding AM_CONFIG_HEADER vs AC_CONFIG_HEADERS, the documentation for
Automake says:
AC_CONFIG_HEADERS
Automake will generate rules to rebuild these headers. Older versions
of Automake required the use of AM_CONFIG_HEADER; this is no longer the
case today.
So I suggest that we keep AC_CONFIG_HEADERS. Automake's NEWS file says
AM_CONFIG_HEADER is obsolete since version 1.7.
> src/Makefile.am:30: invalid unused variable name:
> `nodist_qgit_SOURCES'
That's another sign of an obsolete version of Automake. "nodist_" was
introduced many years ago, back in the good old days when I had time to
track its progress. NEWS says it was introduced in Automake 1.5!
Perhaps we should require version 1.7 by adding this to the top-level
Makefile.am:
AUTOMAKE_OPTIONS = 1.7
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFC] Second parent for reverts
From: Johan Herland @ 2007-05-09 22:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Daniel Barkalow, git
In-Reply-To: <20070509202224.GG3141@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 3134 bytes --]
On Wednesday 09 May 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 9 May 2007, Daniel Barkalow wrote:
> > > The discussion about having a header to specify, for a revert
> > > commit, what it reverts made me realize that this header *would*
> > > be useful, but that we don't need a *new* header for it. I think
> > > that the right method is to add the parent of the reverted commit
> > > as a second parent for the revert.
> >
> > I am not so sure. In a sense, you are correct. But everybody who
> > does "git log --no-merges" would no longer see reverts. Which is
> > somewhat incorrect.
>
> Right.
>
> I've actually done what Daniel just talked about doing in one of my
> "production" repositories. I did it by hand as a developer had
> created a bad merge and accidentially reverted 800 files during
> that merge. 80 or so commits later along a public non-rewinding
> branch coworkers realized things weren't right, and asked me
> to fix the mess. As I wanted to save the blame data when I
> reverted-the-revert I did what Daniel suggests.
>
> But since the revert-the-revert wasn't really an interesting point
> in history, and neither was the bad merge, I don't really care that
> neither shows up with --no-merges. The original bad merge was a
> simple honest mistake made by a developer who was new to Git, and
> was only caused because merge-recursive wasn't installed properly
> on that system.
>
>
> As Dscho says, most reverts are interesting points in time. *Why*
> a particular revert was done is important.
>
> And so I have to disagree quite a bit with Daniel's idea, for exactly
> that reason. If I'm looking at a block of code in a file I want to
> know why its there. If blame tells me its a revert of something,
> that tells me we tried another path and it didn't work out. I might
> be sitting here looking at this line because I'm thinking of redoing
> whatever it was that wasn't good!
Sorry for butting in with pretty much the same arguments as I had in the
previous thread on the "Reverts" header field, but...:
Isn't this exactly why we could use the "Reverts" header field?
1. It would enable Daniel (and me) to get the "correct" blame data (for
some version of "correct" that at least seems to make sense to us).
2. It would make it trivial for git-log (and other porcelains) to detect
reverts and color them bright red in Shawn's and Dscho's logs, so that
they can easily see when and why things were reverted.
3. It wouldn't screw up "git log --no-merges" since it doesn't interfere
with the "real" parent data.
What am I still missing here?
> Hmm. I should teach git-gui to parse out the revert message and
> let you click into its parent. Simple enough. Maybe it will be
> in 0.7.0. Maybe it won't be. ;-)
Isn't it better/cleaner to get this info from a (strict-format) header
field, rather than parsing the commit message? (or worse, detecting
reverse diffs/patches?)
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Johannes Schindelin @ 2007-05-09 22:23 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: J. Bruce Fields, Petr Baudis, kha, junio, git
In-Reply-To: <Pine.LNX.4.64.0705091625200.18541@iabervon.org>
Hi,
On Wed, 9 May 2007, Daniel Barkalow wrote:
> On Wed, 9 May 2007, Johannes Schindelin wrote:
>
> > If you tell Git that it should look for commit e83c6516..., it will
> > store the sha1 as 0xe8 0x3c 0x65 0x16 ... in memory, no matter which
> > endianness the processor has.
>
> But it would be really weird to get 0x90 0xf2 0x4a 0x60 ... 0x16 0x65
> 0x3c 0xe8 unless you've got a 160-bit little-endian processor. That
> would be as strange as having "Test" stored as 0x74 0x73 0x65 0x54, I
> think.
I was not aware originally, that no arithmetic is involved in SHA-1
computation.
If you store large integers, it makes tons of sense to follow the
endianness, especially if you do _both_ boolean and integer operations on
them.
> > Which was positively confusing for me, since I automatically searched
> > for the sequence 0x90 0xf2 0x4a 0x60 ... (which is the tail of that
> > hash).
> >
> > But if all this sounds too confusing, I agree to delete the
> > "(big-endian)".
>
> If it confused you, there should be something there. Maybe "(in order)"
> or something else implying that the underlying type is an octet
> sequence, rather than a 160-bit integer?
Well, I am convinced by now that nobody could be as stupid as me, so I
think it is good without such a hint :-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add --aggressive option to 'git gc'
From: Theodore Tso @ 2007-05-09 22:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Git Mailing List
In-Reply-To: <7v4pmlu4ut.fsf@assigned-by-dhcp.cox.net>
On Wed, May 09, 2007 at 01:19:54PM -0700, Junio C Hamano wrote:
> It's tricky that it defaults to 10 and still called aggressive.
> When the configuration variable is left unspecified, the only
> reason it is called aggressive is because it passes '-f' to
> repack, right? It was not very clear at the first sight and I
> was about to ask why the default is 10, not higher.
Yes, it's called aggressive because it causes git-gc to recalculate
the delta's. So that means that git-gc --aggressive will take around
9-10 times longer than git-gc. If the user changes
gc.aggressive-window to some larger value, say like 30, then git-gc
--aggressive would take around 20 times longer than git-gc.
So that's why I didn't make the default bigger, but instead left it as
something which could be configured by the user. Maybe the default
should be larger; I don't strong opposition towards making it be more
like 30, but it seemed to me that doubling the run time for a 5%
decrease in pack size wasn't worth it.
Regards,
- Ted
^ permalink raw reply
* [PATCH] gitweb: choose appropriate view for file type if a= parameter missing.
From: Gerrit Pape @ 2007-05-09 22:19 UTC (permalink / raw)
To: git; +Cc: 410465
See http://bugs.debian.org/410465
gitweb URLs use the a= parameter for the view to use on the given path, such
as "blob" or "tree". Currently, if a gitweb URL omits the a= parameter,
gitweb just shows the top-level repository summary, regardless of the path
given. gitweb could instead choose an appropriate view based on the file
type: blob for blobs (files), tree for trees (directories), and summary if no
path given (the URL included no f= parameter, or an empty f= parameter).
Apart from making gitweb more robust and supporting URL editing more easily,
this change would aid the creation of shortcuts to git repositories using
simple substitution, such as:
http://example.org/git/?p=path/to/repo.git;hb=HEAD;f=%s
- Josh Triplett
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
gitweb/gitweb.perl | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 90243fd..21864c6 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -458,10 +458,16 @@ my %actions = (
"project_index" => \&git_project_index,
);
-if (defined $project) {
- $action ||= 'summary';
-} else {
- $action ||= 'project_list';
+if (!defined $action) {
+ if (defined $hash) {
+ $action = git_get_type($hash);
+ } elsif (defined $hash_base && defined $file_name) {
+ $action = git_get_type("$hash_base:$file_name");
+ } elsif (defined $project) {
+ $action = 'summary';
+ } else {
+ $action = 'project_list';
+ }
}
if (!defined($actions{$action})) {
die_error(undef, "Unknown action");
--
1.5.1.3
^ permalink raw reply related
* Re: [RFC] Second parent for reverts
From: Linus Torvalds @ 2007-05-09 22:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7v7irhslx1.fsf@assigned-by-dhcp.cox.net>
On Wed, 9 May 2007, Junio C Hamano wrote:
>
> I would suggest to leave a revert as a revert. It is not a
> merge.
Yes, please.
People can do fancy things if they want, but quite frankly, if you start
playing games with the "parent" pointer, it starts losing its meaning, and
becomes a random "pointer to another related commit".
Then, you might as well say "oh, this commit is related to that other
commit", and decide to call the other commit "related" too, and now a
random commit just looks like a strange merge.
That's simply not what "parenthood" is about. Parenthood is about
nonlinear development, and parents should not be reachable from each other
(which such a bogus revert or "related" parent would almost always be: it
would be reachable from the *real* parent.
If you want a "related to that commit" field, it should be a separate
field in the commit object. But since it doesn't really have any real
*semantic* meaning to git itself, it shouldn't be in the header. We
could, for example, make it be in the free-form section, and teach our
graphical visualization tools to automatically turn it into a hyperlink.
.. which we already do.
Linus
^ permalink raw reply
* [RFC] Default options
From: Dana How @ 2007-05-09 22:15 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, danahow
Reading the exchange about new options to e.g.
git gc and git pack-objects over the last few days,
a pattern seemed to emerge. A new option would be
proposed, but then we didn't always want to type it,
so a corresponding config variable would be added as well.
I notice git supports "alias.*" config variables.
Would it be useful to also support "options.*" variables?
When you type
git gc <args>
this is interpreted as
git gc $(git config options.gc) <args>
so anything in options.gc could be overridden
by later appearing on the command line.
The names might have dashes:
pack-objects would use options.pack-objects .
If a command is recognized using alias.*,
options.* would not be consulted (to keep things simple).
In other words, options.* only work for built-ins.
options.* would interpret quoting etc in its
value the same way alias.* does.
Thus, you can add a new --option to a program,
and get a corresponding config variable automatically,
and without cluttering up the documentation.
I've not yet looked at the git driver code.
Is there any interest in this feature?
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: quick bare clones taking longer?
From: David Miller @ 2007-05-09 22:02 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <7virb1sm6h.fsf@assigned-by-dhcp.cox.net>
From: Junio C Hamano <junkio@cox.net>
Date: Wed, 09 May 2007 14:48:38 -0700
> > + no_checkout=yes
> > + use_separate_remote=
> > + test -z ''
> > + origin=origin
> > ++ get_repo_base ../torvalds/linux-2.6.git
> > + base=
>
> This part puzzles me. The only way I could reproduce this was:
>
> $ ls -F victim victim.git
> ls: victim: No such file or directory
> victim.git:
> ./ HEAD config description hooks/ lost-found/ refs/
> ../ branches/ config~ gitcvs.master.sqlite info/ objects/ remotes/
> $ mkdir j
> $ cd j
> $ git clone --bare -l -s -n ../victim new.git
>
> That is, I did not have ../victim but I did have ../victim.git/
> repository, and I gave the former to "git clone".
>
> But that suggests that you do not have ../torvalds/linux-2.6.git
> directory but instead have ../torvalds/linux-2.6.git.git/ which
> sound a bit insane.
>
> Puzzled...
This deeply puzzles me too.
I'm just not going to go into my git directory using that
symlink in my home directory any more. :-)
^ permalink raw reply
* Re: [RFC] Second parent for reverts
From: Junio C Hamano @ 2007-05-09 21:54 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705091406350.18541@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> The discussion about having a header to specify, for a revert commit, what
> it reverts made me realize that this header *would* be useful, but that we
> don't need a *new* header for it. I think that the right method is to add
> the parent of the reverted commit as a second parent for the revert.
>
> If you have:
>
> a -> b -> c -> d
>
> And you want to revert b, the most exact flow would be:
>
> a -> b -> c -> d -> e
> \ /
> -> a' ---
>
> I.e., you exactly remove the effects of b to generate a commit that has
> the same tree as a, and then you merge.
>
> But a' doesn't actually take anything from b, since it's reverting all of
> b (unless it's only reverting part of b), and, if b isn't there, it
> doesn't need a commit message, either, so it's not different from a. So
> the flow should be:
>
> a -> b -> c -> d -> e
> \ /
> --------------
>
> And this means blame work correctly: lines that b changed will be blamed
> on a (or an ancestor), because e will match a there and be different from
> d. So I think git-revert should simply add in the reverted patch's parent.
> Does this analysis make sense to other people?
The revert operation at the tree level (not commit level) treats
AS IF b is a common ancestor between a and d and computes a
merge between a and d using that fake common ancestor to reach
at e. So it is understandable that you are confused that the
result somehow has something to do with a merge between a and d.
But other than that, the "analysis" does not make any sense to
me.
When you have a merge commit somebody else made, you should be
able to reproduce it yourself, with the help from the intent of
the merge explained in the commit log of the merge commit
(usually it says "I am merging this development line with that
one"). With a->b->c->d history, what is the sane merge result
between a and d? It won't be e. The only clue that you did a
revert of b is contained in the message "Revert b", because b is
not a common ancestor between a and d.
An interesting tangent is that you can revert both b and c with
a single tree-level operation by pretending as if c is a common
ancestor between a and d and run tree-level 3-way merge to apply
difference between c and d on top of a to come up with e. It
would not make sense to record neither one of a b c as the fake
second parent.
I would suggest to leave a revert as a revert. It is not a
merge.
In general, you should think of an act of making a commit (not
limited to a merge but a single parent) to mean that you are
making this statement:
I have considered the development history that leads to
the parent commits this commit records, and the tree
recorded with this commit suits the purpose of my branch
better than all of them.
Obviously, if you considered the history that leads to 'd', you
have considered the hsitory that leads to 'a' as well, so
recording both 'a' and 'd' as parents does not make much sense.
You could have recorded 'e' as an Octopus of 'a', 'b', ... 'd',
and the statement does not change.
^ permalink raw reply
* Re: failing test t9400 (Re: [PATCH] git-update-ref: add --no-deref option for overwriting/detaching ref)
From: Junio C Hamano @ 2007-05-09 21:50 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: skimo, git
In-Reply-To: <20070509202720.GN30324@planck.djpig.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> On Wed, May 09, 2007 at 09:19:01AM -0700, Junio C Hamano wrote:
>> Sven Verdoolaege <skimo@kotnet.org> writes:
>> > Shouldn't these tests be skipped if I don't have all that stuff installed?
>> > There doesn't even seem to be an option to turn off these tests.
>>
>> I agree. We would need something like this, but I have no easy
>> way to test it myself, short of uninstalling what I need on the
>> box. As you do not have them, maybe you can give it a quick
>> whirl?
>
> Yeah, I totally forgot add such a check, even though I added one for
> cvs.
>
>> ---
>> diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
>> index f17be6b..98d6bb4 100755
>> --- a/t/t9400-git-cvsserver-server.sh
>> +++ b/t/t9400-git-cvsserver-server.sh
>> @@ -17,6 +17,11 @@ then
>> test_done
>> exit
>> fi
>> +perl -e 'use DBI; use DBD::SQLite' 2>&1 || {
>
> Maybe there is a >/dev/null missing here?
Yes, I have it in the committed version. I wanted to make sure
Sven gets the expected error message from Perl in this test
patch.
^ permalink raw reply
* Re: quick bare clones taking longer?
From: Junio C Hamano @ 2007-05-09 21:48 UTC (permalink / raw)
To: David Miller; +Cc: junkio, git
In-Reply-To: <20070509.130614.15589957.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Junio C Hamano <junkio@cox.net>
> Date: Wed, 09 May 2007 08:41:20 -0700
>
>> There is something very wrong. "-l -s" should never go to the
>> "remote: Generating pack..." codepath. Is that reproducible?
>
> Every single time on master.kernel.org
>
>> Could you try "sh -x git-clone" it?
>
> Sure:
>
> + unset CDPATH
> + '[' -n '' ']'
> + quiet=
> + local=no
> + use_local=no
> + local_shared=no
> + unset template
> + no_checkout=
> + upload_pack=
> + bare=
> + reference=
> + origin=
> + origin_override=
> + use_separate_remote=t
> + depth=
> + no_progress=
> + test -t 1
> + case "$#,$1" in
> + bare=yes
> + shift
> + case "$#,$1" in
> + no_checkout=yes
> + shift
> + case "$#,$1" in
> + use_local=yes
> + shift
> + case "$#,$1" in
> + local_shared=yes
> + use_local=yes
> + shift
> + case "$#,$1" in
> + break
> + repo=../torvalds/linux-2.6.git
> + test -n ../torvalds/linux-2.6.git
> + test yes = yes
> + test yes = ''
> + no_checkout=yes
> + use_separate_remote=
> + test -z ''
> + origin=origin
> ++ get_repo_base ../torvalds/linux-2.6.git
> + base=
This part puzzles me. The only way I could reproduce this was:
$ ls -F victim victim.git
ls: victim: No such file or directory
victim.git:
./ HEAD config description hooks/ lost-found/ refs/
../ branches/ config~ gitcvs.master.sqlite info/ objects/ remotes/
$ mkdir j
$ cd j
$ git clone --bare -l -s -n ../victim new.git
That is, I did not have ../victim but I did have ../victim.git/
repository, and I gave the former to "git clone".
But that suggests that you do not have ../torvalds/linux-2.6.git
directory but instead have ../torvalds/linux-2.6.git.git/ which
sound a bit insane.
Puzzled...
^ permalink raw reply
* Re: git rebase chokes on directory -> symlink -> directory
From: Alex Riesen @ 2007-05-09 21:39 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <4641FDAF.3090608@zytor.com>
H. Peter Anvin, Wed, May 09, 2007 18:58:23 +0200:
> >>
> >> Mine stops already at the directory -> symlink checkin (the above is the
> >> symlink -> directory one), but your trick of using "git checkout" as a
> >> trick to resolve things helped for both... eventually :-/
> >
> > Hmm. What Git version do you have?
>
> Not sure anymore, because I ran a systemwide upgrade late last night.
> *Now* I have git-1.5.1.4, but I think I had 1.5.1.2 before.
... and the rebase you tried originally works now? Or you didn't try?
There were changes (substantial changes) in this area, so it might be
fixed. If not, I'd like to hear, I personally rely on rebase heavily.
> >> Either way, it's still a bug that it stops for either checkin, ...
> >
> > Right. And because it is a bug, I'd like to have it fixed.
> > So, what did you do in that fixup?
>
> I'm sorry, I'm not sure I understand the question, in particular, I'm
> getting the feeling I'm not sure what "that fixup" refers to.
>
>From your original report:
"git rebase dies horribly; on the first change it requires manual fixup,
but it crashes on the second, with or without -m."
You mentioned that on the first change (I assumed it is the first time
git-rebase stopped, complained, and asked for your help) "it" requires
a "manual fixup". Which I assume you did, as it crashed on "second"
(stop?). The "manual fixup" from the original report, what was it?
Can you remember or find the sequence of commands you did before "it
crashed on second"?
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Jan Hudec @ 2007-05-09 21:36 UTC (permalink / raw)
To: Fredrik Kuivinen
Cc: Marco Costalba, Paul Mackerras, Alex Riesen, Linus Torvalds,
Karl Hasselstr?m, Junio C Hamano, Carl Worth, Michael Niedermayer,
Git Mailing List
In-Reply-To: <4c8ef70705091409g30674cb6p6d3af42eb47ffc08@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 991 bytes --]
On Wed, May 09, 2007 at 23:09:25 +0200, Fredrik Kuivinen wrote:
> I have used PyQt for some smaller projects (notably Hgct, a no longer
> developed
> commit tool for git and Mercurial. See
> http://repo.or.cz/w/hgct.git?a=tree). For me
> PyQt has worked very well. The python interface to Qt is more or less a
> direct
> translation of the C++ interface, so the excellent documentation troll
> tech provides
> for Qt can be used when developing with PyQt as well.
>
> I have never seen the segfaulting you mention. Maybe my programs have been
> too
> small to trigger that bug...
It's not about size of the programs. It's about having to be careful not to
refer to widgets inside eg. dialog box from outside and close that dialog
box. That is having to be careful about something, that is normal in C++, but
what you normally expect python to handle for you. And such quirks of the
bindings are completely undocumented.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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