* Re: [PATCH] gitweb: add --full-history to history generation optimization
From: Luben Tuikov @ 2006-07-03 1:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu060bmxy.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Thanks. I believe I have the same change in "next" already, but
> I had to munge your patches by hand so please holler if there is
> any mistake on my part.
Great, thanks. I took a look at "next" and it looks good.
Luben
^ permalink raw reply
* Re: Making perl scripts include the correct Git.pm
From: Junio C Hamano @ 2006-07-03 1:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7v64if1rop.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>> so this is my attempt to summarize it:
>
> Ah, our message crossed -- thanks for summarizing it. I do not
> particularly like any of the solution so far, but maybe the
> patch I just sent out to "do the normal thing unless we are
> running tests" might be the right thing to do.
I see you caught Merlyn so I decided the patch I sent earlier as
a tentative fix and merged the series in "next". We should be
able to fix Perly problems in-tree while we have his attention
;-).
Rene's merge-bases fix is also in "next". Hopefully this would
make merge-recursive work by Alex and Johannes go smoother?
On the other front, I applied the --remove-empty --parents fix
by Linus to "master". Since this broke gitk and qgit it might
warrant a 1.4.1.1 hotfix.
^ permalink raw reply
* Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file
From: Junio C Hamano @ 2006-07-03 2:09 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <e89ock$gks$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> I thought this stuff was "opt-in", but make rpm now requires
>> autoconf?
>
> Ooops. No, git RPM wouldn't need autoconf, neither building git from *.spec
> file or SRPM.
I had an impression that your spec.in change made it required.
It is still somewhat dubious to me if we can keep this "opt-in".
I noticed that it at least lacks a few extra commands to "clean"
target of the main Makefile, and adding them by itself is not so
bad, but who knows what else it would bring in when the series
finishes. I would not be surprised if we start touching *.c and
*.h files with new autoconf-compatible "#ifdef HAVE_XXX" and at
that point I will say "I told you so".
I am not opposed to giving an alternative, semi-automated way to
edit config.mak to the users, and if that is our goal, we should
ship the configure script in the source tarball at least, and
probably we should have the configure script in the revisions as
well. Using autoconf is not the goal here -- giving ./configure
as an alternative way to manage config.mak is.
But if we have autoconf scripts _and_ configure script in
revisions, we are talking about version controlling generated
stuff, and I'd like to avoid that at all cost.
Maybe an alternative is to just add configure script in the
source tree _without_ adding any of the autoconf scripts to the
git repository. The users can choose to use that script to
manage config.mak but do not have to. And I do not mind getting
occasional updates to the configure script in the source tree,
and I do not care if you build it by hand or use autoconf to
generate it, as long as the configure script is readable,
debuggable and maintainable.
The source to generate that configure script might be autoconf
scripts and you would want to version control that. That is
fine but I think that would be a separate project of yours, and
you may call that the git-build-config project. And I do not
mind hosting that somewhere under contrib/ area in the git
repository in order to give it wider exposure.
That would end up in the same situation as having the source and
generated files under the version control, but I think at the
philosophical level the two are vastly different, in that the
things under contrib/ are not part of git.git but are there only
for convenience. I will not be the one who is responsible to
run autoconf in there every time we make changes to the system
and propagate the changes to the main configure script. The
configure script generated by the end user in contrib/autoconf
may not match the toplevel configure script (the end user may
have different version of autoconf, for example) but that is not
a bug, as long as the toplevel configure script, which might be
output by an older version of autoconf, works correctly.
The above assumes that the configure script generated by your
autoconf script is readable and maintainable at all. Otherwise
it would not make any sense to have configure under version
control.
^ permalink raw reply
* contrib/ status
From: Junio C Hamano @ 2006-07-03 2:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vslljwiat.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ... the
> things under contrib/ are not part of git.git but are there only
> for convenience....
This reminds me of something quite different. I am getting an
impression that enough people have been helped by git-svn and it
might be a good idea to have it outside contrib/ area.
OTOH I haven't seen much interest in contrib/colordiff, now
Johannes's built-in "diff --color" is in. So if people do not
mind, I'd like to drop it.
^ permalink raw reply
* [RFC/PATCH] consistently try VISUAL, EDITOR and vi in this order.
From: Junio C Hamano @ 2006-07-03 2:47 UTC (permalink / raw)
To: git
git grep -e VISUAL -e EDITOR revealed this inconsistency. All
other commands seem to check VISUAL and then EDITOR as they should.
---
diff --git a/git-send-email.perl b/git-send-email.perl
index c5d9e73..7b81962 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -222,8 +256,7 @@ GIT: for the patch you are writing.
EOT
close(C);
- my $editor = $ENV{EDITOR};
- $editor = 'vi' unless defined $editor;
+ my $editor = $ENV{VISUAL} || $ENV{EDITOR} || 'vi';
system($editor, $compose_filename);
open(C2,">",$compose_filename . ".final")
^ permalink raw reply related
* Re: [PATCH] send-email: Use setlocale in addition to $ENV{LC_ALL} to set locale
From: Junio C Hamano @ 2006-07-03 2:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Eric Wong
In-Reply-To: <20060621104941.GB15748@localdomain>
I was reviewing old log and noticed this topic has never been
resolved. Your proposal was to use POSIX::setlocale(), and
Eric's counter-proposal was to mimic what 822-date script does,
doing it by hand without mucking with locales, and the
discussion seemed to have died there. Does this still need to
be addressed?
My gut feeling is that it would probably be less problematic if
we do not muck with locales at all (so drop POSIX::strftime as
well).
So maybe something like this (totally untested)?
-- >8 --
[PATCH] do not use locale specific strftime when preparing 2822 date
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-send-email.perl b/git-send-email.perl
index c5d9e73..bc42761 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -23,8 +23,43 @@ use Getopt::Long;
use Data::Dumper;
# most mail servers generate the Date: header, but not all...
-$ENV{LC_ALL} = 'C';
-use POSIX qw/strftime/;
+sub format_2822_time {
+ my ($time) = @_;
+ my @localtm = localtime($time);
+ my @gmttm = gmtime($time);
+ my $localmin = $localtm[1] + $localtm[2] * 60;
+ my $gmtmin = $gmttm[1] + $gmttm[2] * 60;
+ if ($localtm[0] != $gmttm[0]) {
+ die "local zone differs from GMT by a non-minute interval\n";
+ }
+ if ((($gmttm[6] + 1) % 7) == $localtm[6]) {
+ $localmin += 1440;
+ } elsif ((($gmttm[6] - 1) % 7) == $localtm[6]) {
+ $localmin -= 1440;
+ } elsif ($gmttm[6] != $localtm[6]) {
+ die "local time offset greater than or equal to 24 hours\n";
+ }
+ my $offset = $localmin - $gmtmin;
+ my $offhour = $offset / 60;
+ my $offmin = abs($offset % 60);
+ if (abs($offhour) >= 24) {
+ die ("local time offset greater than or equal to 24 hours\n");
+ }
+
+ return sprintf("%s, %2d %s %d %02d:%02d:%02d %s%02d%02d",
+ qw(Sun Mon Tue Wed Thu Fri Sat)[$localtm[6]],
+ $localtm[3],
+ qw(Jan Feb Mar Apr May Jun
+ Jul Aug Sep Oct Nov Dec)[$localtm[4]],
+ $localtm[5]+1900,
+ $localtm[2],
+ $localtm[1],
+ $localtm[0],
+ ($offset >= 0) ? '+' : '-',
+ abs($offhour),
+ $offmin,
+ );
+}
my $have_email_valid = eval { require Email::Valid; 1 };
my $smtp;
@@ -371,7 +405,7 @@ sub send_message
my @recipients = unique_email_list(@to);
my $to = join (",\n\t", @recipients);
@recipients = unique_email_list(@recipients,@cc,@bcclist);
- my $date = strftime('%a, %d %b %Y %H:%M:%S %z', localtime($time++));
+ my $date = format_2822_time($time++);
my $gitversion = '@@GIT_VERSION@@';
if ($gitversion =~ m/..GIT_VERSION../) {
$gitversion = `git --version`;
^ permalink raw reply related
* There you have it. Git.pm breaks pull.
From: Johannes Schindelin @ 2006-07-03 4:35 UTC (permalink / raw)
To: git
Hi,
I do not install git, but run it in place. And now git-pull, the core of
git, is broken.
Can't locate Git.pm in @INC (@INC contains:
/home/gene099/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
/usr/lib/perl5/5.8.0/i586-linux-thread-multi /usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl .) at
./git-fmt-merge-msg line 14.
BEGIN failed--compilation aborted at ./git-fmt-merge-msg line 14.
I have to run for work, but next thing I'll do with git is rewrite
git-fmt-merge-msg in C.
Ciao,
Dscho
^ permalink raw reply
* Re: There you have it. Git.pm breaks pull.
From: Junio C Hamano @ 2006-07-03 4:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607030633120.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Can't locate Git.pm in @INC (@INC contains:
> /home/gene099/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
> /usr/lib/perl5/5.8.0/i586-linux-thread-multi /usr/lib/perl5/5.8.0
> /usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl .) at
> ./git-fmt-merge-msg line 14.
> BEGIN failed--compilation aborted at ./git-fmt-merge-msg line 14.
You need to set up your PERL5LIB appropriately, in addition to
what you used to set: PATH and GIT_EXEC_PATH. Something like
this, perhaps:
PERL5LIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git
GIT_EXEC_PATH=`pwd`
PATH=`pwd`:/usr/bin:/bin
export GIT_EXEC_PATH PATH PERL5LIB
^ permalink raw reply
* Re: There you have it. Git.pm breaks pull.
From: Junio C Hamano @ 2006-07-03 4:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Petr Baudis
In-Reply-To: <7v64ifuwo7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> Can't locate Git.pm in @INC (@INC contains:
>> /home/gene099/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
>>...
> You need to set up your PERL5LIB appropriately, in addition to
> what you used to set: PATH and GIT_EXEC_PATH. Something like
> this, perhaps:
>
> PERL5LIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git
> GIT_EXEC_PATH=`pwd`
> PATH=`pwd`:/usr/bin:/bin
>
> export GIT_EXEC_PATH PATH PERL5LIB
... and I tested the above -- it works fine.
As we repeatedly discussed ever since we introduced
GIT_EXEC_PATH, running without installation is something
nonstandard and one would need to work a bit harder, like the
above, to make it work, but the good thing is it can be made to
work.
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-03 5:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, junkio
In-Reply-To: <e89iql$42a$1@sea.gmane.org>
On 7/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> > What do you think about this:
> >
> > When dropping the selected commits, instead of creating new commits,
> > appears a message box with something like "Do you want to apply the
> > commits on top of your current branch or on your working directory?"
> >
> > Sounds good for you? Or you still prefer the context menu?
> > In the latter case, if I have understood correctly, you are limited to
> > cherry-pick among branches and/or working directory of the _same_
> > repository.
>
> Yes, git-cherry-pick works only between commits in the same repository,
> as it use merge (first "simple", i.e. git-read-tree -m -u --aggresive, if
> fails tries "automatic" i.e. git-merge-index -o git-merge-one-file -a, then
> git-write-tree), as opposed to git-format-patch and git-am or git-apply,
> which can work across repositories.
>
> What I really want is "no-commit" of drag'n'dropped, or exported and applied
> commits/patches (although interface to cherry-pick would be nice, even if
> cherry-pick is limited), so I'd like message box with "Do you want to
> commit selected patches?" when dropping commits, or something like that.
> Unfortunately git-am doesn't have --no-commit flag, but one could emulate it
> with git-reset after git-am a patch, I think.
>
When I need to modify the patch/revision before to import I usaually
drag&drop and then I call git-reset --soft, then I edit working
directory and commit again.
Perhaps I can automate this in case the user answers "No, apply to
working dir only" to the message box.
Is it the correct way to go or is better to wait for a --no-commit
flag in git-am?
Junio?
Thanks
Marco
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Junio C Hamano @ 2006-07-03 6:42 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550607022245s2ef160fu5ad30a822f06117d@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> When I need to modify the patch/revision before to import I usaually
> drag&drop and then I call git-reset --soft, then I edit working
> directory and commit again.
These days, I tend to just let "am" or "pull" do its thing, edit
working tree and retest, and run "commit --amend". Before we
added "commit --amend", I used to do soft reset and recommit
like you described above. One advantage of "commit --amend" is
that it can even amend a merge, but I do not think it applies to
what Jakub wants in this thread.
> Perhaps I can automate this in case the user answers "No, apply to
> working dir only" to the message box.
>
> Is it the correct way to go or is better to wait for a --no-commit
> flag in git-am?
Probably your "git-am --no-commit" would stop after applying one
patch (the first one in the sequence) but before writing a
commit. We already sometimes do that when the patch does not
apply cleanly, so I do not offhand have much objection against
adding such a flag.
I think the workflow to continue after "git-am --no-commit" will
be quite similar to what you would do when "git-am --3way" stops
with conflicts. In order to continue from there, you would do
whatever is needed to bring the index into the shape you wanted
to have if the patch applied cleanly. Then "git am --resolved".
Perhaps something like the attached. If somebody finds it
useful, after testing it out, please kick it back to me, perhaps
with a paragraph or two to properly document it.
-- >8 --
git-am --fail
The new flag prevents a new commit from being made even when the
patch applies cleanly. This gives you an opportunity to further
fix up the change in your working tree before making the final
commit.
In order to continue, do whatever is needed to bring the index
into the shape you wanted to have if the patch applied cleanly,
and run "git am --resolved".
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-am.sh b/git-am.sh
index 679045a..77d8cd9 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -3,7 +3,7 @@ #
# Copyright (c) 2005, 2006 Junio C Hamano
USAGE='[--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way]
- [--interactive] [--whitespace=<option>] <mbox>...
+ [--fail] [--interactive] [--whitespace=<option>] <mbox>...
or, when resuming [--skip | --resolved]'
. git-sh-setup
@@ -91,7 +91,7 @@ fall_back_3way () {
}
prec=4
-dotest=.dotest sign= utf8= keep= skip= interactive= resolved= binary= ws= resolvemsg=
+dotest=.dotest sign= utf8= keep= skip= interactive= resolved= binary= ws= resolvemsg= fail=
while case "$#" in 0) break;; esac
do
@@ -109,6 +109,9 @@ do
-b|--b|--bi|--bin|--bina|--binar|--binary)
binary=t; shift ;;
+ -f|--f|--fa|--fai|--fail)
+ fail=t; shift ;;
+
-3|--3|--3w|--3wa|--3way)
threeway=t; shift ;;
-s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
@@ -401,6 +404,10 @@ do
then
echo Patch failed at $msgnum.
stop_here_user_resolve $this
+ elif test -n "$fail"
+ then
+ echo Stopped at $msg per user request
+ stop_here_user_resolve $this
fi
if test -x "$GIT_DIR"/hooks/pre-applypatch
^ permalink raw reply related
* Re: [POLL] Who likes running Git without make install?
From: Junio C Hamano @ 2006-07-03 6:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060701235906.GE29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Well, yes, it is ugly, but it was really cool that we could have used
> Git without installing it anywhere.
>
> But perhaps that's just me refusing to break his old ways of doing
> things. Does anyone else care about it? (And why?)
I do not think you need to break your old ways. Perhaps a patch
like this might help.
-- >8 --
INSTALL: a tip for running after building but without installing.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/INSTALL b/INSTALL
index f8337e2..ed502de 100644
--- a/INSTALL
+++ b/INSTALL
@@ -29,6 +29,19 @@ Issues of note:
has been actively developed since 1997, and people have moved over to
graphical file managers.
+ - You can use git after building but without installing if you
+ wanted to. Various git commands need to find other git
+ commands and scripts to do their work, so you would need to
+ arrange a few environment variables to tell them that their
+ friends will be found in your built source area instead of at
+ their standard installation area. Something like this works
+ for me:
+
+ GIT_EXEC_PATH=`pwd`
+ PATH=`pwd`:$PATH
+ PERL5LIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git
+ export GIT_EXEC_PATH PATH PERL5LIB
+
- Git is reasonably self-sufficient, but does depend on a few external
programs and libraries:
^ permalink raw reply related
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Andreas Ericsson @ 2006-07-03 7:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Lederhofer, git
In-Reply-To: <7vejx6k54p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Matthias Lederhofer <matled@gmx.net> writes:
>
>
>>Junio C Hamano wrote:
>>
>>>I see you are trying hard to think of a way to justify your
>>>original prefix "--and" (or --FOO) implementation, but I simply
>>>do not see much point in that. I doubt changing the default
>>>operator from --or to --and is less confusing than changing the
>>>precedence for the users, so you would hear the same "I
>>>personally feel FOO should not even exist" objection from me.
>>
>>It just happens to make more sense to me and I don't see a reason not to
>>add this. If no one else is interested in this I'll just stop arguing :)
>>Here again an overview of the arguments if anyone is interested:
>>- Less to type for common searches using only AND (or more ANDs than
>> ORs).
>>- Easy to implement (both with and without extended expressions).
>>- AND/* is the normal implicit operator in other contexts than grep
>> (math).
>>- The high precedence operator (AND) should be implicit rather than
>> the low precedence one (OR) (so this is only fulfilled when the
>> option is used).
>
>
> Side note. It would be interesting to have a slightly different
> form of --and called --near. You would use it like this:
>
> git grep -C -e AND --near -e OR
>
> to find lines that has AND on it, and within the context
> distance there is a line that has OR on it. The lines that are
> hit with such a query are still the ones that have AND on them
> (in other words, a line that has OR is used to further filter
> out the results so it will be prefixed with '-', not ':', unless
> that line happens to also have AND on it).
>
It would also be neat to have --inside main or some such, to make it
only check for things inside whatever's printed on the diff --git line.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [POLL] Who likes running Git without make install?
From: Petr Baudis @ 2006-07-03 7:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslljrxe0.fsf_-_@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Jul 03, 2006 at 08:54:47AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> -- >8 --
> INSTALL: a tip for running after building but without installing.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Petr Baudis <pasky@suse.cz>
I can live with this "weak (D3)". 99% of Git users probably use
installed Git instance anyway and most of the rest are likely to be Git
developers testing new code who can do this extra environment setup.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: contrib/ status
From: Eric Wong @ 2006-07-03 8:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzbrwi3c.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > ... the
> > things under contrib/ are not part of git.git but are there only
> > for convenience....
>
> This reminds me of something quite different. I am getting an
> impression that enough people have been helped by git-svn and it
> might be a good idea to have it outside contrib/ area.
That would be great. IMHO, it puts git in a position to supplant
centralized SVN usage one developer at a time, making it easier
to make a gradual transition to git. Of course, there's also svk
in a similar position...
--
Eric Wong
^ permalink raw reply
* Re: [POLL] Who likes running Git without make install?
From: Junio C Hamano @ 2006-07-03 8:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060703075850.GL29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Mon, Jul 03, 2006 at 08:54:47AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> -- >8 --
>> INSTALL: a tip for running after building but without installing.
>>
>> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> Acked-by: Petr Baudis <pasky@suse.cz>
>
> I can live with this "weak (D3)". 99% of Git users probably use
> installed Git instance anyway and most of the rest are likely to be Git
> developers testing new code who can do this extra environment setup.
You earlier had to set two environment variables anyway but you
have added another. I do not see what's weak about it.
^ permalink raw reply
* Re: [PATCH] consider previous pack undeltified object state only when reusing delta data
From: Andreas Ericsson @ 2006-07-03 8:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606301132510.1213@localhost.localdomain>
Nicolas Pitre wrote:
> On Fri, 30 Jun 2006, Andreas Ericsson wrote:
>
>>Johannes Schindelin wrote:
>>>
>>>>Without this there would never be a chance to improve packing for
>>>>previously undeltified objects.
>>>
>>>
>>>Earlier this year, I was quite surprised to learn that multiple repackings
>>>actually improved packing. Does that patch mean this feature is gone?
>>>
>>
>>The patch Linus sent removes that feature. This one re-introduces it.
>
>
> Not really.
>
> Actually that multiple repacking "feature" was rather an artifact of the
> delta data reuse code and not really by design. Here's what happened
> before:
>
Thanks for the extensive and very clear info. Lovely to see a competent
programmer who can also explain how things work. :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [POLL] Who likes running Git without make install?
From: Petr Baudis @ 2006-07-03 8:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzbrrtz4.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Jul 03, 2006 at 10:08:31AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Dear diary, on Mon, Jul 03, 2006 at 08:54:47AM CEST, I got a letter
> > where Junio C Hamano <junkio@cox.net> said that...
> >> -- >8 --
> >> INSTALL: a tip for running after building but without installing.
> >>
> >> Signed-off-by: Junio C Hamano <junkio@cox.net>
> >
> > Acked-by: Petr Baudis <pasky@suse.cz>
> >
> > I can live with this "weak (D3)". 99% of Git users probably use
> > installed Git instance anyway and most of the rest are likely to be Git
> > developers testing new code who can do this extra environment setup.
>
> You earlier had to set two environment variables anyway but you
> have added another. I do not see what's weak about it.
I don't usually use the git wrapper so I got away without setting
GIT_EXEC_PATH yet. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [POLL] Who likes running Git without make install?
From: Johannes Schindelin @ 2006-07-03 8:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060703081725.GM29115@pasky.or.cz>
Hi,
On Mon, 3 Jul 2006, Petr Baudis wrote:
> Dear diary, on Mon, Jul 03, 2006 at 10:08:31AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > > Dear diary, on Mon, Jul 03, 2006 at 08:54:47AM CEST, I got a letter
> > > where Junio C Hamano <junkio@cox.net> said that...
> > >> -- >8 --
> > >> INSTALL: a tip for running after building but without installing.
> > >>
> > >> Signed-off-by: Junio C Hamano <junkio@cox.net>
> > >
> > > Acked-by: Petr Baudis <pasky@suse.cz>
> > >
> > > I can live with this "weak (D3)". 99% of Git users probably use
> > > installed Git instance anyway and most of the rest are likely to be Git
> > > developers testing new code who can do this extra environment setup.
> >
> > You earlier had to set two environment variables anyway but you
> > have added another. I do not see what's weak about it.
>
> I don't usually use the git wrapper so I got away without setting
> GIT_EXEC_PATH yet. ;-)
This is the config.mak I use everywhere:
-- snip --
bindir = $(shell pwd)
template_dir = $(bindir)/templates/blt
GIT_PYTHON_DIR = $(bindir)/compat
-- snap --
No environment variable.
Ciao,
Dscho
^ permalink raw reply
* Re: There you have it. Git.pm breaks pull.
From: Johannes Schindelin @ 2006-07-03 8:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis
In-Reply-To: <7v1wt3uvvq.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 2 Jul 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> Can't locate Git.pm in @INC (@INC contains:
> >> /home/gene099/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
> >>...
> >
> > PERL5LIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git
> > export PERL5LIB
>
> ... and I tested the above -- it works fine.
Thank you. It works fine, here, too.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] consistently try VISUAL, EDITOR and vi in this order.
From: Jakub Narebski @ 2006-07-03 9:24 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzbrv1yc.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> git grep -e VISUAL -e EDITOR revealed this inconsistency. All
> other commands seem to check VISUAL and then EDITOR as they should.
>
> + my $editor = $ENV{VISUAL} || $ENV{EDITOR} || 'vi';
> system($editor, $compose_filename);
Shouldn't we check if we are in visual (non CLI-only) environment,
like X-Window, MS Windows or MacOS X, before trying to use VISUAL?
How other parts solve it? </me checks> Ah, we use VISUAL unconditionally,
at least in scripts...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 3/3] Make clear_commit_marks() clean harder
From: Junio C Hamano @ 2006-07-03 9:32 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git, Johannes Schindelin, Linus Torvalds
In-Reply-To: <20060701232958.GC2513@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Don't care if objects have been parsed or not and don't stop when we
> reach a commit that is already clean -- its parents could be dirty.
There is something quite wrong with this patch. When you are
dealing with complex commit ancestry, this ends up traversing
the same parent over and over again.
I tried to do a merge in linux-2.6 history with these two
commits:
v2.6.17-g29454dd
v2.6.17-gd6b0c53
The former is Linus's head at this writing, and the latter is
James Bottomley's scsi-misc head.
git describe 29454dd d6b0c53
from the "master" branch returns immediately (the use there can
assume that the mark is set and contiguous, I think) while the
one with this patch takes forever.
Another example is to try changing get_merge_bases() to always
clean-up as Johannes had originally and try computing the merge
base between the two. Just before it starts to clean-up, it has
only seen 5983 objects (object.c::nr_objs) and it definitely
would be faster to clean flags from all these objects than to
wait for the two calls to clear_commit_marks() to complete,
which seems to also take forever.
^ permalink raw reply
* Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file
From: Jakub Narebski @ 2006-07-03 11:05 UTC (permalink / raw)
To: git
In-Reply-To: <7vslljwiat.fsf@assigned-by-dhcp.cox.net>
As I see it, we have the following options with respect to autoconf related
files and use of ./configure script
1. Use autoconf and ./configure script generated by it as optional way to
configure installation process. Have configure.ac and config.mak.in in main
directory of git.git repository. Do not use ./configure script in
git.spec.in, i.e. do not apply this patch... perhaps put _patch_ in the
contrib/. Leave changes to *.spec file to distributions, documenting it
somewhere.
2. Use autoconf and ./configure script generated by it as optional way to
configure installation process _and_ in git.spec.in, i.e. in the RPM
building. Ship generated 'configure' script with distribution (source)
tarball or make patch creating 'configure' script and use it instead in
git.spec.in (avoids shipping 'configure' in source tarball). This has the
consequence that autoconf would be build dependence for creating RPM at
least. Perhaps we can have automatically build configure script in separate
branch, similarly to 'man' and 'html branches of git.git.
3. Write our own ./configure script, put it under version control, and put
autoconf related files in contrib/ as an alternative. Advantages: we can
customize it to git needs and git build process conventions. Disadvantages:
duplication of work put into autoconf to make generated ./configure script
portable (which is also the case why atoconf generated shel script
'configure' is not very readable, and probably should be not under version
control; html and man documentation aren't either). Use %configure in
git.spec.in file. Plan for the future?
I am partially to [*1*], if just because I wouldn't need to take care
autoconf in git. [*2*] has disadvantage in that generated ./configure needs
to be put in main directory to work, either by hand (which complicates
using this way of building and installing git) or by script (which violates
unsaid rule that contrib/ doesn't interfere in top directory). [*3*] would
be probably the best, but it is additional work, duplication of autoconf
efforts, and need someone (not me) well versed in git compiling woes _and_
shell script portability.
--
Jakub Narębski
ShadeHawk on #git
^ permalink raw reply
* Compression speed for large files
From: Joachim B Haga @ 2006-07-03 11:13 UTC (permalink / raw)
To: git
I'm looking at doing version control of data files, potentially very large,
often binary. In git, committing of large files is very slow; I have tested with
a 45MB file, which takes about 1 minute to check in (on an intel core-duo 2GHz).
Now, most of the time is spent in compressing the file. Would it be a good idea
to change the Z_BEST_COMPRESSION flag to zlib, at least for large files? I have
measured the time spent by git-commit with different flags in sha1_file.c:
method time (s) object size (kB)
Z_BEST_COMPRESSION 62.0 17136
Z_DEFAULT_COMPRESSION 10.4 16536
Z_BEST_SPEED 4.8 17071
In this case Z_BEST_COMPRESSION also compresses worse, but that's not the major
issue: the time is. Here's a couple of other data points, measured with gzip -9,
-6 and -1 (comparable to the Z_ flags above):
129MB ascii data file
method time (s) object size (kB)
gzip -9 158 23066
gzip -6 18 23619
gzip -1 6 32304
3MB ascii data file
gzip -9 2.2 887
gzip -6 0.7 912
gzip -1 0.3 1134
So: is it a good idea to change to faster compression, at least for larger
files? From my (limited) testing I would suggest using Z_BEST_COMPRESSION only
for small files (perhaps <1MB?) and Z_DEFAULT_COMPRESSION/Z_BEST_SPEED for
larger ones.
-j.
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-03 11:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vzmfrrxyp.fsf@assigned-by-dhcp.cox.net>
On 7/3/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > When I need to modify the patch/revision before to import I usaually
> > drag&drop and then I call git-reset --soft, then I edit working
> > directory and commit again.
>
> These days, I tend to just let "am" or "pull" do its thing, edit
> working tree and retest, and run "commit --amend". Before we
> added "commit --amend", I used to do soft reset and recommit
> like you described above. One advantage of "commit --amend" is
> that it can even amend a merge, but I do not think it applies to
> what Jakub wants in this thread.
>
I cannot test your patch now, so I'm just guessing, what if we have a
series of patches?
Is it possible that for two patches A and B happens that
git-am A
git-am B
git-reset --soft HEAD^^
gives a different result then
git-am --fail A
git-am --fail B
As example, if B modify the same file of A then could happen that in
the latter case git-am --fail B stops with conflicts because the
working dir is not synced with the index (this happens only in the
latter case) ?
Put in other words, I don't know if the two procedures are
_equivalent_ because in the first case you operate under the
assumption that working dir and index are always synced before and
after to apply, in the second case this assumption is broken so I
don't know if this could have side effects.
Marco
^ 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