* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Andreas Ericsson @ 2007-10-08 9:23 UTC (permalink / raw)
To: Alex Riesen; +Cc: Elijah Newren, Frank Lichtenheld, git
In-Reply-To: <20071008061511.GA2859@steel.home>
Alex Riesen wrote:
> Elijah Newren, Mon, Oct 08, 2007 02:09:50 +0200:
>> On 10/7/07, Alex Riesen <raa.lkml@gmail.com> wrote:
>>> you missed something. Your example compresses to about 124k.
>> What version of git are you running? I reran all the steps to which
>
> git version 1.5.3.4.225.g31b973 (irrelevant custom modifications)
>
>> you responded (repeated below for clarity) with git-1.5.3.3 and still
>> get 11MB. Also, you must have different filesystem extents than me
>> since an empty git repo takes 196k here[1], so I don't think any repo
>> is going to get down to 124k.
>
> it is ext3. I do not install the hooks (~8k apparent, ~32k fs blocks)
> and never activate logs by default.
>
>> # Use vi to remove the line referring to refs/original...
>> git reflog expire --all
>
> another part of the suggestion re reflogs was to look into the logs,
> to check if expire actually removed anything. It seems to have been
> the culprit.
>
On my system, running git version 1.5.3.3.131.g34c6d,
git reflog expire --all
does absolutely nothing.
git reflog expire --expire=0 --all
truncates all the reflogs. I'm not sure if this is intended or not.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [StGit PATCH 0/6] Survive capital punishment
From: Karl Hasselström @ 2007-10-08 9:27 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20071008085830.GA7983@diana.vm.bytemark.co.uk>
On 2007-10-08 10:58:30 +0200, Karl Hasselström wrote:
> Will be available from
>
> git://repo.or.cz/stgit/kha.git safe
>
> momentarily (I just need to rebase the experimental branch on top of
> it).
There; both safe and experimental are updated. (It takes a while to
rebase when you run the test suite for every patch ...)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Andreas Ericsson @ 2007-10-08 9:27 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Elijah Newren, Alex Riesen, Frank Lichtenheld, git
In-Reply-To: <20071008010648.GB29433@potapov>
Dmitry Potapov wrote:
> On Sun, Oct 07, 2007 at 06:22:28PM -0600, Elijah Newren wrote:
>> git-filter-branch --tree-filter 'rm -f testme.txt' HEAD
>> git reset --hard
>> rm -rf .git/refs/original/
>> vi .git/packed-refs
>> # Use vi to remove the line referring to refs/original...
>> git reflog expire --all --expire-unreachable=0
>> git gc --prune
>>
>> Seems like a wrapper is needed. :-)
>
> Actually, I would rather not, because you rarely need to remove anything
> immediately, and 30 days delay is reasonable time to give you a chance
> to recover that you removed accidentally. You can reduce it by setting
> appropriate value for gc.reflogExpireUnreachable in your configuration.
> The only thing you need to do is to remove .git/refs/original/heads/something
> after you are sure that git-filter-branch did exactly what you wanted.
>
>>> Warning: all unreachable references will be removed!
>> What other scenarios could lead to unreachable references?
>
> Any re-writing of history leads to that.
>
git-rebase being the most common culprit, right alongside 'git commit --amend'.
>> I don't
>> know how to determine whether this is safe or not (except that these
>> were test repositories anyway, so I don't care what happens to them).
>
> Git logs all your action, so even re-writing history would not be
> so disastrous if you suddenly realized that you did something wrong.
> The history is stored for 30 days by default. Usually, you do not
> need to mess with Git internals like you did above. Your useless
> files still will disappear after being unreachable for 30 days.
>
> OTOH, if you want to have a clean repository immediately, I believe
> 'git clone' is a better option. After you made a local clone using
> it, 'git gc' should remove old garbage.
>
A clone only fetches revs reachable from a ref, so pruning immediately
after a clone is completely pointless.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Karl Hasselström @ 2007-10-08 10:05 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Dmitry Potapov, Elijah Newren, Alex Riesen, Frank Lichtenheld,
git
In-Reply-To: <4709F805.8050704@op5.se>
On 2007-10-08 11:27:33 +0200, Andreas Ericsson wrote:
> Dmitry Potapov wrote:
>
> > On Sun, Oct 07, 2007 at 06:22:28PM -0600, Elijah Newren wrote:
> >
> > > What other scenarios could lead to unreachable references?
> >
> > Any re-writing of history leads to that.
>
> git-rebase being the most common culprit, right alongside 'git
> commit --amend'.
StGit (and presumably guilt, and any other similar tool) are just
glorified rebase wrappers, so they'll generate tons of unreachable
objects too.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Merge problems with git-mingw
From: Peter Karlsson @ 2007-10-08 11:06 UTC (permalink / raw)
To: git
Hi!
I am running the mingw port of Git from a Cygwin environment, because I
had problems with the Cygwin version (not sure what the problem was,
probably a CRLF issue). Everything works fine, except for merging:
$ git merge master
usage: git-var [-l | <variable>]
$
Does anyone have any idea on what could cause that? (I've checked that
git-var is indeed the mingw version and not the Cygwin version).
$ git --version
git version 1.5.3.mingw.1
I'm running on top of another version control system, so I need to
switch back to master and update the sources from upstream using that
system's tools, and then merge it back into my branch. Without "git
merge" working, that is a bit problematic, to say the least... :-)
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Merge problems with git-mingw
From: Lars Hjemli @ 2007-10-08 12:00 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710081203020.29715@ds9.cixit.se>
On 10/8/07, Peter Karlsson <peter@softwolves.pp.se> wrote:
> $ git merge master
> usage: git-var [-l | <variable>]
> $
What does this command return?
$ git var GIT_COMMITTER_IDENT
--
larsh
^ permalink raw reply
* Re: Merge problems with git-mingw
From: Peter Karlsson @ 2007-10-08 12:33 UTC (permalink / raw)
Cc: git
In-Reply-To: <8c5c35580710080500n78259210v1b087e1ef506c0ee@mail.gmail.com>
> What does this command return?
>
> $ git var GIT_COMMITTER_IDENT
Doesn't seem to work:
$ git var GIT_COMMITTER_IDENT
usage: git-var [-l | <variable>]
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Dmitry Potapov @ 2007-10-08 12:40 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Elijah Newren, Alex Riesen, Frank Lichtenheld, git
In-Reply-To: <4709F805.8050704@op5.se>
On Mon, Oct 08, 2007 at 11:27:33AM +0200, Andreas Ericsson wrote:
> Dmitry Potapov wrote:
> >OTOH, if you want to have a clean repository immediately, I believe
> >'git clone' is a better option. After you made a local clone using
> >it, 'git gc' should remove old garbage.
> >
>
> A clone only fetches revs reachable from a ref, so pruning immediately
> after a clone is completely pointless.
Not true. git-clone copies the whole pack, so it can contain unreachable
objects. Here is a simple script that demonstrates that without garbage
collection the size of the cloned repository will be the same as the
original one.
===========================================
# Make a small repo
mkdir test
cd test
git init
echo hi > there
git add there
git commit -m 'Small repo'
# Add a random 10M binary file
dd if=/dev/urandom of=testme.txt count=10 bs=1M
git add testme.txt
git commit -m 'Add big binary file'
# Remove the 10M binary file
git rm testme.txt
git commit -m 'Remove big binary file'
# Compress the repo, see how big the repo is
git gc --aggressive --prune
du -ks . # 10348
du -ks .git # 10344
git-whatchanged
# Try to rewrite history to remove the binary file
git-filter-branch --tree-filter 'rm -f testme.txt' HEAD
git reset --hard
# Remove original refs
rm .git/refs/original/refs/heads/master
# Remove back
cd ..
# Clone repository
git-clone -l test/.git test2
cd test2
du -ks .git # 10360
# Now run garbage collection
git gc
du -ks .git # 96
===========================================
Dmitry
^ permalink raw reply
* Re: [StGIT PATCH] Better diagnostic for wrong branch configuration.
From: Catalin Marinas @ 2007-10-08 13:00 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20071005204452.30902.60246.stgit@gandelf.nowhere.earth>
On 05/10/2007, Yann Dirson <ydirson@altern.org> wrote:
> --- a/stgit/git.py
> +++ b/stgit/git.py
> @@ -1003,11 +1003,14 @@ def fetch_head():
> m = re.match('^([^\t]*)\t\t', line)
> if m:
> if fetch_head:
> - raise GitException, "StGit does not support multiple FETCH_HEAD"
> + raise GitException, 'StGit does not support multiple FETCH_HEAD'
> else:
> fetch_head=m.group(1)
> stream.close()
>
> + if not fetch_head:
> + raise GitException, 'No for-merge remote head found in FETCH_HEAD'
OK, I tried and it doesn't work with my StGIT over SVN configuration.
What I did is defining 'pull-policy' as 'fetch-rebase', 'fetchcmd' as
'git svn fetch' which doesn't create any FETCH_HEAD. The 'pullcmd' is
defined as 'git svn rebase' and it doesn't use any argument if
git.fetch_head() return None.
I also think it is better for the pull command to re-raise the
git.fetch_head exception as this one contains more detailed
information about the error (after the out.error call). It currently
shows that the remote head couldn't be found but there is the multiple
heads case raised by git.fetch_head.
--
Catalin
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Karl Hasselström @ 2007-10-08 13:01 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Andreas Ericsson, Elijah Newren, Alex Riesen, Frank Lichtenheld,
git
In-Reply-To: <20071008124017.GA22129@potapov>
On 2007-10-08 16:40:17 +0400, Dmitry Potapov wrote:
> On Mon, Oct 08, 2007 at 11:27:33AM +0200, Andreas Ericsson wrote:
>
> > A clone only fetches revs reachable from a ref, so pruning
> > immediately after a clone is completely pointless.
>
> Not true. git-clone copies the whole pack, so it can contain
> unreachable objects.
[...]
> git-clone -l test/.git test2
Try without the -l option and with a file:// URL:
git clone file:///path/to/test/.git test2
From the git-clone man page:
--local::
-l::
When the repository to clone from is on a local machine, this
flag bypasses normal "git aware" transport mechanism and
clones the repository by making a copy of HEAD and everything
under objects and refs directories. The files under
`.git/objects/` directory are hardlinked to save space when
possible. This is now the default when the source repository
is specified with `/path/to/repo` syntax, so it essentially is
a no-op option. To force copying instead of hardlinking (which
may be desirable if you are trying to make a back-up of your
repository), but still avoid the usual "git aware" transport
mechanism, `--no-hardlinks` can be used.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Merge problems with git-mingw
From: Lars Hjemli @ 2007-10-08 13:10 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710081333350.29715@ds9.cixit.se>
On 10/8/07, Peter Karlsson <peter@softwolves.pp.se> wrote:
> > What does this command return?
> >
> > $ git var GIT_COMMITTER_IDENT
>
> Doesn't seem to work:
>
> $ git var GIT_COMMITTER_IDENT
> usage: git-var [-l | <variable>]
Something is weird with your setup and/or the mingw port, but you can
probably work around the issue by doing this:
$ git config user.name "your name"
$ git config user.email "your email"
Optionally, you can add the --global flag to both commands to make the
config visible in all of your repos.
--
larsh
^ permalink raw reply
* Re: [StGit PATCH 09/13] Clear up the semantics of Series.new_patch
From: Catalin Marinas @ 2007-10-08 13:16 UTC (permalink / raw)
To: David Kågedal; +Cc: git
In-Reply-To: <20070914223154.7001.12254.stgit@morpheus.local>
On 14/09/2007, David Kågedal <davidk@lysator.liu.se> wrote:
> This patch adds a number of assertions to document and verify the
> complex restrictions of the input parameters to the Series.new_patch
> function. It also adds the requirement that 'before_existing' and
> 'commit' cannot be true at the same time when calling it, instead of
> updating 'commit' inside the function.
[...]
> --- a/stgit/stack.py
> +++ b/stgit/stack.py
> @@ -833,9 +833,16 @@ class Series(PatchSet):
> author_name = None, author_email = None, author_date = None,
> committer_name = None, committer_email = None,
> before_existing = False):
> - """Creates a new patch
> + """Creates a new patch, either pointing to an existing commit object,
> + or by creating a new commit object.
> """
>
> + assert commit or (top and bottom)
> + assert not before_existing or (top and bottom)
> + assert not (commit and before_existing)
> + assert (top and bottom) or (not top and not bottom)
> + assert not top or (bottom == git.get_commit(top).get_parent())
The last assertion here prevents the use of 'stg pick --reverse'. This
command creates an unapplied patch with top and bottom reversed and
pushes it to force a three-way merge.
It seems to work OK if I comment it out but I wonder whether it will
break in the future with the planned removal of the top and bottom
files.
Thanks.
--
Catalin
^ permalink raw reply
* Re: git: avoiding merges, rebasing
From: Benoit SIGOURE @ 2007-10-08 13:16 UTC (permalink / raw)
To: Bruno Haible; +Cc: bug-gnulib, git list
In-Reply-To: <C64152A3-A5A6-4320-864C-E78E3A60C8E6@lrde.epita.fr>
[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]
On Sep 30, 2007, at 10:27 PM, Benoit SIGOURE wrote:
> On Sep 30, 2007, at 9:41 PM, Bruno Haible wrote:
>
>>> it should be
>>> possible to create a custom [merge "cl-merge"] in your git config
>>> file,
>>> which points to a script designed specifically for resolving
>>> changelog
>>> conflicts
>>
>> I would love such a script, instead of constantly having to do
>> conflict
>> resolution at the top of ChangeLog.
>>
>
> So would I. I've had this in my TODO list for a long time so if no
> one else is willing to give it a try, I can try, but it won't be
> before next week because my schedule is quite busy until then.
>
I finally found some time to hack something and here is my git-merge-
changelog Perl script. I tested it quickly and it seems to work
fine. It will mess up the ChangeLog entries when a commit actually
modifies an existing ChangeLog entry. It needs more testing but I'm
just throwing this out in the wild for people that have interest in
this to review. I will eventually come up with a solution for the
commits modifying existing entries and a testsuite.
I'm CC-ing the Git ML just in case it interests some more people over
there.
In order to use it, add the following to your ~/.gitconfig:
[merge "cl-merge"]
name = GNU-style ChangeLog merge driver
driver = /path/to/git-merge-changelog %O %A %B
(you can also add it to a specific working copy by adding it in .git/
config instead)
Then, in the directory where the ChangeLog is, add a .gitattributes
file with the following content:
ChangeLog merge=cl-merge
For more information, see man gitattributes.
Let me know if something goes wrong.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: git: avoiding merges, rebasing
From: Benoit SIGOURE @ 2007-10-08 13:17 UTC (permalink / raw)
To: Bruno Haible; +Cc: bug-gnulib, git list
In-Reply-To: <C64152A3-A5A6-4320-864C-E78E3A60C8E6@lrde.epita.fr>
[-- Attachment #1.1: Type: text/plain, Size: 1799 bytes --]
[as usual, I forgot the attachment...]
On Sep 30, 2007, at 10:27 PM, Benoit SIGOURE wrote:
> On Sep 30, 2007, at 9:41 PM, Bruno Haible wrote:
>
>>> it should be
>>> possible to create a custom [merge "cl-merge"] in your git config
>>> file,
>>> which points to a script designed specifically for resolving
>>> changelog
>>> conflicts
>>
>> I would love such a script, instead of constantly having to do
>> conflict
>> resolution at the top of ChangeLog.
>>
>
> So would I. I've had this in my TODO list for a long time so if no
> one else is willing to give it a try, I can try, but it won't be
> before next week because my schedule is quite busy until then.
>
I finally found some time to hack something and here is my git-merge-
changelog Perl script. I tested it quickly and it seems to work
fine. It will mess up the ChangeLog entries when a commit actually
modifies an existing ChangeLog entry. It needs more testing but I'm
just throwing this out in the wild for people that have interest in
this to review. I will eventually come up with a solution for the
commits modifying existing entries and a testsuite.
I'm CC-ing the Git ML just in case it interests some more people over
there.
In order to use it, add the following to your ~/.gitconfig:
[merge "cl-merge"]
name = GNU-style ChangeLog merge driver
driver = /path/to/git-merge-changelog %O %A %B
(you can also add it to a specific working copy by adding it in .git/
config instead)
Then, in the directory where the ChangeLog is, add a .gitattributes
file with the following content:
ChangeLog merge=cl-merge
For more information, see man gitattributes.
Let me know if something goes wrong.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #1.2: git-merge-changelog --]
[-- Type: application/octet-stream, Size: 6749 bytes --]
#!/usr/bin/env perl
# Define a merge driver to use with Git to merge GNU-style ChangeLog entries.
# Copyright (C) 2007 Benoit Sigoure.
my $VERSION = '2007-10-08 12:33'; # UTC
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
# USA.
use warnings;
use strict; # Oh yes, spank me baby!
my $usage = "usage: $0 [OPTION] OLD CURRENT OTHERS\n";
# help(VAL)
# ---------
# Print the usage and exit with VAL.
sub help($)
{
print <<EOF;
$usage
Merge driver for Git to merge GNU-style ChangeLog entries. OLD is the the
merge ancestors' version, CURRENT is the current version, OTHERS is the
other branches' version. The result of the merge is left in the file
CURRENT unless the option --output is used.
--help display this help and exit
--version output version information and exit
-o, --output=FILE specify an output file
Report bugs to <tsuna\@lrde.epita.fr>
EOF
exit (shift);
}
sub version() # subversion is wrong! Use Git instead! ;D
{
print <<EOF;
git-merge-changelog $VERSION
Copyright (C) 2007 Benoit Sigoure
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
EOF
}
my $debug = 0;
# debug(MSG [, NL])
# ----------
# Print MSG on stderr if debugging is enabled. If NL is not given or is true,
# an additionnal \n is printed.
sub debug($;$)
{
return if not $debug;
my ($msg, $nl) = @_;
print STDERR $msg . (defined($nl) && !$nl ? '' : "\n");
}
# Return value of the script.
my $res = 0;
# error(MSG)
# ----------
# Print MSG on stderr and set the return value to be 1 (does not exit).
sub error($)
{
print STDERR "@_\n";
&debug;
$res = 1;
}
# Output file.
my $output;
# Parse ARGV, return the list of files to merge.
sub parse_options()
{
use Getopt::Long;
Getopt::Long::config('bundling', 'pass_through');
Getopt::Long::GetOptions
(
'h|help' => sub { help(0); },
'version' => sub { version; },
'debug' => \$debug,
'o|output=s' => \$output,
)
or die;
foreach my $arg (@ARGV)
{
if ($arg =~ /^-./)
{
print STDERR "$0: unrecognized option or bad usage for `$arg'\n";
print STDERR $usage;
print STDERR "Try `$0 --help' for more information.\n";
exit 1;
}
}
return @ARGV;
}
my @input_files = parse_options();
print STDERR $usage and exit(1) if $#input_files != 2;
$output = $input_files[1] unless defined $output;
debug "result of the merge will be written to $output";
foreach my $f (@input_files)
{
print STDERR "$0: `$f': No such file or not readable\n"
and exit(1)
unless -r $f;
}
# Hash of ChangeLog entries.
# The keys are dates of the form YYYY-MM-DD.
# The values are arrays of ChangeLog entries.
my %entries;
# add_entry(DATE, TEXT)
# Add the ChangeLog entry TEXT. DATE is of the form YYYY-MM-DD.
sub add_entry($$)
{
my ($date, $entry) = @_;
return if not defined $date or not defined $entry;
# Prevent duplicate entries.
foreach my $i (@{$entries{$date}})
{
if ($i eq $entry)
{
debug "Duplicate entry $date";
return;
}
}
debug "Got an entry $date";
# Add the new entry.
push (@{$entries{$date}}, $entry);
}
# Optional Copyright notice often found at the end of ChangeLogs.
my $copyright_notice;
# File in which we found the Copyright notice.
my $copyright_notice_file;
foreach my $f (@input_files)
{
# Buffer for the current ChangeLog entry.
my $cur_entry;
# Date of the current ChangeLog entry.
my $cur_date;
open(IN, $f) or die("Could not open '$f' for reading: $!");
debug ">>> processing `$f'";
while (<IN>)
{
if ($_ !~ /^[-0-9]{10} .*@.*/ && defined($cur_entry))
{
debug("adding...", 0);
$cur_entry .= $_;
}
elsif (/^([-0-9]{10}) .*@.*/)
{
add_entry($cur_date, $cur_entry);
$cur_date = $1; # Fragile, assumes that add_entry does use RE.
$cur_entry = $_;
}
elsif ($_ !~ /^\s*$/)
{
error("$0: $f:$.: Junk line: $_");
}
}
close(IN) or die("Error while closing '$f': $!");
# The last entry might contain a Copyright notice that needs to be
# extracted and re-printed last. We assume that the Copyright notice
# will be separated from the last ChangeLog entry by one or more
# blank lines and the Copyright notice starts on the 1st column.
if (defined($cur_entry) && $cur_entry =~ /^[0-9].*([\r\n]{2}\S.*?)$/s)
{
debug "Copyright notice in `$f'? <<<$1>>>";
if (defined $copyright_notice)
{
error("$0: Copyright notices in `$copyright_notice_file'"
. " and `$f' differ.\n")
if ($copyright_notice ne $1);
}
else
{
$copyright_notice = $1;
$copyright_notice_file = $f;
}
$cur_entry = substr($cur_entry, 0, length($1));
}
else
{
debug "No Copyright notice in `$f'";
}
add_entry($cur_date, $cur_entry);
}
# ---------------------- #
# Rebuild the ChangeLog. #
# ---------------------- #
use IO::Handle;
use IO::File;
my $out;
if ($output eq '-')
{
$out = new IO::Handle;
$out->fdopen(fileno(STDOUT), "w")
or die("Error while openning stdout: $!");
}
else
{
$out = new IO::File($output, '>')
or die("Could not open '$output' for writing: $!");
}
foreach my $k (sort { $b cmp $a } keys %entries)
{
foreach my $i (@{$entries{$k}})
{
print $out $i;
}
}
# If we have a Copyright notice, make sure it is terminated by a \n and
# print it.
if (defined $copyright_notice)
{
# Remove all the new lines at the beginning for the Copyright notice.
$copyright_notice =~ s/^[\r\n]+//;
# Ensure there is a trailing new line.
$copyright_notice =~ s/[^\r\n]$/$&\n/;
print $out $copyright_notice;
}
$out->close() or die("Error while closing '$output': $!");
debug "exit $res";
exit $res;
## Local Variables:
## eval: (add-hook 'write-file-hooks 'time-stamp)
## time-stamp-start: "$VERSION = '"
## time-stamp-format: "%:y-%02m-%02d %02H:%02M"
## time-stamp-time-zone: "UTC"
## time-stamp-end: "'; # UTC"
## End:
[-- Attachment #1.3: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [StGit PATCH 09/13] Clear up the semantics of Series.new_patch
From: Karl Hasselström @ 2007-10-08 13:25 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
In-Reply-To: <b0943d9e0710080616r36142946m3e24d2f6893287c9@mail.gmail.com>
On 2007-10-08 14:16:10 +0100, Catalin Marinas wrote:
> On 14/09/2007, David Kågedal <davidk@lysator.liu.se> wrote:
>
> > + assert commit or (top and bottom)
> > + assert not before_existing or (top and bottom)
> > + assert not (commit and before_existing)
> > + assert (top and bottom) or (not top and not bottom)
> > + assert not top or (bottom == git.get_commit(top).get_parent())
>
> The last assertion here prevents the use of 'stg pick --reverse'.
> This command creates an unapplied patch with top and bottom reversed
> and pushes it to force a three-way merge.
>
> It seems to work OK if I comment it out but I wonder whether it will
> break in the future with the planned removal of the top and bottom
> files.
I think the assert represents a real constraint, namely that there has
to be a 1:1 correspondance between patches and commits.
Couldn't "stg pick --reverse" create a new commit and use that? That
is, given that we want to revert commit C, create a new commit C* with
tree(C*) := tree(parent(C))
parent(C*) := C
Creating just one new commit object seems like a cheap thing to do.
And shouldn't there be a test for this? :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] git-gui: offer a list of recent repositories on startup
From: Steffen Prohaska @ 2007-10-08 14:16 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, msysgit
In-Reply-To: <20071007233023.GE2137@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 4995 bytes --]
Shawn,
I attached two patches. They should eventually be both squashed into
one.
You can also cherry pick them from work/setup-preview in 4msysgit.
I'm not yet fully convinced of the performance of the second patch.
It is far from optimal, although it might be sufficient.
If you're satisfied with the current implementation you can squash them
into a single commit; or ask me to do that.
More comments below, after the summary.
commit a483fdd562d6c44d68a998224e0bbb17933b624a
Author: Steffen Prohaska <prohaska@zib.de>
Date: Mon Oct 8 08:25:47 2007 +0200
git-gui: offer a list of recent repositories on startup
If git-gui is started outside a work tree the repository
chooser will offer a list of recently opend repositories.
Clicking on an entry directly opens the repository.
The list of recently opened repositories is stored in the
config as gui.recentrepos. If the list grows beyond 10
entries it will be truncated.
Note, only repositories that are opened through the
repository chooser will get added to the recent list.
Repositories opened from the shell will not yet be added.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
commit a9f083e83717eef91ba8842ece4a3ec0824126af
Author: Steffen Prohaska <prohaska@zib.de>
Date: Mon Oct 8 08:14:34 2007 +0200
git-gui: handle list of recent repos as multi config gui.recentrepo
Instead of encoding the list of recently opened repositories
in a single config line, this commit uses multiple lines of
gui.recentrepo.
An advantage is that the solution makes the list explicit
on the git config level. This may be easier to understand
if the user wants to look at the configuration.
A disadvantage (of the current implementation) is that it
requires more git config calls to manage the list. This could
be optimized. But maybe not required because the list is only
updated on opening a new repository, which is already a quite
expensive operation.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
On Oct 8, 2007, at 1:30 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>
>> + label $w_body.space
>> + label $w_body.recentlabel \
>> + -anchor w \
>> + -text "Select Recent Repository:"
>
> This string needs to be i18n'd with [mc ...].
changed in first patch.
>> + listbox $w_body.recentlist \
>
> Please make a field in this class called say "w_recentlist"
> so you can use that field name instead of $w_body.recentlist.
> This simplifies the code if we ever have to change the actual path
> that the widget resides at, such as to alter the layout.
changed in first patch.
>> +proc _append_recentrepos {path} {
>> + set recent [get_config gui.recentrepos]
>> + if {[lsearch $recent $path] < 0} {
>> + lappend recent $path
>> + }
>> + if {[llength $recent] > 10} {
>> + set recent [lrange $recent 1 end]
>> + }
>> + regsub -all "\[{}\]" $recent {"} recent
>> + git config --global gui.recentrepos $recent
>> +}
>
> Why treat this as a Tcl list in a single value? Why not make it
> a true multi-value configuration entry in ~/.gitconfig, like how
> remote.$name.fetch is a multi-value entry? Does Windows allow
> you to put " in a path name? Because the above regex will make
> a list of paths that contains " in one of the entries invalid.
I don't think " is allowed. I wasn't able to create a file containing
" in its path. Neither from the explorer nor on the command line.
> I think you also want to have this function return back immediately
> if [lsearch $recent $path] >= 0 as then you don't invoke git-config
> to perform a no-op change in the configuration file. As you well
> know forking on Windows is a major cost. We shouldn't run git-config
> just because the user opened a recent repository.
>
The second patch actually runs git config several times to first
remote all multi-value entries and then create them one by one. This
is worse performance than before.
This could be avoided by selectively removing only a single entry.
'git config' could be asked to only remove the entry that was removed
from the tcl list. But 'git config' only accepts regular expression
to do so.
I don't know how to escape a simple string to a corresponding
regular expression that matches only the string but nothing else.
For my problem it would be much easier if 'git config' accepted just
a plain string that must be matched exactly and not a regular
expression.
I see two solutions:
1) Someone explains me how to convert a string to a regular expression
matching only the input string.
2) "git config" is modified to accept a simple string as its second
argument.
Maybe we can use implementation in the second patch for now and wait
until "git config" is modified. Note, I'll not start to work on this
right
away because I want to stay focused on the basic functionality on
Windows and,
for now, do not care about performance too much.
Steffen
[-- Attachment #2: 0001-git-gui-offer-a-list-of-recent-repositories-on-star.patch --]
[-- Type: application/octet-stream, Size: 3342 bytes --]
From a483fdd562d6c44d68a998224e0bbb17933b624a Mon Sep 17 00:00:00 2001
From: Steffen Prohaska <prohaska@zib.de>
Date: Mon, 8 Oct 2007 08:25:47 +0200
Subject: [PATCH] git-gui: offer a list of recent repositories on startup
If git-gui is started outside a work tree the repository
chooser will offer a list of recently opend repositories.
Clicking on an entry directly opens the repository.
The list of recently opened repositories is stored in the
config as gui.recentrepos. If the list grows beyond 10
entries it will be truncated.
Note, only repositories that are opened through the
repository chooser will get added to the recent list.
Repositories opened from the shell will not yet be added.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-gui/lib/choose_repository.tcl | 49 +++++++++++++++++++++++++++++++++++++
1 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/git-gui/lib/choose_repository.tcl b/git-gui/lib/choose_repository.tcl
index 16bf67c..4f57572 100644
--- a/git-gui/lib/choose_repository.tcl
+++ b/git-gui/lib/choose_repository.tcl
@@ -41,6 +41,7 @@ field w_body ; # Widget holding the center content
field w_next ; # Next button
field o_cons ; # Console object (if active)
field w_types ; # List of type buttons in clone
+field w_recentlist ; # Listbox containing recent repositories
field action new ; # What action are we going to perform?
field done 0 ; # Finished picking the repository?
@@ -116,9 +117,27 @@ constructor pick {} {
-text [mc "Open Existing Repository"] \
-variable @action \
-value open
+ label $w_body.space
+ label $w_body.recentlabel \
+ -anchor w \
+ -text [mc "Select Recent Repository:"]
+ set w_recentlist $w_body.recentlist
+ listbox $w_recentlist \
+ -relief flat \
+ -width 50 \
+ -height 10 \
+ -exportselection false \
+ -selectmode select
+ foreach p [_get_recentrepos] {
+ $w_recentlist insert end $p
+ }
+ bind $w_recentlist <<ListboxSelect>> [cb _open_recent]
pack $w_body.new -anchor w -fill x
pack $w_body.clone -anchor w -fill x
pack $w_body.open -anchor w -fill x
+ pack $w_body.space -anchor w -fill x
+ pack $w_body.recentlabel -anchor w -fill x
+ pack $w_recentlist -anchor w -fill x
pack $w_body -fill x -padx 10 -pady 10
frame $w.buttons
@@ -171,6 +190,34 @@ method _invoke_next {} {
}
}
+proc _get_recentrepos {} {
+ set recent [list]
+ foreach p [get_config gui.recentrepos] {
+ if {[file isdirectory [file join $p .git]]} {
+ lappend recent $p
+ }
+ }
+ return [lsort $recent]
+}
+
+proc _append_recentrepos {path} {
+ set recent [get_config gui.recentrepos]
+ if {[lsearch $recent $path] < 0} {
+ lappend recent $path
+ }
+ if {[llength $recent] > 10} {
+ set recent [lrange $recent 1 end]
+ }
+ regsub -all "\[{}\]" $recent {"} recent
+ git config --global gui.recentrepos $recent
+}
+
+method _open_recent {} {
+ set id [$w_recentlist curselection]
+ set local_path [$w_recentlist get $id]
+ _do_open2 $this
+}
+
method _next {} {
destroy $w_body
_do_$action $this
@@ -893,6 +940,8 @@ method _do_open2 {} {
return
}
+ _append_recentrepos $local_path
+
set ::_gitdir .git
set ::_prefix {}
set done 1
--
1.5.3.mingw.1.99.gdbfb3
[-- Attachment #3: 0002-git-gui-handle-list-of-recent-repos-as-multi-config.patch --]
[-- Type: application/octet-stream, Size: 2535 bytes --]
From a9f083e83717eef91ba8842ece4a3ec0824126af Mon Sep 17 00:00:00 2001
From: Steffen Prohaska <prohaska@zib.de>
Date: Mon, 8 Oct 2007 08:14:34 +0200
Subject: [PATCH] git-gui: handle list of recent repos as multi config gui.recentrepo
Instead of encoding the list of recently opened repositories
in a single config line, this commit uses multiple lines of
gui.recentrepo.
An advantage is that the solution makes the list explicit
on the git config level. This may be easier to understand
if the user wants to look at the configuration.
A disadvantage (of the current implementation) is that it
requires more git config calls to manage the list. This could
be optimized. But maybe not required because the list is only
updated on opening a new repository, which is already a quite
expensive operation.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-gui/git-gui.sh | 3 ++-
git-gui/lib/choose_repository.tcl | 15 +++++++++------
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 3f5927f..8e56294 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -206,7 +206,8 @@ proc disable_option {option} {
proc is_many_config {name} {
switch -glob -- $name {
remote.*.fetch -
- remote.*.push
+ remote.*.push -
+ gui.recentrepo
{return 1}
*
{return 0}
diff --git a/git-gui/lib/choose_repository.tcl b/git-gui/lib/choose_repository.tcl
index 4f57572..9f6926c 100644
--- a/git-gui/lib/choose_repository.tcl
+++ b/git-gui/lib/choose_repository.tcl
@@ -192,7 +192,7 @@ method _invoke_next {} {
proc _get_recentrepos {} {
set recent [list]
- foreach p [get_config gui.recentrepos] {
+ foreach p [get_config gui.recentrepo] {
if {[file isdirectory [file join $p .git]]} {
lappend recent $p
}
@@ -201,15 +201,18 @@ proc _get_recentrepos {} {
}
proc _append_recentrepos {path} {
- set recent [get_config gui.recentrepos]
- if {[lsearch $recent $path] < 0} {
- lappend recent $path
+ set recent [get_config gui.recentrepo]
+ if {[lsearch $recent $path] >= 0} {
+ return
}
+ lappend recent $path
if {[llength $recent] > 10} {
set recent [lrange $recent 1 end]
}
- regsub -all "\[{}\]" $recent {"} recent
- git config --global gui.recentrepos $recent
+ git config --global --unset-all gui.recentrepo
+ foreach p $recent {
+ git config --global --add gui.recentrepo $p
+ }
}
method _open_recent {} {
--
1.5.3.mingw.1.99.gdbfb3
[-- Attachment #4: Type: text/plain, Size: 2 bytes --]
^ permalink raw reply related
* Re: [PATCH] git-shell and git-cvsserver
From: Jan Wielemaker @ 2007-10-08 14:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710080534270.4174@racer.site>
Dscho,
On Monday 08 October 2007 06:51, Johannes Schindelin wrote:
> On Fri, 5 Oct 2007, Jan Wielemaker wrote:
> > Hi,
> >
> > I know, I shouldn't be using git-cvsserver :-( Anyway, I patched
> > git-shell to start git-cvsserver if it is started interactively and the
> > one and only line given to it is "cvs server".
> >
> > The patch to shell.c is below. The trick with the EXEC_PATH is needed
> > because git-cvsserver doesn't appear to be working if you do not include
> > the git bindir in $PATH. I think that should be fixed in git-cvsserver
> > and otherwise we should at least make the value come from the prefix
> > make variable. With this patch I was able to use both Unix and Windows
> > cvs clients using git-shell as login shell.
> >
> > Note that you must provide ~/.gitconfig with user and email in the
> > restricted environment.
> >
> > Enjoy --- Jan
>
> I think this is a valuable contribution. That's why I comment...
Great :-)
> Please put a useful commit message (less like an email, more like
> something you want to read in git-log) at the beginning of the email, then
> a line containing _just_ "---", and after that some comments that are not
> meant to be stored in the history, like (I know this does not belong
> to...)
>
> After that, there should be a diffstat, and then the patch.
>
> The easiest to have this layout is to do a proper commit in git, use "git
> format-patch" to produce the patch, and then insert what you want to say
> in addition to the commit message between the "---" marker and the
> diffstat.
I buy that. I'm still trying to get used to all the features ...
> I strongly disagree (as you yourself, probably) with the notion that this
> does not belong into git-shell.
>
> > +#define EXEC_PATH "/usr/local/bin"
>
> This is definitely wrong. Use git_exec_path() instead.
I stated in my comments I was not happy about that. Before I start
submitting a new patch that may or may not be accepted, I'd like to have
some things clear. I manage an Open Source project for a long time (the
term not even invented in 1985 :-) Users come up with problems and
report on this. Most often with just a statement they don't like it,
sometimes with a detailed description of what is wrong and how to fix
it, sometimes with patches.
Generally, patches are not really how I like them, precisely the kind
of things that are wrong with my patch. Style issues, fixed A where
I consider the patch must be in B after a conflict between A and B
was detected, missing opportunities for code reuse, etc.
I try to talk frequent contributors into making things as `ready-to-use'
as possible. For incidental contributors I generally don't care. I just
rewrite the patch. Its less work for me than trying to explain all
details (as you kindly did and I agree to most of it, even learn some
new things) and it is too much work for someone who wishes an incidental
patch in the main distribution.
I don't want to become a GIT comitter, and I don't want to learn all of
its internals. Just a happy user for the SWI-Prolog project and an
internal project with some CVS addicts.
Cheers --- Jan
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: J. Bruce Fields @ 2007-10-08 14:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Elijah Newren, Frank Lichtenheld, git
In-Reply-To: <4709CCB2.4000202@viscovery.net>
On Mon, Oct 08, 2007 at 08:22:42AM +0200, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
>> The rationale was this: filter-branch recently learnt how to rewrite many
>> branches, and it might be tedious to find out which ones. But then, there
>> is git log --no-walk --all, so maybe I really should get rid of
>> refs/original/*?
>> I'd like to have some comments from the heavier filter-branch users on
>> that...
>
> IMHO, a backup of the original refs is needed.
And we can't rely instead on reflogs or some other existing mechanism?
> However, it may be wise to store them in the refs/heads namespace so
> that 'git branch -d' can delete them and 'git branch -m' can move them
> back if something went wrong.
If people want backups like this it'd seem easier to turn this on
optionally with commandline switches, like patch's --backup, --prefix,
--suffix options.
Having it by default leave these backups around, even when everything
succeeds, makes for unnecessary cleanup work in the normal case, and is
inconsistent with the behavior of other git commands that destroy or
rewrite history.
--b.
^ permalink raw reply
* Re: Merge problems with git-mingw
From: Peter Karlsson @ 2007-10-08 14:56 UTC (permalink / raw)
Cc: git
In-Reply-To: <8c5c35580710080610y739fb51aga82964e212c7917f@mail.gmail.com>
Hi!
> Something is weird with your setup and/or the mingw port, but you can
> probably work around the issue by doing this:
>
> $ git config user.name "your name"
> $ git config user.email "your email"
Both of those are configured properly, but even after configuring them
locally for the repository only, I get the same error with "git var".
Weird.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [StGit PATCH 6/6] Let some commands work with detached HEAD
From: Karl Hasselström @ 2007-10-08 15:34 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20071008085540.9734.60137.stgit@yoghurt>
On 2007-10-08 10:55:41 +0200, Karl Hasselström wrote:
> --- a/stgit/commands/diff.py
> +++ b/stgit/commands/diff.py
> @@ -42,7 +42,7 @@ rev = '([patch][//[bottom | top]]) | <tree-ish> | base'
> If neither bottom nor top are given but a '//' is present, the command
> shows the specified patch (defaulting to the current one)."""
>
> -directory = DirectoryHasRepository()
> +directory = DirectoryHasRepository(needs_current_series = False)
> options = [make_option('-r', '--range',
> metavar = 'rev1[..[rev2]]', dest = 'revs',
> help = 'show the diff between revisions'),
This hunk shouldn't be here, since diff does use crt_series. (The
commit message also has to be modified accordingly.)
So, we don't have a single test that tries to run "stg diff". Duh.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Theodore Tso @ 2007-10-08 16:37 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Sixt, Johannes Schindelin, Elijah Newren,
Frank Lichtenheld, git
In-Reply-To: <20071008143650.GC2902@fieldses.org>
On Mon, Oct 08, 2007 at 10:36:50AM -0400, J. Bruce Fields wrote:
> Having it by default leave these backups around, even when everything
> succeeds, makes for unnecessary cleanup work in the normal case, and is
> inconsistent with the behavior of other git commands that destroy or
> rewrite history.
I think what makes git-filter-branch different is that you can change
a large amount of history with git-filter-branch, including large
numbers of tags, etc. The reflog is quite sufficient to recover from
a screwed up "git commit --amend". But I don't think the reflog is
going to be sufficient given the kinds of changes that
git-filter-branch can potentially do to your repository. Maybe
default of --backup vs --no-backup could be changed via a config
parameter, but I think the default is of backing up refs is a good
think....
Perhaps a solution would be to add "git-filter-branch --cleanup" that
that clears the reflog and wipes the backed up tags; perhaps first
asking interactively if the user is really sure he/she wants to do
this.
- Ted
^ permalink raw reply
* [TIG PATCH] Add missing = for comparison in obsolete actions check.
From: James Bowes @ 2007-10-08 17:30 UTC (permalink / raw)
To: fonseca; +Cc: git
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
---
tig.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tig.c b/tig.c
index 933d083..30c505b 100644
--- a/tig.c
+++ b/tig.c
@@ -1184,7 +1184,7 @@ option_bind_command(int argc, char *argv[])
}
request = get_request(argv[2]);
- if (request = REQ_NONE) {
+ if (request == REQ_NONE) {
const char *obsolete[] = { "cherry-pick" };
size_t namelen = strlen(argv[2]);
int i;
--
1.5.3.4.1155.gfe96ee
^ permalink raw reply related
* Re: [PATCH] Make git-clean a builtin
From: Linus Torvalds @ 2007-10-08 18:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jeff King, Shawn Bohrer, git, gitster
In-Reply-To: <4709D027.3090003@viscovery.net>
On Mon, 8 Oct 2007, Johannes Sixt wrote:
> Jeff King schrieb:
> > On Sun, Oct 07, 2007 at 07:17:50PM -0700, Linus Torvalds wrote:
> >
> > > fchdir() is not portable.
> >
> > I was using the "even Solaris has it!" test, but yes, it's not POSIX. I
> > don't know how common it actually is (for curiosity's sake, do you know
> > of a common platform that lacks it?).
>
> Windows. ;)
Not just windows. Almost no "older" Unix has it. Including older versions
of Linux.
Linus
^ permalink raw reply
* Re: [PATCH 1/2] Have a filter_start/filter_end API.
From: Alex Riesen @ 2007-10-08 18:48 UTC (permalink / raw)
To: Pierre Habouzit, Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20071008072947.GB22552@artemis.corp>
Pierre Habouzit, Mon, Oct 08, 2007 09:29:47 +0200:
> On Sun, Oct 07, 2007 at 09:50:41PM +0000, Alex Riesen wrote:
> > Pierre Habouzit, Sun, Oct 07, 2007 18:52:18 +0200:
> > > Though, those are both things that I find ugly to "know" in convert.c.
> > > How things are allocated in strbufs is one of the few things we don't
> > > want to assume anywhere outside of the strbuf module.
> >
> > src is outside of strbuf scope. It is not internal to struct strbuf.
> > The caller must already know if it is inside of the given strbuf
> > instance.
> >
> > need_realloc is covered by make_room, isn't it?
>
> Internally yes, but make_room may move the buffer, if that happens,
> there is nothing we can do, in the case where we point inside (or at the
> begining of - fwiw it's the same here) the buffer
update the outside pointer you can. But I actually lost all interest:
personally I never use the filters and deeply despise the reasons
caused their existence.
> > I'd suggest just fix the caller, it is simple in convert.c: just use
> > ret, which contains exactly this information. If you insist on editing
> > in-place, which makes your routines really need the in-placeability
> > informaion. Just give it to them, better explicitely. All of this
> > makes the routines very convert.c specific, which is the reason why I
> > argument to have them just there and nowhere else.
> >
> > Alternatively, one can memdup ->buf (as it is the input for next
> > filter) every time a filter modifies it (which is safe, but simple,
> > slow, requires memory, and may fragment heap):
>
> This is exactly what we are trying to avoid with the current form.
I take this suggestion back. Do not use memdup, as it is slow,
requires lots of memory and may fragment heap. Sorry for repeating.
> Given how you try to micro-optimize strbuf_cmp I'm a bit lost here…
>
I didn't. It just happened. If I _wanted_ to optimize anything I
wouldn't start with a function which is used exactly one time in a
program with a name like "rerere" which is not even used in default
configuration.
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Alex Riesen @ 2007-10-08 18:51 UTC (permalink / raw)
To: Florian Weimer
Cc: Pierre Habouzit, Miles Bader, Wincent Colaiuta, David Kastrup,
Timo Hirvonen, git, Junio C Hamano
In-Reply-To: <82k5py6l6f.fsf@mid.bfk.de>
Florian Weimer, Mon, Oct 08, 2007 10:54:32 +0200:
> And "int len" in the first line of the function body should be
> "size_t len".
right. Missed that.
^ 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