On Fri, Jan 25, 2013 at 5:17 PM, Sven Strickroth
wrote:
> TortoiseGitMerge now separates cli parameter key-values by space instead
> of colons as TortoiseSVN TortoiseMerge does and supports filesnames
> with spaces in it this way now.
These patches look correct (I do not have the tool to test)
bu
On Fri, Jan 25, 2013 at 4:24 PM, Junio C Hamano wrote:
> Applying this one on top of 1/7 thru 5/7 and 7/7 seems to break
> t7610 rather badly.
I just sent a replacement for the vim/symlink issue stuff.
I tried to keep the patch small. John, can you rebase this
patch on top of it?
> --- >8 -
On 15.01.13 21:38, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> What do we think about something like this for fishing for which:
>>
>> --- a/t/test-lib.sh
>> +++ b/t/test-lib.sh
>> @@ -644,6 +644,10 @@ yes () {
>> :
>> done
>> }
>> +which () {
>> + ech
Remove the exceptions for "vim" and "defaults" in the mergetool library
so that every filename in mergetools/ matches 1:1 with the name of a
valid built-in tool.
Make common functions available in $MERGE_TOOLS_DIR/include/.
Signed-off-by: David Aguilar
---
This should make things ok on platforms
On Sat, Jan 26, 2013 at 2:04 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> ---
>> builtin/branch.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> Forgot to sign-off?
Yes
> Is this a real problem?
Yes. My thoughts yesterday when I happened to type "git branc
tortoisegitmerge and filesnames with space
The tortoisemerge mergetool does not work with filenames which have
a space in it. Fixing this required changes in git and also in
TortoiseGitMerge; see https://github.com/msysgit/msysgit/issues/57.
TortoiseGitMerge now separates cli parameter key-values
The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git and prevent confusion with the TortoiseSVN TortoiseMerge
version.
Signed-off-by: Sven Strickroth
---
mergetools/tortoisemerge | 11 +++
The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git and prevent confusion with the TortoiseSVN TortoiseMerge
version.
Signed-off-by: Sven Strickroth
---
mergetools/tortoisemerge | 11 +++
Throughout git, it is assumed that the WIN32 preprocessor symbol is
defined on native Windows setups (mingw and msvc) and not on Cygwin.
On Cygwin, most of the time git can pretend this is just another Unix
machine, and Windows-specific magic is generally counterproductive.
Unfortunately Cygwin *d
Am 25.01.2013 19:28 schrieb Junio C Hamano:> Sven Strickroth
writes:
>
>> TortoiseGitMerge and filenames with spaces
>
> ??? ECANNOTPARSE.
>
> ... ah, wait. Is this a broken-off tail of your subject line?
Yes.
>> +touch "$BACKUP"
>> +basename="$(basename "$merge_tool_pa
Firefox on Windows by default is placed in "C:\Program Files\Mozilla Firefox"
folder, i.e. its path contains spaces. Before running this browser
"git-web--browse"
tests version of Firefox to decide whether to use "-new-tab" option or not.
Quote browser path to avoid error during this test.
Signe
Use "write_script" helper as suggested by Junio C Hamano.
Also, replace `pwd` with $(pwd) call convention.
Suggested-by: Junio C Hamano
Signed-off-by: Alexey Shumkin
---
t/t9901-git-web--browse.sh | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/t/t9901-git-web--browse.
Reroll patch after all suggestions
Alexey Shumkin (2):
t9901-git-web--browse.sh: Use "write_script" helper
git-web--browser: avoid errors in terminal when running Firefox on
Windows
git-web--browse.sh | 2 +-
t/t9901-git-web--browse.sh | 59 ++
On 01/25/2013 05:11 PM, Junio C Hamano wrote:
> Mark Levedahl writes:
>
>> Cygwin and Windows should be treated as completely separate platforms:
>> if __CYGWIN__ is defined, do one thing, if not, go ahead and check
>> WIN32, but the WIN32 macro should never be tested once we know the
>> platform
Applying this one on top of 1/7 thru 5/7 and 7/7 seems to break
t7610 rather badly.
--- >8 -- >8 -- >8 -- >8 -- >8 -- >8 ---
...
ok 1 - setup
expecting success:
git checkout -b test1 branch1 &&
git submodule update -N &&
test_must_fail git merge master >/dev/null 2
What's cooking in git.git (Jan 2013, #09; Fri, 25)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last
Mark Levedahl writes:
> Cygwin and Windows should be treated as completely separate platforms:
> if __CYGWIN__ is defined, do one thing, if not, go ahead and check
> WIN32, but the WIN32 macro should never be tested once we know the
> platform is CYGWIN - these really are different platforms (if
On 01/22/2013 01:31 PM, Ramsay Jones wrote:
include order. ;-) As I have mentioned here before, the claim that
"WIN32 is not defined on cygwin" is simply nonsense - it depends on
if/when certain header files are included. For example, *as soon as*
you include (and, I suspect, many other win32
2013/1/26 Jeff King :
> On Fri, Jan 25, 2013 at 06:44:13PM +0400, Alexey Shumkin wrote:
>
>> test_web_browse () {
>> - # browser=$1 url=$2
>> + # browser=$1 url=$2 sleep_timeout=$3
>> + sleep_timeout="$3"
>> git web--browse --browser="$1" "$2" >actual &&
>> + # if $3 is set
>
Running make inside contrib/remote-helpers failes in "test-lint-duplicates"
This was because the regexp to check for duplicate numbers strips everything
after the first "-" in the filename, including the prefix.
As a result, 2 pathnames like
"/contrib/remote-helpers/test-bzr.sh" and
"/con
Running make inside contrib/remote-helpers failes in "test-lint-duplicates"
This was because the regexp to check for duplicate numbers strips everything
after the first "-" in the filename, including the prefix.
As a result, 2 pathnames like
"/contrib/remote-helpers/test-bzr.sh" and
"/con
On Fri, Jan 25, 2013 at 06:47:00PM +0100, Krzysztof Mazur wrote:
> On Fri, Jan 25, 2013 at 07:28:54PM +0400, Alexey Shumkin wrote:
> > "git format-patch --attach/--inline" generates multi-part messages.
> > Every part of such messages can contain non-ASCII characters with its own
> > "Content-Type
On Fri, Jan 25, 2013 at 10:46:48AM -0800, Junio C Hamano wrote:
> Will queue this one, to be merged to 'maint' and 'master'.
>
> -- >8 --
> From: Jonathan Nieder
> Date: Thu, 24 Jan 2013 15:21:46 -0800
> Subject: [PATCH] ident: do not drop username when reading from /etc/mailname
Thanks, looks
On Fri, Jan 25, 2013 at 10:34:56AM -0800, Junio C Hamano wrote:
> >> Not so quick, though. The lower level "read from help -a" is only
> >> run once and its output kept in a two-level cache hierarchy; we need
> >> to reset both.
> >
> > Ugh, I didn't even think about that.
> >
> > I wonder if it
On Fri, Jan 25, 2013 at 06:44:13PM +0400, Alexey Shumkin wrote:
> test_web_browse () {
> - # browser=$1 url=$2
> + # browser=$1 url=$2 sleep_timeout=$3
> + sleep_timeout="$3"
> git web--browse --browser="$1" "$2" >actual &&
> + # if $3 is set
> + # as far as Firefox is r
This will make it easier to use setup_tool in places where we expect
that the selected tool will not support the current mode.
Signed-off-by: John Keeping
---
git-mergetool--lib.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--li
guess_merge_tool calls translate_merge_tool_path in order to get the
correct name of the tool to check whether it can be found on the user's
system. But this function is designed to be overridden by tool
scriptlets so it does nothing if the relevant scriptlet has not been
sourced.
Fix this by cal
On Fri, Jan 25, 2013 at 01:47:59PM -0800, Junio C Hamano wrote:
> John Keeping writes:
> > With the patch above, the block of code at the top becomes:
> >
> > test "$tool" = defaults && continue
> >
> > setup_tool "$tool" 2>/dev/null || continue
> > merge_tool_path=$(translate_merge_to
John Keeping writes:
>> > It doesn't - the "|| continue" is to catch errors from setup_tool.
>>
>> Ugh.
>
> Is that targeted at my suggestion at the top of this email or calling
> exit in setup_tool?
At the fact that you had to go a convoluted route because you cannot
just run setup_tool in sub
On Fri, Jan 25, 2013 at 12:56:37PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
> > On Fri, Jan 25, 2013 at 12:16:42PM -0800, Junio C Hamano wrote:
> >> John Keeping writes:
> >>
> >> > Actually, can we just change all of the above part of the loop to:
> >> >
> >> > test "$tool" = def
Both patches look simple enough. Pete, what do you think?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
John Keeping writes:
> On Fri, Jan 25, 2013 at 12:16:42PM -0800, Junio C Hamano wrote:
>> John Keeping writes:
>>
>> > Actually, can we just change all of the above part of the loop to:
>> >
>> >test "$tool" = defaults && continue
>> >
>> >merge_tool_path=$(
>> >setup_tool "
On Fri, Jan 25, 2013 at 12:16:42PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
> > Actually, can we just change all of the above part of the loop to:
> >
> > test "$tool" = defaults && continue
> >
> > merge_tool_path=$(
> > setup_tool "$tool" >/dev/null 2>&1 &&
> >
Offered for consideration.
These two patches allow git-p4 to run on python 2.4 which is shipped on
RHEL 5.X. The changes are minor and unintrusive in my opinion, but please
feel free to reject one or both of them for any reason (in which case the
version check at the top of git-p4.py should be up
Python 2.4 lacks the following features:
subprocess.check_call
struct.pack_into
Take a cue from 460d1026 and provide an implementation of the
CalledProcessError exception. Then replace the calls to
subproccess.check_call with calls to subprocess.call that check the return
status and raise
Python 2.5 and older do not accept None as the first argument to
translate() and complain with:
TypeError: expected a character buffer object
Satisfy this older python by calling maketrans() to generate an empty
translation table and supplying that to translate().
This allows git-p4 to be use
On Wed, Jan 23, 2013 at 12:36 PM, Junio C Hamano wrote:
> Sverre Rabbelier writes:
>
>> On Wed, Jan 23, 2013 at 11:47 AM, John Keeping wrote:
When did we last revisit what minimal python version we are ok with
requiring?
>>>
>>> I was wondering if people would weigh in discussing that
John Keeping writes:
> Actually, can we just change all of the above part of the loop to:
>
> test "$tool" = defaults && continue
>
> merge_tool_path=$(
> setup_tool "$tool" >/dev/null 2>&1 &&
> translate_merge_tool_path "$tool"
> ) || continue
Meani
On Fri, Jan 25, 2013 at 07:54:46PM +, John Keeping wrote:
> On Fri, Jan 25, 2013 at 01:43:54AM -0800, David Aguilar wrote:
> > Check the can_diff and can_merge functions before deciding whether to
> > add the tool to the available/unavailable lists. This makes --tool-help
> > context-
> > sen
John Keeping writes:
>> +tool="$(basename "$i")"
>
> Quotes are unnecessary here.
Yeah, the outer quotes aren't needed; the inner ones are.
>> +if test "$tool" = "defaults"
>> +then
>> +continue
>> +elif merge_mode && ! can_mer
On Fri, Jan 25, 2013 at 01:43:54AM -0800, David Aguilar wrote:
> Check the can_diff and can_merge functions before deciding whether to
> add the tool to the available/unavailable lists. This makes --tool-help
> context-
> sensitive so that "git mergetool --tool-help" displays merge tools only
> a
Alexey Shumkin writes:
> Firefox on Windows by default is placed in "C:\Program Files\Mozilla Firefox"
> folder, i.e. its path contains spaces. Before running this browser
> "git-web--browse"
> tests version of Firefox to decide whether to use "-new-tab" option or not.
>
> Quote browser path to
Matthieu Moy writes:
> Most git commands that can be used with our without a filepattern are
> tree-wide by default, the filepattern being used to restrict their scope.
> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.
>
> The inconsistancy of 'git add -u' and 'git a
David Aguilar writes:
> On Fri, Jan 25, 2013 at 2:38 AM, John Keeping wrote:
>> On Fri, Jan 25, 2013 at 01:43:53AM -0800, David Aguilar wrote:
>>> "git difftool --tool-help" and "git mergetool --tool-help" incorreclty
>>> list "vim" as being an unavailable tool. This is because they attempt
>>>
Nguyễn Thái Ngọc Duy writes:
> ---
> builtin/branch.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
Forgot to sign-off?
Is this a real problem?
I do not see it particularly wrong to succeed after deleting 0 or
more given branch names.
>
> diff --git a/builtin/branch.c b/built
Duy Nguyen writes:
> Even
> when cache-tree is not involved, I do not want the index to point to
> an non-existing SHA-1 ("git diff --cached" may fail next time, for
> example).
I think we have tests that explicitly add SHA-1 that names an object
that does not exist to the index and check f
Jeff King writes:
> (with a proper commit message, of course).
Will queue this one, to be merged to 'maint' and 'master'.
-- >8 --
From: Jonathan Nieder
Date: Thu, 24 Jan 2013 15:21:46 -0800
Subject: [PATCH] ident: do not drop username when reading from /etc/mailname
An earlier conversion fro
Jeff King writes:
> On Thu, Jan 24, 2013 at 08:19:30PM -0800, Junio C Hamano wrote:
>
>> > Ahh, ok, we show one element per line and just make sure "bundle"
>> > is there, and we do not care what other buns appear in the output.
>> >
>> Not so quick, though. The lower level "read from help -a" i
Sven Strickroth writes:
> TortoiseGitMerge and filenames with spaces
??? ECANNOTPARSE.
... ah, wait. Is this a broken-off tail of your subject line?
It may be a sign that you are doing too many unrelated things in a
single patch when your subject does not fit on a single line.
Perhaps this
Alexey Shumkin writes:
> This function is used to determine "broken" (non-ASCII) headers (to be encode
> them)
> The problem is if "Subject" is not broken, but message body contains
> non-ASCII chars,
> subject is marked as broken and encoded again.
I think that is not a "problem" but is a mer
Carsten Fuchs writes:
> Hi all,
>
> in my repo, I'm doing this:
>
>> $ git status
>> # On branch master
>> # Your branch is behind 'origin/master' by 2 commits, and can be
>> fast-forwarded.
>> #
>> # Untracked files:
>> # (use "git add ..." to include in what will be committed)
>> #
>> #
On Fri, Jan 25, 2013 at 07:28:54PM +0400, Alexey Shumkin wrote:
> "git format-patch --attach/--inline" generates multi-part messages.
> Every part of such messages can contain non-ASCII characters with its own
> "Content-Type" and "Content-Transfer-Encoding" headers.
> But git-send-mail script inte
Jonathon Mah writes:
> Just to note, the proposals so far don't prevent a "smart-ass"
> function from freeing the buffer when it's called underneath the
> use/release scope, as in:
>
> with_commit_buffer(commit); {
> fn1_needing_buffer(commit);
> walk_rev_tree_or_something();
>
Let's try to involve Krzysztof Mazur
who have met the similar problem recently
(according to this thread
http://thread.gmane.org/gmane.comp.version-control.git/208297/focus=208310)
I recitate myself:
>Well, as I understand "current" algorithm:
>1. It assumes that file is one-part email message
>2
"git format-patch --attach/--inline" generates multi-part messages.
Every part of such messages can contain non-ASCII characters with its own
"Content-Type" and "Content-Transfer-Encoding" headers.
But git-send-mail script interprets a patch-file as one-part message
and does not recognize multi-par
> Alexey Shumkin writes:
>
> >> Why do we want "whatever_7" variables and use "cut -c1-7" to
> >> produce them? Is "7" something we care deeply about?
> >>
> >> I think what we care a lot more than "7" that happens to be the
> >> current default value is to make sure that, if we ever update the
Alexey Shumkin writes:
>> Why do we want "whatever_7" variables and use "cut -c1-7" to produce
>> them? Is "7" something we care deeply about?
>>
>> I think what we care a lot more than "7" that happens to be the
>> current default value is to make sure that, if we ever update the
>> default ab
Firefox on Windows by default is placed in "C:\Program Files\Mozilla Firefox"
folder, i.e. its path contains spaces. Before running this browser
"git-web--browse"
tests version of Firefox to decide whether to use "-new-tab" option or not.
Quote browser path to avoid error during this test.
Signe
Cc-ing the Git list again.
Mario Michael Krell writes:
> I am sorry for being so unspecific. I had problems finding your
> mentioned website and quickly went through the "getting started"
> tutorial and found the mentioned command at:
>
> http://git-scm.com/book/en/Getting-Started-Installing-Git
On Fri, 25 Jan 2013 14:50:24 +0100
Mario Michael Krell wrote:
> In your documentation you say, that git should be installed on Unix
> using
>
> apt-get install git-core
Note that Ubuntu is not Unix.
> Unfortunately it tells the user, that this package is obsolete and
> "git" should be used ins
Mario Michael Krell writes:
> Dear git developers,
>
> In your documentation you say,
Which documentation?
> that git should be installed on Unix using
>
> apt-get install git-core
A quick grep shows that this is not the case in the documentation
provided with Git, and it's not what I see on
h
Dear git developers,
In your documentation you say, that git should be installed on Unix using
apt-get install git-core
Unfortunately it tells the user, that this package is obsolete and "git" should
be used instead. Is this an error in the package manager or in the website
documentation?
Gr
TortoiseGitMerge and filenames with spaces
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git, (uses spaces as cli parameter key-value separators)
and prevent confusion with the Tort
---
builtin/branch.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index ca61c5b..597b578 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -466,7 +466,7 @@ static void add_verbose_info(struct strbuf *out, struct
ref_item
While at there, do not stop user from editing a branch description
when the unrelated HEAD is detached.
---
builtin/branch.c | 12 ++--
t/t3200-branch.sh | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 50fcacc..ca61c5b 10
---
builtin/branch.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 873f624..50fcacc 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -837,9 +837,11 @@ int cmd_branch(int argc, const char **argv, const char
*prefix)
On Fri, Jan 25, 2013 at 11:34 AM, Sebastian Schuberth
wrote:
>> I thought Git did something sensible there like create a normal file?
>
> It does not. Also see my answer over here:
> http://stackoverflow.com/questions/11412028/git-not-storing-symlink-as-a-symlink-on-windows/11412341#11412341
Thi
> Why do we want "whatever_7" variables and use "cut -c1-7" to produce
> them? Is "7" something we care deeply about?
>
> I think what we care a lot more than "7" that happens to be the
> current default value is to make sure that, if we ever update the
> default abbreviation length to a larger v
Most git commands that can be used with our without a filepattern are
tree-wide by default, the filepattern being used to restrict their scope.
A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.
The inconsistancy of 'git add -u' and 'git add -A' are particularly
problema
On Fri, Jan 25, 2013 at 01:55:03AM -0800, David Aguilar wrote:
> list_merge_tool_candidates() has a bunch of other special cases
> for $EDITOR, $DISPLAY, $GNOME-something and such so I think
> we should keep using it only for the guess_merge_tool() path.
>
> I honestly want to remove list_merge_to
On Fri, Jan 25, 2013 at 2:38 AM, John Keeping wrote:
> On Fri, Jan 25, 2013 at 01:43:53AM -0800, David Aguilar wrote:
>> "git difftool --tool-help" and "git mergetool --tool-help" incorreclty
>> list "vim" as being an unavailable tool. This is because they attempt
>> to find a tool named accordin
On Fri, Jan 25, 2013 at 01:43:53AM -0800, David Aguilar wrote:
> "git difftool --tool-help" and "git mergetool --tool-help" incorreclty
> list "vim" as being an unavailable tool. This is because they attempt
> to find a tool named according to the mergetool scriptlet instead of the Git-
> recogniz
Hi all,
in my repo, I'm doing this:
> $ git status
> # On branch master
> # Your branch is behind 'origin/master' by 2 commits, and can be
fast-forwarded.
> #
> # Untracked files:
> # (use "git add ..." to include in what will be committed)
> #
> # obsolete/
> nothing added to commit bu
On Fri, Jan 25, 2013 at 2:23 AM, Sebastian Schuberth
wrote:
> On 2013/01/25 10:43 , David Aguilar wrote:
>
>> Remove the exception for "vim" and allow the scriptlets to be found
>> naturally by using symlinks to a single "vimdiff" scriptlet. This
>
>
> I guess that won't work on platforms where G
On 2013/01/25 10:43 , David Aguilar wrote:
Remove the exception for "vim" and allow the scriptlets to be found
naturally by using symlinks to a single "vimdiff" scriptlet. This
I guess that won't work on platforms where Git does not support
symlinks, then, like Windows. But Windows has (g)vi
On Fri, Jan 25, 2013 at 1:06 AM, Sven Strickroth
wrote:
> TortoiseGitMerge and filenames with spaces
>
> - The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
> (starting with 1.8.0) in order to make clear that this one has special
> support for git, (uses spaces as cli para
On Fri, Jan 25, 2013 at 1:19 AM, John Keeping wrote:
> On Thu, Jan 24, 2013 at 09:29:58PM -0800, David Aguilar wrote:
>> On Thu, Jan 24, 2013 at 11:55 AM, John Keeping wrote:
>> > The "--tool-help" option to git-difftool currently displays incorrect
>> > output since it uses the names of the file
On Thu, Jan 24, 2013 at 11:54:25PM -0800, David Aguilar wrote:
> On Thu, Jan 24, 2013 at 11:21 PM, Junio C Hamano wrote:
> > Is there a way for me to programatically tell what merge.tool and
> > diff.tool could be enabled for a particular source checkout of Git
> > regardless of what platform am I
From: John Keeping
TOOL_MODE is set at the top of git-mergetool.sh so there is no need to
set it again in show_tool_help. Removing this lets us re-use
show_tool_help in git-difftool.
Signed-off-by: John Keeping
Signed-off-by: David Aguilar
---
git-mergetool--lib.sh | 1 -
1 file changed, 1 d
From: John Keeping
This is the first step in unifying "git difftool --tool-help" and
"git mergetool --tool-help".
Signed-off-by: John Keeping
Signed-off-by: David Aguilar
---
git-mergetool--lib.sh | 37 +
git-mergetool.sh | 37 -
"git difftool --tool-help" and "git mergetool --tool-help" incorreclty
list "vim" as being an unavailable tool. This is because they attempt
to find a tool named according to the mergetool scriptlet instead of the Git-
recognized tool name.
vimdiff, vimdiff2, gvimdiff, and gvimdiff2 are all provi
Check the can_diff and can_merge functions before deciding whether to
add the tool to the available/unavailable lists. This makes --tool-help
context-
sensitive so that "git mergetool --tool-help" displays merge tools only
and "git difftool --tool-help" displays diff tools only.
Signed-off-by: D
From: John Keeping
The "--tool-help" option to git-difftool currently displays incorrect
output since it uses the names of the files in
"$GIT_EXEC_PATH/mergetools/" rather than the list of command names in
git-mergetool--lib.
Fix this by simply delegating the "--tool-help" argument to the
show_t
vimdiff and vimdiff2 differ only by their merge command so remove the
logic in the diff command since it's not actually needed.
Signed-off-by: David Aguilar
---
mergetools/vim | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/mergetools/vim b/mergetools/vim
index
From: John Keeping
When using show_tool_help from git-difftool we will want it to print
"git difftool" not "git mergetool" so use "git ${TOOL_MODE}tool".
Signed-off-by: John Keeping
Signed-off-by: David Aguilar
---
git-mergetool--lib.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions
I ran with John's idea and simplified a few more things so
that the --tool-help output shows the correct results.
My final commit is dependent on John's commits but the other two
could be picked up independently since they are general improvements.
This does add a few symlinks to the repo for the
On Thu, Jan 24, 2013 at 09:29:58PM -0800, David Aguilar wrote:
> On Thu, Jan 24, 2013 at 11:55 AM, John Keeping wrote:
> > The "--tool-help" option to git-difftool currently displays incorrect
> > output since it uses the names of the files in
> > "$GIT_EXEC_PATH/mergetools/" rather than the list
> Alexey Shumkin writes:
>
> > The expected SHA-1 digests are always available in variables. Use
> > them instead of hardcoding.
> >
> > Signed-off-by: Alexey Shumkin
> > ---
> > t/t6006-rev-list-format.sh | 130
> > + 1 file changed, 72
> > insertion
On Thu, Jan 24, 2013 at 10:55:57PM -0600, Chris Rorvick wrote:
> On Wed, Jan 23, 2013 at 3:12 PM, John Keeping wrote:
> > The existing script (git-cvsimport.perl) won't ever work with cvsps-3
> > since features it relies on have been removed.
>
> Not reporting the ancestry branch seems to be the
> Alexey Shumkin writes:
>
> > The expected SHA-1 digests are always available in variables. Use
> > them instead of hardcoding.
> >
> > Signed-off-by: Alexey Shumkin
> > ---
>
> Looks good (" refactoring:" in the title may not want to be there,
> though).
oops, it's remained from "working ver
> Alexey Shumkin writes:
>
> > The following two commands are expected to give the same output to
> > a terminal:
> >
> > $ git log --oneline --no-color
> > $ git log --pretty=format:'%h %s'
> >
> > However, the former pays attention to i18n.logOutputEncoding
> > configuration, while the
TortoiseGitMerge and filenames with spaces
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git, (uses spaces as cli parameter key-value separators)
and prevent confusion with the Torto
> Alexey Shumkin writes:
>
> > diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
> > index c248509..4db43a4 100755
> > --- a/t/t6006-rev-list-format.sh
> > +++ b/t/t6006-rev-list-format.sh
> > ...
> > @@ -112,12 +133,12 @@ commit $head2
> > commit $head1
> > EOF
> >
> > -te
On Fri, Jan 25, 2013 at 3:45 PM, Matthieu Moy
wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> diff --git a/builtin/branch.c b/builtin/branch.c
>> index 873f624..1d3e842 100644
>> --- a/builtin/branch.c
>> +++ b/builtin/branch.c
>> @@ -837,7 +837,7 @@ int cmd_branch(int argc, const char **argv, const c
Nguyễn Thái Ngọc Duy writes:
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 873f624..1d3e842 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -837,7 +837,7 @@ int cmd_branch(int argc, const char **argv, const char
> *prefix)
> colopts = 0;
> }
>
> -
Maybe, some time ;)
Actually, I'm not TCL-programmer. With one of these patches I just have
solved one my problem (to run tortoisemerge with git-gui) when I
was showing to my collegue how to work with Git, and on the side I
fixed another two bugs. So, I decided to sumbit these patches, to avoid
app
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 873f624..1d3e842 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -837,7 +837,7 @@ int cmd_branch(int argc, const char **a
97 matches
Mail list logo
