* Re: cvs importer woes
From: Andreas Ericsson @ 2006-06-27 10:49 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90606270342k2288cc2ds34ae05e089b8c906@mail.gmail.com>
Martin Langhoff wrote:
> On 6/27/06, Andreas Ericsson <ae@op5.se> wrote:
>
>> Sadly, the cvsimport command no longer works to create new repositories
>> from scratch.
>
>
> We are seeing some breakage in cvsimport that started with a patch of mine:
>
> 8f732649bc4d5619a1b399e5808b3f4c662ad200 cvsimport: keep one index
> per branch during import
>
I experimented a bit with that one too, but it worked for my (very
small, no branches, no tags) cvs repo
>
>> The culprit is definitely 061303f0b50a648db8e0af23791fc56181f6bf93.
>>
>> Any perl-literate takers? Otherwise, just reverting the patch makes
>> things work (for me) again.
>
>
> Don't just revert that patch, unless I'm wrong there is some subtle
> branch-creation breakage too.
>
Dscho's patch on top of 061303f0b works wonders. Thanks all the same though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: cvs importer woes
From: Martin Langhoff @ 2006-06-27 10:42 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <44A102F0.9090604@op5.se>
On 6/27/06, Andreas Ericsson <ae@op5.se> wrote:
> Sadly, the cvsimport command no longer works to create new repositories
> from scratch.
We are seeing some breakage in cvsimport that started with a patch of mine:
8f732649bc4d5619a1b399e5808b3f4c662ad200 cvsimport: keep one index
per branch during import
so I'd say that if you are using cvsimport, stick to the v1.4.0
version. You can do
git-cat-file blob v1.4.0:git-cvsimport.perl >git-cvsimport.perl
> problem seems to be firstly 061303f0b50a648db8e0af23791fc56181f6bf93.
Yes, that commit will break brand new imports, but it's trying to
fixup breakage that started with my patch. It shouldn't be too hard to
fix up, but real life is interfering.
> Oh, now it's done (4 minutes for 620 revisions with automated testing
> between good/bad. *LOVE* bisect).
Love bisect too for easy-to-test cases.
> The culprit is definitely 061303f0b50a648db8e0af23791fc56181f6bf93.
>
> Any perl-literate takers? Otherwise, just reverting the patch makes
> things work (for me) again.
Don't just revert that patch, unless I'm wrong there is some subtle
branch-creation breakage too.
cheers,
martin
^ permalink raw reply
* Re: [TRYTHIS] cvsimport: fix initial import
From: Andreas Ericsson @ 2006-06-27 10:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0606271234350.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> ---
> Hi,
>
> On Tue, 27 Jun 2006, Andreas Ericsson wrote:
>
>
>>Sadly, the cvsimport command no longer works to create new repositories from
>>scratch. I'm not nearly perl literate enough to fix it, but the problem seems
>>to be firstly 061303f0b50a648db8e0af23791fc56181f6bf93.
>
>
> My bad. Could you try this patch on top of 'next'?
>
Works wonderfully. Weird that it didn't when I removed the read-tree
completely. There was probably some pilot error involved on my part
there and then.
Thanks, and ack.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [TRYTHIS] cvsimport: fix initial import
From: Johannes Schindelin @ 2006-06-27 10:35 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <44A102F0.9090604@op5.se>
---
Hi,
On Tue, 27 Jun 2006, Andreas Ericsson wrote:
> Sadly, the cvsimport command no longer works to create new repositories from
> scratch. I'm not nearly perl literate enough to fix it, but the problem seems
> to be firstly 061303f0b50a648db8e0af23791fc56181f6bf93.
My bad. Could you try this patch on top of 'next'?
git-cvsimport.perl | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 50f5d96..f8eb6ef 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -471,7 +471,6 @@ my %index; # holds filenames of one inde
$ENV{GIT_INDEX_FILE} = $index{$opt_o};
system("git-read-tree", $opt_o);
-die "read-tree failed: $?\n" if $?;
unless(-d $git_dir) {
system("git-init-db");
^ permalink raw reply related
* Re: Rework a patch serie
From: Karl Hasselström @ 2006-06-27 10:16 UTC (permalink / raw)
To: moreau francis; +Cc: git
In-Reply-To: <20060627084130.28886.qmail@web25814.mail.ukl.yahoo.com>
On 2006-06-27 08:41:30 +0000, moreau francis wrote:
> Then I submit these patches for reviewing. Unfortunately, they're
> not perfect, so after some feedbacks from the communauty it appears
> that I need to make small modifications in the second commit in the
> topic branch for example...
>
> What is the best and fastest way to do that ? Should I create a new
> topic branch and cherry pick from the old one ?
stgit is a good fit for this situation. You just pop patches off the
stack untill you reach the one you want to modify, then do your
changes, refresh the patch, and push the other patches back. (If you
want to keep the original series for future reference, you can simply
tag HEAD before you embark on this procedure.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* cvs importer woes
From: Andreas Ericsson @ 2006-06-27 10:05 UTC (permalink / raw)
To: Git Mailing List
Sadly, the cvsimport command no longer works to create new repositories
from scratch. I'm not nearly perl literate enough to fix it, but the
problem seems to be firstly 061303f0b50a648db8e0af23791fc56181f6bf93. In
particular "Also, make sure that the initial git-read-tree is
performed." which fails if there is not a complete git repo already
created with at least one tree committed.
Some sample output:
$ git cvsimport -k -u -d:local:/home/CVS packages
fatal: Not a git repository: '/data/home/exon/git/packages/.git'
read-tree failed: 32768
Removing the unconditional read-tree call, I get this (still in an empty
directory which isn't a repo):
$ git cvsimport -k -u -d:local:/home/CVS packages
fatal: Not a git repository: '/data/home/exon/git/packages/.git'
read-tree failed: 32768
$ git init-db
defaulting to local storage area
$ git cvsimport -k -u -d:local:/home/CVS packages
fatal: Not a valid object name origin
read-tree failed: 32768
Bisect running now. v1.3.1 is good and imports the stuff properly to an
empty directory.
Oh, now it's done (4 minutes for 620 revisions with automated testing
between good/bad. *LOVE* bisect).
The culprit is definitely 061303f0b50a648db8e0af23791fc56181f6bf93.
Any perl-literate takers? Otherwise, just reverting the patch makes
things work (for me) again.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Martin Langhoff @ 2006-06-27 9:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff (CatalystIT), git, junkio
In-Reply-To: <Pine.LNX.4.63.0606271016450.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> I just cloned your repo, and as far as I can tell, the latest commit is on
> June 23rd. So your numbers should be the same as mine. But not all are.
Taht repo is on a machine at work, but it's possible that I've cherry
picked a new commit onto master that isn't on the publc repo yet.
> The problem I see: from the 53 non-merges in nzvleportfolio (who makes up
> your branch names anyway?), there are two already in upstream: e3f56c and
> 7e448c5c. So it really should be 51.
>
> > $ git-rev-list svnhead..master | wc -l
> > 61
>
> Same on my repo.
And if you add --no-merges it'll give you 51 or 52, depending...
> > $ ~/local/git/git-format-patch.sh -o .patchesold svnhead master
> > ...
> > $ ls .patchesold | wc -l
> > 52
>
> I guess this propagates from git-cherry. (Did not test here, since I do
> not have an old git-format-patch.sh handy, and am too lazy to get the last
> version from my git repo.)
I think I did something like
git-cat-file blob v1.3.3:git-format-patch.sh > git-format-patch.sh
chmod ugo+x git-format-patch.sh
> But anyway, looking at your numbers I take it that the new format-patch
> with --ignore-if-in-upstream has the same output as the old format-patch,
> right?
It does, but it may be "right" even though it's not realising that
some of the patches were cherry picked. git-cherry doesn't either. So
that algorythm isn't so hot in this case :-/
I jumped to conclusions earlier because I called git format-patch with
the old syntax (theirs ours) and it gave me 186 patches, which may
very well be the whole repo history, like it did earlier with git
itself. I thought that 186 were the patches pending, and that
git-cherry was cutting that to 52. Not so: it was a syntax issue.
Sorry about the noise!
cheers,
martin
^ permalink raw reply
* [PATCH] pre-commit hook: less easily-tripped conflict marker detection
From: Eric Wong @ 2006-06-27 9:06 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Eric Wong
This should make adding asciidoc files to Documentation easier.
Only complain about conflict markers if we see that we have
some combination of '<<<<<<< ', '>>>>>>> ', and '======='.
Also add a NO_VERIFY environment check to this hook, in case
there's something that we want to force in but still gets
tripped by this hook. It'd be a lot more work to add
--no-verify flags to all things that could potentially call this
hook.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
templates/hooks--pre-commit | 32 ++++++++++++++++++++++++++++----
1 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 723a9ef..1657f96 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -1,4 +1,5 @@
#!/bin/sh
+test -n "$NO_VERIFY" && exit 0
#
# An example hook script to verify what is about to be committed.
# Called by git-commit with no arguments. The hook should
@@ -24,8 +25,9 @@ perl -e '
my $filename;
my $reported_filename = "";
my $lineno;
- sub bad_line {
- my ($why, $line) = @_;
+ my $in_unresolved;
+ my @unresolved;
+ sub bad_common {
if (!$found_bad) {
print STDERR "*\n";
print STDERR "* You have some suspicious patch lines:\n";
@@ -36,12 +38,34 @@ perl -e '
print STDERR "* In $filename\n";
$reported_filename = $filename;
}
+ }
+ sub bad_line {
+ my ($why, $line) = @_;
+ bad_common();
print STDERR "* $why (line $lineno)\n";
print STDERR "$filename:$lineno:$line\n";
}
+ sub show_unresolved {
+ # if we want even less easily-tripped checks,
+ # change the "||" to "&&" here. Right now, we can deal with
+ # the case where somebody removed one of the <{7} or >{7} lines
+ # but left the other one (as well as ={7}) in there.
+ if (($unresolved[0]->[0] =~ /^<{7} / ||
+ $unresolved[-1]->[0] =~ /^>{7} /) &&
+ grep { $_->[0] =~ /^={7}$/ } @unresolved) {
+ bad_common();
+ foreach my $l (@unresolved) {
+ print STDERR "* unresolved merge conflict (line $l->[1])\n";
+ print STDERR "$filename:$l->[1]:$l->[0]\n"
+ }
+ }
+ @unresolved = ();
+ }
+
while (<>) {
if (m|^diff --git a/(.*) b/\1$|) {
$filename = $1;
+ show_unresolved() if @unresolved;
next;
}
if (/^@@ -\S+ \+(\d+)/) {
@@ -61,8 +85,8 @@ perl -e '
if (/^\s* /) {
bad_line("indent SP followed by a TAB", $_);
}
- if (/^(?:[<>=]){7}/) {
- bad_line("unresolved merge conflict", $_);
+ if (/^[<>]{7} / || /^={7}$/) {
+ push @unresolved, [ $_, $lineno ];
}
}
}
--
1.4.1.rc1.g2faf-dirty
^ permalink raw reply related
* [PATCH/RFC] Add git-instaweb, instantly browse the working repo with gitweb
From: Eric Wong @ 2006-06-27 9:05 UTC (permalink / raw)
To: git; +Cc: Eric Wong
I got tired of having to configure gitweb for every repository
I work on. I sometimes prefer gitweb to standard GUIs like gitk
or gitview; so this lets me automatically configure gitweb to
browse my working repository and also opens my browser to it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
.gitignore | 1
Documentation/git-instaweb.txt | 84 ++++++++++++++++
Makefile | 16 +++
git-instaweb.sh | 206 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 306 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index 7b954d5..2bcc604 100644
--- a/.gitignore
+++ b/.gitignore
@@ -46,6 +46,7 @@ git-http-push
git-imap-send
git-index-pack
git-init-db
+git-instaweb
git-local-fetch
git-log
git-lost-found
diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt
new file mode 100644
index 0000000..7dd393b
--- /dev/null
+++ b/Documentation/git-instaweb.txt
@@ -0,0 +1,84 @@
+git-instaweb(1)
+===============
+
+NAME
+----
+git-instaweb - instantly browse your working repository in gitweb
+
+SYNOPSIS
+--------
+'git-instaweb' [--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
+
+'git-instaweb' [--start] [--stop] [--restart]
+
+DESCRIPTION
+-----------
+A simple script to setup gitweb and a web server for browsing the local
+repository.
+
+OPTIONS
+-------
+
+-l|--local::
+ Only bind the web server to the local IP (127.0.0.1).
+
+-d|--httpd::
+ The HTTP daemon command-line that will be executed.
+ Command-line options may be specified here, and the
+ configuration file will be added at the end of the command-line.
+ Currently, lighttpd and apache2 are the only supported servers.
+ (Default: lighttpd)
+
+-m|--module-path::
+ The module path (only needed if httpd is Apache).
+ (Default: /usr/lib/apache2/modules)
+
+-p|--port::
+ The port number to bind the httpd to. (Default: 1234)
+
+-b|--browser::
+
+ The web browser command-line to execute to view the gitweb page.
+ If blank, the URL of the gitweb instance will be printed to
+ stdout. (Default: 'firefox')
+
+--start::
+ Start the httpd instance and exit. This does not generate
+ any of the configuration files for spawning a new instance.
+
+--stop::
+ Stop the httpd instance and exit. This does not generate
+ any of the configuration files for spawning a new instance,
+ nor does it close the browser.
+
+--restart::
+ Restart the httpd instance and exit. This does not generate
+ any of the configuration files for spawning a new instance.
+
+CONFIGURATION
+-------------
+
+You may specify configuration in your .git/config
+
+-----------------------------------------------------------------------
+[instaweb]
+ local = true
+ httpd = apache2 -f
+ port = 4321
+ browser = konqueror
+ modulepath = /usr/lib/apache2/modules
+
+-----------------------------------------------------------------------
+
+Author
+------
+Written by Eric Wong <normalperson@yhbt.net>
+
+Documentation
+--------------
+Documentation by Eric Wong <normalperson@yhbt.net>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index cde619c..83d8922 100644
--- a/Makefile
+++ b/Makefile
@@ -142,7 +142,7 @@ SCRIPT_PYTHON = \
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
- git-cherry-pick git-status
+ git-cherry-pick git-status git-instaweb
# The ones that do not have to link with lcrypto, lz nor xdiff.
SIMPLE_PROGRAMS = \
@@ -545,6 +545,20 @@ git-status: git-commit
cp $< $@+
mv $@+ $@
+git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
+ rm -f $@ $@+
+ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+ -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \
+ $@.sh | sed \
+ -e 's|@@GITWEB_CGI@@|#!$(PERL_PATH_SQ)|; T; r gitweb/gitweb.cgi' \
+ | sed \
+ -e 's|@@GITWEB_CSS@@||; T; r gitweb/gitweb.css' \
+ > $@+
+ chmod +x $@+
+ mv $@+ $@
+
# These can record GIT_VERSION
git$X git.spec \
$(patsubst %.sh,%,$(SCRIPT_SH)) \
diff --git a/git-instaweb.sh b/git-instaweb.sh
new file mode 100755
index 0000000..8f4b2df
--- /dev/null
+++ b/git-instaweb.sh
@@ -0,0 +1,206 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Eric Wong
+#
+USAGE='[--start] [--stop] [--restart]
+ [--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
+ [--module-path=<path> (for Apache2 only)]'
+
+. git-sh-setup
+
+if echo $GIT_DIR | grep ^/
+then
+ fqgitdir="$GIT_DIR"
+else
+ fqgitdir="$PWD/$GIT_DIR"
+fi
+
+local="`git repo-config --bool --get instaweb.local`"
+httpd="`git repo-config --get instaweb.httpd`"
+browser="`git repo-config --get instaweb.browser`"
+port=`git repo-config --get instaweb.port`
+module_path="`git repo-config --get instaweb.modulepath`"
+
+conf=$GIT_DIR/gitweb/httpd.conf
+
+# Defaults:
+
+# if installed, it doesn't need further configuration (module_path)
+test -z "$httpd" && httpd='lighttpd -f'
+
+# probably the most popular browser among gitweb users
+test -z "$browser" && browser='firefox'
+
+# any untaken local port will do...
+test -z "$port" && port=1234
+
+start_httpd () {
+ if echo $httpd | grep ^/ >/dev/null || which $httpd >/dev/null
+ then
+ $httpd $fqgitdir/gitweb/httpd.conf
+ else
+ # many httpds are installed in /usr/sbin or /usr/local/sbin
+ # these days and those are not in most users $PATHs
+ httpd_only=`echo $httpd | sed 's/ .*$//'`
+ for i in /usr/local/sbin /usr/sbin
+ do
+ if test -x "$i/$httpd_only"
+ then
+ $i/$httpd $fqgitdir/gitweb/httpd.conf
+ return
+ fi
+ done
+ fi
+}
+
+stop_httpd () {
+ if test -f "$fqgitdir/pid"
+ then
+ kill `cat "$fqgitdir/pid"` 2>/dev/null
+ fi
+}
+
+while case "$#" in 0) break ;; esac
+do
+ case "$1" in
+ --stop|stop)
+ stop_httpd
+ exit 0
+ ;;
+ --start|start)
+ start_httpd
+ exit 0
+ ;;
+ --restart|restart)
+ stop_httpd
+ start_httpd
+ exit 0
+ ;;
+ --local|-l)
+ local=true
+ ;;
+ -d|--httpd|--httpd=*)
+ case "$#,$1" in
+ *,*=*)
+ httpd=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ httpd="$2"
+ shift ;;
+ esac
+ ;;
+ -b|--browser|--browser=*)
+ case "$#,$1" in
+ *,*=*)
+ browser=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ browser="$2"
+ shift ;;
+ esac
+ ;;
+ -p|--port|--port=*)
+ case "$#,$1" in
+ *,*=*)
+ port=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ port="$2"
+ shift ;;
+ esac
+ ;;
+ -m|--module-path=*|--module-path)
+ case "$#,$1" in
+ *,*=*)
+ module_path=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ module_path="$2"
+ shift ;;
+ esac
+ ;;
+ *)
+ usage
+ ;;
+ esac
+ shift
+done
+
+mkdir -p "$GIT_DIR/gitweb/tmp"
+
+lighttpd_conf () {
+ cat > "$conf" <<EOF
+server.document-root = "$fqgitdir/gitweb"
+server.port = $port
+server.modules = ( "mod_cgi" )
+server.indexfiles = ( "gitweb.cgi" )
+server.pid-file = "$fqgitdir/pid"
+cgi.assign = ( ".cgi" => "" )
+mimetype.assign = ( ".css" => "text/css" )
+EOF
+ test "$local" = true && echo 'server.bind = "127.0.0.1"' >> "$conf"
+}
+
+apache2_conf () {
+ test -z "$module_path" && module_path=/usr/lib/apache2/modules
+ mkdir -p "$GIT_DIR/gitweb/logs"
+ bind=
+ test -n "$local" = true && bind='127.0.0.1:'
+ echo 'text/css css' > $fqgitdir/mime.types
+ cat > "$conf" <<EOF
+ServerRoot "$fqgitdir/gitweb"
+DocumentRoot "$fqgitdir/gitweb"
+PidFile "$fqgitdir/pid"
+Listen $bind$port
+LoadModule cgi_module $module_path/mod_cgi.so
+TypesConfig $fqgitdir/mime.types
+DirectoryIndex gitweb.cgi
+AddHandler cgi-script .cgi
+<Location /gitweb.cgi>
+ Options +ExecCGI
+</Location>
+EOF
+}
+
+script='s#^my $projectroot =.*#my $projectroot = "'`dirname $fqgitdir`'";#;
+s#my $gitbin =.*#my $gitbin = "'`git --exec-path`'";#;
+s#my $projects_list =.*#my $projects_list = $projectroot;#;
+s#my $git_temp =.*#my $git_temp = "'$fqgitdir/gitweb/tmp'";#'
+
+gitweb_cgi () {
+ cat > "$1.tmp" <<\EOFGITWEB
+@@GITWEB_CGI@@
+EOFGITWEB
+ sed "$script" "$1.tmp" > "$1"
+ chmod +x "$1"
+ rm -f "$1.tmp"
+}
+
+gitweb_css () {
+ cat > "$1" <<\EOFGITWEB
+@@GITWEB_CSS@@
+EOFGITWEB
+}
+
+gitweb_cgi $GIT_DIR/gitweb/gitweb.cgi
+gitweb_css $GIT_DIR/gitweb/gitweb.css
+
+if echo "$httpd" | grep lighttpd >/dev/null
+then
+ lighttpd_conf
+elif echo "$httpd" | grep apache2 >/dev/null
+then
+ apache2_conf
+else
+ echo "Unknown httpd specified: $httpd"
+ exit 1
+fi
+
+start_httpd
+test -z "$browser" && browser=echo
+$browser http://127.0.0.1:$port
+
--
1.4.1.rc1.g2faf-dirty
^ permalink raw reply related
* Re: CFT: merge-recursive in C
From: Alex Riesen @ 2006-06-27 8:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, Fredrik Kuivinen
In-Reply-To: <Pine.LNX.4.63.0606270936520.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > I finally got pis^Witched enough by my platform at work and decided
> > to start the effort of converting Fredriks git-merge-recursive to C.
>
> Darn. I was working on the same thing since a few days.
I didn't know :)
> - have you considered using run-command() instead of system()?
No. What run-program?
> - in setup_index(), you set GIT_INDEX_FILE, but I do not think that the
> rest of git picks up on it. environment.cc:get_index_file() checks if
> the variable was set already, but not if it changed.
Not even sure it's needed. Leftover from conversion
> - You work with linked lists all the time. This is slow, especially for
> the checks, if a file/directory is already there. Sorted lists would be
> way faster there. Since you encapsulated that, it is no problem to
> change that later (before inclusion).
Right, that's why it is mostly encapsulated.
> - is not "struct commit_list" more appropriate than "struct graph"?
Not even properly considered it yet. It probably is.
> - I always wondered why merge-recursive did not call merge-base, but did
> its own thing. Hmm?
No idea yet.
> > To my deep disappointment, it didn't work out as good as I hoped: one
> > program I see most often and for longest time in the process list
> > (git-diff-tree) is a too complex thing to be put directly into
> > merge-recursive.c, so any help in this direction will be greatly
> > appreciated.
>
> Maybe something like this (ripped from my fragment of merge-recursive.c):
>
> static struct container *get_renames(struct tree *tree,
> struct tree *o, struct tree *a, struct tree *b,
> struct container *cache_entries)
...
> It is not tested, evidently, since I did not get the merge-base code
> integrated yet. But it should give you an idea.
>
Thanks! It was something I was getting at after Junio explained it.
Will have to wait until after work.
^ permalink raw reply
* Re: Rework a patch serie
From: Andreas Ericsson @ 2006-06-27 8:53 UTC (permalink / raw)
To: moreau francis; +Cc: git
In-Reply-To: <20060627084130.28886.qmail@web25814.mail.ukl.yahoo.com>
moreau francis wrote:
> Hello
>
> Several times I have a topic branch that contains several commits like
> this:
>
> "master"
> o---o
> \ "topic"
> o---o---o---o---o---o
>
>
> When I think everything is in a good shape I generate several patches to
> submit them. For that, I do:
>
> $ git checkout topic
> $ git-format-patch -s -k -n master
> 001-aaa.patch
> 002-bbb.patch
> [...]
> 006-fff.patch
>
> Then I submit these patches for reviewing. Unfortunately, they're not perfect,
> so after some feedbacks from the communauty it appears that I need to make
> small modifications in the second commit in the topic branch for example...
>
> What is the best and fastest way to do that ? Should I create a new topic branch
> and cherry pick from the old one ?
>
It really depends on what the problem is. If it's a thinko in the design
I usually find it worth keeping to avoid falling in the same trap again.
I do the same for bugfixes, although some don't like that (I'm lazy,
they're anal). In this case, patches go on top of topic. Typos and stuff
can usually be changed inside the patch-file, in which case you can just
apply them to a new topic-branch.
It all boils down to how lazy you are, how much of your f***ups you want
to preserve (they *are* useful sometimes) and what you prefer, really.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Rework a patch serie
From: moreau francis @ 2006-06-27 8:41 UTC (permalink / raw)
To: git
Hello
Several times I have a topic branch that contains several commits like
this:
"master"
o---o
\ "topic"
o---o---o---o---o---o
When I think everything is in a good shape I generate several patches to
submit them. For that, I do:
$ git checkout topic
$ git-format-patch -s -k -n master
001-aaa.patch
002-bbb.patch
[...]
006-fff.patch
Then I submit these patches for reviewing. Unfortunately, they're not perfect,
so after some feedbacks from the communauty it appears that I need to make
small modifications in the second commit in the topic branch for example...
What is the best and fastest way to do that ? Should I create a new topic branch
and cherry pick from the old one ?
Thanks for your advices
Francis
^ permalink raw reply
* Re: Notes on diffcore API
From: Alex Riesen @ 2006-06-27 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Timo Hirvonen, git
In-Reply-To: <7virmn9hx8.fsf_-_@assigned-by-dhcp.cox.net>
On 6/27/06, Junio C Hamano <junkio@cox.net> wrote:
> -- >8 --
> Notes on diffcore API
> =====================
Thanks!
> Diffcore Transformation
> -----------------------
>
> The input file pairs recorded in the previous phase are
> collected in diff_queued_diff (a global variable -- which means
> that you cannot have two diffs running in parallel with the
> current setup). This is an expandable array of pointers to
> `struct diff_filepair` structure.
>
merge-recursive shouldn't have any problems with that, as the
renames are just read in the current implementation.
Still, it is somehow uncomfortable to see the amount of APIs
with the above restriction. Never know when it'll bite.
^ permalink raw reply
* [PATCH] git.c: Re-introduce sane error messages on missing commands.
From: Andreas Ericsson @ 2006-06-27 8:28 UTC (permalink / raw)
To: git
Somewhere in the alias handling git turned hostile on fat fingers:
$ git showbranch
Failed to run command '': Is a directory
This patch fixes that by doing 2 things:
* The variable git_command[MAX_PATH + 1] is now retired from
git.c:main() where it was never set. Instead the variable "cmd"
is used for all error messages.
* The introduction of the "exec_errno" variable which preserves the
errno number from the execve() attempt. Later "why did it fail"
tests evaluate exec_errno, which gives the correct error message
along with the brief command-list (telling me I missed the dash in
"show-branch").
It's possible that alias handling can fail and set errno to something
proper, making this change less sane than I think, but handle_alias()
seems to take care of its own error-handling so it shouldn't matter.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
git.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/git.c b/git.c
index 94e9a4a..b04424f 100644
--- a/git.c
+++ b/git.c
@@ -206,9 +206,8 @@ int main(int argc, const char **argv, ch
{
const char *cmd = argv[0];
char *slash = strrchr(cmd, '/');
- char git_command[PATH_MAX + 1];
const char *exec_path = NULL;
- int done_alias = 0;
+ int exec_errno = 0, done_alias = 0;
/*
* Take the basename of argv[0] as the command
@@ -300,6 +299,9 @@ int main(int argc, const char **argv, ch
/* .. then try the external ones */
execv_git_cmd(argv);
+ /* if it's not an alias, the execve() errno is what we want */
+ exec_errno = errno;
+
/* It could be an alias -- this works around the insanity
* of overriding "git log" with "git show" by having
* alias.log = show
@@ -309,11 +311,11 @@ int main(int argc, const char **argv, ch
done_alias = 1;
}
- if (errno == ENOENT)
+ if (exec_errno == ENOENT)
cmd_usage(0, exec_path, "'%s' is not a git-command", cmd);
fprintf(stderr, "Failed to run command '%s': %s\n",
- git_command, strerror(errno));
+ cmd, strerror(exec_errno));
return 1;
}
--
1.4.1.rc1.g1ef9
^ permalink raw reply related
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Johannes Schindelin @ 2006-06-27 8:31 UTC (permalink / raw)
To: Martin Langhoff (CatalystIT); +Cc: Martin Langhoff, git, junkio
In-Reply-To: <44A06A8D.7080202@catalyst.net.nz>
Hi,
I just cloned your repo, and as far as I can tell, the latest commit is on
June 23rd. So your numbers should be the same as mine. But not all are.
On Tue, 27 Jun 2006, Martin Langhoff (CatalystIT) wrote:
> Ok, I cooked the numbers up a bit, it was 60 total, with 10 merged upstream.
> Here's what I have today:
>
> $ git-cherry svnhead..master | grep -c '+'
> 52
Here, it is 51!
The problem I see: from the 53 non-merges in nzvleportfolio (who makes up
your branch names anyway?), there are two already in upstream: e3f56c and
7e448c5c. So it really should be 51.
> $ git-rev-list svnhead..master | wc -l
> 61
Same on my repo.
> $ ~/local/git/git-format-patch.sh -o .patchesold svnhead master
> ...
> $ ls .patchesold | wc -l
> 52
I guess this propagates from git-cherry. (Did not test here, since I do
not have an old git-format-patch.sh handy, and am too lazy to get the last
version from my git repo.)
> $ ~/local/git/git format-patch -o .patchesnewall svnhead..master
> ...
> $ ls .patchesnewall/ | wc -l
> 53
Same on my repo. Correct, since
"git rev-list --parents svnhead..master | grep -c \ .*\ "
yields 8, which is exactly 61 - 53.
> $ ~/local/git/git format-patch --ignore-if-in-upstream -o .patchesnewignore
> svnhead..master
> ...
> $ ls .patchesnewignore | wc -l
> 52
Again, I get 51.
I do not know what is happening, but it could be that there was a bug
fixed lately. I run a slightly modified version of 'next', updated about
15 minutes ago.
But anyway, looking at your numbers I take it that the new format-patch
with --ignore-if-in-upstream has the same output as the old format-patch,
right?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] t4014: fix for whitespace from "wc -l"
From: Johannes Schindelin @ 2006-06-27 8:12 UTC (permalink / raw)
To: git, junkio
Some "wc" insist on putting a TAB in front of the number.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
t/t4014-format-patch.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index c044044..ac2fde7 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -37,7 +37,7 @@ test_expect_success "format-patch --igno
git format-patch --stdout master..side >patch0 &&
cnt=`grep "^From " patch0 | wc -l` &&
- test "$cnt" = 3
+ test $cnt = 3
'
@@ -46,7 +46,7 @@ test_expect_success "format-patch --igno
git format-patch --stdout \
--ignore-if-in-upstream master..side >patch1 &&
cnt=`grep "^From " patch1 | wc -l` &&
- test "$cnt" = 2
+ test $cnt = 2
'
@@ -55,7 +55,7 @@ test_expect_success "format-patch result
git checkout -b rebuild-0 master &&
git am -3 patch0 &&
cnt=`git rev-list master.. | wc -l` &&
- test "$cnt" = 2
+ test $cnt = 2
'
test_expect_success "format-patch --ignore-if-in-upstream result applies" '
@@ -63,7 +63,7 @@ test_expect_success "format-patch --igno
git checkout -b rebuild-1 master &&
git am -3 patch1 &&
cnt=`git rev-list master.. | wc -l` &&
- test "$cnt" = 2
+ test $cnt = 2
'
test_done
--
1.4.1.rc1.ga1a38
^ permalink raw reply related
* Re: What's in git.git
From: Johannes Schindelin @ 2006-06-27 7:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git, Timo Hirvonen
In-Reply-To: <Pine.LNX.4.64.0606262321270.3927@g5.osdl.org>
Hi,
On Mon, 26 Jun 2006, Linus Torvalds wrote:
> #define DUMMYPTR ((void *)"")
NULL_STRING describes better what you want.
Ciao,
Dscho
^ permalink raw reply
* Re: CFT: merge-recursive in C
From: Johannes Schindelin @ 2006-06-27 7:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano, Fredrik Kuivinen
In-Reply-To: <20060626233838.GA3121@steel.home>
Hi,
On Tue, 27 Jun 2006, Alex Riesen wrote:
> I finally got pis^Witched enough by my platform at work and decided
> to start the effort of converting Fredriks git-merge-recursive to C.
Darn. I was working on the same thing since a few days.
A few remarks:
- have you considered using run-command() instead of system()?
- in setup_index(), you set GIT_INDEX_FILE, but I do not think that the
rest of git picks up on it. environment.cc:get_index_file() checks if
the variable was set already, but not if it changed.
- You work with linked lists all the time. This is slow, especially for
the checks, if a file/directory is already there. Sorted lists would be
way faster there. Since you encapsulated that, it is no problem to
change that later (before inclusion).
- is not "struct commit_list" more appropriate than "struct graph"?
- I always wondered why merge-recursive did not call merge-base, but did
its own thing. Hmm?
> It still uses some calls to git programs (git-update-index,
> git-hash-object, git-diff-tree and git-write-tree), and merge(1) has
> the labels (-L) missing - I was unsure how to tackle this on windows -
> it has only argv[1].
See above.
> And it needs to be cleaned up a bit (a lot) - Python is not exactly
> what you'd call "C-conversion-friendly-language", and I am not an
> expert (as in "git-merge-recursive.py is my first Python experience").
No problem. Since I already worked on it, that should be easy.
> To my deep disappointment, it didn't work out as good as I hoped: one
> program I see most often and for longest time in the process list
> (git-diff-tree) is a too complex thing to be put directly into
> merge-recursive.c, so any help in this direction will be greatly
> appreciated.
Maybe something like this (ripped from my fragment of merge-recursive.c):
static struct container *get_renames(struct tree *tree,
struct tree *o, struct tree *a, struct tree *b,
struct container *cache_entries)
{
/*
* Get information of all renames which occured between 'oTree' and
* 'tree'. We need the three trees in the merge ('oTree', 'aTree' and
* 'bTree') to be able to associate the correct cache entries with the
* rename information. 'tree' is always equal to either aTree or bTree.
*/
int i;
struct diff_options diff_opts;
struct container *result
= xcalloc(1, sizeof(struct container));
diff_setup(&diff_opts);
diff_opts.recursive = 1;
diff_opts.detect_rename = DIFF_DETECT_RENAME;
if (diff_setup_done(&diff_opts) < 0)
die("diff_setup_done failed");
diff_tree_sha1(o->object.sha1, tree->object.sha1,
"", &diff_opts);
diffcore_std(&diff_opts);
for (i = 0; i < diff_queued_diff.nr; i++) {
struct diff_filepair *p = diff_queued_diff.queue[i];
if (p->status == 'R') {
struct entry *entry = get_rename(result, p->one->path);
struct rename *rename = entry->priv;
rename->src.mode = p->one->mode;
rename->src.sha1 = p->one->sha1;
rename->src.data
= get_cache_entry(cache_entries, p->one->path)->priv;
fake_stage_data(rename->src.data, o, a, b);
rename->dest.path = p->two->path;
rename->dest.mode = p->two->mode;
rename->dest.sha1 = p->two->sha1;
rename->dest.data
= get_cache_entry(cache_entries, p->two->path)->priv;
fake_stage_data(rename->dest.data, o, a, b);
rename->score = p->score;
}
}
return result;
}
It is not tested, evidently, since I did not get the merge-base code
integrated yet. But it should give you an idea.
Ciao,
Dscho
^ permalink raw reply
* Notes on diffcore API
From: Junio C Hamano @ 2006-06-27 7:28 UTC (permalink / raw)
To: Alex Riesen, Timo Hirvonen; +Cc: git
In-Reply-To: <7v4py7h2b9.fsf@assigned-by-dhcp.cox.net>
I really should have done this six months ago, but I guess being
late is much better than never...
Somebody might want to do proper asciidoc and throw it in
Documentation/technical/.
-- >8 --
Notes on diffcore API
=====================
The diff generation mechanism in git is designed to be
self-contained and you should be able to call it as set of
library functions, unlike other parts of the system where "we
run once and let exit() to clean up afterwards" mentality is
dominant. This is mainly because from early on "diff-tree
--stdin" needed to be able to process hundreds of parent-child
tree pairs without leaking.
NOTE: this note does not describe how combined diff works. It
is quite a different animal.
The diffcore machinery works in 4 phases:
1. setting up the machinery, including command line parsing.
2. feeding input pairs to the machinery.
3. letting it munge input pairs.
4. flushing the output.
The first phase sets up the operational parameters (e.g. use of
rename detector, output format). The second phase feeds pairs
of 'old' and 'new' files to the machinery as the front-end finds
them (e.g. diff-files compares each path found in the index and
in the working tree, and feeds the information from the index as
'old' and the information from the working tree as 'new';
diff-tree compares entries in two trees or entries in the tree
of the first parent commit and the tree of the commit). In the
third phase, the pairs collected in the previous phase are
split, matched up, and filtered to form a different set of
pairs. The last phase formats the resulting set of pairs for
the output.
Setting it up
-------------
The diffcore machinery takes one structure, `struct diff_options`,
to record the set of options that affects its behaviour. These
options affect different parts of its operation, but can roughly
be classified into three groups: the ones that affects how the
input set of pairs are transformed in phase 3, and the ones that
affects how the resulting set of pairs are formatted in phase 4.
First call diff_setup() to initialize the diff_options
structure. This gives the minimum default set of options:
- output format defaults to --raw format;
- output lines are LF terminated;
- no diffcore transformation (phase 3) is used;
If you are writing a top-level diff command, you can then call
diff_opt_parse() to parse the common diff options and fill the
information in diff_options structure, but if your usage does
not require end-user customizability, you can set up the fields in
diff_options yourself without calling this function.
Then call diff_setup_done() -- this makes sure the set of
options are consistent and derives a reasonable default
(e.g. --find-copies-harder without -C does not make sense, patch
output is always recursive).
Feeding Input
-------------
Your main program feeds 'file pairs' to the diffcore machinery
by using these three functions: diff_addremove(), diff_change()
and diff_unmerge(). The first one records a path appears not in
'old' tree but in 'new' tree (or vice versa), the second one
records a path is different between 'old' and 'new', and the
third one says the comparison is meaningless for the path
because it is unmerged (this is only used by diff-index and
diff-files).
When you want to do something diff-tree does, which is quite
common, you can give two tree object names to diff_tree_sha1()
function and let it walk the trees and call these functions for
you.
To signal the end of input, call `diffcore_std()`. This
starts the diffcore transformation described next.
Diffcore Transformation
-----------------------
The input file pairs recorded in the previous phase are
collected in diff_queued_diff (a global variable -- which means
that you cannot have two diffs running in parallel with the
current setup). This is an expandable array of pointers to
`struct diff_filepair` structure.
The `struct diff_filepair` structure has (as the name suggests)
two pointers to `struct diff_filespec` to record the 'old' and
the 'new' file in this pair (the old one is called 'one', and
the new one 'two'), along with some information used by various
diffcore transformation. `struct diff_filespec` records the
blob object name, pathname, size and mode among other things.
Two things to watch out for are:
- a non-existent path is denoted by mode=0 (e.g. in a filepair
for a deleted file, one->mode != 0 and two->mode == 0).
- 0{40} SHA-1 is used when the filespec talks about the file in
the working tree.
Documentation/diffcore.txt should be consulted for the details
of what each transformation does. A short version:
- diffcore-break breaks a filepair that modifies 'one' to 'two'
into two filepairs that deletes 'one' and creates 'two' if
'one' and 'two' are sufficiently dissimilar.
- diffcore-rename matches up a filepair that deletes 'one' and
another filepair that creates 'two' and makes them into one
filepair.
- diffcore-merge-broken picks up two filepairs that were
originally one but broken by diffcore-break but did not get
matched up by diffcore-rename.
- diffcore-pickaxe filters out filepairs whose 'one' and 'two'
have the same number of occurrences of the specified string.
- diffcore-order reorders the resulting filepairs according to
the given input.
- after all of the above, --diff-filter is applied to remove
the uninteresting classes of output (e.g. --diff-filter=A
shows only additions).
Flushing output
---------------
After diffcore transformation runs, the result is still in the
same diff_queued_diff variable. Before calling the standard
output routines, you can inspect each file pair in the queue to
see its status (e.g. what renames to what).
Especially interesting is the 'status' field of the filepair
structure. At this point in the processing chain, each file
pair is marked with `M` (modified), `C` (copied), `R` (renamed),
etc.
Once you are done, calling diff_flush() to perform the output
and free the data structure. If you ran the diff primarily
because you wanted to read the diff_queued_diff and you do not
want any output from this phase, set the putput_format to
DIFF_FORMAT_NO_OUTPUT before calling diff_flush() -- otherwise
you would leak memory the big way.
The raw, patch-text, diffstat and summary output all happens in
this final phase; recent work to make --patch, --stat, --raw
etc. independent flags by Timo are primarily about phase 2 and
this phase.
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-06-27 6:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Timo Hirvonen
In-Reply-To: <7vpsgvf8jf.fsf@assigned-by-dhcp.cox.net>
On Mon, 26 Jun 2006, Junio C Hamano wrote:
>
> As long as none of the following does not dereference the NULL
> pointer that should work fine:
>
> - memchr(NULL, ch, 0);
>
> - memcmp(NULL, ptr, 0);
>
> - stream.next_in = NULL;
> stream.avail_in = 0;
> deflate(&stream, Z_FINISH);
Well, they clearly _shouldn't_, but bugs happen in libraries too.
(The reason they shouldn't is simple: replace the NULL pointer with a
perfectly normal pointer at the end of a page, and if you access past the
length of the memory area, you'd get the same SIGSEGV that a NULL pointer
should give you).
So the question is how much to trust the libraries for a special case that
has a clearly "Right Answer", but is probably unusual in practice.
(That said, "malloc(0)" can validly return NULL, so the NULL+<zero length>
thing can really happen in real code even if it's not explicit).
If people want to be anally defensive, we should give it a valid pointer.
If there are known buggy libraries, I wouldn't object to something
explicit like
#define DUMMYPTR ((void *)"")
and hide it that way - the code may be the exact same thing that I
objected to, but now you're showing that you know that the cast is crud,
and you're just wanting to pass in some non-NULL valid pointer that can be
dereferenced but never written to.
Personally, I think NULL is much better, until somebody shows an actual
buggy library.
Linus
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-06-27 5:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Timo Hirvonen
In-Reply-To: <Pine.LNX.4.64.0606251033030.3747@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I suspect that both could have been made to use NULL instead to indicate
> that no pointer exists.
As long as none of the following does not dereference the NULL
pointer that should work fine:
- memchr(NULL, ch, 0);
- memcmp(NULL, ptr, 0);
- stream.next_in = NULL;
stream.avail_in = 0;
deflate(&stream, Z_FINISH);
^ permalink raw reply
* Just added It will be great Delight in
From: Brigitte @ 2006-06-27 3:54 UTC (permalink / raw)
To: glenn
Good day dear Customer,
Achieve astounding results in bed with these products designed to make any man a winner
Low prices, handy delivery, everything for your convenience.
Millions of people enjoy goods from these brands, and they are more than happy
Come in: http://www.spaedna.com
Come on in and get it all very cheap!
^ permalink raw reply
* Re: CFT: merge-recursive in C
From: Alex Riesen @ 2006-06-27 0:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Fredrik Kuivinen
In-Reply-To: <7v4py7h2b9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Tue, Jun 27, 2006 02:25:46 +0200:
>
> Have fun.
>
Wow. Thats more of explanation that I hoped. Just let me sleep on it a bit :)
^ permalink raw reply
* Re: CFT: merge-recursive in C
From: Junio C Hamano @ 2006-06-27 0:27 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060627002439.GD3121@steel.home>
fork0@t-online.de (Alex Riesen) writes:
> Linus Torvalds, Tue, Jun 27, 2006 02:07:02 +0200:
>> >
>> > git-diff-tree is one of the simplest git operations. We've got absolutely
>> > _tons_ of infrastructure in place to do it efficiently, since it's done
>> > all over the map (a "git-rev-list" with path limiting will do a diff-tree
>> > against all the commits).
>>
>> Side note - I think merge-recursive could/should be rewritten to use
>> "git-merge-tree" instead of "git-read-tree -u -m". I suspect that the
>> git-merge-tree output is in fact a lot closer to what git-merge-recursive
>> actually wants to have.
>>
>
> Yep. And does not touch the index, too. Cool...
Actually "does not touch the index" part is a defect in
merge-tree. It is fine at the recursive level, but at the top
level we need to make sure the local changes do not interfere
with the merge.
^ permalink raw reply
* Re: CFT: merge-recursive in C
From: Junio C Hamano @ 2006-06-27 0:25 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Fredrik Kuivinen
In-Reply-To: <20060626233838.GA3121@steel.home>
fork0@t-online.de (Alex Riesen) writes:
> To my deep disappointment, it didn't work out as good as I hoped: one
> program I see most often and for longest time in the process list
> (git-diff-tree) is a too complex thing to be put directly into
> merge-recursive.c, so any help in this direction will be greatly
> appreciated.
Actually, diff-tree is (and to similar degree the internal diff
machinery is) quite reusable as library piece, far more reusable
than other parts of the core git. If you present what you want
to achieve nicely and ask politely I might even get conned into
helping you interface with the rest of your code ;-).
I am guessing that you want to find out how to do the diff-tree -M
used by the recursive merge without spitting out patch text nor
raw output. That's quite doable and should be easy. Most
likely you would use NO_OUTPUT option when you call diff_tree().
First look at builtin-diff.c::builtin_diff_tree() to see how you
can call the diff machinery given two tree object names. diff_tree()
itself does not emit the diff, but leaves the result in "diff
queue".
After calling diff_tree(), inspect diff_queued_diff() and use
the result to do whatever sensible. The queue is an array of
diff_filepair that records the (path, sha1, mode) among other
things from old tree and from new tree (the one from the old
tree is called "one", and the new tree is called "two").
So if you have one->path = "old-name.c" and two->path = "new-name.c"
then you see the old-name.c file was renamed to new-name.c
When you are done, do not forget to call diff_flush() to get rid
of queued_diff(); otherwise you would leak.
Have fun.
^ 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