* [PATCH] gitk: UTF-8 support
From: Pavel Roskin @ 2005-11-23 4:15 UTC (permalink / raw)
To: git, Paul Mackerras
Add gitencoding variable and set it to "utf-8". Use it for converting
git-rev-list output.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/gitk b/gitk
index 3dd97e2..e53b609 100755
--- a/gitk
+++ b/gitk
@@ -19,7 +19,7 @@ proc gitdir {} {
proc getcommits {rargs} {
global commits commfd phase canv mainfont env
global startmsecs nextupdate ncmupdate
- global ctext maincursor textcursor leftover
+ global ctext maincursor textcursor leftover gitencoding
# check that we can find a .git directory somewhere...
set gitdir [gitdir]
@@ -49,7 +49,7 @@ proc getcommits {rargs} {
exit 1
}
set leftover {}
- fconfigure $commfd -blocking 0 -translation lf
+ fconfigure $commfd -blocking 0 -translation lf -encoding $gitencoding
fileevent $commfd readable [list getcommitlines $commfd]
$canv delete all
$canv create text 3 3 -anchor nw -text "Reading commits..." \
@@ -3657,6 +3657,7 @@ set datemode 0
set boldnames 0
set diffopts "-U 5 -p"
set wrcomcmd "git-diff-tree --stdin -p --pretty"
+set gitencoding "utf-8"
set mainfont {Helvetica 9}
set textfont {Courier 9}
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Paul Mackerras @ 2005-11-23 3:29 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Johannes Schindelin, git
In-Reply-To: <20051120073244.GA7902@kiste.smurf.noris.de>
Matthias Urlichs writes:
> If we want (need, these days -- the history is so long that gitk draws
> spurious lines becase of 16-bit window coordinate overflow) to chop off
I have it on good authority that canvas coordinates in Tcl/Tk are
*not* limited to 16 bits. The Tcl/Tk core developers acknowledged
that there might be a bug in the code that translates canvas
coordinates to X coordinates (which are 16 bit), and asked me for a
screenshot or repro-case to illustrate the problem.
However, I was unable to get current gitk to exhibit the problem, even
with Thomas Gleixner's enormous history.git repository. Do you have a
specific example (repository and commit ID) where you see the problem
occur?
Paul.
^ permalink raw reply
* [PATCH] git-mv is not able to handle big directories
From: Alexander Litvinov @ 2005-11-23 5:41 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 473 bytes --]
When moving directory with large number of files git-mv says:
> git-mv jsp* .
Can't exec "git-update-index": Argument list too long at /usr/local/bin/git-mv
line 193.
git-update-index failed to add new names with code -1
This patch fixes this by building list of files with limited len (currently
5000) and executing git-update-index few times until all files will be
processed. I don't know how to determinate limit of command line but 5000
seems safe enougth to me.
[-- Attachment #2: git-mv.perl.patch --]
[-- Type: text/x-diff, Size: 1492 bytes --]
--- git-mv.perl.orig 2005-11-23 11:24:10.000000000 +0600
+++ git-mv.perl 2005-11-23 11:33:31.000000000 +0600
@@ -185,13 +185,36 @@
}
my $rc;
-if (scalar @changedfiles >0) {
- $rc = system("git-update-index","--",@changedfiles);
+while (scalar @changedfiles >0) {
+ my @toHandle = ();
+ my $len = 0;
+ while ($len < 5000 && scalar(@changedfiles) >0) {
+ my $f = pop(@changedfiles);
+ $len += length($f) + 1;
+ push(@toHandle, $f);
+ }
+ $rc = system("git-update-index","--",@toHandle);
die "git-update-index failed to update changed files with code $?\n" if $rc;
}
-if (scalar @addedfiles >0) {
- $rc = system("git-update-index","--add","--",@addedfiles);
+while (scalar @addedfiles >0) {
+ my @toHandle = ();
+ my $len = 0;
+ while ($len < 5000 && scalar(@addedfiles) >0) {
+ my $f = pop(@addedfiles);
+ $len += length($f) + 1;
+ push(@toHandle, $f);
+ }
+ $rc = system("git-update-index","--add","--",@toHandle);
die "git-update-index failed to add new names with code $?\n" if $rc;
}
-$rc = system("git-update-index","--remove","--",@deletedfiles);
-die "git-update-index failed to remove old names with code $?\n" if $rc;
+while (scalar @deletedfiles > 0) {
+ my @toHandle = ();
+ my $len = 0;
+ while ($len < 5000 && scalar(@deletedfiles) >0) {
+ my $f = pop(@deletedfiles);
+ $len += length($f) + 1;
+ push(@toHandle, $f);
+ }
+ $rc = system("git-update-index","--remove","--",@toHandle);
+ die "git-update-index failed to remove old names with code $?\n" if $rc;
+}
^ permalink raw reply
* Re: [PATCH] git-mv is not able to handle big directories
From: Junio C Hamano @ 2005-11-23 6:14 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <200511231141.57683.lan@ac-sw.com>
Alexander Litvinov <lan@ac-sw.com> writes:
> When moving directory with large number of files git-mv says:
>> git-mv jsp* .
> Can't exec "git-update-index": Argument list too long at /usr/local/bin/git-mv
> line 193.
> git-update-index failed to add new names with code -1
>
> This patch fixes this by building list of files with limited len (currently
> 5000) and executing git-update-index few times until all files will be
> processed. I don't know how to determinate limit of command line but 5000
> seems safe enougth to me.
Two comments.
(1) the argument limit is enforced by the operating system in
bytes (including environment size unfortunately) so we might
want to count bytes not number of paths. I heard GNU xargs
uses 131072 as the default limit.
(2) I wonder if we can detect this particular failure case and
then fall back on splitting the arguments dynamically, maybe
something like this:
sub xargs_system {
my ($cmd, @args) = @_;
my $rc = system(@$cmd, @args);
if ($rc == 'argument list too long error') {
my (@args0) = splice(@args, 0, @args/2);
$rc = xargs_system($cmd, @args0);
return $c if ($rc);
return xargs_system($cmd, @args);
}
return $rc;
}
and:
$rc = xargs_system([qw(git-update-index --)], @changedfiles);
$rc = xargs_system([qw(git-update-index --add --)], @addedfiles);
...
^ permalink raw reply
* Re: [PATCH] git-mv is not able to handle big directories
From: Junio C Hamano @ 2005-11-23 6:32 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <7voe4b7uw7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Two comments.
>
> (1) the argument limit is enforced by the operating system in
> ...
> (2) I wonder if we can detect this particular failure case and
> ...
(3) Even better, 'git-update-index -z --stdin'
if (@changedfiles) {
open my $oh, qw(|- git-update-index -z --stdin)
or die "oops";
for (@changedfiles) {
print $oh "$_\0";
}
close $oh;
}
JC "added too many features that myself cannot remember" Hamano
^ permalink raw reply
* Re: [PATCH] Add git-graft-ripple, a tool for permanently grafting history into a tree.
From: Andreas Ericsson @ 2005-11-23 7:22 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511221652530.13959@g5.osdl.org>
Linus Torvalds wrote:
>
> On Tue, 22 Nov 2005, Ryan Anderson wrote:
>
>>Enhancements over the original example:
>>
>> o Each newly created commit A' references A, and (A^1)' (The first try
>> referenced A^1 and (A^1)' but not A)
>>
>> o Support for incrementally rewriting history is present.
>
>
> How about the case of having commits that have pointers to other commits
> in the comments?
>
> For example, on the kernel do
>
> gitk 19842d67340e4a8f616552d344e97fc7452aa37a
>
> and see how gitk highlights the SHA1's in the commit message and makes
> hyperlinks to the commits they point to..
>
For reference, gitweb does the same.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-mv is not able to handle directory with one file in it
From: Alexander Litvinov @ 2005-11-23 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe4b7uw7.fsf@assigned-by-dhcp.cox.net>
I have found one error during directory movig: If I move directory with one
file somewhere in it this script will try to add target directory instead of
file. Commenting lines starting from 190 solve this error. But I don't
understand what is the logic behind this case ? Why do target directory
checked instead of target file ? Should we replace $dst my $destfiles[0] ?
at line 190 in git-mv:
if (scalar @srcfiles == 1) {
if ($overwritten{$dst} ==1) {
push @changedfiles, $dst;
} else {
push @addedfiles, $dst;
}
}
else {
push @addedfiles, @dstfiles;
}
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Matthias Urlichs @ 2005-11-23 7:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Johannes Schindelin, git
In-Reply-To: <17283.57854.256145.253465@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 676 bytes --]
Hi,
Paul Mackerras:
> However, I was unable to get current gitk to exhibit the problem, even
> with Thomas Gleixner's enormous history.git repository. Do you have a
> specific example (repository and commit ID) where you see the problem
> occur?
>
I've seen it in the past ... hmmm ... testing ... and it seems to
majickally have fixed itself.
Oh well...
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The Tenth Commandment of Frisbee: The single most difficult move with a disc
is to put it down. (Just one more.)
-- Dan Roddick
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: speedup allocation in pack-redundant.c
From: Alex Riesen @ 2005-11-23 7:31 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git, Junio C Hamano
In-Reply-To: <4383AFDB.90907@etek.chalmers.se>
On 11/23/05, Lukas Sandström <lukass@etek.chalmers.se> wrote:
> >>>>I think making allocation/deallocation to the central place is a
> >>>>good cleanup, but I am not sure about the free-nodes reusing.
> >>>>Does this make difference in real life?
> >>>
> >>>It definitely does, though nor very much. I have no real numbers at
> >>>hand (being home now), but I remember it was 1 min with against 3 min
> >>>without the patch on cygwin+fat32, which is already bad enough all by
> >>>itself. Very big repository with no redundant packs in it.
> >>
> >>Would you mind sharing the .idx files?
> >
> > this time I probably would (they're not here)... But for a perfomance
> > testing any big repository will do, linux kernel, for example.
> >
> The problem is that the large repository I have contains lots of
> redundant packs, which makes quite fast to find a complete set
> and end the search. If you don't have any redundant packs, the
> complete set search really is 2**n (n = the number of packs).
>
> I did some quick experiments with slab allocation and got a 4.4%
> improvement on the redundant repo, so that might be worth persuing.
> (Concept patch below)
>
I don't have the old packs anymore, but I benchmarked all three
allocation types anyway:
malloc/free:
$ time git-pack-redundant --all --alt-odb
real 0m0.092s
user 0m0.108s
sys 0m0.015s
simple node reuse (the patch in official tree):
$ time git-pack-redundant --all --alt-odb
real 0m0.074s
user 0m0.093s
sys 0m0.015s
slab node allocation (your concept patch):
$ time git-pack-redundant --all --alt-odb
real 0m0.031s
user 0m0.046s
sys 0m0.015s
This repository has one pack and 17758 files.
^ permalink raw reply
* Re: [PATCH] git-mv is not able to handle big directories
From: Randal L. Schwartz @ 2005-11-23 7:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, git
In-Reply-To: <7vk6ez7u1y.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> open my $oh, qw(|- git-update-index -z --stdin)
Junio> or die "oops";
This is Perl 5.6 or later. Breaks on Perl 5.5, which is still in use
in some places.
To be compatible with 5.5, you have to create a handle explicitly:
require IO::Handle;
my $oh = IO::Handle->new;
open $oh, qw(...) ...;
That works all the way back to 5.4, which is the earliest Perl
supported by the core team.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: git-mv is not able to handle directory with one file in it
From: Andreas Ericsson @ 2005-11-23 7:57 UTC (permalink / raw)
To: git
In-Reply-To: <200511231326.27972.lan@ac-sw.com>
Alexander Litvinov wrote:
> I have found one error during directory movig: If I move directory with one
> file somewhere in it this script will try to add target directory instead of
> file.
Are you saying this setup
foodir/somefile.c <--file
newdir/ <--directory
with this command
git-mv foodir/ newdir
tries to create
newdir/foodir/somefile.c <-- directory
or does it create
newdir/somefile.c <-- file
?
It should create
newdir/foodir/somefile.c <-- file
Otherwise it's misbehaving.
Try running it with the -v switch to make it shout out loud what it's
trying to do, and then paste the output here.
> Commenting lines starting from 190 solve this error. But I don't
> understand what is the logic behind this case ? Why do target directory
> checked instead of target file ? Should we replace $dst my $destfiles[0] ?
>
> at line 190 in git-mv:
> if (scalar @srcfiles == 1) {
> if ($overwritten{$dst} ==1) {
> push @changedfiles, $dst;
> } else {
> push @addedfiles, $dst;
> }
> }
> else {
> push @addedfiles, @dstfiles;
> }
This is broken. It only checks if there's just one source-file
regardless of whether or not it resided in a subdirectory. I'm not
exactly fluent in perl so I can't submit a patch, but the src option
needs to be directory aware, traverse all source directories and then
move the files axing everything but the bottom-most dirname to the
destination directory.
Any takers?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-mv is not able to handle big directories
From: Junio C Hamano @ 2005-11-23 8:37 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <867jazre78.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> open my $oh, qw(|- git-update-index -z --stdin)
> Junio> or die "oops";
>
> This is Perl 5.6 or later. Breaks on Perl 5.5, which is still in use
> in some places.
I should have known better than posting Perl code to the list
where a real guru is lurking and making afool of myself ;-).
Thanks for the advice. How much do we care about 5.5? IOW, is
"in some places" wide enough to matter?
git-cvsimport, git-svnimport and git-shortlog share the same
problem (svnimport declares that it wants 5.8). perl58delta.pod
does say list form of open for pipes is new in that version. So
what I wrote above requires 5.8 or better, perhaps? cvsimport
uses that same structure. That is doubly Ouch.
^ permalink raw reply
* Re: Problem merging
From: Fredrik Kuivinen @ 2005-11-23 8:59 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20051123025001.15527.qmail@web31812.mail.mud.yahoo.com>
On Tue, Nov 22, 2005 at 06:50:01PM -0800, Luben Tuikov wrote:
> Ok, background:
>
> I've two branches of the same .git, _but_ they live in
> different directories (bearing the branches' names)
> with different index caches, but with the same identical
> objects directory (different HEADs of course).
> (in effect, I have both branches "checked out")
>
> Branch A is the "trunk", branch B is trunk+my changes.
> I do:
>
> branchA: git pull <remote>
> branchA: cd ../branchB/
> branchB: git resolve HEAD branchA "merge trunk"
>
> And I get:
>
> Trying to merge 4b4a27dff4e2d4cc2eac1cde31aede834a966a48 into
> e1ef47b54d7e7e477f7f1eb3251a9d37f38e0469 using 989e4d6cbc69191c41ddf4b1c492457410376b43.
> Simple merge failed, trying Automatic merge
> Removing include/asm-um/ldt.h
> fatal: merge program failed
> Automatic merge failed, fix up by hand
>
> This is with git HEAD:
> 2392ee98eb76aa821de53c93c9e36acb18d27fc0 -- latest as
> of now.
>
> Is this a bug in git? Since this process has always worked
> before.
Have you tried this merge with the recursive merge strategy?
Btw is there a reason why 'recursive' isn't the default merge strategy
for git-merge? It might be a bit confusing that git-pull and git-merge
have different default strategies...
- Fredrik
^ permalink raw reply
* Re: git-mv is not able to handle directory with one file in it
From: Alexander Litvinov @ 2005-11-23 9:57 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <438420CC.4050303@op5.se>
On Wednesday 23 November 2005 13:57, Andreas Ericsson wrote:
> Are you saying this setup
> foodir/somefile.c <--file
> newdir/ <--directory
>
> with this command
> git-mv foodir/ newdir
It is calling git-update-index --add newdir but actiual file structire is
correct:
newdir/somefile.c - is a file
^ permalink raw reply
* Re: git-mv is not able to handle directory with one file in it
From: Alexander Litvinov @ 2005-11-23 10:21 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <438420CC.4050303@op5.se>
On Wednesday 23 November 2005 13:57, Andreas Ericsson wrote:
> This is broken. It only checks if there's just one source-file
> regardless of whether or not it resided in a subdirectory. I'm not
> exactly fluent in perl so I can't submit a patch, but the src option
> needs to be directory aware, traverse all source directories and then
> move the files axing everything but the bottom-most dirname to the
> destination directory.
>
> Any takers?
I still does not understand what this part should do. I know perl enought to
fix it but I don't understand the logic.
^ permalink raw reply
* [PATCH] Fix cg-mv for moving directories with 1 file
From: Josef Weidendorfer @ 2005-11-23 11:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Alexander Litvinov
This is fixed by putting the file into @changedfiles/@addedfiles,
and not the directory this file is in.
Additionally, this fixes the behavior for attempting to overwrite
a file with a directory, and gives a message for all cases where
overwriting is not possible (file->dir,dir->file,dir->dir).
Thanks for Alexander Litvinov for noting this problem.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
This should fix the wrong behavior.
Alexander, can you confirm this?
git-mv.perl | 25 +++++++++++++++++--------
1 files changed, 17 insertions(+), 8 deletions(-)
applies-to: 5bc7f67c535dbbbb9340285c82226a8dd6e4afec
5237e9ac4adc6bed0074ce1eeee6846e40f45d84
diff --git a/git-mv.perl b/git-mv.perl
index a21d87e..bf54c38 100755
--- a/git-mv.perl
+++ b/git-mv.perl
@@ -103,13 +103,22 @@ while(scalar @srcArgs > 0) {
$bad = "bad source '$src'";
}
+ $safesrc = quotemeta($src);
+ @srcfiles = grep /^$safesrc(\/|$)/, @allfiles;
+
$overwritten{$dst} = 0;
if (($bad eq "") && -e $dst) {
$bad = "destination '$dst' already exists";
- if (-f $dst && $opt_f) {
- print "Warning: $bad; will overwrite!\n";
- $bad = "";
- $overwritten{$dst} = 1;
+ if ($opt_f) {
+ # only files can overwrite each other: check both source and destination
+ if (-f $dst && (scalar @srcfiles == 1)) {
+ print "Warning: $bad; will overwrite!\n";
+ $bad = "";
+ $overwritten{$dst} = 1;
+ }
+ else {
+ $bad = "Can not overwrite '$src' with '$dst'";
+ }
}
}
@@ -118,8 +127,6 @@ while(scalar @srcArgs > 0) {
}
if ($bad eq "") {
- $safesrc = quotemeta($src);
- @srcfiles = grep /^$safesrc(\/|$)/, @allfiles;
if (scalar @srcfiles == 0) {
$bad = "'$src' not under version control";
}
@@ -166,10 +173,12 @@ while(scalar @srcs > 0) {
push @deletedfiles, @srcfiles;
if (scalar @srcfiles == 1) {
+ # $dst can be a directory with 1 file inside
if ($overwritten{$dst} ==1) {
- push @changedfiles, $dst;
+ push @changedfiles, $dstfiles[0];
+
} else {
- push @addedfiles, $dst;
+ push @addedfiles, $dstfiles[0];
}
}
else {
---
0.99.9.GIT
^ permalink raw reply related
* Re: git-mv is not able to handle directory with one file in it
From: Josef Weidendorfer @ 2005-11-23 11:07 UTC (permalink / raw)
To: git
In-Reply-To: <200511231621.34259.lan@ac-sw.com>
On Wednesday 23 November 2005 11:21, Alexander Litvinov wrote:
> On Wednesday 23 November 2005 13:57, Andreas Ericsson wrote:
> > This is broken. It only checks if there's just one source-file
> > regardless of whether or not it resided in a subdirectory.
Yes.
For git-update-index we have to use the file inside the directory.
I just sent a patch for this.
Josef
^ permalink raw reply
* Re: [PATCH] Cogito documentation updates
From: Jonas Fonseca @ 2005-11-23 12:16 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Petr Baudis, git
In-Reply-To: <86veyn49gc.fsf@blue.stonehenge.com>
Randal L. Schwartz <merlyn@stonehenge.com> wrote Sun, Nov 20, 2005:
> >>>>> "Jonas" == Jonas Fonseca <fonseca@diku.dk> writes:
>
> Jonas> - local cg-fetch now works without the cp option -u
>
> But it still requires cp -d, unless some other patch fixed that recently.
Ah, yes. I just recently tried local cloning on a FreeBSD box and it
worked fine (apart from it spitting out a few errors, see the log below)
and since the caveat section only mentioned the -u option I thought
everything was fine. However, cloning a specific branch hits the error.
So maybe the caveat section should just be updated to say that the -d
option is required.
---
$ cg clone cogito cogito-now
defaulting to local storage area
Hard links don't work - using copy
Fetching head...
/home/jonas/src/cogito/.git/HEAD -> .git/refs/heads/.origin-fetching
Fetching objects...
progress: 10289 objects, 16992385 bytes
Fetching tags...
error: missing object referenced by 'refs/tags/junio-gpg-pub'
fatal: protocol error: bad line length character
Failed to find remote refs
unable to get tags list (non-fatal)
New branch: 73874dddeec2d0a8e5cd343eec762d98314def63
Cloned to cogito-now/ (origin /home/jonas/src/cogito available as branch "origin")
$ cg clone cogito#cogito-0.10 cogito-0.10
cp: illegal option -- d
usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src target
cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src1 ... srcN
directory
cg-fetch: unable to get the head pointer of branch cogito-0.10
cg-clone: fetch failed
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Add git-graft-ripple, a tool for permanently grafting history into a tree.
From: Ryan Anderson @ 2005-11-23 13:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0511221652530.13959@g5.osdl.org>
On Tue, Nov 22, 2005 at 04:55:04PM -0800, Linus Torvalds wrote:
> On Tue, 22 Nov 2005, Ryan Anderson wrote:
> >
> > Enhancements over the original example:
> >
> > o Each newly created commit A' references A, and (A^1)' (The first try
> > referenced A^1 and (A^1)' but not A)
> >
> > o Support for incrementally rewriting history is present.
>
> How about the case of having commits that have pointers to other commits
> in the comments?
>
> For example, on the kernel do
>
> gitk 19842d67340e4a8f616552d344e97fc7452aa37a
>
> and see how gitk highlights the SHA1's in the commit message and makes
> hyperlinks to the commits they point to..
For some reason, my gut says that this goes too far. I'm having a hard
time pinning down a way to explain that.
I guess something (untested) like this could do it, right before I call
git_commit_tree():
my $found;
do {
$found = 0;
if ($csets{$old}{comments} =~ /\s([a-f0-9]{40})\s/ &&
exists $newcsets{$1}) {
my $tcommit = $1;
$found = 1;
$csets{$old}{comments} =~ s/$tcommit/$newcsets{$tcommit}/g;
}
} while ($found);
I'm not entirely convinced this is a good idea, but there it is.
I'll write up a patch later for this (probably switching to GetOpt in
the process.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] git-mv is not able to handle big directories
From: Ryan Anderson @ 2005-11-23 13:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, git
In-Reply-To: <7vu0e369p4.fsf@assigned-by-dhcp.cox.net>
On Wed, Nov 23, 2005 at 12:37:59AM -0800, Junio C Hamano wrote:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>
> >>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> >
> > Junio> open my $oh, qw(|- git-update-index -z --stdin)
> > Junio> or die "oops";
> >
> > This is Perl 5.6 or later. Breaks on Perl 5.5, which is still in use
> > in some places.
>
> I should have known better than posting Perl code to the list
> where a real guru is lurking and making afool of myself ;-).
>
> Thanks for the advice. How much do we care about 5.5? IOW, is
> "in some places" wide enough to matter?
>
> git-cvsimport, git-svnimport and git-shortlog share the same
> problem (svnimport declares that it wants 5.8). perl58delta.pod
> does say list form of open for pipes is new in that version. So
> what I wrote above requires 5.8 or better, perhaps? cvsimport
> uses that same structure. That is doubly Ouch.
No, you're not using the list form for pipes. I use that in
git-graft-ripple:
open(P,"-|","git-rev-list","--parents","--merge-order",$range)
For the kernel, requiring 5.8 shouldn't be a big issue. I suspect it's
really only the commercial Unixes where requiring 5.8 would be annoying.
Randal, is my guess even remotely accurate?
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: auto-packing on kernel.org? please?
From: Catalin Marinas @ 2005-11-23 14:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v1x18eddp.fsf@assigned-by-dhcp.cox.net>
On 22/11/05, Junio C Hamano <junkio@cox.net> wrote:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>
> > What I meant is any object whose exact reference is found in
> > refs/patches (not reachable via refs/patches), even if it is reachable
> > from refs/heads.
>
> do you mean you
> keep blobs and trees in refs/patches, or "exactly found in
> refs/patches" imply "commits in refs/patches and trees and blobs
> reachable from it"? If the latter I think it amounts to the
> same thing. If some of the blobs are shared with what is
> reachable from refs/heads or refs/tags I would presume you would
> want to pack them.
Each patch needs to have 2 commit and 2 tree objects (with the
corresponding blobs). I now understand where the problem appears. Most
of the blobs should actually be packed since they are part of the base
of the stack.
Since refs/heads files always point to the top of the stack, the
applied patches (the corresponding objects) would be automatically
packed. The alternative would be to only pack the objects reachable
from refs/bases but that's really StGIT-specific.
Other algorithm would be to avoid packing objects reachable from
refs/patches but not reachable from refs/bases but this would probably
complicate GIT.
> And the "volatile" idea may be a good way of doing this.
> Perhaps "git repack --volatile <glob>" to name paths under
> .git/refs to mark things not to be packed, with a per-repository
> configuration item to give default 'volatile' patterns? I could
> use it when packing my repository to exclude things that are
> only reachable from "pu" branch.
After I eventually understood what you meant, the above would still
include the already applied StGIT patches since they are reachable via
HEAD. Maybe StGIT could avoid modifying refs/heads but I think it
would lose some benefits.
--
Catalin
^ permalink raw reply
* Re: auto-packing on kernel.org? please?
From: Catalin Marinas @ 2005-11-23 14:18 UTC (permalink / raw)
To: cel; +Cc: Linus Torvalds, Carl Baldwin, H. Peter Anvin, Git Mailing List
In-Reply-To: <4383610D.7080100@citi.umich.edu>
On 22/11/05, Chuck Lever <cel@citi.umich.edu> wrote:
> Linus Torvalds wrote:
> > But maybe that's what stgit wants (since they are "temporary"), but it
> > does mean that if you see a big advantage from packing, you might be
> > losing some of it.
>
> actually, those commits aren't all that "temporary". the
> history/revision feature i'm working on would like to maintain all the
> commits ever done to an StGIT patch.
That's to avoid pruning them but you might not always want to add them
to a pack.
> the only time you can throw away such commits is when the patch is
> deleted or when it is finally committed to the repository via "stg
> commit". otherwise, keeping these commits in a pack would be quite a
> good thing.
>
> maybe the first thing to do is to get a basic understanding of an StGIT
> commit's lifetime.
My initial idea was to throw the old commit away once a patch is
refreshed. Even if you want to preserve the history, it would be only
preserved until you send the patch to be merged upstream and you would
delete it locally. If all the patches are meant to be sent upstream at
some point, you can avoid packing them.
--
Catalin
^ permalink raw reply
* files are disappearing in git
From: Nico -telmich- Schottelius @ 2005-11-23 14:23 UTC (permalink / raw)
To: Git ML
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]
Hello!
I've the problem that some files (a directory with 3 files) is simply 'away':
- We added it once
- In current tree it's away
- pasky aided me in irc to find the commit where it is gone with git bisect
--> very nice tool
- the commit, after which the directory was gone did NOT modify this directory
- though the directory is gone
What should I do know to find out what's the reason git 'forgot' that directory?
Nico
P.S.: I cannot put the .git directory online, it's a closed source project
for a special customer with customer data in it.
--
Latest project: cinit-0.2.1 (http://linux.schottelius.org/cinit/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Perl version support (was Re: [PATCH] git-mv is not able to handle big directories)
From: Randal L. Schwartz @ 2005-11-23 14:27 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git
In-Reply-To: <20051123135604.GB16995@mythryan2.michonline.com>
>>>>> "Ryan" == Ryan Anderson <ryan@michonline.com> writes:
Ryan> For the kernel, requiring 5.8 shouldn't be a big issue. I suspect it's
Ryan> really only the commercial Unixes where requiring 5.8 would be annoying.
Ryan> Randal, is my guess even remotely accurate?
I'd say that 50% of the Perl-using population is at 5.6, with 25% each
at 5.5 and 5.8. Those on 5.5 are generally unable to upgrade Perl
for corporate reasons.
Targetting Perl 5.6 would assist broad acceptance of git for the
typical commercial end user. Targetting 5.5 where possible would
ensure practical success for everyone.
However, I have not seen the "target market" of git discussed yet
(I came late to the party), so if support for 5.6 (or 5.5) is not chosen,
it merely limits the market.
If you'd like, I can review all the Perl code with a tool that
determines the minimum Perl version, and provide patches to bring the
code to 5.5 level. But if it's likely that someone will say "this
is not important to us", I'd rather not waste my time. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] git-mv is not able to handle big directories
From: Randal L. Schwartz @ 2005-11-23 14:29 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Junio C Hamano, git
In-Reply-To: <200511231619.41497.lan@ac-sw.com>
>>>>> "Alexander" == Alexander Litvinov <lan@ac-sw.com> writes:
Alexander> I have made this change. I also belive it will work on earlier perl but I
Alexander> can't test this.
This patch looks good back to 5.5. I didn't execute it either, but
the Perl version installed in my head gave it a thumbs-up. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ 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