* Re: Re : 2 questions on git-send-email usage
From: Junio C Hamano @ 2006-07-12 16:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Franck Bui-Huu
In-Reply-To: <Pine.LNX.4.64.0607120834200.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On a slightly related note, I absolutely _hate_ how cherry-picking adds
> "(cherry-picked from commit <sha1>)" at the end. It's wrong for so many
> reasons, one of them being that it then breaks things like this, but the
> main one being that <sha1> will quite often actually end up not even
> _existing_ in the resulting archive (you cherry-picked from your private
> branch, and even if you keep your branch, you don't necessarily push it
> out).
>
> Junio, can we make the default _not_ to do it, please?
I understand that it can be annoying.
I was hoping that however when you do something like this:
git log --filter-backported-commits v2.6.16.9..v2.6.17
an improved log-inspection tool could notice and filter out the
ones that was backported from the mainline to the maintenance
branch.
But I realize that is probably a faulty logic. First of all,
not all backports are cherry-picked (the same patch can be
applied from an e-mail, for example), so if we really want to do
the above filtering, we would need to be able to detect the same
patch anyway without "cherry-picked from" information.
To a certain degree, git-patch-id would help detecting such a
duplicated patch, but it would not help you detect "moral
equivalent" changes that are textually different. A cherry-pick
after a conflict resolution that ends up applying a textually
different patch would still leave the "cherry-picked from"
message in the commit log (or a "note " header if we implement
it to reduce cluttering the log message), which would be the
only advantage of recording the information somehow. But that
is probably not worth it -- it means "moral equivalent" changes
need to be recorded somehow by hand, which is unnecessarly
developer burden if it is rare enough to want to filter such
duplicates when inspecting the log.
Do people find "cherry-picked from" information useful? Does
anybody mind if we change the default not to record it?
^ permalink raw reply
* Re: Sharing repositories later on
From: Erik Mouw @ 2006-07-12 15:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsgazw5j.fsf@assigned-by-dhcp.cox.net>
On Wed, Jul 12, 2006 at 08:21:28AM -0700, Junio C Hamano wrote:
> Erik Mouw <erik@harddisk-recovery.com> writes:
> > Right now I have a "linux-2.6" repository to track Linus's 2.6 kernel
> > tree and an "elinux-2.6" tree that pulls from linux-2.6 and holds my
> > own changes. I created a file .git/objects/info/alternates that
> > contains the line "/home/erik/git/linux-2.6/.git/objects". Now how do I
> > get rid of the "old" objects and packs without loosing my changes?
>
> repack -a -d -l perhaps?
Thanks, that did the trick. I now have a small pack with around 100
objects.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: Sharing repositories later on
From: Linus Torvalds @ 2006-07-12 15:47 UTC (permalink / raw)
To: Erik Mouw; +Cc: git
In-Reply-To: <20060712132800.GA7328@harddisk-recovery.com>
On Wed, 12 Jul 2006, Erik Mouw wrote:
>
> I just learned out about "git clone -s" to share objects between
> repositories. How do I use that with already existing repositories?
Do
echo "/source/git/project/.git/objects/" > .git/objects/info/alternates
and then follow it up with
git repack -a -d -l
where the "-l" means that it will only put _local_ objects in the
pack-file (strictly speaking, it will put any loose objects from the
alternate tree too, so you'll have a fully packed archive, but it won't
duplicate objects that are already packed in the alternate tree).
Linus
^ permalink raw reply
* Re: Re : 2 questions on git-send-email usage
From: Linus Torvalds @ 2006-07-12 15:43 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Junio C Hamano, git
In-Reply-To: <44B4A6CA.3020206@innova-card.com>
On Wed, 12 Jul 2006, Franck Bui-Huu wrote:
>
> [PATCH] Add a newline before appending "Signed-off-by:"
>
> It looks nicer.
Yes. However, I think the sign-off detection is a bit broken (quite
independently of your patch).
A number of people end up capitalizing the sign-off differently, so you
have lines like "Signed-Off-By: Xy Zzy <xyzzy@example.org>".
Also, at least for the kernel, we often have alternative formats, like
Acked-by: Elliot Xavier Ample <example@dummy.org>
and for that case, adding the extra newline is actually bad.
So I would suggest a totally different approach: instead of using
"strstr(comments, signed_off_by)", it would probably be much better to
just look for the last non-empty line, and see if it matches the format
"^[nonspace]*: .*@.*$"
(yeah, that's not a valid regexp, but you get the idea).
On a slightly related note, I absolutely _hate_ how cherry-picking adds
"(cherry-picked from commit <sha1>)" at the end. It's wrong for so many
reasons, one of them being that it then breaks things like this, but the
main one being that <sha1> will quite often actually end up not even
_existing_ in the resulting archive (you cherry-picked from your private
branch, and even if you keep your branch, you don't necessarily push it
out).
Junio, can we make the default _not_ to do it, please?
Linus
^ permalink raw reply
* Re: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Junio C Hamano @ 2006-07-12 15:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607120810320.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Junio - do you want me to send an updated patch, or do you want to reverse
> bit#7 yourself?
Pushed out in "pu" already, thanks.
^ permalink raw reply
* Re: Sharing repositories later on
From: Junio C Hamano @ 2006-07-12 15:21 UTC (permalink / raw)
To: Erik Mouw; +Cc: git
In-Reply-To: <20060712132800.GA7328@harddisk-recovery.com>
Erik Mouw <erik@harddisk-recovery.com> writes:
> Hi,
>
> I just learned out about "git clone -s" to share objects between
> repositories. How do I use that with already existing repositories?
>
> Right now I have a "linux-2.6" repository to track Linus's 2.6 kernel
> tree and an "elinux-2.6" tree that pulls from linux-2.6 and holds my
> own changes. I created a file .git/objects/info/alternates that
> contains the line "/home/erik/git/linux-2.6/.git/objects". Now how do I
> get rid of the "old" objects and packs without loosing my changes?
repack -a -d -l perhaps?
^ permalink raw reply
* Re: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Linus Torvalds @ 2006-07-12 15:13 UTC (permalink / raw)
To: Peter Baumann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <slrneb96rd.dma.Peter.B.Baumann@xp.machine.xx>
On Wed, 12 Jul 2006, Peter Baumann wrote:
>
> This doesn't match the logic used in unpack_object_header, which is used
> in the packs:
Yeah, good point. I reversed the meaning of the high bit by mistake. In
pack-files, the high bit is a "there is more to come" bit, and in my new
code it was a "this is the last byte" bit.
It doesn't matter for the ultimate reason for this (being able to re-use
the actual _bulk_ of the data), but having it be different would be stupid
and confusing, and means that we can't later try to use the same routines
for packing/unpacking the objects.
Junio - do you want me to send an updated patch, or do you want to reverse
bit#7 yourself?
Linus
^ permalink raw reply
* Re: [PATCH] Remove more gcc extension usage.
From: Paul Jakma @ 2006-07-12 13:46 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jan-Benedict Glaw, Junio C Hamano, git
In-Reply-To: <20060710052255.GA15173@spearce.org>
On Mon, 10 Jul 2006, Shawn Pearce wrote:
> So Monday turned out to be today. The compiler version:
>
> $ cc -V
> cc: Forte Developer 7 C 5.4 2002/03/09
> usage: cc [ options] files. Use 'cc -flags' for details
> and from `man cc`:
>
> -xc99 enables C99 features:
Only a subset of C99.
You need SOS10 for full C99 support, Sun have made SOS freely
downloadable since version 10.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
It is easier to change the specification to fit the program than vice versa.
^ permalink raw reply
* Sharing repositories later on
From: Erik Mouw @ 2006-07-12 13:28 UTC (permalink / raw)
To: git
Hi,
I just learned out about "git clone -s" to share objects between
repositories. How do I use that with already existing repositories?
Right now I have a "linux-2.6" repository to track Linus's 2.6 kernel
tree and an "elinux-2.6" tree that pulls from linux-2.6 and holds my
own changes. I created a file .git/objects/info/alternates that
contains the line "/home/erik/git/linux-2.6/.git/objects". Now how do I
get rid of the "old" objects and packs without loosing my changes?
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: remove perl from git-commit.sh
From: Alex Riesen @ 2006-07-12 12:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Junio C Hamano
In-Reply-To: <20060712114805.GD13776@pasky.or.cz>
On 7/12/06, Petr Baudis <pasky@suse.cz> wrote:
> BTW, why people so often want to keep stuff like the following from
> commit messages?
Well, strictly speaking it isn't the description of what the patch does.
> > than having to constantly patch git-commit.sh for binmode
> > or perl path (Windows has no stable tool set, and perl
> > for instance often resides "somewhere").
>
> ...but I would prefer much better if we could actually fix the problem.
> I'm not sure what "patching for binmode" takes but it sounds that we
ActiveState Perl normally replaces \n in the output with \r\n, which is
annoying, as the rest of git does output \n verbatim.
> should do it for the other Perl scripts anyway. If Cygwin usually really
> doesn't have stable Perl path, you could special-case PERL_PATH in
It's not cygwin. It's an organization typical for windows environements:
stinky trash can.
> Makefile for Cygwin to be just "perl" (or perhaps that's the issue only
> for non-source packages so you might want to simply set PERL_PATH to
> perl when building those).
I did. I didn't mention it because the patch was about the binmode.
sh is from cygwin here, so just removing this one dependency helps
a lot. I will change other scripts as soon as they get problematic.
Another small problem is with windows pathnames (activestate perl
expects _windows_ path, but allows forward slashes in it: c:/a/b/c).
I have calls to cygpath (converts cygwin path to windows and vice
versa) all over (not everywhere, just clone, rerere, mv, shortlog and
fmt-merge-msg. The tools that were important to me) just to deal
with this. It's a horribly unstable and poorly tested and breaks from
time to time but it mostly works. As I saw no complaints here about
the same problem I have never submitted the changes. Maybe I am
just unlucky to have to deal with windows so often.
^ permalink raw reply
* Re: remove perl from git-commit.sh
From: Petr Baudis @ 2006-07-12 11:48 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0607120415g243f2160tf42c40e52b8bc9ac@mail.gmail.com>
Dear diary, on Wed, Jul 12, 2006 at 01:15:03PM CEST, I got a letter
where Alex Riesen <raa.lkml@gmail.com> said that...
> ---
BTW, why people so often want to keep stuff like the following from
commit messages?
> git-commit.sh has only ohne place where perl is used
> and it can actually quite trivially be done in sh.
> git-ls-files without "-z" produces quoted output, even if
> is different from that produced by perl code it could be
> enough. Otherwise I'd better suggest to add another
> quoting style (replacing only \t, \n and backslash)
Of course getting rid of Perl from the "essentials" is an option...
> than having to constantly patch git-commit.sh for binmode
> or perl path (Windows has no stable tool set, and perl
> for instance often resides "somewhere").
...but I would prefer much better if we could actually fix the problem.
I'm not sure what "patching for binmode" takes but it sounds that we
should do it for the other Perl scripts anyway. If Cygwin usually really
doesn't have stable Perl path, you could special-case PERL_PATH in
Makefile for Cygwin to be just "perl" (or perhaps that's the issue only
for non-source packages so you might want to simply set PERL_PATH to
perl when building those).
--
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: remove perl from git-commit.sh
From: Alex Riesen @ 2006-07-12 11:41 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: git, Junio C Hamano
In-Reply-To: <dbfc82860607120435v5482ce31pdf002f049c51669a@mail.gmail.com>
On 7/12/06, Nikolai Weibull <now@bitwi.se> wrote:
> Anyway, I was just wondering
> what the motives were, not questioning them ;-).
Being forced to use ActiveState Perl on a W2K in a
corporate environment.
^ permalink raw reply
* Re: remove perl from git-commit.sh
From: Nikolai Weibull @ 2006-07-12 11:35 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0607120423q8c75ecl7d42dfd67f99a549@mail.gmail.com>
On 7/12/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 7/12/06, Nikolai Weibull <now@bitwi.se> wrote:
> > > Otherwise I'd better suggest to add another
> > > quoting style (replacing only \t, \n and backslash)
> > One could always do the quoting with sed, or am I missing something?
> No, but if look closely at this list you'll find a lot of incompatibilities
> in sed too. So the less, the better
Well, that's true, of course, but something as "simple" as what is
needed in this case should be possible. Anyway, I was just wondering
what the motives were, not questioning them ;-).
nikolai
^ permalink raw reply
* Re: remove perl from git-commit.sh
From: Alex Riesen @ 2006-07-12 11:23 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: git, Junio C Hamano
In-Reply-To: <dbfc82860607120417m19c0ecefydb4b3f4cf60d646a@mail.gmail.com>
On 7/12/06, Nikolai Weibull <now@bitwi.se> wrote:
> > Otherwise I'd better suggest to add another
> > quoting style (replacing only \t, \n and backslash)
>
> One could always do the quoting with sed, or am I missing something?
>
No, but if look closely at this list you'll find a lot of incompatibilities
in sed too. So the less, the better
^ permalink raw reply
* Re: remove perl from git-commit.sh
From: Nikolai Weibull @ 2006-07-12 11:17 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0607120415g243f2160tf42c40e52b8bc9ac@mail.gmail.com>
On 7/12/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> Otherwise I'd better suggest to add another
> quoting style (replacing only \t, \n and backslash)
One could always do the quoting with sed, or am I missing something?
nikolai
^ permalink raw reply
* remove perl from git-commit.sh
From: Alex Riesen @ 2006-07-12 11:15 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
It is really annoying when the essentials do not work.
I think we could improve at least them, by minimizing
their dependencies to external tools.
---
git-commit.sh has only ohne place where perl is used
and it can actually quite trivially be done in sh.
git-ls-files without "-z" produces quoted output, even if
is different from that produced by perl code it could be
enough. Otherwise I'd better suggest to add another
quoting style (replacing only \t, \n and backslash) than
having to constantly patch git-commit.sh for binmode
or perl path (Windows has no stable tool set, and perl
for instance often resides "somewhere").
[-- Attachment #2: 0001-remove-perl-from-git-commit.sh.txt --]
[-- Type: text/plain, Size: 1501 bytes --]
From 69bf41df4ef69d0f1e4ab52942c59bb3fd568cb8 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Wed, 12 Jul 2006 13:02:23 +0200
Subject: remove perl from git-commit.sh
---
git-commit.sh | 32 +++++++++++++-------------------
1 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 802dd72..4cf3fab 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -138,32 +138,26 @@ #'
if test -z "$untracked_files"; then
option="--directory --no-empty-directory"
fi
+ hdr_shown=
if test -f "$GIT_DIR/info/exclude"
then
- git-ls-files -z --others $option \
+ git-ls-files --others $option \
--exclude-from="$GIT_DIR/info/exclude" \
--exclude-per-directory=.gitignore
else
- git-ls-files -z --others $option \
+ git-ls-files --others $option \
--exclude-per-directory=.gitignore
fi |
- @@PERL@@ -e '$/ = "\0";
- my $shown = 0;
- while (<>) {
- chomp;
- s|\\|\\\\|g;
- s|\t|\\t|g;
- s|\n|\\n|g;
- s/^/# /;
- if (!$shown) {
- print "#\n# Untracked files:\n";
- print "# (use \"git add\" to add to commit)\n";
- print "#\n";
- $shown = 1;
- }
- print "$_\n";
- }
- '
+ while read line; do
+ if [ -z "$hdr_shown" ]; then
+ echo '#'
+ echo '# Untracked files:'
+ echo '# (use "git add" to add to commit)'
+ echo '#'
+ hdr_shown=1
+ fi
+ echo "# $line"
+ done
if test -n "$verbose" -a -z "$IS_INITIAL"
then
--
1.4.1.gb4adf
^ permalink raw reply related
* [RFC] New REuse REcorded REsolve tool.
From: Shawn Pearce @ 2006-07-12 9:33 UTC (permalink / raw)
To: git
What follows is a draft implementation of a different git-rerere tool.
Please use caution when testing this on any real repository. It has
been very lightly tested and only for a small handful of cases.
Its probably going to fail on something that I haven't tried yet.
It could overwrite entries in your current index, making it possible
to commit a file with <<<< === >>>> conflict markers in it. :-)
My goal with this tool is to get something that git-merge can use
as a pre-filter to the current git-rerere and by which git-merge
can automatically reuse prior resolutions on a more predictable
basis then what happens with git-rerere today. Ideally I want
git-rerere2 to make the merge commit for me if it was successful
at resolving all unmerged entries and thus have git-merge return
with an exit code of 0 rather than 1.
Lots of TODOs still exist:
- Prune cache at some threshold in size/age.
- Anchor prior recorded merge commits along a special ref (to prevent
them from pruning while they are still in the cache).
- Automatically create merge commit if successfully resolved.
- Test cases.
- More/better documentation.
- Friendly error handling on invalid command line option combinations.
And all of the above means no signoff yet. :-)
-->8--
New REuse REcorded REsolve tool.
git-rerere2 attempts to remember lines of development that have been
merged together before by tracking merge commits in .git/rr2-cache.
When two lines of development are merged together again in the
future git-rerere2 searches its cache for the most recent merge
commit between the two branches and tries to select the merge commit
that contains the maximum number of commits from each branch.
If such a commit exists in the cache then git-rerere2 attempts
to resolve any unmerged index entries by comparing the conflicted
stage 1/2/3 from the chosen prior merge against the current index;
if stage 1 is unchanged and stage 2/3 are unchanged (but possibly
permuted in order) then the working directory (and current index)
are updated with resolved file as committed in the chosen commit.
Unlike git-rerere, git-rerere2 can remember and reuse structual
modifications (adds/deletes, mode changes, type changes) as well as
reuse binary file resolutions which the standard RCS `merge` tool
wouldn't have been able to process. However, also unlike git-rerere,
git-rerere2 does not attempt to merge the contents of a file.
---
.gitignore | 1
Makefile | 2
git-commit.sh | 4 +
git-merge.sh | 4 +
git-rerere2.perl | 281 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 291 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index fb0fa3f..1a3ed42 100644
--- a/.gitignore
+++ b/.gitignore
@@ -87,6 +87,7 @@ git-repack
git-repo-config
git-request-pull
git-rerere
+git-rerere2
git-reset
git-resolve
git-rev-list
diff --git a/Makefile b/Makefile
index 5b7bac8..e1fa96a 100644
--- a/Makefile
+++ b/Makefile
@@ -147,7 +147,7 @@ SCRIPT_SH = \
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
- git-shortlog.perl git-rerere.perl \
+ git-shortlog.perl git-rerere.perl git-rerere2.perl \
git-annotate.perl git-cvsserver.perl \
git-svnimport.perl git-mv.perl git-cvsexportcommit.perl \
git-send-email.perl git-svn.perl
diff --git a/git-commit.sh b/git-commit.sh
index 802dd72..3451072 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -742,6 +742,10 @@ else
fi
ret="$?"
rm -f "$GIT_DIR/COMMIT_MSG" "$GIT_DIR/COMMIT_EDITMSG" "$GIT_DIR/SQUASH_MSG"
+if test -d "$GIT_DIR/rr2-cache"
+then
+ git-rerere2 --record
+fi
if test -d "$GIT_DIR/rr-cache"
then
git-rerere
diff --git a/git-merge.sh b/git-merge.sh
index a9cfafb..53a907b 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -375,6 +375,10 @@ Conflicts:
sed -e 's/^[^ ]* / /' |
uniq
} >>"$GIT_DIR/MERGE_MSG"
+ if test -d "$GIT_DIR/rr2-cache"
+ then
+ git-rerere2 --reset --remember-unmerged --reuse "$head_arg" "$@"
+ fi
if test -d "$GIT_DIR/rr-cache"
then
git-rerere
diff --git a/git-rerere2.perl b/git-rerere2.perl
new file mode 100644
index 0000000..8925faf
--- /dev/null
+++ b/git-rerere2.perl
@@ -0,0 +1,281 @@
+#!/usr/bin/perl
+#
+# REuse REcorded REsolve. This tool records a conflicted automerge
+# result and its hand resolution, and helps to resolve future
+# automerge that results in the same conflict.
+#
+
+use strict;
+use warnings;
+use Getopt::Long;
+use Pod::Usage;
+use File::Spec::Functions qw(catfile);
+use Git;
+
+my $repo = Git->repository;
+my $cache_dir = catfile($repo->repo_path, 'rr2-cache');
+my $cache_toc = catfile($cache_dir, 'contents');
+my $tmp_lst = catfile($cache_dir, 'current_unmerged');
+
+my ($enable, $disable,
+ $reset, $remember_unmerged,
+ $reuse, $dry_run, $no_update,
+ $record,
+ $man, $help);
+GetOptions(
+ "enable" => \$enable,
+ "disable" => \$disable,
+ "reset" => \$reset,
+ "remember-unmerged" => \$remember_unmerged,
+ "reuse" => \$reuse,
+ "n|dry-run" =>, \$dry_run,
+ "no-update" =>, \$no_update,
+ "record" => \$record,
+ "man" => \$man,
+ "help" => \$help,
+);
+pod2usage(1) if $help;
+pod2usage(-exitstatus => 0, -verbose => 2) if $man;
+
+if ($enable) {
+ mkdir $cache_dir, 0777;
+ die "Failed to create $cache_dir: $!\n" unless -d $cache_dir;
+ print "Created $cache_dir\n";
+ exit 0;
+}
+exit unless -d $cache_dir;
+
+my (%unmerged);
+sub load_unmerged ($$);
+sub save_unmerged ($$);
+
+if ($reset) {
+ unlink $tmp_lst;
+} else {
+ if (open(T, '<',$tmp_lst)) {
+ load_unmerged \*T, \%unmerged;
+ close T;
+ }
+}
+
+if ($remember_unmerged) {
+ my ($f,$c) = $repo->command_output_pipe(qw(ls-files -z --unmerged));
+ load_unmerged $f, \%unmerged;
+ $repo->command_close_pipe($f,$c);
+
+ if (%unmerged) {
+ open(T, '>',$tmp_lst) or die "Can't overwrite $tmp_lst: $!\n";
+ save_unmerged \*T, \%unmerged;
+ close T;
+ } else {
+ unlink $tmp_lst;
+ }
+}
+
+if ($reuse && !$record && @ARGV > 1 && %unmerged) {
+ my %cache_by_parent;
+ if (open(T,'<',$cache_toc)) {
+ while (<T>) {
+ chop;
+ my ($then, $result, @parents) = split / /;
+ my $e = [$then, $result, @parents];
+ push @{$cache_by_parent{$_}}, $e foreach @parents;
+ }
+ close T;
+ }
+
+ my $base = $repo->command_oneline('merge-base',@ARGV);
+ my %possib_results;
+ foreach my $r (@ARGV) {
+ my ($f,$c) = $repo->command_output_pipe('rev-list',"^$base",$r);
+ while (<$f>) {
+ chop;
+ my $e_arr = $cache_by_parent{$_};
+ next unless $e_arr;
+ $possib_results{$_->[1]}++ foreach @$e_arr;
+ }
+ $repo->command_close_pipe($f,$c);
+ }
+ my @p = sort {$b->[0] <=> $a->[0]}
+ grep {$possib_results{$_} == @ARGV} keys %possib_results;
+ my $best = $p[0];
+
+ my @reuse;
+ if (open(T, '<',catfile($cache_dir, $best))) {
+ my %best_conflicts;
+ $_ = <T>;
+ load_unmerged \*T, \%best_conflicts;
+ close T;
+
+ print "Trying to reuse resolution(s) from $best.\n";
+ my ($name, $u);
+ while (($name,$u) = each %unmerged) {
+ my $b = $best_conflicts{$name};
+ next unless $b; # no prior resolution
+ next unless $u->[1] eq $b->[1]; # different base
+ next unless (($u->[2] eq $b->[2] && $u->[3] eq $b->[3])
+ || ($u->[2] eq $b->[3] && $u->[3] eq $b->[2]));
+
+ push @reuse, $name;
+ }
+ }
+
+ if (@reuse) {
+ print "Reuse ",$_,"\n" foreach @reuse;
+ print "\n";
+
+ if ($dry_run) {
+ print "Skipped checkout (--dry-run enabled).\n";
+ } else {
+ print "Checking out resolved versions...\n";
+ my $idx = catfile($repo->repo_path,'rerere2idx');
+ local $ENV{GIT_INDEX_FILE} = $idx;
+ $repo->command(qw(read-tree --reset),$best);
+ my ($f,$c) = $repo->command_input_pipe(
+ qw(checkout-index --force -z --stdin));
+ print $f $_, "\0" foreach @reuse;
+ $repo->command_close_pipe($f,$c);
+ unlink $idx;
+ }
+ delete $unmerged{$_} foreach @reuse;
+
+ if ($dry_run) {
+ print "Skipped index update (--dry-run enabled).\n";
+ } elsif ($no_update) {
+ print "Skipped index update (--no-update enabled).\n";
+ } else {
+ print "Updating index with resolved versions...\n";
+ my ($f,$c) = $repo->command_input_pipe(
+ qw(update-index -z --stdin));
+ print $f $_, "\0" foreach @reuse;
+ $repo->command_close_pipe($f,$c);
+ }
+
+ if (%unmerged) {
+ unless ($dry_run) {
+ open(T, '>',$tmp_lst)
+ or die "Can't overwrite $tmp_lst: $!\n";
+ save_unmerged \*T, \%unmerged;
+ close T;
+ }
+ print "Some conflicts remain.\n";
+ exit 1;
+ } else {
+ unlink $tmp_lst unless $dry_run;
+ print "Everything resolved.\n";
+ exit 0;
+ }
+ } else {
+ print "No matching resolutions available for reuse.\n";
+ }
+ exit 1;
+}
+
+if (!$reuse && $record && %unmerged) {
+ my $head = $repo->command_oneline(qw(rev-parse --verify HEAD));
+ my $now = time;
+
+ my @parents;
+ my ($f,$c) = $repo->command_output_pipe(qw(cat-file commit HEAD));
+ while (<$f>) {
+ push @parents, $1 if /^parent ([0-9a-f]{40})/;
+ last if /^author /;
+ }
+ $repo->command_close_pipe($f,$c);
+
+ unlink $tmp_lst;
+ exit unless @parents > 1;
+
+ open(T, '>',catfile($cache_dir,$head)) or die "Can't cache: $!\n";
+ print T $now,' ',$head,' ',join(' ', @parents),"\n";
+ save_unmerged \*T, \%unmerged;
+ close T;
+
+ my %toc;
+ if (open(T,'<',$cache_toc)) {
+ while (<T>) {
+ chop;
+ my ($then, $result, $ps) = split / /, $_, 3;
+ $toc{$ps} = [$then, $result, $ps];
+ }
+ close T;
+ }
+
+ my $ps = join(' ', sort @parents);
+ $toc{$ps} = [$now, $head, $ps];
+
+ open(T, '>',$cache_toc) or die "Can't update $cache_toc: $!\n";
+ foreach my $e (sort {$a->[0] <=> $b->[1]} values %toc) {
+ print T join(' ', @$e), "\n";
+ }
+ close T;
+}
+
+exit;
+
+sub load_unmerged ($$) {
+ my ($f, $um) = @_;
+ local $_;
+ local $/ = "\0";
+ my $cur_name;
+ my @cur_stages = ('', '', '', '');
+ while ($_ = <$f>) {
+ chomp;
+ my ($info,$name) = split /\t/, $_, 2;
+ if ($cur_name && $name ne $cur_name) {
+ $um->{$cur_name} = [@cur_stages];
+ @cur_stages = ('', '', '', '');
+ }
+ $cur_name = $name;
+ $info =~ / ([123])$/;
+ $cur_stages[$1] = $info;
+ }
+ $um->{$cur_name} = [@cur_stages] if $cur_name;
+}
+
+sub save_unmerged ($$) {
+ my ($f, $um) = @_;
+ foreach my $cur_name (sort keys %$um) {
+ my $u = $um->{$cur_name};
+ foreach my $stage (1..3) {
+ my $s = $u->[$stage];
+ next unless $s;
+ print $f $s,"\t",$cur_name,"\0";
+ }
+ }
+}
+
+__END__
+
+=head1 NAME
+
+git-rerere2 - REuse REcorded REsolve
+
+=head1 SYNOPSIS
+
+ git-rerere2 --enable ; #to activate
+
+=head1 OPTIONS
+
+=over 4
+
+=item B<--enable>
+
+Activate git-rerere2 in the current repository.
+
+=item B<-n> | B<--dry-run>
+
+Perform reuse actions in memory but don't alter the working directory
+or the index.
+
+=item B<--no-update>
+
+Update the working directory with a reused resolution but don't
+update the index. This will leave the index entry unmerged with
+all relevant stages still contained within it. It is the caller's
+responsibility to update the index prior to commit.
+
+=back
+
+=cut
+
--
1.4.1.gd3d5
^ permalink raw reply related
* Re: [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob
From: Jakub Narebski @ 2006-07-12 8:32 UTC (permalink / raw)
To: git
In-Reply-To: <7v64i31h6f.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
>> Teach tree->raw to not require the hash of the blob, but to
>> figure it out from the file name. This allows to externally
>> link to files into the repository, such that the hash is not
>> required. I.e. the file obtained would be as of the HEAD
>> commit.
>>
>> In contrast tree->blob for binary files passes the hash, as
>> does tree->blob->plain for "text/*" files.
> I think _allowing_ to accept filename not hash is a sane change,
> and would be useful if you want to allow linking to always the
> HEAD version from external sites, but I do not think listing the
> raw link in the tree view without the hash is a good idea. It
> makes things quite confusing that "blob" link in its
> neighbourhood gives the blob from that specific version, but
> "raw" gives the version from HEAD, even when you are browsing
> something other than HEAD.
>
> BTW, can somebody volunteer to be a gitweb/ "subsystem
> maintainer"?
I think the change to raw aka. blob_plain and not to plain is because in
plain view you have this HEAD link which takes us to HEAD revision of the
file (even if we are on different branch IIRC).
Workaround for either format is to remove 'h' (hash) parameter entirely, and
put in 'hb' (hashbase aka headref aka branch) the branch name. Gitweb then
shows the contents of latest version of the file.
BTW. sometimes you want to link to specific version of the file, and
sometimes to newest. I think it would be best (if possible, feasible, and
not too much resource consuming) that links from tree specified by hash be
to specified by hash version of file, while links from tree specified by
headref and name only would have links to latest version of the file.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Peter Baumann @ 2006-07-12 8:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Baumann, git, Linus Torvalds
In-Reply-To: <7vveq3z41v.fsf@assigned-by-dhcp.cox.net>
On Wed, Jul 12, 2006 at 12:16:12AM -0700, Junio C Hamano wrote:
> >> + bits = 4;
> >> + size = c & 0xf;
> >> + while (!(c & 0x80)) {
> >> + if (bits >= 8*sizeof(long))
> >> + return -1;
> >> + c = *map++;
> >> + size += (c & 0x7f) << bits;
> >> + bits += 7;
> >> + mapsize--;
> >> + }
> >
> > This doesn't match the logic used in unpack_object_header, which is used
> > in the packs:
> > ...
> >> + c = (type << 4) | (len & 15);
> >> + len >>= 4;
> >> + hdr_len = 1;
> >> + while (len) {
> >> + *hdr++ = c;
> >> + hdr_len++;
> >> + c = (len & 0x7f);
> >> + len >>= 7;
> >> + }
> >> + *hdr = c | 0x80;
> >> + return hdr_len;
> >> +}
> >> +
> >
> > Dito, but in this case see pack-objects.c
>
> Well, while these are not strictly needed to match, there is no
> good reason to make them inconsistent. Very well spotted.
>
During packing one could simply copy the existing object into the generated
pack in the non delta case, so I think this _is_ necessary/usefull.
-Peter Baumann
^ permalink raw reply
* Re: Re : 2 questions on git-send-email usage
From: Franck Bui-Huu @ 2006-07-12 7:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Franck, git
In-Reply-To: <7vd5cc3q0o.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Haven't checked the code around the patch yet, but does it work
> when the original commit log message ends with a blank line and
> existing signed-off-by lines by other people? You do not want
> an extra blank lines there.
>
argh, no I just tested the previous case. Here is an update
which fix all cases.
-- >8 --
[PATCH] Add a newline before appending "Signed-off-by:"
It looks nicer.
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com>
---
log-tree.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 9d8d46f..69d5c8a 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -17,9 +17,10 @@ static int append_signoff(char *buf, int
int signoff_len = strlen(signoff);
static const char signed_off_by[] = "Signed-off-by: ";
char *cp = buf;
+ int has_signoff = 0;
/* Do we have enough space to add it? */
- if (buf_sz - at <= strlen(signed_off_by) + signoff_len + 2)
+ if (buf_sz - at <= strlen(signed_off_by) + signoff_len + 3)
return at;
/* First see if we already have the sign-off by the signer */
@@ -32,8 +33,11 @@ static int append_signoff(char *buf, int
!strncmp(cp, signoff, signoff_len) &&
isspace(cp[signoff_len]))
return at; /* we already have him */
+ has_signoff = 1;
}
+ if (!has_signoff)
+ buf[at++] = '\n';
strcpy(buf + at, signed_off_by);
at += strlen(signed_off_by);
strcpy(buf + at, signoff);
--
1.4.1.g55b7
^ permalink raw reply related
* Re: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Junio C Hamano @ 2006-07-12 7:16 UTC (permalink / raw)
To: Peter Baumann; +Cc: git, Linus Torvalds
In-Reply-To: <slrneb96rd.dma.Peter.B.Baumann@xp.machine.xx>
Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de>
writes:
>> + bits = 4;
>> + size = c & 0xf;
>> + while (!(c & 0x80)) {
>> + if (bits >= 8*sizeof(long))
>> + return -1;
>> + c = *map++;
>> + size += (c & 0x7f) << bits;
>> + bits += 7;
>> + mapsize--;
>> + }
>
> This doesn't match the logic used in unpack_object_header, which is used
> in the packs:
> ...
>> + c = (type << 4) | (len & 15);
>> + len >>= 4;
>> + hdr_len = 1;
>> + while (len) {
>> + *hdr++ = c;
>> + hdr_len++;
>> + c = (len & 0x7f);
>> + len >>= 7;
>> + }
>> + *hdr = c | 0x80;
>> + return hdr_len;
>> +}
>> +
>
> Dito, but in this case see pack-objects.c
Well, while these are not strictly needed to match, there is no
good reason to make them inconsistent. Very well spotted.
^ permalink raw reply
* Re: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Peter Baumann @ 2006-07-12 6:49 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0607111656250.5623@g5.osdl.org>
On 2006-07-12, Linus Torvalds <torvalds@osdl.org> wrote:
[...]
> Anyway, I think this following patch replaces the old 2/3 and 3/3 (it
> still depends on the original [1/3] cleanup.
>
> (It also renames and reverses the meaning of the config file option: it's
> now "[core] LegacyHeaders = true" for using legacy headers.)
>
> Not heavily tested, but seems ok.
>
> sf? Dscho? Can you check this thing out?
>
> Linus
> ----
[...]
> diff --git a/sha1_file.c b/sha1_file.c
> index 8734d50..475b23d 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -684,26 +684,74 @@ static void *map_sha1_file_internal(cons
> return map;
> }
>
> -static int unpack_sha1_header(z_stream *stream, void *map, unsigned long mapsize, void *buffer, unsigned long size)
> +static int unpack_sha1_header(z_stream *stream, unsigned char *map, unsigned long mapsize, void *buffer, unsigned long bufsiz)
> {
> + unsigned char c;
> + unsigned int word, bits;
> + unsigned long size;
> + static const char *typename[8] = {
> + NULL, /* OBJ_EXT */
> + "commit", "tree", "blob", "tag",
> + NULL, NULL, NULL
> + };
> + const char *type;
> +
> /* Get the data stream */
> memset(stream, 0, sizeof(*stream));
> stream->next_in = map;
> stream->avail_in = mapsize;
> stream->next_out = buffer;
> - stream->avail_out = size;
> + stream->avail_out = bufsiz;
> +
> + /*
> + * Is it a zlib-compressed buffer? If so, the first byte
> + * must be 0x78 (15-bit window size, deflated), and the
> + * first 16-bit word is evenly divisible by 31
> + */
> + word = (map[0] << 8) + map[1];
> + if (map[0] == 0x78 && !(word % 31)) {
> + inflateInit(stream);
> + return inflate(stream, 0);
> + }
> +
> + c = *map++;
> + mapsize--;
> + type = typename[(c >> 4) & 7];
> + if (!type)
> + return -1;
> +
> + bits = 4;
> + size = c & 0xf;
> + while (!(c & 0x80)) {
> + if (bits >= 8*sizeof(long))
> + return -1;
> + c = *map++;
> + size += (c & 0x7f) << bits;
> + bits += 7;
> + mapsize--;
> + }
This doesn't match the logic used in unpack_object_header, which is used
in the packs:
static unsigned long unpack_object_header(struct packed_git *p, unsigned long offset,
enum object_type *type, unsigned long *sizep)
{
unsigned shift;
unsigned char *pack, c;
unsigned long size;
if (offset >= p->pack_size)
die("object offset outside of pack file");
pack = (unsigned char *) p->pack_base + offset;
c = *pack++;
offset++;
*type = (c >> 4) & 7;
size = c & 15;
shift = 4;
while (c & 0x80) { <==========
if (offset >= p->pack_size)
die("object offset outside of pack file");
c = *pack++;
offset++;
size += (c & 0x7f) << shift;
shift += 7;
}
*sizep = size; <==========
return offset;
}
> @@ -1414,6 +1462,49 @@ static int write_buffer(int fd, const vo
> return 0;
> }
>
> +static int write_binary_header(unsigned char *hdr, enum object_type type, unsigned long len)
> +{
> + int hdr_len;
> + unsigned char c;
> +
> + c = (type << 4) | (len & 15);
> + len >>= 4;
> + hdr_len = 1;
> + while (len) {
> + *hdr++ = c;
> + hdr_len++;
> + c = (len & 0x7f);
> + len >>= 7;
> + }
> + *hdr = c | 0x80;
> + return hdr_len;
> +}
> +
Dito, but in this case see pack-objects.c
/*
* The per-object header is a pretty dense thing, which is
* - first byte: low four bits are "size", then three bits of "type",
* and the high bit is "size continues".
* - each byte afterwards: low seven bits are size continuation,
* with the high bit being "size continues"
*/
static int encode_header(enum object_type type, unsigned long size, unsigned char *hdr)
{
int n = 1;
unsigned char c;
if (type < OBJ_COMMIT || type > OBJ_DELTA)
die("bad type %d", type);
c = (type << 4) | (size & 15);
size >>= 4;
while (size) {
*hdr++ = c | 0x80; <=======
c = size & 0x7f;
size >>= 7;
n++;
}
*hdr = c; <=======
return n;
}
-Peter Baumann
^ permalink raw reply
* Re: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Junio C Hamano @ 2006-07-12 6:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607111755180.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I shouldn't have introduced the new TYPE_xxx macros. I should just have
> used the same OBJ_xxx macros that we use in the pack-file.
>
> Junio: this patch is totally independent from the other patches, and is on
> top of you current "master". It gets rid of TYPE_xxx in favor of the
> OBJ_xxx enums, which are moved from pack.h into object.h.
You seem to have forgotten one file (fetch-pack.c) but that was
trivial. I'll apply and push it out shortly.
This might collide with a few topic branches but I have rerere
to help me cope with it ;-).
^ permalink raw reply
* Re: [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob
From: Junio C Hamano @ 2006-07-12 6:16 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20060712034345.14009.qmail@web31802.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Teach tree->raw to not require the hash of the blob, but to
> figure it out from the file name. This allows to externally
> link to files into the repository, such that the hash is not
> required. I.e. the file obtained would be as of the HEAD
> commit.
>
> In contrast tree->blob for binary files passes the hash, as
> does tree->blob->plain for "text/*" files.
>
> Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
> ---
> gitweb/gitweb.cgi | 20 ++++++++++++++++----
> 1 files changed, 16 insertions(+), 4 deletions(-)
This has exactly the same line number problem.
@@ -1678,8 +1690,7 @@ sub git_tree {
$cgi->a({-href => "$my_uri?" . esc...
# " | " . $cgi->a({-href => "$my_uri...
" | " . $cgi->a({-href => "$my_uri...
- " | " . $cgi->a({-href => "$my_uri...
+ " | " . $cgi->a({-href => "$my_uri...
"</td>\n";
} elsif ($t_type eq "tree") {
print "<td class=\"list\">" .
You are removing one line and adding one line, so the number of
old and new lines better match.
Hand-applied, tried, got confused and dropped.
I think _allowing_ to accept filename not hash is a sane change,
and would be useful if you want to allow linking to always the
HEAD version from external sites, but I do not think listing the
raw link in the tree view without the hash is a good idea. It
makes things quite confusing that "blob" link in its
neighbourhood gives the blob from that specific version, but
"raw" gives the version from HEAD, even when you are browsing
something other than HEAD.
BTW, can somebody volunteer to be a gitweb/ "subsystem
maintainer"?
^ permalink raw reply
* Re: [PATCH] gitweb.css: Courer fonts for commits and tree-diff
From: Junio C Hamano @ 2006-07-12 6:02 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20060712034323.48414.qmail@web31806.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Courer fonts for the commit header, commit message,
> and tree-diff.
>
> Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
I really do not want to be in the position to judge a patch like
this, whose evaluation is solely based on "prettiness" factor.
But if I really have to, I would say this makes things uglier
and less readable. Maybe asking for monospace is less yucky but
naming Courier explicitly?
BTW what tool do you use to generate and send your patches? I
remember another patch from you recently did not apply and it
turned out the problem was that the last hunk had line numbers
wrong. This patch has exactly the same problem and I am
wondering why.
I count 10 lines of original and 15 lines of new material in
this hunk but the hunk header claims to have 11 lines of
original text.
---
gitweb/gitweb.css | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 98410f5..b51282b 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
...
@@ -142,11 +144,15 @@ table {
padding: 8px 4px;
}
-table.project_list, table.diff_tree {
+table.project_list {
border-spacing: 0;
}
+table.diff_tree {
+ border-spacing: 0;
+ font-family: courier;
+}
+
table.blame {
border-collapse: collapse;
}
--
1.4.1.g9ca3
^ 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