* Re: [PATCH 6/7] mergetools: Fix difftool/mergetool --tool-help listing for vim
From: Sebastian Schuberth @ 2013-01-25 10:23 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git, John Keeping
In-Reply-To: <1359107034-14606-7-git-send-email-davvid@gmail.com>
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)vimdiff, so loosing
these on that platform would not be so nice.
--
Sebastian Schuberth
^ permalink raw reply
* Re: [PATCH 6/7] mergetools: Fix difftool/mergetool --tool-help listing for vim
From: David Aguilar @ 2013-01-25 10:28 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: Junio C Hamano, git, John Keeping
In-Reply-To: <51025D1C.2030307@gmail.com>
On Fri, Jan 25, 2013 at 2:23 AM, Sebastian Schuberth
<sschuberth@gmail.com> 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 Git does not support symlinks,
> then, like Windows. But Windows has (g)vimdiff, so loosing these on that
> platform would not be so nice.
I thought Git did something sensible there like create a normal file?
If not then I was thinking we could add a provides_tools() function that
each scriptlet could supply.
--
David
^ permalink raw reply
* Re: [PATCH 6/7] mergetools: Fix difftool/mergetool --tool-help listing for vim
From: Sebastian Schuberth @ 2013-01-25 10:34 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git, John Keeping
In-Reply-To: <CAJDDKr4yb1-C9W1ZnKxHUk7WKpq-EN_YiR6diHCm5DVtQWzeCQ@mail.gmail.com>
On Fri, Jan 25, 2013 at 11:28 AM, David Aguilar <davvid@gmail.com> 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
> If not then I was thinking we could add a provides_tools() function that
> each scriptlet could supply.
Or maybe simply introduce scriptlets that do nothing but include /
inline another scriptlet?
--
Sebastian Schuberth
^ permalink raw reply
* git merge error question: The following untracked working tree files would be overwritten by merge
From: Carsten Fuchs @ 2013-01-25 10:37 UTC (permalink / raw)
To: git
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 <file>..." to include in what will be committed)
> #
> # obsolete/
> nothing added to commit but untracked files present (use "git add" to track)
>
> $ git merge origin/master --ff-only
> Updating f419d57..2da6052
> error: The following untracked working tree files would be overwritten by merge:
> obsolete/e107/Readme.txt
> obsolete/e107/article.php
> obsolete/e107/backend.php
> [...]
That is, the local repository has the untracked directory "obsolete", which was added
upstream as well, and now I try to reconcile.
I seem to understand the problem stated in the error message, and the solution seems to
be simple as well: renaming the obsolete/ directory is enough.
But why does Git find a problem here at all?
Compare with what Subversion did in an analogous case: When I ran "svn update" and the
update brought new files for which there already was an untracked copy in the working
directory, Subversion:
- started to consider the file as tracked,
- but left the file in the working-copy alone.
As a result, a subsequent "svn status" might
a) no longer show the file at all, if the foreign copy in the working directory
happened to be the same as the one brought by the "svn update", or
b) flag the file as modified, if different from the one that "svn update" would
have created in its place.
So my real question is, why does Git not do something analogous?
(Afaics, update the HEAD, update the Index, but leave the working-copy edition alone?)
I searched for this beforehand, and most advice involves either stashing, or with "git
reset --hard" the loss of the untracked files.
Sorry if this is a stupid question -- I still consider myself a Git learner.
Best regards,
Carsten
^ permalink raw reply
* Re: [PATCH 6/7] mergetools: Fix difftool/mergetool --tool-help listing for vim
From: John Keeping @ 2013-01-25 10:38 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git
In-Reply-To: <1359107034-14606-7-git-send-email-davvid@gmail.com>
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-
> recognized tool name.
Actually, after my patches both git-difftool and git-mergetool get this
right since list_merge_tool_candidates lists vimdiff and gvimdiff.
> vimdiff, vimdiff2, gvimdiff, and gvimdiff2 are all provided by the "vim"
> scriptlet. This required git-mergetool--lib to special-case it when
> setting up the tool.
>
> Remove the exception for "vim" and allow the scriptlets to be found
> naturally by using symlinks to a single "vimdiff" scriptlet.
I wonder if it would be better to make these single-line scripts instead
of symlinks:
. "$MERGE_TOOLS_DIR"/vimdiff
where we make git-mergetool--lib.sh export:
MERGE_TOOLS_DIR=$(git --exec-path)/mergetools
John
^ permalink raw reply
* Re: [PATCH 6/7] mergetools: Fix difftool/mergetool --tool-help listing for vim
From: David Aguilar @ 2013-01-25 10:40 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, git
In-Reply-To: <20130125103845.GX7498@serenity.lan>
On Fri, Jan 25, 2013 at 2:38 AM, John Keeping <john@keeping.me.uk> 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 according to the mergetool scriptlet instead of the Git-
>> recognized tool name.
>
> Actually, after my patches both git-difftool and git-mergetool get this
> right since list_merge_tool_candidates lists vimdiff and gvimdiff.
>
>> vimdiff, vimdiff2, gvimdiff, and gvimdiff2 are all provided by the "vim"
>> scriptlet. This required git-mergetool--lib to special-case it when
>> setting up the tool.
>>
>> Remove the exception for "vim" and allow the scriptlets to be found
>> naturally by using symlinks to a single "vimdiff" scriptlet.
>
> I wonder if it would be better to make these single-line scripts instead
> of symlinks:
>
> . "$MERGE_TOOLS_DIR"/vimdiff
>
> where we make git-mergetool--lib.sh export:
>
> MERGE_TOOLS_DIR=$(git --exec-path)/mergetools
That sounds like the way to go.
--
David
^ permalink raw reply
* Re: [PATCH 4/4] git-difftool: use git-mergetool--lib for "--tool-help"
From: John Keeping @ 2013-01-25 10:47 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <CAJDDKr5Xd4-e6VO-iO=EmwOcg0RimJHyO4ey-dFk6aENt+qZBQ@mail.gmail.com>
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_tool_candidates every
> time I read it, but I recognize that it does serve a purpose
> for users who have not configured anything.
Actually, I'm not sure it does. I asked one of my colleagues whether
he used git-mergetool the other day and he said no because he couldn't
understand the OS X FileMerge tool and was happier to edit things
manually in vim. I don't think he'd realised that he could configure a
different mergetool.
Perhaps we're trying to be too clever by guessing what the user wants
and should instead exit with a message saying:
You have not configured a merge tool to use. Please select one of
the following tools and configure it using:
git config merge.tool <tool>
These tools are availalble on your system:
...
These tools are supported but unavailable:
...
This may be too much of a regression for current users though.
John
^ permalink raw reply
* [PATCH v2] add: warn when -u or -A is used without filepattern
From: Matthieu Moy @ 2013-01-25 10:49 UTC (permalink / raw)
To: git, gitster
Cc: Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki,
Eric James Michael Ritz, Tomas Carnecky, Matthieu Moy
In-Reply-To: <vpq1uddoedj.fsf@grenoble-inp.fr>
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
problematic since other 'git add' subcommands (namely 'git add -p' and
'git add -e') are tree-wide by default.
Flipping the default now is unacceptable, so this patch starts training
users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare
for the next steps:
* forbid 'git add -u|-A' without filepattern (like 'git add' without
option)
* much later, maybe, re-allow 'git add -u|-A' without filepattern, with a
tree-wide scope.
A nice side effect of this patch is that it makes the :/ special
filepattern easier to discover for users.
When the command is called from the root of the tree, there is no
ambiguity and no need to change the behavior, hence no need to warn.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Changes since v1:
* Do not warn from the root of the tree.
* Say explicitely "Git 2.0" to announce the change.
(plus fix a C99 style issue)
Documentation/git-add.txt | 7 ++++---
builtin/add.c | 36 +++++++++++++++++++++++++++++++++++-
2 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index fd9e36b..5333559 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.
from the index if the corresponding files in the working tree
have been removed.
+
-If no <filepattern> is given, default to "."; in other words,
-update all tracked files in the current directory and its
-subdirectories.
+If no <filepattern> is given, the current version of Git defaults to
+"."; in other words, update all tracked files in the current directory
+and its subdirectories. This default will change in a future version
+of Git, hence the form without <filepattern> should not be used.
-A::
--all::
diff --git a/builtin/add.c b/builtin/add.c
index e664100..8252d19 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -363,6 +363,33 @@ static int add_files(struct dir_struct *dir, int flags)
return exit_status;
}
+static void warn_pathless_add(const char *option_name) {
+ /*
+ * To be consistant with "git add -p" and most Git
+ * commands, we should default to being tree-wide, but
+ * this is not the original behavior and can't be
+ * changed until users trained themselves not to type
+ * "git add -u" or "git add -A". For now, we warn and
+ * keep the old behavior. Later, this warning can be
+ * turned into a die(...), and eventually we may
+ * reallow the command with a new behavior.
+ */
+ warning(_("The behavior of 'git add %s' with no path argument from a subdirectory of the\n"
+ "tree will change in Git 2.0 and shouldn't be used anymore.\n"
+ "To add content for the whole tree, run:\n"
+ "\n"
+ " git add %s :/\n"
+ "\n"
+ "To restrict the command to the current directory, run:\n"
+ "\n"
+ " git add %s .\n"
+ "\n"
+ "With the current Git version, the command is restricted to the current directory."),
+ option_name,
+ option_name,
+ option_name);
+}
+
int cmd_add(int argc, const char **argv, const char *prefix)
{
int exit_status = 0;
@@ -373,6 +400,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
int add_new_files;
int require_pathspec;
char *seen = NULL;
+ const char *option_with_implicit_dot = NULL;
git_config(add_config, NULL);
@@ -392,8 +420,14 @@ int cmd_add(int argc, const char **argv, const char *prefix)
die(_("-A and -u are mutually incompatible"));
if (!show_only && ignore_missing)
die(_("Option --ignore-missing can only be used together with --dry-run"));
- if ((addremove || take_worktree_changes) && !argc) {
+ if (addremove)
+ option_with_implicit_dot = "--all";
+ if (take_worktree_changes)
+ option_with_implicit_dot = "--update";
+ if (option_with_implicit_dot && !argc) {
static const char *here[2] = { ".", NULL };
+ if (prefix)
+ warn_pathless_add(option_with_implicit_dot);
argc = 1;
argv = here;
}
--
1.8.0.1.527.gd366564.dirty
^ permalink raw reply related
* Re: [PATCH v4 1/4] t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
From: Alexey Shumkin @ 2013-01-25 11:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v38xqba04.fsf@alter.siamese.dyndns.org>
> 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 value, the abbreviation
> shown with --format=%h is consistent with the abbreviation that is
> given by rev-parse --short.
>
> head1_short=$(git rev-parse --short $head1)
>
> perhaps?
>
> > + echo changed >foo &&
> > + git commit -a -m "changed foo" &&
> > + head2=$(git rev-parse --verify HEAD) &&
> > + head2_7=$(echo $head2 | cut -c1-7) &&
> > + head2_parent=$(git cat-file -p HEAD | grep parent | cut -f
> > 2 -d" ") &&
>
> Do not use "cat-file -p" that is for human consumption in scripts,
> unless you are testing how the format for human consumption should
> look like (we may later add more pretty-print to them), which is not
> the case here.
>
> Also be careful and pay attention to the end of the header; you do
> not want to pick up a random "parent" string in the middle of a log
> message.
>
> head2_parent=$(git cat-file commit HEAD | sed -n -e
> "s/^parent //p" -e "/^$/q")
>
> would be much better.
>
> > + head2_parent_7=$(echo $head2_parent | cut -c1-7) &&
> > + tree2=$(git cat-file -p HEAD | grep tree | cut -f 2 -d" ")
> > &&
>
> Likewise.
>
> > + tree2_7=$(echo $tree2 | cut -c1-7)
>
> Likewise.
but is there "git something" to return abbreviated tree hash except
"pretty formats" that is implicitly tested here?
^ permalink raw reply
* Re: [PATCH 6/7] mergetools: Fix difftool/mergetool --tool-help listing for vim
From: Sebastian Schuberth @ 2013-01-25 11:39 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git, John Keeping
In-Reply-To: <CAHGBnuMPQWr8Z9jeQmHs7wFN5kf=MwBEEDy_M-QeY0mRnSke_g@mail.gmail.com>
On Fri, Jan 25, 2013 at 11:34 AM, Sebastian Schuberth
<sschuberth@gmail.com> 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
This one might be the even more appropriate answer:
http://stackoverflow.com/questions/11662868/what-happens-when-i-clone-a-repository-with-symlinks-on-windows/11664406#11664406
--
Sebastian Schuberth
^ permalink raw reply
* [PATCH v2 1/3] branch: reject -D/-d without branch name
From: Nguyễn Thái Ngọc Duy @ 2013-01-25 12:50 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Matthieu Moy,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1359102416-1240-1-git-send-email-pclouds@gmail.com>
---
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)
colopts = 0;
}
- if (delete)
+ if (delete) {
+ if (!argc)
+ die(_("branch name required"));
return delete_branches(argc, argv, delete > 1, kinds, quiet);
- else if (list) {
+ } else if (list) {
int ret = print_ref_list(kinds, detached, verbose, abbrev,
with_commit, argv);
print_columns(&output, colopts, NULL);
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCH v2 2/3] branch: give a more helpful message on redundant arguments
From: Nguyễn Thái Ngọc Duy @ 2013-01-25 12:50 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Matthieu Moy,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1359118225-14356-1-git-send-email-pclouds@gmail.com>
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 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -852,14 +852,14 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
const char *branch_name;
struct strbuf branch_ref = STRBUF_INIT;
- if (detached)
- die("Cannot give description to detached HEAD");
- if (!argc)
+ if (!argc) {
+ if (detached)
+ die("Cannot give description to detached HEAD");
branch_name = head;
- else if (argc == 1)
+ } else if (argc == 1)
branch_name = argv[0];
else
- usage_with_options(builtin_branch_usage, options);
+ die(_("cannot edit description of more than one branch"));
strbuf_addf(&branch_ref, "refs/heads/%s", branch_name);
if (!ref_exists(branch_ref.buf)) {
@@ -881,7 +881,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
else if (argc == 2)
rename_branch(argv[0], argv[1], rename > 1);
else
- usage_with_options(builtin_branch_usage, options);
+ die(_("too many branches for a rename operation"));
} else if (new_upstream) {
struct branch *branch = branch_get(argv[0]);
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 80e6be3..f3e0e4a 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -73,8 +73,8 @@ test_expect_success \
test_expect_success \
'git branch -m dumps usage' \
- 'test_expect_code 129 git branch -m 2>err &&
- test_i18ngrep "[Uu]sage: git branch" err'
+ 'test_expect_code 128 git branch -m 2>err &&
+ test_i18ngrep "too many branches for a rename operation" err'
test_expect_success \
'git branch -m m m/m should work' \
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCH v2 3/3] branch: mark more strings for translation
From: Nguyễn Thái Ngọc Duy @ 2013-01-25 12:50 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Matthieu Moy,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1359118225-14356-1-git-send-email-pclouds@gmail.com>
---
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 *item,
int verbose, int abbrev)
{
struct strbuf subject = STRBUF_INIT, stat = STRBUF_INIT;
- const char *sub = " **** invalid ref ****";
+ const char *sub = _(" **** invalid ref ****");
struct commit *commit = item->commit;
if (commit && !parse_commit(commit)) {
@@ -590,7 +590,7 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
struct commit *filter;
filter = lookup_commit_reference_gently(merge_filter_ref, 0);
if (!filter)
- die("object '%s' does not point to a commit",
+ die(_("object '%s' does not point to a commit"),
sha1_to_hex(merge_filter_ref));
filter->object.flags |= UNINTERESTING;
@@ -854,7 +854,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (!argc) {
if (detached)
- die("Cannot give description to detached HEAD");
+ die(_("Cannot give description to detached HEAD"));
branch_name = head;
} else if (argc == 1)
branch_name = argv[0];
@@ -866,10 +866,11 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
strbuf_release(&branch_ref);
if (!argc)
- return error("No commit on branch '%s' yet.",
+ return error(_("No commit on branch '%s' yet."),
branch_name);
else
- return error("No such branch '%s'.", branch_name);
+ return error(_("No branch named '%s'."),
+ branch_name);
}
strbuf_release(&branch_ref);
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCH] mergetools: Enhance tortoisemerge to work with
From: Sven Strickroth @ 2013-01-25 13:07 UTC (permalink / raw)
To: git; +Cc: David Aguilar, Junio C Hamano, Sebastian Schuberth, Jeff King
In-Reply-To: <CAJDDKr7eNyJp1ffBYEJaZkmnVWqd0AMpnm1kdjnrrhPtuGNL_w@mail.gmail.com>
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 TortoiseSVN TortoiseMerge version.
- 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.
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Reported-by: Sebastian Schuberth <sschuberth@gmail.com>
---
mergetools/tortoisemerge | 51 ++++++++++++++++++++++++++++++++----------------
1 file changed, 34 insertions(+), 17 deletions(-)
diff --git a/mergetools/tortoisemerge b/mergetools/tortoisemerge
index ed7db49..8ee99a5 100644
--- a/mergetools/tortoisemerge
+++ b/mergetools/tortoisemerge
@@ -1,17 +1,34 @@
-can_diff () {
- return 1
-}
-
-merge_cmd () {
- if $base_present
- then
- touch "$BACKUP"
- "$merge_tool_path" \
- -base:"$BASE" -mine:"$LOCAL" \
- -theirs:"$REMOTE" -merged:"$MERGED"
- check_unchanged
- else
- echo "TortoiseMerge cannot be used without a base" 1>&2
- return 1
- fi
-}
+can_diff () {
+ return 1
+}
+
+merge_cmd () {
+ if $base_present
+ then
+ touch "$BACKUP"
+ basename="$(basename "$merge_tool_path" .exe)"
+ if test "$basename" = "tortoisegitmerge"
+ then
+ "$merge_tool_path" \
+ -base "$BASE" -mine "$LOCAL" \
+ -theirs "$REMOTE" -merged "$MERGED"
+ else
+ "$merge_tool_path" \
+ -base:"$BASE" -mine:"$LOCAL" \
+ -theirs:"$REMOTE" -merged:"$MERGED"
+ fi
+ check_unchanged
+ else
+ echo "$merge_tool_path cannot be used without a base" 1>&2
+ return 1
+ fi
+}
+
+translate_merge_tool_path() {
+ if type tortoisegitmerge >/dev/null 2>/dev/null
+ then
+ echo tortoisegitmerge
+ else
+ echo tortoisemerge
+ fi
+}
--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply related
* git-core vs git package on ubuntu
From: Mario Michael Krell @ 2013-01-25 13:50 UTC (permalink / raw)
To: git
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?
Greets
Mario
^ permalink raw reply
* Re: git-core vs git package on ubuntu
From: Matthieu Moy @ 2013-01-25 14:06 UTC (permalink / raw)
To: Mario Michael Krell; +Cc: git
In-Reply-To: <4A4C2896-042A-4BE3-9E74-012D881D5776@googlemail.com>
Mario Michael Krell <supermariton@googlemail.com> 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
http://git-scm.com/download/linux either.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: git-core vs git package on ubuntu
From: Konstantin Khomoutov @ 2013-01-25 14:06 UTC (permalink / raw)
To: Mario Michael Krell; +Cc: git
In-Reply-To: <4A4C2896-042A-4BE3-9E74-012D881D5776@googlemail.com>
On Fri, 25 Jan 2013 14:50:24 +0100
Mario Michael Krell <supermariton@googlemail.com> 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 instead. Is this an error in the package manager
> or in the website documentation?
Neither of them. Git was packaged for Debian (and hence appeared in
Ubuntu) when another package with the name "git" already existed in the
archive, and was unrelated to Git. So the Git package maintainer
picked the name "git-core". After that, the maintainers of both
packages discussed this issue and the maintainer of the original
package named "git" agreed to change the name of his package, and then,
subsequently, "git-core" has been renamed to "git", and the "git-core"
package has been turned into transitional dummy obsolete package.
Now, whenever you're trying to install the "git-core" package, the
package system tells you it's obsolete and suggests the "correct"
package to install. After some time (the next OS release or later),
the "git-core" package will be removed completely from the archive.
This is the standard way to handle such situations in Debian and its
derivatives, so nothing special here. The documentation on the
whatever site you were referring to should probably be updated as
git-core is obsolete even in the current stable release of Debian [1].
I'm not sure which LTS release of Ubuntu is currently supported, but
you might check the state of the git-core package in it yourself,
using [2].
1. http://packages.debian.org/squeeze/git-core
2. http://packages.ubuntu.com
^ permalink raw reply
* Re: git-core vs git package on ubuntu
From: Matthieu Moy @ 2013-01-25 14:25 UTC (permalink / raw)
To: Mario Michael Krell; +Cc: git
In-Reply-To: <58A2D0C1-5E74-4449-9AC4-D2BDC494555C@googlemail.com>
Cc-ing the Git list again.
Mario Michael Krell <supermariton@googlemail.com> 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
OK, this is the "pro Git" book. I just submitted a pull request:
https://github.com/progit/progit/pull/358
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] git-web--browser: avoid errors in terminal when running Firefox on Windows
From: Alexey Shumkin @ 2013-01-25 14:44 UTC (permalink / raw)
To: git; +Cc: Alexey Shumkin, Junio C Hamano, Jeff King
In-Reply-To: <20111111202636.GA20515@sigill.intra.peff.net>
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.
Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
---
git-web--browse.sh | 2 +-
t/t9901-git-web--browse.sh | 57 +++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/git-web--browse.sh b/git-web--browse.sh
index 1e82726..f96e5bd 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -149,7 +149,7 @@ fi
case "$browser" in
firefox|iceweasel|seamonkey|iceape)
# Check version because firefox < 2.0 does not support "-new-tab".
- vers=$(expr "$($browser_path -version)" : '.* \([0-9][0-9]*\)\..*')
+ vers=$(expr "$("$browser_path" -version)" : '.* \([0-9][0-9]*\)\..*')
NEWTAB='-new-tab'
test "$vers" -lt 2 && NEWTAB=''
"$browser_path" $NEWTAB "$@" &
diff --git a/t/t9901-git-web--browse.sh b/t/t9901-git-web--browse.sh
index b0a6bad..30d5294 100755
--- a/t/t9901-git-web--browse.sh
+++ b/t/t9901-git-web--browse.sh
@@ -8,8 +8,21 @@ This test checks that git web--browse can handle various valid URLs.'
. ./test-lib.sh
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 run in background (it is run with &)
+ # we trying to avoid race condition
+ # by waiting for "$sleep_timeout" seconds of timeout for 'fake_browser_ran' file appearance
+ (test -z "$sleep_timeout" || (
+ for timeout in $(seq 1 $sleep_timeout); do
+ test -f fake_browser_ran && break
+ sleep 1
+ done
+ test $timeout -ne $sleep_timeout
+ )
+ ) &&
tr -d '\015' <actual >text &&
test_cmp expect text
}
@@ -48,6 +61,48 @@ test_expect_success \
'
test_expect_success \
+ 'Firefox below v2.0 paths are properly quoted' '
+ echo fake: http://example.com/foo >expect &&
+ rm -f fake_browser_ran &&
+ cat >"fake browser" <<-\EOF &&
+ #!/bin/sh
+
+ : > fake_browser_ran
+ if test "$1" = "-version"; then
+ echo Fake Firefox browser version 1.2.3
+ else
+ # Firefox (in contrast to w3m) is run in background (with &)
+ # so redirect output to "actual"
+ echo fake: "$@" > actual
+ fi
+ EOF
+ chmod +x "fake browser" &&
+ git config browser.firefox.path "`pwd`/fake browser" &&
+ test_web_browse firefox http://example.com/foo 5
+'
+
+test_expect_success \
+ 'Firefox not lower v2.0 paths are properly quoted' '
+ echo fake: -new-tab http://example.com/foo >expect &&
+ rm -f fake_browser_ran &&
+ cat >"fake browser" <<-\EOF &&
+ #!/bin/sh
+
+ : > fake_browser_ran
+ if test "$1" = "-version"; then
+ echo Fake Firefox browser version 2.0.0
+ else
+ # Firefox (in contrast to w3m) is run in background (with &)
+ # so redirect output to "actual"
+ echo fake: "$@" > actual
+ fi
+ EOF
+ chmod +x "fake browser" &&
+ git config browser.firefox.path "`pwd`/fake browser" &&
+ test_web_browse firefox http://example.com/foo 5
+'
+
+test_expect_success \
'browser command allows arbitrary shell code' '
echo "arg: http://example.com/foo" >expect &&
git config browser.custom.cmd "
--
1.8.1.1.10.g9255f3f
^ permalink raw reply related
* Re: [PATCH v4 1/4] t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
From: Junio C Hamano @ 2013-01-25 15:16 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <20130125150620.3b9dc9c3@ashu.dyn1.rarus.ru>
Alexey Shumkin <alex.crezoff@gmail.com> 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 abbreviation length to a larger value, the abbreviation
>> shown with --format=%h is consistent with the abbreviation that is
>> given by rev-parse --short.
>>
>> head1_short=$(git rev-parse --short $head1)
>>
>> perhaps?
>> ...
>> Likewise.
>>
>> > + tree2_7=$(echo $tree2 | cut -c1-7)
>>
>> Likewise.
> but is there "git something" to return abbreviated tree hash except
> "pretty formats" that is implicitly tested here?
Does "git rev-parse --short $tree2" count?
^ permalink raw reply
* Re: [PATCH v4 1/4] t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
From: Alexey Shumkin @ 2013-01-25 15:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmwvx5m4o.fsf@alter.siamese.dyndns.org>
> Alexey Shumkin <alex.crezoff@gmail.com> 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 abbreviation length to a larger value, the abbreviation
> >> shown with --format=%h is consistent with the abbreviation that is
> >> given by rev-parse --short.
> >>
> >> head1_short=$(git rev-parse --short $head1)
> >>
> >> perhaps?
> >> ...
> >> Likewise.
> >>
> >> > + tree2_7=$(echo $tree2 | cut -c1-7)
> >>
> >> Likewise.
> > but is there "git something" to return abbreviated tree hash except
> > "pretty formats" that is implicitly tested here?
>
> Does "git rev-parse --short $tree2" count?
Oops! Yep!
^ permalink raw reply
* [PATCH] send-email: Honor multi-part email messages
From: Alexey Shumkin @ 2013-01-25 15:28 UTC (permalink / raw)
To: git; +Cc: Alexey Shumkin, Junio C Hamano, Krzysztof Mazur
In-Reply-To: <cover.1359126360.git.Alex.Crezoff@gmail.com>
"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-part messages.
So already quoted printable email subject may be encoded as quoted printable
again. Due to this bug email subject looks corrupted in email clients.
Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
---
git-send-email.perl | 5 ++++
t/t9001-send-email.sh | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 71 insertions(+)
diff --git a/git-send-email.perl b/git-send-email.perl
index 94c7f76..d49befe 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1499,12 +1499,17 @@ sub file_has_nonascii {
sub body_or_subject_has_nonascii {
my $fn = shift;
+ my $multipart = 0;
open(my $fh, '<', $fn)
or die "unable to open $fn: $!\n";
while (my $line = <$fh>) {
last if $line =~ /^$/;
+ if ($line =~ /^Content-Type:\s*multipart\/mixed.*$/) {
+ $multipart = 1;
+ }
return 1 if $line =~ /^Subject.*[^[:ascii:]]/;
}
+ return 0 if $multipart;
while (my $line = <$fh>) {
return 1 if $line =~ /[^[:ascii:]]/;
}
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 97d6f4c..c7ed370 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1323,4 +1323,70 @@ test_expect_success $PREREQ 'sendemail.aliasfile=~/.mailrc' '
grep "^!someone@example\.org!$" commandline1
'
+test_expect_success $PREREQ 'setup multi-part message' '
+cat >multi-part-email-using-8bit <<EOF
+From fe6ecc66ece37198fe5db91fa2fc41d9f4fe5cc4 Mon Sep 17 00:00:00 2001
+Message-Id: <bogus-message-id@example.com>
+From: author@example.com
+Date: Sat, 12 Jun 2010 15:53:58 +0200
+Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=B1=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=20?=
+ =?UTF-8?q?=D1=84=D0=B0=D0=B9=D0=BB?=
+MIME-Version: 1.0
+Content-Type: multipart/mixed; boundary="------------123"
+
+This is a multi-part message in MIME format.
+--------------1.7.6.3.4.gf71f
+Content-Type: text/plain; charset=UTF-8; format=fixed
+Content-Transfer-Encoding: 8bit
+
+This is a message created with "git format-patch --attach=123"
+---
+ master | 1 +
+ файл | 1 +
+ 2 files changed, 2 insertions(+), 0 deletions(-)
+ create mode 100644 master
+ create mode 100644 файл
+
+
+--------------123
+Content-Type: text/x-patch; name="0001-.patch"
+Content-Transfer-Encoding: 8bit
+Content-Disposition: attachment; filename="0001-.patch"
+
+diff --git a/master b/master
+new file mode 100644
+index 0000000..1f7391f
+--- /dev/null
++++ b/master
+@@ -0,0 +1 @@
++master
+diff --git a/файл b/файл
+new file mode 100644
+index 0000000..44e5cfe
+--- /dev/null
++++ b/файл
+@@ -0,0 +1 @@
++содержимое файла
+
+--------------123--
+EOF
+'
+
+test_expect_success $PREREQ 'setup expect' '
+cat >expected <<EOF
+Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=B1=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=20?= =?UTF-8?q?=D1=84=D0=B0=D0=B9=D0=BB?=
+EOF
+'
+
+test_expect_success $PREREQ '--attach/--inline also treats subject' '
+ clean_fake_sendmail &&
+ echo bogus |
+ git send-email --from=author@example.com --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ --8bit-encoding=UTF-8 \
+ multi-part-email-using-8bit >stdout &&
+ grep "Subject" msgtxt1 >actual &&
+ test_cmp expected actual
+'
+
test_done
--
1.8.1.1.10.g9255f3f
^ permalink raw reply related
* [PATCH resent] send-email: Honor multi-part email messages
From: Alexey Shumkin @ 2013-01-25 15:28 UTC (permalink / raw)
To: git; +Cc: Alexey Shumkin, Junio C Hamano, Krzysztof Mazur
Let's try to involve Krzysztof Mazur <krzysiek@podlesie.net>
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. Function searches non-ASCII characters in Subject header
>3. If none then it looks non-ASCII characters at message body
>
>my changes are to skip looking at message body of a multi-part
>message as it has parts with their own Content-Type headers
>
>The said above in details:
>1. To set flag when we meet Content-Type: multipart/mixed header
>2. After we processed all headers and did not found non-ASCII characters
>in a Subject we take a look at this flag and exit with 0
>if it is a multi-part message
>>I think your patch is wrong. What happens when we see a Subject:
>>line with a non-ascii on it that causes an early return of the loop
>>before your new code has a chance to see Content-Type: header?
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.
P.S.
To involved: the beginning of thread is here http://thread.gmane.org/gmane.comp.version-control.git/181743
Alexey Shumkin (1):
send-email: Honor multi-part email messages
git-send-email.perl | 5 ++++
t/t9001-send-email.sh | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 71 insertions(+)
--
1.8.1.1.10.g9255f3f
^ permalink raw reply
* Re: segmentation fault (nullpointer) with git log --submodule -p
From: Junio C Hamano @ 2013-01-25 15:36 UTC (permalink / raw)
To: Jonathon Mah
Cc: Jonathan Nieder, Jeff King, Duy Nguyen, Stefan Näwe, Armin,
git@vger.kernel.org
In-Reply-To: <FE6CC927-1915-4486-BBB8-4C109F7B5295@me.com>
Jonathon Mah <jmah@me.com> 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();
> fn2_needing_buffer(commit);
> } done_with_commit_buffer(commit);
I think the goal of everybody discussing these ideas is to make sure
that all code follows the simple ownership policy proposed at the
beginning of this subthread: commit->buffer belongs to the revision
traversal machinery, and other users could borrow it when available.
Even though your sample code will break, from that point of view, I
do not think it is something worth worrying about. If the function
"walk_rev_tree_or_something()" discards commit->buffer, it by
definition must be a part of the revision traversal machinery, and
any code that calls it inside with_commit_buffer() or uses the field
after such a call without revalidating commit->buffer, is already in
violation. With or without such a macro, we would need to be
careful about enforcing the ownership rule, and I think a code
structure like the above example is easier to spot problems in
during the review than the current code.
Because retaining commit->buffer is done for the benefit of the
next/future users of the data, and not for the users that _are_
using them right now, I do not think the usual refcounting that
discards when nobody references the data is a good match to the
problem we are discussing.
^ permalink raw reply
* Re: [PATCH] send-email: Honor multi-part email messages
From: Krzysztof Mazur @ 2013-01-25 17:47 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git, Junio C Hamano
In-Reply-To: <4de442db9fd0896f78166e6038b6ea35ed5ab266.1359126360.git.Alex.Crezoff@gmail.com>
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 interprets a patch-file as one-part message
> and does not recognize multi-part messages.
> So already quoted printable email subject may be encoded as quoted printable
> again. Due to this bug email subject looks corrupted in email clients.
I don't think that the problem with the Subject is multi-part message
specific. The real problem with the Subject is probably that
is_rfc2047_quoted() does not detect that the Subject is already quoted.
Of course we still need that explicit multi-part message support to
avoid "Which 8bit encoding should I declare [UTF-8]? " message.
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 94c7f76..d49befe 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1499,12 +1499,17 @@ sub file_has_nonascii {
>
> sub body_or_subject_has_nonascii {
> my $fn = shift;
> + my $multipart = 0;
> open(my $fh, '<', $fn)
> or die "unable to open $fn: $!\n";
> while (my $line = <$fh>) {
> last if $line =~ /^$/;
> + if ($line =~ /^Content-Type:\s*multipart\/mixed.*$/) {
> + $multipart = 1;
> + }
> return 1 if $line =~ /^Subject.*[^[:ascii:]]/;
> }
> + return 0 if $multipart;
> while (my $line = <$fh>) {
> return 1 if $line =~ /[^[:ascii:]]/;
> }
After this change the function name is no longer appropriate.
Maybe we should join body_or_subject_has_nonascii()
and file_declares_8bit_cte() because in case of multi-part messages
"next unless (body_or_subject_has_nonascii($f)
&& !file_declares_8bit_cte($f));"
is not valid anymore. We could also check for broken_encoding
in single pass.
Thanks,
Krzysiek
^ 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