Git development
 help / color / mirror / Atom feed
* [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Charles Bailey @ 2008-11-13 12:41 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: git, Jeff King, Andreas Ericsson, Theodore Ts'o,
	William Pursell
In-Reply-To: <1226580075-29289-3-git-send-email-charles@hashpling.org>

This option stops git mergetool from aborting at the first failed merge.
This allows some additional use patterns. Merge conflicts can now be
previewed one at time and merges can also be skipped so that they can be
performed in a later pass.

There is also a mergetool.keepGoing configuration variable covering the
same behaviour.

Signed-off-by: Charles Bailey <charles@hashpling.org>
---
 Documentation/config.txt        |    4 +++
 Documentation/git-mergetool.txt |   12 +++++++++-
 git-mergetool.sh                |   46 ++++++++++++++++++++++++++++++--------
 3 files changed, 51 insertions(+), 11 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index c5b211a..0b0bc99 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -976,6 +976,10 @@ mergetool.keepBackup::
 	is set to `false` then this file is not preserved.  Defaults to
 	`true` (i.e. keep the backup files).
 
+mergetool.keepGoing::
+	Continue to attempt resolution of remaining conflicted files even
+	after a merge has failed or been aborted.
+
 mergetool.prompt::
 	Prompt before each invocation of the merge resolution program.
 
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 176483a..bd2a5ab 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -7,7 +7,8 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
 
 SYNOPSIS
 --------
-'git mergetool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<file>]...
+'git mergetool' [--tool=<tool>] [-y|--no-prompt|--prompt]
+	[-k|--keep-going|--no-keep-going] [<file>]...
 
 DESCRIPTION
 -----------
@@ -69,6 +70,15 @@ success of the resolution after the custom tool has exited.
 	This is the default behaviour; the option is provided to
 	override any configuration settings.
 
+-k or --keep-going::
+	Continue to attempt resolution of remaining conflicted files
+	even after a merge has failed or been aborted.
+
+--no-keep-going::
+	Abort the conflict resolution attempt if any single conflict
+	resolution fails or is aborted. This is the default behaviour;
+	the option is provided to override any configuration settings.
+
 Author
 ------
 Written by Theodore Y Ts'o <tytso@mit.edu>
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 507028f..d60f493 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -8,7 +8,8 @@
 # at the discretion of Junio C Hamano.
 #
 
-USAGE='[--tool=tool] [-y|--no-prompt|--prompt] [file to merge] ...'
+USAGE='[--tool=tool] [-y|--no-prompt|--prompt]
+[-k|--keep-going|--no-keep-going] [file to merge] ...'
 SUBDIRECTORY_OK=Yes
 OPTIONS_SPEC=
 . git-sh-setup
@@ -70,16 +71,16 @@ resolve_symlink_merge () {
 		git checkout-index -f --stage=2 -- "$MERGED"
 		git add -- "$MERGED"
 		cleanup_temp_files --save-backup
-		return
+		return 0
 		;;
 	    [rR]*)
 		git checkout-index -f --stage=3 -- "$MERGED"
 		git add -- "$MERGED"
 		cleanup_temp_files --save-backup
-		return
+		return 0
 		;;
 	    [aA]*)
-		exit 1
+		return 1
 		;;
 	    esac
 	done
@@ -97,15 +98,15 @@ resolve_deleted_merge () {
 	    [mMcC]*)
 		git add -- "$MERGED"
 		cleanup_temp_files --save-backup
-		return
+		return 0
 		;;
 	    [dD]*)
 		git rm -- "$MERGED" > /dev/null
 		cleanup_temp_files
-		return
+		return 0
 		;;
 	    [aA]*)
-		exit 1
+		return 1
 		;;
 	    esac
 	done
@@ -137,7 +138,7 @@ merge_file () {
 	else
 	    echo "$MERGED: file does not need merging"
 	fi
-	exit 1
+	return 1
     fi
 
     ext="$$$(expr "$MERGED" : '.*\(\.[^/]*\)$')"
@@ -269,7 +270,8 @@ merge_file () {
     if test "$status" -ne 0; then
 	echo "merge of $MERGED failed" 1>&2
 	mv -- "$BACKUP" "$MERGED"
-	exit 1
+	cleanup_temp_files
+	return 1
     fi
 
     if test "$merge_keep_backup" = "true"; then
@@ -280,9 +282,11 @@ merge_file () {
 
     git add -- "$MERGED"
     cleanup_temp_files
+    return 0
 }
 
 prompt=$(git config --bool mergetool.prompt || echo true)
+keep_going=$(git config --bool mergetool.keepGoing || echo false)
 
 while test $# != 0
 do
@@ -305,6 +309,12 @@ do
 	--prompt)
 	    prompt=true
 	    ;;
+	-k|--keep-going)
+	    keep_going=true
+	    ;;
+	--no-keep-going)
+	    keep_going=false
+	    ;;
 	--)
 	    break
 	    ;;
@@ -409,6 +419,7 @@ else
     fi
 fi
 
+rollup_status=0
 
 if test $# -eq 0 ; then
     files=`git ls-files -u | sed -e 's/^[^	]*	//' | sort -u`
@@ -424,12 +435,27 @@ if test $# -eq 0 ; then
     do
 	printf "\n"
 	merge_file "$i" < /dev/tty > /dev/tty
+	if test $? -ne 0; then
+	    if test "$keep_going" = true; then
+		rollup_status=1
+	    else
+		exit 1
+	    fi
+	fi
     done
 else
     while test $# -gt 0; do
 	printf "\n"
 	merge_file "$1"
+	if test $? -ne 0; then
+	    if test "$keep_going" = true; then
+		rollup_status=1
+	    else
+		exit 1
+	    fi
+	fi
 	shift
     done
 fi
-exit 0
+
+exit $rollup_status
-- 
1.6.0.2.534.g5ab59

^ permalink raw reply related

* git mergetool enhancements
From: Charles Bailey @ 2008-11-13 12:41 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: git, Jeff King, Andreas Ericsson, Theodore Ts'o,
	William Pursell

Reroll of previously sent mergetool enhancements. Now using -y as the short
option for --no-prompt, but otherwise the same as before.

^ permalink raw reply

* [PATCH 1/3] Fix some tab/space inconsistencies in git-mergetool.sh
From: Charles Bailey @ 2008-11-13 12:41 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: git, Jeff King, Andreas Ericsson, Theodore Ts'o,
	William Pursell
In-Reply-To: <1226580075-29289-1-git-send-email-charles@hashpling.org>

git-mergetool.sh mostly uses 8 space tabs and 4 spaces per indent. This
change corrects this in a part of the file affect by a later commit in
this patch series. diff -w considers this change is to be a null change.

Signed-off-by: Charles Bailey <charles@hashpling.org>
---
 git-mergetool.sh |   38 +++++++++++++++++++-------------------
 1 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/git-mergetool.sh b/git-mergetool.sh
index 94187c3..e2da5fc 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -401,25 +401,25 @@ fi
 
 
 if test $# -eq 0 ; then
-	files=`git ls-files -u | sed -e 's/^[^	]*	//' | sort -u`
-	if test -z "$files" ; then
-		echo "No files need merging"
-		exit 0
-	fi
-	echo Merging the files: "$files"
-	git ls-files -u |
-	sed -e 's/^[^	]*	//' |
-	sort -u |
-	while IFS= read i
-	do
-		printf "\n"
-		merge_file "$i" < /dev/tty > /dev/tty
-	done
+    files=`git ls-files -u | sed -e 's/^[^	]*	//' | sort -u`
+    if test -z "$files" ; then
+	echo "No files need merging"
+	exit 0
+    fi
+    echo Merging the files: "$files"
+    git ls-files -u |
+    sed -e 's/^[^	]*	//' |
+    sort -u |
+    while IFS= read i
+    do
+	printf "\n"
+	merge_file "$i" < /dev/tty > /dev/tty
+    done
 else
-	while test $# -gt 0; do
-		printf "\n"
-		merge_file "$1"
-		shift
-	done
+    while test $# -gt 0; do
+	printf "\n"
+	merge_file "$1"
+	shift
+    done
 fi
 exit 0
-- 
1.6.0.2.534.g5ab59

^ permalink raw reply related

* Re: [PATCH 2/3] Add -n/--no-prompt option to mergetool
From: Charles Bailey @ 2008-11-13 12:28 UTC (permalink / raw)
  To: William Pursell
  Cc: Junio C Hamano, git, Jeff King, Andreas Ericsson,
	Theodore Ts'o
In-Reply-To: <4902F0C2.2070709@gmail.com>

On Sat, Oct 25, 2008 at 11:11:14AM +0100, William Pursell wrote:
>
> My thinking is that when using an interactive tool
> like vimdiff, the user is probably not going to
> care as much about being prompted, or may prefer
> to have the prompt in that situation.  However,
> if they've written a script to do the merge
> non-interactively, then the prompt is undesirable.
>
> So a person might want to be prompted with
> git mergetool -t vimdiff, and prefer no prompt
> with git mergetool -t my-script.  Being able
> to configure the behavior on a per-tool
> basis would allow that.

I can see your point, although personally I feel that if you've gone
to the trouble of writing a special script, the extra typing of an
extra long option (if you prefer prompting normally) is not that big
compared with the hassle of maintaining per-tool config settings if
you like to regularly swap between merge tools.

Both scenarios are probably not too common so I wouldn't object
strongly to either. (But per tool configs is more dev work!)

-- 
Charles Bailey
http://ccgi.hashpling.plus.com/blog/

^ permalink raw reply

* [PATCH fixed] Git.pm: Make _temp_cache use the repository directory
From: Marten Svanfeldt (dev) @ 2008-11-13 12:04 UTC (permalink / raw)
  To: msysgit, git, Eric Wong

Update the usage of File::Temp->tempfile to place the temporary files
within the repository directory instead of just letting Perl decide what
directory to use, given there is a repository specified when requesting
the temporary file.

This is needed to be able to fix git-svn on msys as msysperl generates
paths with UNIX-style paths (/tmp/xxx) while the git tools expect natvie
path format (c:/..). The repository dir is stored in native format so by
using it as the base directory for temporary files we always get a
usable native full path.

Signed-off-by: Marten Svanfeldt <developer@svanfeldt.com>
---
Hi,
Reworked the second part of the commit message after comments to make it
more obvious why this patch is needed.



 perl/Git.pm |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/perl/Git.pm b/perl/Git.pm
index 6aab712..4b71dad 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -961,9 +961,7 @@ issue.
 =cut

 sub temp_acquire {
-	my ($self, $name) = _maybe_self(@_);
-
-	my $temp_fd = _temp_cache($name);
+	my $temp_fd = _temp_cache(@_);

 	$TEMP_FILES{$temp_fd}{locked} = 1;
 	$temp_fd;
@@ -1005,7 +1003,7 @@ sub temp_release {
 }

 sub _temp_cache {
-	my ($name) = @_;
+	my ($self, $name) = _maybe_self(@_);

 	_verify_require();

@@ -1022,9 +1020,16 @@ sub _temp_cache {
 				"' was closed. Opening replacement.";
 		}
 		my $fname;
+
+		my $tmpdir;
+		if (defined $self) {
+			$tmpdir = $self->repo_path();
+		}
+		
 		($$temp_fd, $fname) = File::Temp->tempfile(
-			'Git_XXXXXX', UNLINK => 1
+			'Git_XXXXXX', UNLINK => 1, DIR => $tmpdir,
 			) or throw Error::Simple("couldn't open new temp file");
+
 		$$temp_fd->autoflush;
 		binmode $$temp_fd;
 		$TEMP_FILES{$$temp_fd}{fname} = $fname;
-- 
1.6.0.3.1439.gc9385a.dirty

^ permalink raw reply related

* Re: [PATCH (GITK)] gitk: Fix commit encoding support.
From: Paul Mackerras @ 2008-11-13 11:42 UTC (permalink / raw)
  To: Alexander Gavrilov; +Cc: git
In-Reply-To: <bb6f213e0811100406l2fcde5b8k8772360947b948fd@mail.gmail.com>

Alexander Gavrilov writes:

> If all commits were loaded through cat-file, that would be the way to
> go. Otherwise, when one code path uses one method of conversion, and
> another one, which is used rarely and semi-randomly, a different
> method, it may lead to confusing results if something goes slightly
> wrong.

OK, that makes sense.  I applied the patch with a paragraph added to
the description that explains that.

Thanks,
Paul.

^ permalink raw reply

* Re: [PATCH (GITK)] gitk: Fix transient windows on Win32 and MacOS.
From: Paul Mackerras @ 2008-11-13 11:41 UTC (permalink / raw)
  To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200811112355.43352.angavrilov@gmail.com>

Alexander Gavrilov writes:

> Transient windows cause problems on these platforms:
> 
> - On Win32 the windows appear in the top left corner
>   of the screen. In order to fix it, this patch causes
>   them to be explicitly centered on their parents by
>   an idle handler.
> 
> - On MacOS with Tk 8.4 they appear without a title bar.
>   Since it is clearly unacceptable, this patch disables
>   transient on that platform.
> 
> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>

Thanks, applied.
Paul.

^ permalink raw reply

* Re: [PATCH (GITK)] gitk: Fix transient windows on Win32 and MacOS.
From: Paul Mackerras @ 2008-11-13 11:41 UTC (permalink / raw)
  To: Alexander Gavrilov; +Cc: Johannes Sixt, git
In-Reply-To: <bb6f213e0811120236j7c65bfe4xf95f88df440cbafb@mail.gmail.com>

Alexander Gavrilov writes:

> I'm sorry, it is indeed applied over another patch (attached because I
> only have access to Gmail Web UI right now). These patches eventually
> come from two ends of one long series that has been gradually applied
> over the time, so I still think of them as a unit.

I applied the attached patch.

Thanks,
Paul.

^ permalink raw reply

* Re: [MonoDevelop] git integration with monodevelop
From: Andreas Ericsson @ 2008-11-13 11:01 UTC (permalink / raw)
  To: Christian Hergert
  Cc: Michael Hutchinson, monodevelop-list, Git Mailing List,
	Shawn Pearce
In-Reply-To: <6d4a25b10811130128r4ebf60a4s5679d06961b92450@mail.gmail.com>

Christian Hergert wrote:
> By unmanaged, he means the [DllImport] which you would need to do the call
> to the extern in the shared library.
> 
> Everyone that has chimed in has considered doing the git code before,
> believe us when we say we've thought about wrapping C.  In this case, it
> will be far more flexible in C#.  Especially since tools like silverlight do
> not allow DllImport's.
> 

Well, browser plugins may have a fun time with git support, but it's so far
from my priority list I couldn't even poke it with a really long pole. The
fastest way forward is probably to hack on libgit2 and use C# micro-apps
to verify continually that the binding layer works properly, so that's what
I'll be doing. I should also state that while C# seems fun and all, my top
priority is to make the git library usable as quickly as possible so that
it can attract more attention from developers. That's why I think it's so
vitally important to get some few usable steps working fast (such as diffing
against the index, staging stuff for commit and creating a commit).

Once we have that much, basic IDE integration should be fairly easy, and
then people will want to do more so interest (hopefully from developers)
is likely to increase.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

^ permalink raw reply

* Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Junio C Hamano @ 2008-11-13  9:46 UTC (permalink / raw)
  To: Christian Couder; +Cc: Johannes Schindelin, git
In-Reply-To: <200811121515.48277.chriscool@tuxfamily.org>

Christian Couder <chriscool@tuxfamily.org> writes:

> Le mercredi 12 novembre 2008, Junio C Hamano a écrit :
> ...
>> When you want to hunt for a bug, it is certainly possible that your tests
>> fail for a bug that is unrelated to what you are hunting for for a range
>> of commits.  Borrowing from your picture:
>>
>>     ...--O--A--X1--X2--...--Xn--B--...
>>
>> non of the commit marked as Xi may not be testable.
>>
>> But at that point, will you really spend time to rebuild history between
>> A and B by fixing an unrelated bug that hinders your bisect, so that you
>> can have a parallel history that is bisectable?  I doubt anybody would.
>
> I think kernel developers and perhaps others do that somehow. I mean, there 
> is the following text in the git-bisect(1) documentation:
>
> "
> You may often find that during bisect you want to have near-constant tweaks 
> (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or "revision 
> that does not have this commit needs this patch applied to work around 
> other problem this bisection is not interested in") applied to the revision 
> being tested.
>
> To cope with such a situation, after the inner git-bisect finds the next 
> revision to test, with the "run" script, you can apply that tweak before 
> compiling,...
> "
>
> So we suggest that people patch at bisect time in case of problems. But I 
> think creating a parallel branch should be better in the long run, because 
> you can easily keep the work you did to make things easier to bisect and 
> you can easily share it with other people working with you.

I strongly disagree.

Maybe you hit X2 which does have a breakage, and you would need to patch
up that one before being able to test for your bug, but after you say good
or bad on that one, the next pick will be far away from that Xi segment.
You will test many more revisions before you come back to X3 or X5.  Why
should we force the users to fix all the commits in the segment "just in
case" somebody's bisect falls into the range before that actually happens?

In other words, unless the breakage you are hunting for exists between
point A and B that you cannot bisect for that other breakage, you won't
need to patch-up _every single revision_ in the range for the breakage.
Doing so beforehand is wasteful.

And if you know the range of A..B and the fix, the procedure to follow the
suggestion you quoted above from the doc can even be automated relatively
easily.  Your "run" script would need to do two merge-base to see if the
version to be tested falls inside the range, and if so apply the known fix
before testing (and clean it up afterwards).

Come to think of it, you do not even need to have a custom run script.
How about an approach illustrated by this patch?

I think it also needs to call unapply_fixup when "bisect reset" is given
to clean up, but this is more about a possible approach and not about a
adding a polished and finished shiny new toy, so...

-- >8 --
bisect: use canned "fixup patch"

This allows you to have $GIT_DIR/bisect-fixup directory, populated with
"fixup" patch files.  When revisions between A and B (inclusive) cannot be
tested for your bisection purpose because they have other unrelated
breakage whose fix is already known, you can store a fix-up patch in the
file whose name is A-B (the commit object name of A, a dash, then the
commit object name of B).  When "git bisect" suggests you to test a
revision that falls in that range, the patch will automatically be
applied to the working tree, so that you can test with the known fix
already in place.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-bisect.sh           |   36 ++++++++++++++++++++++++++
 t/t6035-bisect-fixup.sh |   64 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 100 insertions(+), 0 deletions(-)

diff --git c/git-bisect.sh w/git-bisect.sh
index 0d0e278..600d9aa 100755
--- c/git-bisect.sh
+++ w/git-bisect.sh
@@ -338,13 +338,48 @@ exit_if_skipped_commits () {
 	fi
 }
 
+apply_fixup() {
+	>"$GIT_DIR/BISECT_FIXUP"
+	(
+		cd "$GIT_DIR" 2>/dev/null &&
+		find bisect-fixup -type f -print
+	) |
+	while read _fixup
+	do
+		_btm=$(expr "$_fixup" : 'bisect-fixup/\([0-9a-f]*\)-[0-9a-f]*$') &&
+		_btm=$(git rev-parse --quiet --verify "$_btm" 2>/dev/null) &&
+		_top=$(expr "$_fixup" : 'bisect-fixup/[0-9a-f]*-\([0-9a-f]*\)$') &&
+		_top=$(git rev-parse --quiet --verify "$_top" 2>/dev/null) ||
+		continue
+		if	test "z$(git merge-base $_btm "$1")" = z$_btm &&
+			test "z$(git merge-base "$1" $_top)" = "z$1"
+		then
+			echo "Applying $_fixup..."
+			git apply "$GIT_DIR/$_fixup" || exit 1
+			echo >>"$GIT_DIR/BISECT_FIXUP" "$_fixup"
+		fi
+	done
+}
+
+unapply_fixup() {
+	test -r "$GIT_DIR/BISECT_FIXUP" || return 0
+	@@PERL@@ -e "print reverse <>" "$GIT_DIR/BISECT_FIXUP" |
+	while read _fixup
+	do
+		echo "Unapplying $_fixup..."
+		git apply -R "$GIT_DIR/$_fixup" || exit
+	done
+}
+
 bisect_checkout() {
+	unapply_fixup || exit ;# should not happen but try to be careful
 	_rev="$1"
 	_msg="$2"
 	echo "Bisecting: $_msg"
 	mark_expected_rev "$_rev"
 	git checkout -q "$_rev" || exit
 	git show-branch "$_rev"
+	apply_fixup "$_rev" || exit
 }
 
 is_among() {
@@ -532,6 +567,7 @@ bisect_clean_state() {
 	do
 		git update-ref -d $ref $hash || exit
 	done
+	rm -f "$GIT_DIR/BISECT_FIXUP" &&
 	rm -f "$GIT_DIR/BISECT_EXPECTED_REV" &&
 	rm -f "$GIT_DIR/BISECT_ANCESTORS_OK" &&
 	rm -f "$GIT_DIR/BISECT_LOG" &&
diff --git c/t/t6035-bisect-fixup.sh w/t/t6035-bisect-fixup.sh
new file mode 100755
index 0000000..4745b73
--- /dev/null
+++ w/t/t6035-bisect-fixup.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+# Copyright (c) 2008, Junio C Hamano
+
+test_description='bisect fixup'
+
+. ./test-lib.sh
+
+cat >test-fixup <<\EOF
+diff a/elif b/elif
+--- a/elif
++++ b/elif
+@@ -1 +1 @@
+-0
++Z
+EOF
+
+test_expect_success setup '
+	echo 0 >elif
+	git add elif
+	for i in 1 2 3 4 5 6 7 8 9
+	do
+		test_tick &&
+		echo $i >file &&
+		git add file &&
+		git commit -m $i &&
+		git tag t$i
+	done &&
+
+	mkdir ".git/bisect-fixup" &&
+
+	btm=$(git rev-parse --short t3) &&
+	top=$(git rev-parse --short t5) &&
+	cat test-fixup >".git/bisect-fixup/$btm-$top" &&
+
+	btm=$(git rev-parse --short t7) &&
+	top=$(git rev-parse --short t8) &&
+	sed -e "s|Z|A|" test-fixup >".git/bisect-fixup/$btm-$top"
+'
+
+test_expect_success 'bisect fixup' '
+	t1=$(git rev-parse t1) &&
+	t5=$(git rev-parse t5) &&
+	t6=$(git rev-parse t6) &&
+	t7=$(git rev-parse t7) &&
+	t9=$(git rev-parse t9) &&
+
+	git bisect start &&
+	test $(git rev-parse HEAD) = $t9 &&
+	git bisect bad t9 &&
+	test $(git rev-parse HEAD) = $t9 &&
+	git bisect good t1 &&
+	test $(git rev-parse HEAD) = $t5 &&
+	grep Z elif &&
+
+	git bisect good &&
+	test $(git rev-parse HEAD) = $t7 &&
+	grep A elif &&
+
+	git bisect bad &&
+	test $(git rev-parse HEAD) = $t6 &&
+	grep 0 elif
+'
+
+test_done

^ permalink raw reply related

* Re: [PATCH] git-svn: Update git-svn to use the ability to place temporary files within repository directory
From: Eric Wong @ 2008-11-13  9:41 UTC (permalink / raw)
  To: Marten Svanfeldt (dev); +Cc: msysgit, git
In-Reply-To: <491AE935.4040406@svanfeldt.com>

"Marten Svanfeldt (dev)" <developer@svanfeldt.com> wrote:
> This fixes git-svn within msys where Perl will provide temporary files
> with path such as /tmp while the git suit expects native Windows paths.

Ah, I completely didn't understand the related Git.pm patch from you
until I saw this sentence above.

Can you update that other patch and clarify this statement so it
makes sense to UNIX-only folks?

 | This fixes issues when the Perl in use uses a different format for paths
 | than in use by native code in the git tools such as msysgit with msys-perl.

Thanks,

-- 
Eric Wong

^ permalink raw reply

* Re: git integration with monodevelop
From: Christian Hergert @ 2008-11-13  9:28 UTC (permalink / raw)
  To: Andreas Ericsson; +Cc: monodevelop-list, Shawn Pearce, Git Mailing List
In-Reply-To: <491BDD70.1080701@op5.se>


[-- Attachment #1.1: Type: text/plain, Size: 5568 bytes --]

By unmanaged, he means the [DllImport] which you would need to do the call
to the extern in the shared library.

Everyone that has chimed in has considered doing the git code before,
believe us when we say we've thought about wrapping C.  In this case, it
will be far more flexible in C#.  Especially since tools like silverlight do
not allow DllImport's.

However, its your time, and I'd love to see git support happen any way
possible.

-- Christian

On Wed, Nov 12, 2008 at 11:55 PM, Andreas Ericsson <ae@op5.se> wrote:

> Michael Hutchinson wrote:
> > On Wed, Nov 12, 2008 at 5:22 AM, Andreas Ericsson <ae@op5.se> wrote:
> >> Recently, I've started learning C#. More for fun than anything else,
> >> but one of the mono core devs sniffed me out and said they've been
> >> thinking of porting jgit to C# to get a working IDE integration in
> >> monodevelop. Currently, the only option available (with IDE
> >> integration anyways) to the poor C# devs is either Microsoft's
> >> crappy VSS, or the less crappy but still far from fantastic
> >> Subversion.
> >
> > I'm glad you're interested :-)
> >
> > We do have an interface in MD for integrating VCS providers, and
> > although the only existing one is SVN, I believe some users are
> > working on bzr and perforce addins. I'd prefer to see git get
> > established as the default (D)VCS ...
> >
> > Currently, to implement  a VCS provider one needs to subclass
> > VersionControlSystem, as demonstrated by the SVN provider:
> >
> http://anonsvn.mono-project.com/viewvc/trunk/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion/MonoDevelop.VersionControl.Subversion.addin.xml?view=markup
> .
> > We may need to extend the interfaces in order to expose more
> > DVCS-specific features, but I think it's best to find and fix these as
> > needed rather than speculatively implementing things.
> >
>
> I'll look into it. One thing I'd love to see is a "bisect" command
> from within the IDE. That's one of those things that would make the
> first IDE implementing it simply sell itself to hackers and suits
> alike. Besides, "bisect", once learned, is such an awesome tool that
> coders will start to adapt their workflow just to get full benefit
> from it.
>
> >> So in an effort to learn C#, I've decided to play along with this
> >> (hopefully with some help from the MonoDevelop team), but it seems
> >> to me that the best place to start is the fledgling libgit2 and link
> >> that with git-sharp. The primary reason for this is ofcourse that I
> >> think it'd be a terrible waste to have yet another from-scratch
> >> implementation of git in a new language (ruby, java, C#, C...). The
> >> secondary reason is that it would be neat to have more OSS projects
> >> use my favourite scm.
> >
> > That's actually one of the reasons we'd like a full managed
> > implementation --it'd be trivial to include to with cross-platform
> > Mono-based apps without worrying about architecture, C dependencies,
> > etc. For example, Tomboy could use git to store its notes, so users
> > would have a versioned history and better synch/merge. Then, for
> > example, you could build a Silverlight version that would have full
> > history in local storage.
> >
>
> What's considered "unmanaged"? (remember I'm a C# newbie here). Is it
> stuff marked as "unsafe"? If so, there's a whole platoon of stuff to
> re-implement, which is quite nuts. Iiuc, a "safe" way of implementing
> unmanaged code is to always write to objects passed as parameters in
> libgit2, like so:
>
>    int git_commit_get(git_commit *commit, git_oid *oid);
>
> instead of
>
>    git_commit *git_commit_get(git_oid *oid);
>
> as one can let git_commit be a class that gets instantiated and also
> gc'd the normal way. libgit just has to make sure not to leak memory
> and avoid side-effects, but that's good library design anyways, so
> it's not as if C# integration would hurt libgit design.
>
> I really think this would be a better approach that could make the C#
> implementation stay on top of new features (such as the up-and-coming
> v4 pack) a lot better than writing it from scratch.
>
> libgit2 is intended to be portable to all unices as well as Windows
> and Mac OS X, so there's no real problem there
>
> >> Besides, getting something to rely on libgit2 early on is probably
> >> the best way to get more people interested in making development of
> >> it proceed rapidly.
> >>
> >> Thoughts anyone?
> >
> > I hadn't heard of libgit2 (it looks pretty recent)
>
> It is.
>
> > but it looks
> > interesting -- at least stable APIs would no longer be a worry.
> > However, I think fully managed is the way to go, from the point of
> > view of much easier dependencies (on windows, mac, silverlight and
> > older linux distros) and licensing.
> >
>
> But who's going to write (and separately maintain) the 50k or so LoC
> that will make up the git core lib in C#? It really is a waste of
> resources, imo. Especially since libgit will get a lot of exercise,
> whereas the C# code will get that of C#-based integrations only. I
> have a feeling this would lead to bugs (or limitations) in the C#
> implementation that the git community would be expected to deal with.
>
> --
> Andreas Ericsson                   andreas.ericsson@op5.se
> OP5 AB                             www.op5.se
> Tel: +46 8-230225                  Fax: +46 8-230231
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>

[-- Attachment #1.2: Type: text/html, Size: 7295 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Monodevelop-list mailing list
Monodevelop-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-list

^ permalink raw reply

* [BUG] fatal error during merge
From: Anders Melchiorsen @ 2008-11-13  9:22 UTC (permalink / raw)
  To: git

It took a while to make a minimal test case for this, but I think that all
the below steps are required. It ends up with this message:

after/one: unmerged (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
fatal: git write-tree failed to write a tree

and the file that was moved has disappeared from the working tree.

I have tested the script with Git 1.6.0.2, but the real scenario that made
this appear seems to also fail with master and next from git.git.

Cheers,
Anders.


Test script:

mkdir am-merge-fail
cd am-merge-fail
git init

mkdir before
touch before/one after
git add -A
git commit -minitial

rm -f after
git mv before after
git commit -mmove

git checkout -b parallel HEAD~
touch another
git add -A
git commit -mparallel

git merge master

^ permalink raw reply

* Re: git svn branch
From: Michael J Gruber @ 2008-11-13  8:34 UTC (permalink / raw)
  To: yb_Art; +Cc: git
In-Reply-To: <ac92b632-f300-4cbd-8450-6a908fc2c762@t39g2000prh.googlegroups.com>

yb_Art venit, vidit, dixit 13.11.2008 00:47:
> I'm using the binary from google code on my mac os-x leopard machine,
> and it doesn't have git svn branch.  How can I work around this
> issue?  Is there anyway to create a branch on the svn repository using
> git?

I don't know which version google code has, but git-svn is a perl script
which you can download directly from

http://repo.or.cz/w/git.git?a=blob_plain;f=git-svn.perl;hb=HEAD

Note that in git-svn.perl as downloaded you will have to adjust the
first few lines (maybe a uselib in the second line; @@GIT_VERSION@@) to
match what you have in your current git-svn. If your git is not too
ancient then current git-svn should work with it.

Actually, I think compiling yourself is easier...

Michael

^ permalink raw reply

* Re: git integration with monodevelop
From: Andreas Ericsson @ 2008-11-13  7:55 UTC (permalink / raw)
  To: Michael Hutchinson; +Cc: monodevelop-list, Git Mailing List, Shawn Pearce
In-Reply-To: <aec34c770811121556y34465436i9ffb5e29dbf203a7@mail.gmail.com>

Michael Hutchinson wrote:
> On Wed, Nov 12, 2008 at 5:22 AM, Andreas Ericsson <ae@op5.se> wrote:
>> Recently, I've started learning C#. More for fun than anything else,
>> but one of the mono core devs sniffed me out and said they've been
>> thinking of porting jgit to C# to get a working IDE integration in
>> monodevelop. Currently, the only option available (with IDE
>> integration anyways) to the poor C# devs is either Microsoft's
>> crappy VSS, or the less crappy but still far from fantastic
>> Subversion.
> 
> I'm glad you're interested :-)
> 
> We do have an interface in MD for integrating VCS providers, and
> although the only existing one is SVN, I believe some users are
> working on bzr and perforce addins. I'd prefer to see git get
> established as the default (D)VCS ...
> 
> Currently, to implement  a VCS provider one needs to subclass
> VersionControlSystem, as demonstrated by the SVN provider:
> http://anonsvn.mono-project.com/viewvc/trunk/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion/MonoDevelop.VersionControl.Subversion.addin.xml?view=markup.
> We may need to extend the interfaces in order to expose more
> DVCS-specific features, but I think it's best to find and fix these as
> needed rather than speculatively implementing things.
> 

I'll look into it. One thing I'd love to see is a "bisect" command
from within the IDE. That's one of those things that would make the
first IDE implementing it simply sell itself to hackers and suits
alike. Besides, "bisect", once learned, is such an awesome tool that
coders will start to adapt their workflow just to get full benefit
from it.

>> So in an effort to learn C#, I've decided to play along with this
>> (hopefully with some help from the MonoDevelop team), but it seems
>> to me that the best place to start is the fledgling libgit2 and link
>> that with git-sharp. The primary reason for this is ofcourse that I
>> think it'd be a terrible waste to have yet another from-scratch
>> implementation of git in a new language (ruby, java, C#, C...). The
>> secondary reason is that it would be neat to have more OSS projects
>> use my favourite scm.
> 
> That's actually one of the reasons we'd like a full managed
> implementation --it'd be trivial to include to with cross-platform
> Mono-based apps without worrying about architecture, C dependencies,
> etc. For example, Tomboy could use git to store its notes, so users
> would have a versioned history and better synch/merge. Then, for
> example, you could build a Silverlight version that would have full
> history in local storage.
> 

What's considered "unmanaged"? (remember I'm a C# newbie here). Is it
stuff marked as "unsafe"? If so, there's a whole platoon of stuff to
re-implement, which is quite nuts. Iiuc, a "safe" way of implementing
unmanaged code is to always write to objects passed as parameters in
libgit2, like so:

    int git_commit_get(git_commit *commit, git_oid *oid);

instead of

    git_commit *git_commit_get(git_oid *oid);

as one can let git_commit be a class that gets instantiated and also
gc'd the normal way. libgit just has to make sure not to leak memory
and avoid side-effects, but that's good library design anyways, so
it's not as if C# integration would hurt libgit design.

I really think this would be a better approach that could make the C#
implementation stay on top of new features (such as the up-and-coming
v4 pack) a lot better than writing it from scratch.

libgit2 is intended to be portable to all unices as well as Windows
and Mac OS X, so there's no real problem there

>> Besides, getting something to rely on libgit2 early on is probably
>> the best way to get more people interested in making development of
>> it proceed rapidly.
>>
>> Thoughts anyone?
> 
> I hadn't heard of libgit2 (it looks pretty recent)

It is.

> but it looks
> interesting -- at least stable APIs would no longer be a worry.
> However, I think fully managed is the way to go, from the point of
> view of much easier dependencies (on windows, mac, silverlight and
> older linux distros) and licensing.
> 

But who's going to write (and separately maintain) the 50k or so LoC
that will make up the git core lib in C#? It really is a waste of
resources, imo. Especially since libgit will get a lot of exercise,
whereas the C# code will get that of C#-based integrations only. I
have a feeling this would lead to bugs (or limitations) in the C#
implementation that the git community would be expected to deal with.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

^ permalink raw reply

* Re: git integration with monodevelop
From: Andreas Ericsson @ 2008-11-13  7:20 UTC (permalink / raw)
  To: Evgeniy Ivanov; +Cc: Shawn Pearce, Git Mailing List
In-Reply-To: <491B02FF.2060204@kde.ru>

Evgeniy Ivanov wrote:
> Andreas Ericsson wrote:
>> Evgeniy Ivanov wrote:
>>> Hi Andreas,
>>> I've developed basic git-support in KDevelop using git's cmd-line
>>> interface. I'm very interested in rewriting it with libgit2, when
>>> libgit2 becomes usable. Can you, please, drop me a line, when you have
>>> some code?
>>>
>> git clone http://www.spearce.org/projects/scm/libgit2/libgit2.git
>>
>> will probably prove beneficial. I'm adding Shawn to Cc as he's the
>> primary libgit2 author. Please follow the git.git guidelines for
>> submitting patches, and please note that there's not much there
>> right now. Adding a wishlist for what you need in terms of UI
>> integration might make it easier to focus on something when it's
>> going slow.
>>
> 
> I can only suggest something like this on top of library (something like
>  common used things):
> http://websvn.kde.org/trunk/KDE/kdevplatform/plugins/git/gitexecutor.h?revision=856589&view=markup
> 
> I Don't think library interface should be much differ from cmd-line's one.

Well, it will be. The git CLI is inconsistent in places but it would be
weird to have libgit2 inherit those inconsistencies.

> For advanced use, QGit's includes can be used (search commit objects,
> etc). QGit has much more features, than my integration. AFAIK Shawn has
> experience in egit

Yes. He wrote it.

> (and maybe even gitk). IMHO the best thing is to
> implement libgit2 in terms of QGit, egit and maybe kdevelop's git
> support.

That would defeat the purpose rather wildly. The idea with libgit2 is
to create a library that the git cli can use, so building it based on
command-line output is a no-go. libgit2 is the attempt to make it right.

> I will help with pleasure (mentored by Shawn), when have some
> time (maybe only in January-February).
> 

Excellent :)

> But this is the same things Shawn has suggested to my mentor and me at
> the beginning of SoC...
>

Oh? I didn't know libgit2 started as a SoC project.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

^ permalink raw reply

* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Junio C Hamano @ 2008-11-13  6:14 UTC (permalink / raw)
  To: Jeff King; +Cc: Kyle Moffett, git, Sam Vilain
In-Reply-To: <20081113053735.GA5343@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

> And then the "push to current branch" problem is neatly solved: you have
> no current branch.
>
> So:
>
>   $ git checkout new/branch/to/test^0
>   $ make, configure, etc

Exactly.

I keep a handful pseudo worktrees around (created with git-new-workdir on
top of a single repository) for quick patch test and build purposes.  I do
not push into them but pushing into a non-bare repository and checking out
the same branch twice in such a setup share exactly the same issue, and I
keep their HEADs all detached for exactly the same reason.

^ permalink raw reply

* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Jeff King @ 2008-11-13  5:48 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Constantine Plotnikov, git
In-Reply-To: <7vod0ki531.fsf@gitster.siamese.dyndns.org>

On Wed, Nov 12, 2008 at 09:10:26PM -0800, Junio C Hamano wrote:

> > What about "git rev-list --pretty=raw"? Is that also porcelain?
> 
> Does it re-encode?  I didn't check, but ideally it shouldn't (but I do not
> care too much either way, to be honest).

Yes, it uses the same pretty_print_commit routine as the "log".

> > I would be curious to hear your take on our failure to respect
> > --encoding for --pretty=format. Is it a bug to be fixed, or a historical
> > behavior to be maintained?
> 
> I think the fix you outlined was quite reasonable.

One thing I just realized that makes it even more reasonable: we
properly munge the encoding header when we _do_ re-encode. So whether we
re-encode or not, you will always get the correct encoding for what is
being output via "%e". Which means that a tool which handles the current
"broken" behavior by re-encoding themselves will trivially handle the
new version: the output will just always be in the --encoding specified
instead of whatever the original encoding was.

And if there are tools that are not looking at the output encoding (and
blindly assuming --encoding works), then they are already broken by the
current behavior, and we will be fixing them.

So I think it is safe to "fix" it as I described.

-Peff

^ permalink raw reply

* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Jeff King @ 2008-11-13  5:37 UTC (permalink / raw)
  To: Kyle Moffett; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <f73f7ab80811122122i4ae3ba6dn2ceb314b86660a70@mail.gmail.com>

On Thu, Nov 13, 2008 at 12:22:20AM -0500, Kyle Moffett wrote:

> somebody to push something for me to test, they push directly to that
> repo, and when I'm done playing with a previous run I just do:
> 
> $ git checkout new/branch/to/test
> $ make clean
> $ ./configure
> $ make
> $ make check

OK, I see how using a detached HEAD makes sense. But I think just going
straight to a detached HEAD might make even more sense. With your
proposed behavior, you need to be prepared to unexpectedly and
asynchronously move to a detached HEAD at any time, so why not just
start there in the first place?

And then the "push to current branch" problem is neatly solved: you have
no current branch.

So:

  $ git checkout new/branch/to/test^0
  $ make, configure, etc

-Peff

^ permalink raw reply

* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Kyle Moffett @ 2008-11-13  5:22 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <20081112084412.GA3860@coredump.intra.peff.net>

On Wed, Nov 12, 2008 at 3:44 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 11, 2008 at 07:44:06PM -0500, Kyle Moffett wrote:
>> Hmm, I wonder if it would be possible to also add a "detach" variant;
>> which would create a detached-HEAD at the current commit when
>> automatically receiving a push to the working branch.  I have a
>> post-receive script that does so right now on a couple repositories.
>> It's still a little confusing to someone actively working in the
>> repository being pushed to, but it's much easier to explain than the
>> current default behavior.
>
> A neat idea, but I'm not sure what workflow that is meant to support.

Basically, I have a remote tree on a fast multicore box used for runs
of a test suite on various peoples different branches.  When I want
somebody to push something for me to test, they push directly to that
repo, and when I'm done playing with a previous run I just do:

$ git checkout new/branch/to/test
$ make clean
$ ./configure
$ make
$ make check

Occasionally I notice a bug which I want to temporarily fix to let the
build continue, even though I will need to have the author merge that
fix as a part of his original buggy patch.  If nobody pushes the
branch I'm currently testing again, I can "git diff" just fine to see
what I had to fix.  If somebody pushes to a different branch than the
one I'm testing, it's also fine.  The inconsistency is pushing to the
branch I'm on.

So it would be handy to be able to mark that repository as
"detach-HEAD-on-push-of-current-branch", which would let me remember
where I was, even if that's not where that branch is anymore.

There are other ways I could probably do something very similar, but
since the config option was being added it seemed it would probably be
easy to extend.  If nobody else is interested in that behavior, I will
just keep maintaining my own hook, but I thought I'd mention it.

Cheers,
Kyle Moffett

^ permalink raw reply

* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Junio C Hamano @ 2008-11-13  5:10 UTC (permalink / raw)
  To: Jeff King; +Cc: Constantine Plotnikov, git
In-Reply-To: <20081113043454.GA5048@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

> What about "git rev-list --pretty=raw"? Is that also porcelain?

Does it re-encode?  I didn't check, but ideally it shouldn't (but I do not
care too much either way, to be honest).

> I would be curious to hear your take on our failure to respect
> --encoding for --pretty=format. Is it a bug to be fixed, or a historical
> behavior to be maintained?

I think the fix you outlined was quite reasonable.

^ permalink raw reply

* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Jeff King @ 2008-11-13  4:34 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Constantine Plotnikov, git
In-Reply-To: <7vvdusjtg8.fsf@gitster.siamese.dyndns.org>

On Wed, Nov 12, 2008 at 05:38:47PM -0800, Junio C Hamano wrote:

> > BTW for some reason --pretty=raw is affected by encoding option on the
> > command line.
> 
> Unfortunately, that is what you get for reading from a Porcelain output,
> which is meant for, and are subject to improvement for, human consumption.
> 
> If you want bit-for-bit information, you can always ask "git cat-file".

What about "git rev-list --pretty=raw"? Is that also porcelain?

I would be curious to hear your take on our failure to respect
--encoding for --pretty=format. Is it a bug to be fixed, or a historical
behavior to be maintained?

-Peff

^ permalink raw reply

* Re: running out of memory when doing a clone of a large repository?
From: Nicolas Pitre @ 2008-11-13  3:22 UTC (permalink / raw)
  To: Paul E. Rybski; +Cc: git
In-Reply-To: <491B2550.1050005@cs.cmu.edu>

On Wed, 12 Nov 2008, Paul E. Rybski wrote:

> Hi,
> 	I've recently started evaluating git for use on one of my projects.  I
> used git-svn to convert a fairly large subversion repository and one of
> its branches into two separate git repositories following the
> instructions found here:
> 
> http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/
> 
> From that, I created a 1.5G repository from the trunk of the subversion
> repo and a 1.1G repository from one of the branches.  I then tried to
> clone the repositories from one machine to another via ssh and the
> smaller 1.1G repository of the subversion branch (with 1932 commits)
> came over just fine but the larger 1.5G repository of the subversion
> trunk (5865 commits) died with the following error:
> 
> remote: Counting objects: 48415, done.
> remote: warning: suboptimal pack - out of memory
> error: git-upload-pack: git-pack-objects died with error.
> fatal: git-upload-pack: aborting due to possible repository corruption
> on the remote side.
> remote: aborting due to possible repository corruption on the remote side.
> fatal: early EOF
> fatal: index-pack failed
> 
> Is this simply because the git repository is too large for the machine
> that's trying to send it over ssh?

Possibly.

> Is there a way to restrict the memory usage of git or do I need to get 
> more RAM or somehow not import the full subversion history of my 
> original trunk?

It is possible that the inport from svn didn't produce a fully packed 
repository.  Try a "git repack -a -f -d" on the server machine. If you 
get the same out-of-memory problem then ideally you should copy the 
whole directory to a bigger machine and run 'git repack -a -f -d" there.  
Then you may copy it back to the small machine and subsequent clone 
requests should be just fine.

You could also investigate the pack.windowMemory configuration variable 
on the server side.  If you have lots of big files then setting this to 
64m for example may help.

> I'm using Ubuntu 8.04.1 on both machines and using the Ubuntu packages
> of git version 1.5.4.3.

There was a bug in versions prior to v1.5.6.4 affecting memory usage.  
Upgrading to this version or later on the server machine might help too.

> The machine holding the repository is a 5-year
> old AthlonXP 3200 with 1G RAM and 32-bit Ubuntu.  The machine I'm
> cloning the repository on is a more recent Intel Dual Core Quad Q6600
> with 4GRAM and 64-bit Ubuntu.
> 
> Any advice would be greatly appreciated.
> 
> Thanks!
> 
> -Paul
> 
> -- 
> Paul E. Rybski, Ph.D., Systems Scientist
> The Robotics Institute, Carnegie Mellon University
> Phone: 412-268-7417, Fax: 412-268-7350
> Web: http://www.cs.cmu.edu/~prybski
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


Nicolas

^ permalink raw reply

* Re: [PATCH v2] Edit recipient addresses with the --compose flag
From: Junio C Hamano @ 2008-11-13  3:18 UTC (permalink / raw)
  To: Ian Hilt; +Cc: Git Mailing List, Pierre Habouzit
In-Reply-To: <1226544602-1839-1-git-send-email-ian.hilt@gmx.com>

Ian Hilt <ian.hilt@gmx.com> writes:

> Sometimes specifying the recipient addresses can be tedious on the
> command-line.  This commit allows the user to edit the recipient
> addresses in their editor of choice.
>
> Signed-off-by: Ian Hilt <ian.hilt@gmx.com>
> ---
> Here's an updated commit with improved regex's from Junio and Francis.

This heavily depends on Pierre's patch, so I am CC'ing him for comments.
Until his series settles down, I cannot apply this anyway.

> @@ -489,6 +492,9 @@ GIT: for the patch you are writing.
>  GIT:
>  GIT: Clear the body content if you don't wish to send a summary.
>  From: $tpl_sender
> +To: $tpl_to
> +Cc: $tpl_cc
> +Bcc: $tpl_bcc
>  Subject: $tpl_subject
>  In-Reply-To: $tpl_reply_to
>  
> @@ -512,9 +518,31 @@ EOT
>  	open(C,"<",$compose_filename)
>  		or die "Failed to open $compose_filename : " . $!;
>  
> +	local $/;
> +	my $c_file = <C>;
> +	$/ = "\n";
> +	close(C);
> +
> +	my (@tmp_to, @tmp_cc, @tmp_bcc);
> +
> +	if ($c_file =~ /^To:\s*(\S.+?)\s*\nCc:/ism) {
> +		@tmp_to = get_recipients($1);
> +	}

Why "\S.+?" and not "\S.*?"?  A local user whose login name is 'q' is
disallowed?

Why does the user must keep "Cc:" in order for this new code to pick up
the list of recipients?  In other words, you are forbidding the user from
removing the entire "Cc:" line, even when the message should not be Cc'ed
to anywhere.  Instead there has to remain an empty Cc: line.  Worse yet,
such an empty "Cc:" line is printed to C2 with your patch and eventually
fed to sendmail.  I think it is a violation of 2822 to have Cc: that is
empty, as the format is specified as:

    cc              =       "Cc:" address-list CRLF
    bcc             =       "Bcc:" (address-list / [CFWS]) CRLF
    address-list    =       (address *("," address)) / obs-addr-list

> +	if ($c_file =~ /^Cc:\s*(\S.+?)\s*\nBcc:/ism) {
> +		@tmp_cc = get_recipients($1);
> +	}
> +	if ($c_file =~ /^Bcc:\s*(\S.+?)\s*\nSubject:/ism) {
> +		@tmp_bcc = get_recipients($1);
> +	}

Exactly the same comment applies to Bcc and Subject part of the parsing.

I think the parsing code you introduced simply suck.  Why isn't it done as
a part of the main loop to read the same file that already exists?

Unlike your additional code above that reads the whole file into a scalar
only to discard, the existing main loop processes one line at a file
(which should be more memory efficient), and you are not handling the
header continuation line anyway, processing one line at a time would make
your code much simpler (for one thing, you do not have to do /sm at all).
Also it won't be confused as your version would if the message happens to
have "To:" or "Cc:" in the message part, thanks to $in_body variable check
that is already in the code.

^ permalink raw reply

* [PATCH v2] Edit recipient addresses with the --compose flag
From: Ian Hilt @ 2008-11-13  2:50 UTC (permalink / raw)
  To: Git Mailing List

Sometimes specifying the recipient addresses can be tedious on the
command-line.  This commit allows the user to edit the recipient
addresses in their editor of choice.

Signed-off-by: Ian Hilt <ian.hilt@gmx.com>
---
Here's an updated commit with improved regex's from Junio and Francis.

 git-send-email.perl |   47 ++++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index 9039cfd..4d8aaa7 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -480,6 +480,9 @@ if ($compose) {
 	my $tpl_sender = $sender || $repoauthor || $repocommitter || '';
 	my $tpl_subject = $initial_subject || '';
 	my $tpl_reply_to = $initial_reply_to || '';
+	my $tpl_to = join(', ', @to);
+	my $tpl_cc = join(', ', @initial_cc);
+	my $tpl_bcc = join(', ', @bcclist);
 
 	print C <<EOT;
 From $tpl_sender # This line is ignored.
@@ -489,6 +492,9 @@ GIT: for the patch you are writing.
 GIT:
 GIT: Clear the body content if you don't wish to send a summary.
 From: $tpl_sender
+To: $tpl_to
+Cc: $tpl_cc
+Bcc: $tpl_bcc
 Subject: $tpl_subject
 In-Reply-To: $tpl_reply_to
 
@@ -512,9 +518,31 @@ EOT
 	open(C,"<",$compose_filename)
 		or die "Failed to open $compose_filename : " . $!;
 
+	local $/;
+	my $c_file = <C>;
+	$/ = "\n";
+	close(C);
+
+	my (@tmp_to, @tmp_cc, @tmp_bcc);
+
+	if ($c_file =~ /^To:\s*(\S.+?)\s*\nCc:/ism) {
+		@tmp_to = get_recipients($1);
+	}
+	if ($c_file =~ /^Cc:\s*(\S.+?)\s*\nBcc:/ism) {
+		@tmp_cc = get_recipients($1);
+	}
+	if ($c_file =~ /^Bcc:\s*(\S.+?)\s*\nSubject:/ism) {
+		@tmp_bcc = get_recipients($1);
+	}
+
+
 	my $need_8bit_cte = file_has_nonascii($compose_filename);
 	my $in_body = 0;
 	my $summary_empty = 1;
+
+	open(C,"<",$compose_filename)
+		or die "Failed to open $compose_filename : " . $!;
+
 	while(<C>) {
 		next if m/^GIT: /;
 		if ($in_body) {
@@ -543,15 +571,21 @@ EOT
 		} elsif (/^From:\s*(.+)\s*$/i) {
 			$sender = $1;
 			next;
-		} elsif (/^(?:To|Cc|Bcc):/i) {
-			print "To/Cc/Bcc fields are not interpreted yet, they have been ignored\n";
-			next;
 		}
 		print C2 $_;
 	}
 	close(C);
 	close(C2);
 
+	if (@tmp_to) {
+		@to = @tmp_to;
+	}
+	if (@tmp_cc) {
+		@initial_cc = @tmp_cc;
+	}
+	if (@tmp_bcc) {
+		@bcclist = @tmp_bcc;
+	}
 	if ($summary_empty) {
 		print "Summary email is empty, skipping it\n";
 		$compose = -1;
@@ -1095,3 +1129,10 @@ sub file_has_nonascii {
 	}
 	return 0;
 }
+
+sub get_recipients {
+	my $match = shift(@_);
+	my @recipients = split(/\s*,\s*(?![^"]+(?:\"[^*]*)*")/, $match);
+
+	return @recipients;
+}
-- 
1.6.0.3.523.g304d0

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox