* Re: git push (mis ?)behavior
From: Steffen Prohaska @ 2007-10-09 7:23 UTC (permalink / raw)
To: Jan Hudec; +Cc: Junio C Hamano, Pierre Habouzit, git
In-Reply-To: <20071009050533.GA2968@efreet.light.src>
On Oct 9, 2007, at 7:05 AM, Jan Hudec wrote:
> On Fri, Sep 28, 2007 at 00:07:27 -0700, Junio C Hamano wrote:
>> Steffen Prohaska <prohaska@zib.de> writes:
>>
>>> When "remote.<name>.push" is set I'd expect "git push" to
>>> choose only the 'right' remote.<name>.push lines, that is
>>> the lines that have the current branch as the local ref.
>
> I would like this for another reason and maybe in slightly
> different way.
> Basically I would have configured something along the lines:
> [remote "origin"]
> push = refs/heads/*:refs/heads/jahu/*
> and would want to choose, via option, whether I want to push all
> the branches
> or just the current one, but in any case with the renaming specified.
>
> The idea behind this is to have a shared repository, but not shared
> branches.
> Everybody would have a subdirectory in refs/heads where he could push
> anything that the others should see and than somebody else (either
> designated
> integrator, or just anybody different) would do a quick review and
> merge it
> into master.
>
> Now I could of course push out everything, but usually I'd want to
> push
> exactly the current branch, renaming it by the rule given, whether
> it already
> existed in origin or not. Than there can be eg. a post-receive hook
> notifying
> the integrator that there is something for review.
I had a similar scenario in mind. So a more general question is the
following:
Git well supports the clone from read-only and push to private repo
scheme.
In this case all repositories you're pushing to are by definition _your_
repositories. The only question left is, which subset of your
branches are
pushed. But there's no need for renaming during push.
Now the question is, what is a sensible workflow on a shared repository?
One option is to use some kind of private 'namespace' scheme. For
example
developers should push their topics to a branch prefixed with their
name,
or to a 'subdirectory' ref/heads/needsreview/*.
This workflow may require to 'rename' branches during push. So how
can this
be supported by git? Supporting only renames that add a prefix, as
suggested
by Jan, may be reasonable restriction.
Steffen
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Benoit SIGOURE @ 2007-10-09 7:19 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710090807060.26773@ds9.cixit.se>
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
On Oct 9, 2007, at 9:09 AM, Peter Karlsson wrote:
> Hi!
>
> I have a couple of repositories converted from CVS to Git using
> parsecvs. Some are just converted, some I've continued to develop
> after
> the conversion (and cloned a couple of times).
>
> Since parsecvs gave me all the CVS branches, I would like to record
> the
> merge points in the Git history, if possible. I have commited merges
> with comments like "merged <branchname>", so I can probably find them
> quite easily, and I do have the imported CVS branches available. Can I
> record the merge information so git knows about them?
>
> Is it safe to do so on a repository that has already been cloned (i.e,
> will a later push/pull work)?
I think you can use grafts do achieve this.
From Documentation/repository-layout.txt:
info/grafts::
This file records fake commit ancestry information, to
pretend the set of parents a commit has is different
from how the commit was actually created. One record
per line describes a commit and its fake parents by
listing their 40-byte hexadecimal object names separated
by a space and terminated by a newline.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Recording merges after repo conversion
From: Peter Karlsson @ 2007-10-09 7:09 UTC (permalink / raw)
To: git
Hi!
I have a couple of repositories converted from CVS to Git using
parsecvs. Some are just converted, some I've continued to develop after
the conversion (and cloned a couple of times).
Since parsecvs gave me all the CVS branches, I would like to record the
merge points in the Git history, if possible. I have commited merges
with comments like "merged <branchname>", so I can probably find them
quite easily, and I do have the imported CVS branches available. Can I
record the merge information so git knows about them?
Is it safe to do so on a repository that has already been cloned (i.e,
will a later push/pull work)?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Merge problems with git-mingw
From: Peter Karlsson @ 2007-10-09 7:06 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <8c5c35580710081259j6d7e8587r546d4c35d42a67a6@mail.gmail.com>
HI!
> Does 'git var -l' work as expected?
Hmm, it also gives an error message:
$ git var -l
usage: git-var [-l | <variable>]
> Also, could you try the latest git-package provided by the cygwin
> installer? If CRLF-handling was your problem, take a look at the
> description of core.autocrlf with 'git help config'.
I tried it with Git 1.5.3.2 from Cygwin, and the problem I'm having is
not with the CRLF handling in the checked out files, but rather in the
repository database itself. Cloning a repository with Cygwin-Git
produced various errors about the object database being corrupt.
Mingw-Git does not produce those errors.
> [This does look like an issue with running mingw.git under Cygwin.
> Johannes, is this even supposed to work?]
I get the same error running mingw-git from a regular cmd.exe prompt,
so it doesn't seem to be related to Cygwin at all.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Steffen Prohaska @ 2007-10-09 6:42 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Theodore Ts'o, git
In-Reply-To: <20071008220025.GZ31659@planck.djpig.de>
On Oct 9, 2007, at 12:00 AM, Frank Lichtenheld wrote:
> On Mon, Oct 08, 2007 at 11:22:40PM +0200, Steffen Prohaska wrote:
>> This commit adds a mechanism to provide absolute paths to the
>> commands called by 'git mergetool'. A path can be specified
>> in the configuation variable merge.<toolname>path.
>
> Why not merge.<toolname>.path?
>
> This would it make easy to introduce new variables of the form
> merge.<toolname>.<var> later if needed. I also think it is more
> consistent with names of existing configuration variables.
> (think branch.<name>.<var> or remote.<name>.<var>)
Looks more beautiful on the command line but a bit more complex
in the config file. But I like the idea.
Maybe mergetool.<tool>.path is even a better choice? It clearly
indicate the relationship with mergetool. We could explain:
'The variable merge.tool = <tool> refers to a tool that can
be further specified in mergetool.<tool>.path.'
Steffen
^ permalink raw reply
* Hi dear
From: Angela @ 2007-10-08 20:05 UTC (permalink / raw)
To: git
Hey, my name isAngela. Im looking for a fiend and dying to meet you. Catch my photo and call me. My photo http://10ur.net/logo.JPG
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Steffen Prohaska @ 2007-10-09 6:30 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20071008215729.GC31713@thunk.org>
On Oct 8, 2007, at 11:57 PM, Theodore Tso wrote:
> On Mon, Oct 08, 2007 at 11:22:40PM +0200, Steffen Prohaska wrote:
>> This commit adds a mechanism to provide absolute paths to the
>> commands called by 'git mergetool'. A path can be specified
>> in the configuation variable merge.<toolname>path.
>
> This patch doesn't work if the config file doesn't specify an explicit
> mergetool via merge.tool. The reason for that is this loop:
>
> for i in $merge_tool_candidates; do
> if test $i = emerge ; then
> cmd=emacs
> else
> cmd=$i
> fi
> if type $cmd > /dev/null 2>&1; then
> merge_tool=$i
> break
> fi
> done
>
> is only checking to see if $cmd is in the path; it's not looking up
> the merge.<toolname>path variable in this loop.
I didn't change the automatic detection. It should work as before.
That is it continues to assume that merge tools are in PATH.
Is you expectation that git-mergetool should also consider the
absolute paths provided in merge.<toolname>path?
When I wrote the patch I had in mind that people will set the
merge.tool explicitly if they provide an absolute path. Automatic
detection would only be used if nothing is configured. In this
case a tool must be in PATH or would not be found.
> I guess the other question is whether we would be better off simply
> telling the user to specify an absolute pathname in merge.tool, and
> then having git-mergetool strip off the directory path via basename,
> and then on window systems, stripping off the .EXE or .COM suffix, and
> then downcasing the name so that something like "C:\Program
> Files\ECMerge\ECMerge.exe" gets translated to "ecmerge". Would I be
> right in guessing that the reason why you used merge.<toolname>path
> approach was to avoid this messy headache?
Yes. The program to start ECMerge on Windows is called 'guimerge.exe'.
Hard to derive a sensible short name from this.
So I don't think that an automatic translation is an option. I prefer
to provide the absolute paths.
Absolute paths have another advantage. You can set several of them
and choose a tool on the command line. Maybe you have several tools
you want to try. Or you hacking with someone else who preferes a
different tool. Or you just want to give a demo. I see
merge.<toolname>path more as a database associating absolute paths
with the shortnames.
My mental model is as follows:
1) merge.tool selects the mechanism needed to call the tool, that is
command line arguments, how merge result is passed, ...
2) merge.<toolname>path provides additional information how to locate
the selected tool in the filesystem.
The two points are somewhat orthogonal. I'd not fuse them into one.
Steffen
^ permalink raw reply
* Re: [PATCH] mergetool: add support for ECMerge
From: Steffen Prohaska @ 2007-10-09 6:14 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20071008214451.GB31713@thunk.org>
On Oct 8, 2007, at 11:44 PM, Theodore Tso wrote:
> On Mon, Oct 08, 2007 at 11:22:41PM +0200, Steffen Prohaska wrote:
>> Add support for ECMerge available from
>> http://www.elliecomputing.com/Products/merge_overview.asp
>
> Hmm. A propietary merge tool. It's not that much code, so I
> guess....
>
> I note though that it claims on the web page that they are integrated
> with "most famous SCM's", but they don't include git. If we add this
> support, are they going to change their web page? :-)
You may even apply for a free (as beer) license if you contribute
to open source projects:
http://www.elliecomputing.com/Community/opensource.asp
I didn't try this, so I can't say how this works in practice.
> Also, ECmerge is supported on Linux, Solaris, MacOS X, and Windows.
> Which platforms have you tested on?
Windows. Haven't tested Unix systems yet.
> My guess is that if it works on
> Linux, it'll probably work on Solaris and MacOS, but is it a fair
> guess you haven't tested under Windows? Not that most Windows systems
> are going to be able to use git-mergetool since it's a bash script,
> unless they are using Cygwin or some such.
I work on the msysgit project and I'd like to have mergetool
available before I advertise git on Windows. It makes merging
so much easier ;)
Steffen
^ permalink raw reply
* Re: Merge problems with git-mingw
From: Johannes Sixt @ 2007-10-09 6:10 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Peter Karlsson, git
In-Reply-To: <8c5c35580710081259j6d7e8587r546d4c35d42a67a6@mail.gmail.com>
Lars Hjemli schrieb:
> On 10/8/07, Peter Karlsson <peter@softwolves.pp.se> wrote:
>> $ git var GIT_COMMITTER_IDENT
>> usage: git-var [-l | <variable>]
>
> Does 'git var -l' work as expected? Also, could you try the latest
> git-package provided by the cygwin installer? If CRLF-handling was
> your problem, take a look at the description of core.autocrlf with
> 'git help config'.
>
> [This does look like an issue with running mingw.git under Cygwin.
> Johannes, is this even supposed to work?]
Sure, why not? Cygwin's settings as well as core.autocrlf should be
completely irrelevant. I've no clue what could be wrong here.
-- Hannes
^ permalink raw reply
* Re: [StGit PATCH 6/6] Let some commands work with detached HEAD
From: Karl Hasselström @ 2007-10-09 5:12 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20071008153450.GA12247@diana.vm.bytemark.co.uk>
On 2007-10-08 17:34:50 +0200, Karl Hasselström wrote:
> This hunk shouldn't be here, since diff does use crt_series. (The
> commit message also has to be modified accordingly.)
I've fixed the patch and pushed it out, along with the two new ones.
For good measure, I also demoted it from safe to experimental.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Jan Hudec @ 2007-10-09 5:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, Pierre Habouzit, git
In-Reply-To: <7vodfnqndc.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]
On Fri, Sep 28, 2007 at 00:07:27 -0700, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
> > When "remote.<name>.push" is set I'd expect "git push" to
> > choose only the 'right' remote.<name>.push lines, that is
> > the lines that have the current branch as the local ref.
I would like this for another reason and maybe in slightly different way.
Basically I would have configured something along the lines:
[remote "origin"]
push = refs/heads/*:refs/heads/jahu/*
and would want to choose, via option, whether I want to push all the branches
or just the current one, but in any case with the renaming specified.
The idea behind this is to have a shared repository, but not shared branches.
Everybody would have a subdirectory in refs/heads where he could push
anything that the others should see and than somebody else (either designated
integrator, or just anybody different) would do a quick review and merge it
into master.
Now I could of course push out everything, but usually I'd want to push
exactly the current branch, renaming it by the rule given, whether it already
existed in origin or not. Than there can be eg. a post-receive hook notifying
the integrator that there is something for review.
> That would break the existing setup so it would not fly as a
> default, although it could be added as an option.
We can have an option and/or we can have some new parameter in .git/config.
Maybe:
push = refs/heads/*:refs/heads/jahu/*
would mean to push always (ie. everything under refs/heads) and eg.:
push = !refs/heads/*:refs/heads/jahu/*
would mean to push just current branch if it matches. Mixed setups would be
possible:
push = refs/heads/*:refs/heads/jahu/* !master:master !next:next
would mean push everything to jahu/ and if current is master, push it to
master, or if current is next, push it to next.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [StGit PATCH] New test: "stg diff"
From: Karl Hasselström @ 2007-10-09 4:42 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20071008153450.GA12247@diana.vm.bytemark.co.uk>
A simple test to make sure that we can run "stg diff" without
arguments, just to list local changes.
Note that two subtests currently fail; these are due to plain "stg
diff" failing on a branch where "stg init" hasn't been run, which is
plainly a bug.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
On 2007-10-08 17:34:50 +0200, Karl Hasselström wrote:
> So, we don't have a single test that tries to run "stg diff". Duh.
t/t2400-diff.sh | 37 +++++++++++++++++++++++++++++++++++++
1 files changed, 37 insertions(+), 0 deletions(-)
create mode 100755 t/t2400-diff.sh
diff --git a/t/t2400-diff.sh b/t/t2400-diff.sh
new file mode 100755
index 0000000..6d9ed98
--- /dev/null
+++ b/t/t2400-diff.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+
+test_description='Run "stg diff"'
+
+. ./test-lib.sh
+
+test_expect_failure 'Diff with no StGit data' '
+ stg diff
+'
+
+test_expect_success 'Make some local changes' '
+ echo foo >> foo.txt &&
+ git add foo.txt
+'
+
+test_expect_failure 'Diff with some local changes' '
+ stg diff
+'
+
+test_expect_success 'Initialize StGit stuff' '
+ stg init &&
+ stg new foo -m foo
+'
+
+test_expect_success 'Diff with some local changes' '
+ stg diff
+'
+
+test_expect_success 'Refresh patch' '
+ stg refresh
+'
+
+test_expect_success 'Diff with no local changes' '
+ stg diff
+'
+
+test_done
^ permalink raw reply related
* [StGit PATCH] Fix error message generation
From: Karl Hasselström @ 2007-10-09 4:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
The right-hand-side operand of % is supposed to be a tuple with the
same number of arguments as there are formatting codes in the
left-hand-side operand, or just any value if there is just one
formatting code; however, here it was a variable with a tuple value,
which didn't work. So wrap it in a tuple of length one, and all is
well again.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/run.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stgit/run.py b/stgit/run.py
index 989bb27..83bf5f5 100644
--- a/stgit/run.py
+++ b/stgit/run.py
@@ -40,7 +40,7 @@ class Run:
self.__cmd = list(cmd)
for c in cmd:
if type(c) != str:
- raise Exception, 'Bad command: %r' % cmd
+ raise Exception, 'Bad command: %r' % (cmd,)
self.__good_retvals = [0]
self.__env = None
self.__indata = None
^ permalink raw reply related
* [PATCH 3/3] Bisect: implement "bisect dunno" to mark untestable revisions.
From: Christian Couder @ 2007-10-09 4:25 UTC (permalink / raw)
To: Junio Hamano, Johannes Schindelin; +Cc: git
When there are some dunno revisions, we add the '--bisect-all'
option to "git rev-list --bisect-vars". Then we filter out the
dunno revisions from the result of the rev-list command, and we
modify the "bisect_rev" var accordingly.
We don't always use "--bisect-all" because it is slower
than "--bisect-vars" or "--bisect".
When we cannot find for sure the first bad commit because of
dunno commits, we print the hash of each possible first bad
commit and then we exit with code 2.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 115 ++++++++++++++++++++++++++++++++++++++++++-
t/t6030-bisect-porcelain.sh | 71 ++++++++++++++++++++++++++
2 files changed, 184 insertions(+), 2 deletions(-)
I removed the "search_dunno" function that was in
the previous version of this patch and replaced it
with a "case" as suggested by Dscho.
I did not removed the bisect_write_{bad,good,dunno}
functions because some of them are used in more than
one place. But I will factorise them in a following
patch.
diff --git a/git-bisect.sh b/git-bisect.sh
index 436ccf6..022671d 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -17,6 +17,8 @@ git bisect replay <logfile>
replay bisection log.
git bisect log
show bisect log.
+git bisect dunno [<rev>...]
+ mark <rev>... untestable revisions.
git bisect run <cmd>...
use <cmd>... to automatically bisect.'
@@ -163,6 +165,28 @@ bisect_write_good() {
echo "# good: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
}
+bisect_dunno() {
+ bisect_autostart
+ case "$#" in
+ 0) revs=$(git rev-parse --verify HEAD) || exit ;;
+ *) revs=$(git rev-parse --revs-only --no-flags "$@") &&
+ test '' != "$revs" || die "Bad rev input: $@" ;;
+ esac
+ for rev in $revs
+ do
+ rev=$(git rev-parse --verify "$rev^{commit}") || exit
+ bisect_write_dunno "$rev"
+ echo "git-bisect dunno $rev" >>"$GIT_DIR/BISECT_LOG"
+ done
+ bisect_auto_next
+}
+
+bisect_write_dunno() {
+ rev="$1"
+ echo "$rev" >"$GIT_DIR/refs/bisect/dunno-$rev"
+ echo "# dunno: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
+}
+
bisect_next_check() {
missing_good= missing_bad=
git show-ref -q --verify refs/bisect/bad || missing_bad=t
@@ -205,17 +229,97 @@ bisect_auto_next() {
bisect_next_check && bisect_next || :
}
+filter_dunno() {
+ _eval="$1"
+ _dunno="$2"
+
+ if [ -z "$_dunno" ]; then
+ eval $_eval
+ return
+ fi
+
+ # Let's parse the output of:
+ # "git rev-list --bisect-vars --bisect-all ..."
+ eval $_eval | while read hash line
+ do
+ case "$VARS,$FOUND,$TRIED,$hash" in
+ # We display some vars.
+ 1,*,*,*) echo "$hash $line" ;;
+
+ # Split line.
+ ,*,*,---*) ;;
+
+ # We had nothing to search.
+ ,,,bisect_rev*)
+ echo "bisect_rev="
+ VARS=1
+ ;;
+
+ # We did not find a good bisect rev.
+ # This should happen only if the "bad"
+ # commit is also a "dunno" commit.
+ ,,*,bisect_rev*)
+ echo "bisect_rev=$TRIED"
+ VARS=1
+ ;;
+
+ # We are searching.
+ ,,*,*)
+ TRIED="${TRIED:+$TRIED|}$hash"
+ case "$_dunno" in
+ *$hash*) ;;
+ *)
+ echo "bisect_rev=$hash"
+ echo "bisect_tried=\"$TRIED\""
+ FOUND=1
+ ;;
+ esac
+ ;;
+
+ # We have already found a rev to be tested.
+ ,1,*,bisect_rev*) VARS=1 ;;
+ ,1,*,*) ;;
+
+ # ???
+ *) die "filter_dunno error " \
+ "VARS: '$VARS' " \
+ "FOUND: '$FOUND' " \
+ "TRIED: '$TRIED' " \
+ "hash: '$hash' " \
+ "line: '$line'"
+ ;;
+ esac
+ done
+}
+
+exit_if_dunno_commits () {
+ _tried=$1
+ if expr "$_tried" : ".*[|].*" > /dev/null ; then
+ echo "There are only 'dunno' commit left to test."
+ echo "The first bad commit could be any of:"
+ echo "$_tried" | sed -e 's/[|]/\n/g'
+ echo "We cannot bisect more!"
+ exit 2
+ fi
+}
+
bisect_next() {
case "$#" in 0) ;; *) usage ;; esac
bisect_autostart
bisect_next_check good
+ dunno=$(git for-each-ref --format='%(objectname)' \
+ "refs/bisect/dunno-*" | tr '[\012]' ' ') || exit
+
+ BISECT_OPT=''
+ test -n "$dunno" && BISECT_OPT='--bisect-all'
+
bad=$(git rev-parse --verify refs/bisect/bad) &&
good=$(git for-each-ref --format='^%(objectname)' \
"refs/bisect/good-*" | tr '[\012]' ' ') &&
- eval="git rev-list --bisect-vars $good $bad --" &&
+ eval="git rev-list --bisect-vars $BISECT_OPT $good $bad --" &&
eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
- eval=$(eval "$eval") &&
+ eval=$(filter_dunno "$eval" "$dunno") &&
eval "$eval" || exit
if [ -z "$bisect_rev" ]; then
@@ -223,11 +327,16 @@ bisect_next() {
exit 1
fi
if [ "$bisect_rev" = "$bad" ]; then
+ exit_if_dunno_commits "$bisect_tried"
echo "$bisect_rev is first bad commit"
git diff-tree --pretty $bisect_rev
exit 0
fi
+ # We should exit here only if the "bad"
+ # commit is also a "dunno" commit (see above).
+ exit_if_dunno_commits "$bisect_rev"
+
echo "Bisecting: $bisect_nr revisions left to test after this"
echo "$bisect_rev" >"$GIT_DIR/refs/heads/new-bisect"
git checkout -q new-bisect || exit
@@ -362,6 +471,8 @@ case "$#" in
bisect_bad "$@" ;;
good)
bisect_good "$@" ;;
+ dunno)
+ bisect_dunno "$@" ;;
next)
# Not sure we want "next" at the UI level anymore.
bisect_next "$@" ;;
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 03cdba5..7f41a46 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -71,6 +71,63 @@ test_expect_success 'bisect start with one bad and good' '
git bisect next
'
+# $HASH1 is good, $HASH4 is bad, we dunno about $HASH3
+# but $HASH2 is bad,
+# so we should find $HASH2 as the first bad commit
+test_expect_success 'bisect dunno: successfull result' '
+ git bisect reset &&
+ git bisect start $HASH4 $HASH1 &&
+ git bisect dunno &&
+ git bisect bad > my_bisect_log.txt &&
+ grep "$HASH2 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
+# $HASH1 is good, $HASH4 is bad, we dunno about $HASH3 and $HASH2
+# so we should not be able to tell the first bad commit
+# among $HASH2, $HASH3 and $HASH4
+test_expect_success 'bisect dunno: cannot tell between 3 commits' '
+ git bisect start $HASH4 $HASH1 &&
+ git bisect dunno || return 1
+
+ if git bisect dunno > my_bisect_log.txt
+ then
+ echo Oops, should have failed.
+ false
+ else
+ test $? -eq 2 &&
+ grep "first bad commit could be any of" my_bisect_log.txt &&
+ ! grep $HASH1 my_bisect_log.txt &&
+ grep $HASH2 my_bisect_log.txt &&
+ grep $HASH3 my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ git bisect reset
+ fi
+'
+
+# $HASH1 is good, $HASH4 is bad, we dunno about $HASH3
+# but $HASH2 is good,
+# so we should not be able to tell the first bad commit
+# among $HASH3 and $HASH4
+test_expect_success 'bisect dunno: cannot tell between 2 commits' '
+ git bisect start $HASH4 $HASH1 &&
+ git bisect dunno || return 1
+
+ if git bisect good > my_bisect_log.txt
+ then
+ echo Oops, should have failed.
+ false
+ else
+ test $? -eq 2 &&
+ grep "first bad commit could be any of" my_bisect_log.txt &&
+ ! grep $HASH1 my_bisect_log.txt &&
+ ! grep $HASH2 my_bisect_log.txt &&
+ grep $HASH3 my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ git bisect reset
+ fi
+'
+
# We want to automatically find the commit that
# introduced "Another" into hello.
test_expect_success \
@@ -99,6 +156,20 @@ test_expect_success \
grep "$HASH4 is first bad commit" my_bisect_log.txt &&
git bisect reset'
+# $HASH1 is good, $HASH5 is bad, we dunno about $HASH3
+# but $HASH4 is good,
+# so we should find $HASH5 as the first bad commit
+HASH5=
+test_expect_success 'bisect dunno: add line and then a new test' '
+ add_line_into_file "5: Another new line." hello &&
+ HASH5=$(git rev-parse --verify HEAD) &&
+ git bisect start $HASH5 $HASH1 &&
+ git bisect dunno &&
+ git bisect good > my_bisect_log.txt &&
+ grep "$HASH5 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
#
#
test_done
--
1.5.3.4.209.g5612
^ permalink raw reply related
* [PATCH 2/3] Bisect: fix some white spaces and empty lines breakages.
From: Christian Couder @ 2007-10-09 4:25 UTC (permalink / raw)
To: Junio Hamano, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 17 ++++++++---------
1 files changed, 8 insertions(+), 9 deletions(-)
This is a new patch where I put some trivial
stuff to avoid distracting Dscho.
diff --git a/git-bisect.sh b/git-bisect.sh
index 388887a..436ccf6 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -64,7 +64,7 @@ bisect_start() {
branch=`cat "$GIT_DIR/head-name"`
else
branch=master
- fi
+ fi
git checkout $branch || exit
;;
refs/heads/*)
@@ -95,11 +95,11 @@ bisect_start() {
arg="$1"
case "$arg" in
--)
- shift
+ shift
break
;;
*)
- rev=$(git rev-parse --verify "$arg^{commit}" 2>/dev/null) || {
+ rev=$(git rev-parse --verify "$arg^{commit}" 2>/dev/null) || {
test $has_double_dash -eq 1 &&
die "'$arg' does not appear to be a valid revision"
break
@@ -110,10 +110,10 @@ bisect_start() {
else
bisect_write_good "$rev"
fi
- shift
+ shift
;;
esac
- done
+ done
sq "$@" >"$GIT_DIR/BISECT_NAMES"
echo "git-bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG"
@@ -143,7 +143,7 @@ bisect_write_bad() {
bisect_good() {
bisect_autostart
- case "$#" in
+ case "$#" in
0) revs=$(git rev-parse --verify HEAD) || exit ;;
*) revs=$(git rev-parse --revs-only --no-flags "$@") &&
test '' != "$revs" || die "Bad rev input: $@" ;;
@@ -153,7 +153,6 @@ bisect_good() {
rev=$(git rev-parse --verify "$rev^{commit}") || exit
bisect_write_good "$rev"
echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
-
done
bisect_auto_next
}
@@ -207,7 +206,7 @@ bisect_auto_next() {
}
bisect_next() {
- case "$#" in 0) ;; *) usage ;; esac
+ case "$#" in 0) ;; *) usage ;; esac
bisect_autostart
bisect_next_check good
@@ -255,7 +254,7 @@ bisect_reset() {
exit 1
}
branch="$1" ;;
- *)
+ *)
usage ;;
esac
if git checkout "$branch"; then
--
1.5.3.4.209.g5612
^ permalink raw reply related
* [PATCH 1/3] rev-list: implement --bisect-all
From: Christian Couder @ 2007-10-09 4:25 UTC (permalink / raw)
To: Junio Hamano, Johannes Schindelin; +Cc: git
This is Junio's patch with some stuff to make --bisect-all
compatible with --bisect-vars.
This option makes it possible to see all the potential
bisection points. The best ones are displayed first.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-rev-list.c | 100 ++++++++++++++++++++++++++++++++++++++++++++-------
log-tree.c | 2 +-
log-tree.h | 1 +
3 files changed, 88 insertions(+), 15 deletions(-)
There is a a small change in the second hunk
compared to the patch I sent yesterday.
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 33726b8..4439332 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -9,6 +9,7 @@
#include "revision.h"
#include "list-objects.h"
#include "builtin.h"
+#include "log-tree.h"
/* bits #0-15 in revision.h */
@@ -38,7 +39,8 @@ static const char rev_list_usage[] =
" --left-right\n"
" special purpose:\n"
" --bisect\n"
-" --bisect-vars"
+" --bisect-vars\n"
+" --bisect-all"
;
static struct rev_info revs;
@@ -74,6 +76,7 @@ static void show_commit(struct commit *commit)
parents = parents->next;
}
}
+ show_decorations(commit);
if (revs.commit_format == CMIT_FMT_ONELINE)
putchar(' ');
else
@@ -278,6 +281,57 @@ static struct commit_list *best_bisection(struct commit_list *list, int nr)
return best;
}
+struct commit_dist {
+ struct commit *commit;
+ int distance;
+};
+
+static int compare_commit_dist(const void *a_, const void *b_)
+{
+ struct commit_dist *a, *b;
+
+ a = (struct commit_dist *)a_;
+ b = (struct commit_dist *)b_;
+ if (a->distance != b->distance)
+ return b->distance - a->distance; /* desc sort */
+ return hashcmp(a->commit->object.sha1, b->commit->object.sha1);
+}
+
+static struct commit_list *best_bisection_sorted(struct commit_list *list, int nr)
+{
+ struct commit_list *p;
+ struct commit_dist *array = xcalloc(nr, sizeof(*array));
+ int cnt, i;
+
+ for (p = list, cnt = 0; p; p = p->next) {
+ int distance;
+ unsigned flags = p->item->object.flags;
+
+ if (revs.prune_fn && !(flags & TREECHANGE))
+ continue;
+ distance = weight(p);
+ if (nr - distance < distance)
+ distance = nr - distance;
+ array[cnt].commit = p->item;
+ array[cnt].distance = distance;
+ cnt++;
+ }
+ qsort(array, cnt, sizeof(*array), compare_commit_dist);
+ for (p = list, i = 0; i < cnt; i++) {
+ struct name_decoration *r = xmalloc(sizeof(*r) + 100);
+ struct object *obj = &(array[i].commit->object);
+
+ sprintf(r->name, "dist=%d", array[i].distance);
+ r->next = add_decoration(&name_decoration, obj, r);
+ p->item = array[i].commit;
+ p = p->next;
+ }
+ if (p)
+ p->next = NULL;
+ free(array);
+ return list;
+}
+
/*
* zero or positive weight is the number of interesting commits it can
* reach, including itself. Especially, weight = 0 means it does not
@@ -292,7 +346,8 @@ static struct commit_list *best_bisection(struct commit_list *list, int nr)
* or positive distance.
*/
static struct commit_list *do_find_bisection(struct commit_list *list,
- int nr, int *weights)
+ int nr, int *weights,
+ int find_all)
{
int n, counted;
struct commit_list *p;
@@ -351,7 +406,7 @@ static struct commit_list *do_find_bisection(struct commit_list *list,
clear_distance(list);
/* Does it happen to be at exactly half-way? */
- if (halfway(p, nr))
+ if (!find_all && halfway(p, nr))
return p;
counted++;
}
@@ -389,19 +444,22 @@ static struct commit_list *do_find_bisection(struct commit_list *list,
weight_set(p, weight(q));
/* Does it happen to be at exactly half-way? */
- if (halfway(p, nr))
+ if (!find_all && halfway(p, nr))
return p;
}
}
show_list("bisection 2 counted all", counted, nr, list);
- /* Then find the best one */
- return best_bisection(list, nr);
+ if (!find_all)
+ return best_bisection(list, nr);
+ else
+ return best_bisection_sorted(list, nr);
}
static struct commit_list *find_bisection(struct commit_list *list,
- int *reaches, int *all)
+ int *reaches, int *all,
+ int find_all)
{
int nr, on_list;
struct commit_list *p, *best, *next, *last;
@@ -434,14 +492,13 @@ static struct commit_list *find_bisection(struct commit_list *list,
weights = xcalloc(on_list, sizeof(*weights));
/* Do the real work of finding bisection commit. */
- best = do_find_bisection(list, nr, weights);
-
+ best = do_find_bisection(list, nr, weights, find_all);
if (best) {
- best->next = NULL;
+ if (!find_all)
+ best->next = NULL;
*reaches = weight(best);
}
free(weights);
-
return best;
}
@@ -468,6 +525,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
int i;
int read_from_stdin = 0;
int bisect_show_vars = 0;
+ int bisect_find_all = 0;
git_config(git_default_config);
init_revisions(&revs, prefix);
@@ -490,6 +548,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
bisect_list = 1;
continue;
}
+ if (!strcmp(arg, "--bisect-all")) {
+ bisect_list = 1;
+ bisect_find_all = 1;
+ continue;
+ }
if (!strcmp(arg, "--bisect-vars")) {
bisect_list = 1;
bisect_show_vars = 1;
@@ -536,9 +599,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
if (bisect_list) {
int reaches = reaches, all = all;
- revs.commits = find_bisection(revs.commits, &reaches, &all);
+ revs.commits = find_bisection(revs.commits, &reaches, &all,
+ bisect_find_all);
if (bisect_show_vars) {
int cnt;
+ char hex[41];
if (!revs.commits)
return 1;
/*
@@ -550,15 +615,22 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
* A bisect set of size N has (N-1) commits further
* to test, as we already know one bad one.
*/
- cnt = all-reaches;
+ cnt = all - reaches;
if (cnt < reaches)
cnt = reaches;
+ strcpy(hex, sha1_to_hex(revs.commits->item->object.sha1));
+
+ if (bisect_find_all) {
+ traverse_commit_list(&revs, show_commit, show_object);
+ printf("------\n");
+ }
+
printf("bisect_rev=%s\n"
"bisect_nr=%d\n"
"bisect_good=%d\n"
"bisect_bad=%d\n"
"bisect_all=%d\n",
- sha1_to_hex(revs.commits->item->object.sha1),
+ hex,
cnt - 1,
all - reaches - 1,
reaches - 1,
diff --git a/log-tree.c b/log-tree.c
index 2319154..f766758 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -15,7 +15,7 @@ static void show_parents(struct commit *commit, int abbrev)
}
}
-static void show_decorations(struct commit *commit)
+void show_decorations(struct commit *commit)
{
const char *prefix;
struct name_decoration *decoration;
diff --git a/log-tree.h b/log-tree.h
index e82b56a..b33f7cd 100644
--- a/log-tree.h
+++ b/log-tree.h
@@ -12,5 +12,6 @@ int log_tree_diff_flush(struct rev_info *);
int log_tree_commit(struct rev_info *, struct commit *);
int log_tree_opt_parse(struct rev_info *, const char **, int);
void show_log(struct rev_info *opt, const char *sep);
+void show_decorations(struct commit *commit);
#endif
--
1.5.3.4.209.g5612
^ permalink raw reply related
* Re: bug? - git-checkout treeish paths ignores deleted files
From: Mark Levedahl @ 2007-10-09 3:39 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <3B0685AB-0725-4473-8AE6-359F93851C10@wincent.com>
Wincent Colaiuta wrote:
> El 9/10/2007, a las 2:58, Mark Levedahl escribió:
>
>> Shouldn't "git checkout topic path" make the directory tree rooted
>> at path identical to what is on branch topic? It doesn't.
>>
>>
>
> No, the behaviour is correct.
>
> - first you removed the file on the topic branch; at the same time you
> removed it from your working tree
> - then you switched back to the master branch and so the file was
> added back to your working tree
> - then you switched back to the topic branch, and seeing as the file
> "a" is not being tracked in the topic branch Git doesn't touch it
>
> In general, Git only meddles with stuff that you've told it to track.
> This is actually a good thing in most cases because it makes some
> workflows involving dirty trees or trees with untracked content
> somewhat more convenient.
>
> Cheers,
> Wincent
>
>
I'm not convinced...
"git checkout branch dir" should make dir have the same value it would
get if I just did "git checkout branch". The latter command will ignore
files only if they are untracked in *both* HEAD and branch. I fail to
see why the path-limited version of git-checkout should give a different
result on the part it is asked to affect than the non-path limited
version. This is very inconsistent and I'm having a hard time
understanding what workflow it will help.
Mark
^ permalink raw reply
* Re: bug? - git-checkout treeish paths ignores deleted files
From: Wincent Colaiuta @ 2007-10-09 1:52 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Git Mailing List
In-Reply-To: <470AD21E.6070906@gmail.com>
El 9/10/2007, a las 2:58, Mark Levedahl escribió:
> Shouldn't "git checkout topic path" make the directory tree
> rooted at path identical to what is on branch topic? It doesn't.
>
> Try this:
>
> mkdir test
> cd test
> git init
> touch a b
> git add a b
> git commit -m 'base'
> git checkout -b topic
> git rm a
> git commit -m 'removed a'
> git checkout master
> git checkout topic .
>
> ...and the result is...
> ls
> a b
>
> instead of
> b
No, the behaviour is correct.
- first you removed the file on the topic branch; at the same time
you removed it from your working tree
- then you switched back to the master branch and so the file was
added back to your working tree
- then you switched back to the topic branch, and seeing as the file
"a" is not being tracked in the topic branch Git doesn't touch it
In general, Git only meddles with stuff that you've told it to track.
This is actually a good thing in most cases because it makes some
workflows involving dirty trees or trees with untracked content
somewhat more convenient.
Cheers,
Wincent
^ permalink raw reply
* Re: confused about a conflict during octopus merging
From: Linus Torvalds @ 2007-10-09 1:21 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20071009003156.GA30498@lapse.madduck.net>
On Tue, 9 Oct 2007, martin f krafft wrote:
>
> I am a little confused why the following yields a conflict:
Octopus merges are special. Don't use them unless you really know what
you're doing. And generally not even then ;)
> $ git merge master second
> Trying simple merge with bb5f1b4f3a8cbfcbc9dbc97cc823f3ca05db2db1
> Trying simple merge with 7370737ff3aa6540a425db015e194766d2cbda2e
> Simple merge did not work, trying automatic merge.
> Added d in both, but differently.
> error: Could not read .merge_file_mCwa4W
> ERROR: Merge conflict in d
> fatal: merge program failed
> Automatic merge failed; fix conflicts and then commit the result.
>
> I don't understand why these conflict. I mean, sure, it makes sense:
> after merging master, file d is at d2. Now when merging second, it
> tries to replace d by its ancestor, d1.
Right. It makes total sense, because an octopus merge is simply always
going to create a whole new merge commit that goes through the sources one
by one, and merges them in - and if you do that, then you get a conflict
in "d".
> What I don't understand is why Git does not understand that commit
> d is part of the path of arriving at d2, so when 'second' is merged,
> Git *should* really see that the change to file d in 'second' (d1)
> is an ancestor of the already present d2 commit, and *not* conflict.
>
> What am I misunderstanding here?
Octopus merges do *not* fast-forward. Maybe they should. But they don't.
So when the octopus merge starts merging in "master" into the "merger"
branch, it will *not* just fast-forward the branch to "master". Instead,
if will generate a new tree that is basically the merged state: but that
new tree is *not* the same as the master commit, it's literally a merge of
the two branches - which in practice means that it has the same *content*
as master, but it's not at that commit.
So that first stage of the octopus merge has gone fine, but it didn't
really do what you expected.
And so now we have a half-way done octopus merge, with the first branch
added. Now it merges in the second branch ("second"), and it *still* has
the merge base being the original merge base, namely "merger".
And from that standpoint, it really *is* a conflict.
I do think that
- octopus merges should probably refuse to happen when a branch isn't a
"merge" at all, but a fast-forward.
*or*
- we should make octopus-merges smarter, and for each branch that is a
fast-forward, it really just fast-forwards.
but I don't think the current behaviour is "wrong", it's just not what you
expected.
If you think of octopus merges as a really stupid thing where git will
mindlessly do a three-way merge based on the *current* state with all the
branches you name, then you get the current octopus merge. You just
expected it to be smarter than it is, probably because you compare it to
the *real* merge.
Linus
^ permalink raw reply
* bug? - git-checkout treeish paths ignores deleted files
From: Mark Levedahl @ 2007-10-09 0:58 UTC (permalink / raw)
To: Git Mailing List
Shouldn't "git checkout topic path" make the directory tree rooted at
path identical to what is on branch topic? It doesn't.
Try this:
mkdir test
cd test
git init
touch a b
git add a b
git commit -m 'base'
git checkout -b topic
git rm a
git commit -m 'removed a'
git checkout master
git checkout topic .
...and the result is...
ls
a b
instead of
b
Mark
^ permalink raw reply
* Re: [TIG PATCH] Add missing = for comparison in obsolete actions check.
From: Jonas Fonseca @ 2007-10-09 0:53 UTC (permalink / raw)
To: James Bowes; +Cc: git
In-Reply-To: <20071008173034.GA27292@crux.toronto.redhat.com>
James Bowes <jbowes@dangerouslyinc.com> wrote Mon, Oct 08, 2007:
> Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
> ---
> tig.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/tig.c b/tig.c
> index 933d083..30c505b 100644
> --- a/tig.c
> +++ b/tig.c
> @@ -1184,7 +1184,7 @@ option_bind_command(int argc, char *argv[])
> }
>
> request = get_request(argv[2]);
> - if (request = REQ_NONE) {
> + if (request == REQ_NONE) {
> const char *obsolete[] = { "cherry-pick" };
> size_t namelen = strlen(argv[2]);
> int i;
Oops, thanks. I should readd -Wall to CFLAGS in my config.make file.
--
Jonas Fonseca
^ permalink raw reply
* confused about a conflict during octopus merging
From: martin f krafft @ 2007-10-09 0:31 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]
Dear list,
I am a little confused why the following yields a conflict:
$ git init
$ touch a; git add a; git commit -ma
Created initial commit 0ba90cc: a
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a
# create merger branch for later
$ git branch merger
# create a file
$ date > d; git add d; git commit -md1
Created commit 89d22eb: d
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 d
# branch off a second branch and populate it
$ git checkout -b second
Switched to a new branch "second"
$ touch b; git add b; git commit -mb
Created commit 7370737: b
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b
# modify file changed in previous commit
$ git checkout master
Switched to branch "master"
$ date >> d; git add d; git commit -md2
Created commit bb5f1b4: d2
1 files changed, 1 insertions(+), 1 deletions(-)
Now the tree structure is
x -- master: d2
| x -- second: b
|/
x d1
|
x -- merger: a
# now octopus-merge master+second into merger
$ git checkout merger
Switched to branch "merger"
$ git merge master second
Trying simple merge with bb5f1b4f3a8cbfcbc9dbc97cc823f3ca05db2db1
Trying simple merge with 7370737ff3aa6540a425db015e194766d2cbda2e
Simple merge did not work, trying automatic merge.
Added d in both, but differently.
error: Could not read .merge_file_mCwa4W
ERROR: Merge conflict in d
fatal: merge program failed
Automatic merge failed; fix conflicts and then commit the result.
I don't understand why these conflict. I mean, sure, it makes sense:
after merging master, file d is at d2. Now when merging second, it
tries to replace d by its ancestor, d1.
What I don't understand is why Git does not understand that commit
d is part of the path of arriving at d2, so when 'second' is merged,
Git *should* really see that the change to file d in 'second' (d1)
is an ancestor of the already present d2 commit, and *not* conflict.
What am I misunderstanding here?
Thanks,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"distrust all those who love you extremely
upon a very slight acquaintance and without any visible reason."
-- lord chesterfield
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Theodore Tso @ 2007-10-08 22:01 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <20071008215729.GC31713@thunk.org>
On Mon, Oct 08, 2007 at 05:57:29PM -0400, Theodore Tso wrote:
> This patch doesn't work the config file doesn't specify an explicit
> mergetool via merge.tool. The reason for that is this loop:
Err, let me try that again. "This patch doesn't work IF the config
file doesn't specify an explicit > mergetool via merge.tool."
Sorry about the missing conjuction; the sentence doesn't make much
sense without it...
- Ted
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Frank Lichtenheld @ 2007-10-08 22:00 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Theodore Ts'o, git
In-Reply-To: <11918785613855-git-send-email-prohaska@zib.de>
On Mon, Oct 08, 2007 at 11:22:40PM +0200, Steffen Prohaska wrote:
> This commit adds a mechanism to provide absolute paths to the
> commands called by 'git mergetool'. A path can be specified
> in the configuation variable merge.<toolname>path.
Why not merge.<toolname>.path?
This would it make easy to introduce new variables of the form
merge.<toolname>.<var> later if needed. I also think it is more
consistent with names of existing configuration variables.
(think branch.<name>.<var> or remote.<name>.<var>)
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Theodore Tso @ 2007-10-08 21:57 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11918785613855-git-send-email-prohaska@zib.de>
On Mon, Oct 08, 2007 at 11:22:40PM +0200, Steffen Prohaska wrote:
> This commit adds a mechanism to provide absolute paths to the
> commands called by 'git mergetool'. A path can be specified
> in the configuation variable merge.<toolname>path.
This patch doesn't work the config file doesn't specify an explicit
mergetool via merge.tool. The reason for that is this loop:
for i in $merge_tool_candidates; do
if test $i = emerge ; then
cmd=emacs
else
cmd=$i
fi
if type $cmd > /dev/null 2>&1; then
merge_tool=$i
break
fi
done
is only checking to see if $cmd is in the path; it's not looking up
the merge.<toolname>path variable in this loop.
I guess the other question is whether we would be better off simply
telling the user to specify an absolute pathname in merge.tool, and
then having git-mergetool strip off the directory path via basename,
and then on window systems, stripping off the .EXE or .COM suffix, and
then downcasing the name so that something like "C:\Program
Files\ECMerge\ECMerge.exe" gets translated to "ecmerge". Would I be
right in guessing that the reason why you used merge.<toolname>path
approach was to avoid this messy headache?
- Ted
^ 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