невозвратимо жжёт жир поменьше чем за месяц
экстракт бобов Зеленого кофе характеризуется значительнейшим жиросжигающим действием http://www.sauna-banya.by/templates/beez/xosxw.htm?C
I have a better plans
I have a better plans for us reply me ASAP. 2721745...@qq.com Thanks. -- 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
Re: Git send-email fail on Mac OS X Lion
(Please, not top-posting) >> On Oct 12, 2013, at 8:47 AM, "brian m. carlson" >> wrote: >> >>> On Fri, Oct 11, 2013 at 11:06:17PM -0500, Fernando Ortiz (e2k) wrote: >>> I'm getting the following error when I do: >>> >>> git send-email --compose --from Fernando Ortiz --to >>> forti...@gmail.com --cc forti...@gmail.com >>> 0001-Change-zcat-to-gzcat-to-fix-build-restore-steps.patch >>> >>> Net::SSLeay version 1.46 required--this is only version 1.36 at >>> /Users/fortiz/perl5/perlbrew/perls/perl-5.14.4/lib/site_perl/5.14.4/IO/Socket/SSL.pm >>> line 17. >> >> Here's your answer: Net::SSLeay is too old for IO::Socket::SSL. You >> either need to use cpan or cpanm to install a newer Net::SSLeay, and >> then it will work. On 2013-10-12 19.40, Gmail wrote:> Brian, > > I already tried to reinstall with cpan/m using -f -i options. I even removed > the PERL5LIB location and reinstalled the packages from scratch to no avail. > > Nando > > Sent from my iPhone > This may be a stupid question: Which perl is in your $PATH ? What do you get entering type perl on the command line ? /Torsten -- 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
Re: Git send-email fail on Mac OS X Lion
On Oct 13, 2013, at 3:32 AM, Torsten Bögershausen wrote: > (Please, not top-posting) Sorry about that > >>> On Oct 12, 2013, at 8:47 AM, "brian m. carlson" >>> wrote: >>> On Fri, Oct 11, 2013 at 11:06:17PM -0500, Fernando Ortiz (e2k) wrote: I'm getting the following error when I do: git send-email --compose --from Fernando Ortiz --to forti...@gmail.com --cc forti...@gmail.com 0001-Change-zcat-to-gzcat-to-fix-build-restore-steps.patch Net::SSLeay version 1.46 required--this is only version 1.36 at /Users/fortiz/perl5/perlbrew/perls/perl-5.14.4/lib/site_perl/5.14.4/IO/Socket/SSL.pm line 17. >>> >>> Here's your answer: Net::SSLeay is too old for IO::Socket::SSL. You >>> either need to use cpan or cpanm to install a newer Net::SSLeay, and >>> then it will work. > > On 2013-10-12 19.40, Gmail wrote:> Brian, >> >> I already tried to reinstall with cpan/m using -f -i options. I even >> removed the PERL5LIB location and reinstalled the packages from scratch to >> no avail. >> >> Nando >> >> Sent from my iPhone >> > This may be a stupid question: > Which perl is in your $PATH ? I was using perlbrew to manage all the perls. I got so frustrated and decided to dump perlbrew and decided to use plenv instead. I'm not getting the error anymore, after switching to plenv everything is working now. > What do you get entering > type perl > on the command line ? > /Torsten > > -- 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
Re: [PATCH] http: enable keepalive on TCP sockets
On Sat, 12 Oct 2013, Eric Wong wrote: This is a follow up to commit e47a8583a20256851e7fc882233e3bd5bf33dc6e (enable SO_KEEPALIVE for connected TCP sockets). Just keep in mind that TCP keep-alive is enabled in awkwardly many different ways on different systems and this patch only supports one of them. Feel free to take inspiration from libcurl's source code for doing this. See: https://github.com/bagder/curl/blob/master/lib/connect.c#L108 -- / daniel.haxx.se -- 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
Re: [PATCH try2 09/14] apply: add --stage option
On Sat, Oct 12, 2013 at 3:04 AM, Felipe Contreras
wrote:
> Synonym for --index.
>
> Signed-off-by: Felipe Contreras
> ---
> Documentation/git-apply.txt | 5 -
> builtin/apply.c | 2 ++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
> index f605327..ce44327 100644
> --- a/Documentation/git-apply.txt
> +++ b/Documentation/git-apply.txt
> @@ -12,7 +12,7 @@ SYNOPSIS
> 'git apply' [--stat] [--numstat] [--summary] [--check] [--index] [--3way]
> [--apply] [--no-add] [--build-fake-ancestor=] [-R | --reverse]
> [--allow-binary-replacement | --binary] [--reject] [-z]
> - [-p] [-C] [--inaccurate-eof] [--recount] [--cached]
> + [-p] [-C] [--inaccurate-eof] [--recount] [--cached|--staged]
Here "staged".
> [--ignore-space-change | --ignore-whitespace ]
> [--whitespace=(nowarn|warn|fix|error|error-all)]
> [--exclude=] [--include=] [--directory=]
> @@ -67,6 +67,9 @@ OPTIONS
> up-to-date, it is flagged as an error. This flag also
> causes the index file to be updated.
>
> +--staged::
> + Synonym for --index.
> +
Also "staged".
> --cached::
> Apply a patch without touching the working tree. Instead take the
> cached data, apply the patch, and store the result in the index
> diff --git a/builtin/apply.c b/builtin/apply.c
> index 50912c9..42b5a4b 100644
> --- a/builtin/apply.c
> +++ b/builtin/apply.c
> @@ -4377,6 +4377,8 @@ int cmd_apply(int argc, const char **argv, const char
> *prefix_)
> N_("instead of applying the patch, see if the patch
> is applicable")),
> OPT_BOOLEAN(0, "index", &check_index,
> N_("make sure the patch is applicable to the current
> index")),
> + OPT_BOOLEAN(0, "stage", &check_index,
But here "stage".
> + N_("make sure the patch is applicable to the current
> index")),
> OPT_BOOLEAN(0, "cached", &cached,
> N_("apply a patch without touching the working
> tree")),
> OPT_BOOLEAN(0, "apply", &force_apply,
> --
> 1.8.4-fc
>
> --
> 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
--
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
Re: [PATCH try2 7/8] push: add --set-publish option
On Sat, Oct 12, 2013 at 3:05 AM, Felipe Contreras
wrote:
> diff --git a/t/t5529-push-publish.sh b/t/t5529-push-publish.sh
> new file mode 100755
> index 000..2037026
> --- /dev/null
> +++ b/t/t5529-push-publish.sh
> @@ -0,0 +1,70 @@
> +#!/bin/sh
> +
> +test_description='push with --set-publish'
> +
> +. ./test-lib.sh
> +
> +test_expect_success 'setup bare parent' '
> + git init --bare parent &&
> + git remote add publish parent
> +'
> +
> +test_expect_success 'setup local commit' '
> + echo content >file &&
> + git add file &&
> + git commit -m one
> +'
> +
> +check_config() {
> + (echo $2; echo $3) >expect.$1
> + (git config branch.$1.pushremote
> +git config branch.$1.push) >actual.$1
> + test_cmp expect.$1 actual.$1
> +}
Do you want to maintain &&-chain in this test?
> +
> +test_expect_success 'push -p master:master' '
> + git push -p publish master:master &&
> + check_config master publish refs/heads/master
> +'
> +
> +test_expect_success 'push -u master:other' '
> + git push -p publish master:other &&
> + check_config master publish refs/heads/other
> +'
> +
> +test_expect_success 'push -p --dry-run master:otherX' '
> + git push -p --dry-run publish master:otherX &&
> + check_config master publish refs/heads/other
> +'
> +
> +test_expect_success 'push -p master2:master2' '
> + git branch master2 &&
> + git push -p publish master2:master2 &&
> + check_config master2 publish refs/heads/master2
> +'
> +
> +test_expect_success 'push -p master2:other2' '
> + git push -p publish master2:other2 &&
> + check_config master2 publish refs/heads/other2
> +'
> +
> +test_expect_success 'push -p :master2' '
> + git push -p publish :master2 &&
> + check_config master2 publish refs/heads/other2
> +'
> +
> +test_expect_success 'push -u --all' '
> + git branch all1 &&
> + git branch all2 &&
> + git push -p --all &&
> + check_config all1 publish refs/heads/all1 &&
> + check_config all2 publish refs/heads/all2
> +'
> +
> +test_expect_success 'push -p HEAD' '
> + git checkout -b headbranch &&
> + git push -p publish HEAD &&
> + check_config headbranch publish refs/heads/headbranch
> +'
> +
> +test_done
--
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
Re: [PATCH try2 7/8] push: add --set-publish option
On Sun, Oct 13, 2013 at 5:03 AM, Eric Sunshine wrote:
> On Sat, Oct 12, 2013 at 3:05 AM, Felipe Contreras
> wrote:
>> diff --git a/t/t5529-push-publish.sh b/t/t5529-push-publish.sh
>> new file mode 100755
>> index 000..2037026
>> --- /dev/null
>> +++ b/t/t5529-push-publish.sh
>> @@ -0,0 +1,70 @@
>> +#!/bin/sh
>> +
>> +test_description='push with --set-publish'
>> +
>> +. ./test-lib.sh
>> +
>> +test_expect_success 'setup bare parent' '
>> + git init --bare parent &&
>> + git remote add publish parent
>> +'
>> +
>> +test_expect_success 'setup local commit' '
>> + echo content >file &&
>> + git add file &&
>> + git commit -m one
>> +'
>> +
>> +check_config() {
>> + (echo $2; echo $3) >expect.$1
>> + (git config branch.$1.pushremote
>> +git config branch.$1.push) >actual.$1
>> + test_cmp expect.$1 actual.$1
>> +}
>
> Do you want to maintain &&-chain in this test?
As much as we want to do it in t/t5523-push-upstream.sh, which has
this exact function.
--
Felipe Contreras
--
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
Re: [PATCH try2 09/14] apply: add --stage option
On Sun, Oct 13, 2013 at 4:53 AM, Eric Sunshine wrote:
> On Sat, Oct 12, 2013 at 3:04 AM, Felipe Contreras
> wrote:
>> Synonym for --index.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> Documentation/git-apply.txt | 5 -
>> builtin/apply.c | 2 ++
>> 2 files changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
>> index f605327..ce44327 100644
>> --- a/Documentation/git-apply.txt
>> +++ b/Documentation/git-apply.txt
>> @@ -12,7 +12,7 @@ SYNOPSIS
>> 'git apply' [--stat] [--numstat] [--summary] [--check] [--index] [--3way]
>> [--apply] [--no-add] [--build-fake-ancestor=] [-R |
>> --reverse]
>> [--allow-binary-replacement | --binary] [--reject] [-z]
>> - [-p] [-C] [--inaccurate-eof] [--recount] [--cached]
>> + [-p] [-C] [--inaccurate-eof] [--recount] [--cached|--staged]
>
> Here "staged".
>
>> [--ignore-space-change | --ignore-whitespace ]
>> [--whitespace=(nowarn|warn|fix|error|error-all)]
>> [--exclude=] [--include=] [--directory=]
>> @@ -67,6 +67,9 @@ OPTIONS
>> up-to-date, it is flagged as an error. This flag also
>> causes the index file to be updated.
>>
>> +--staged::
>> + Synonym for --index.
>> +
>
> Also "staged".
>
>> --cached::
>> Apply a patch without touching the working tree. Instead take the
>> cached data, apply the patch, and store the result in the index
>> diff --git a/builtin/apply.c b/builtin/apply.c
>> index 50912c9..42b5a4b 100644
>> --- a/builtin/apply.c
>> +++ b/builtin/apply.c
>> @@ -4377,6 +4377,8 @@ int cmd_apply(int argc, const char **argv, const char
>> *prefix_)
>> N_("instead of applying the patch, see if the patch
>> is applicable")),
>> OPT_BOOLEAN(0, "index", &check_index,
>> N_("make sure the patch is applicable to the current
>> index")),
>> + OPT_BOOLEAN(0, "stage", &check_index,
>
> But here "stage".
Right. Should be "staged".
--
Felipe Contreras
--
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
Re: [PATCH try2 09/14] apply: add --stage option
2013/10/13 Eric Sunshine : > Here "staged". ... > But here "stage". The inconsistency is weird, but isn't the term "staged" a bit odd with something that affects the future...? "Apply to the stage" seems a reasonable english phrasing, but "staged" seems more awkward... -miles -- Cat is power. Cat is peace. -- 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
Re: [PATCH try2 09/14] apply: add --stage option
On Sun, Oct 13, 2013 at 5:19 AM, Miles Bader wrote: > 2013/10/13 Eric Sunshine : >> Here "staged". > ... >> But here "stage". > > The inconsistency is weird, but isn't the term "staged" a bit odd with > something that affects the future...? > > "Apply to the stage" seems a reasonable english phrasing, but "staged" > seems more awkward... That's true, I was thinking since this was supposed to be a non-intrusive change, it would make sense to keep close to the --cached option, but the synonym is actually --index, not --cached. So --stage makes more sense from those two points of view. -- Felipe Contreras -- 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
[PATCH] mv: Fix spurious warning when moving a file in presence of submodules
In commit 0656781fa "git mv" learned to update the submodule path in the
.gitmodules file when moving a submodule in the work tree. But since that
commit update_path_in_gitmodules() gets called no matter if we moved a
submodule or a regular file, which is wrong and leads to a bogus warning
when moving a regular file in a repo containing a .gitmodules file:
warning: Could not find section in .gitmodules where path=
Fix that by only calling update_path_in_gitmodules() when moving a
submodule. To achieve that, we introduce the special SUBMODULE_WITH_GITDIR
define to distinguish the cases where we also have to connect work tree
and git directory from those where we only need to update the .gitmodules
setting.
A test for submodules using a .git directory together with a .gitmodules
file has been added to t7001. Even though newer git versions will always
use a gitfile when cloning submodules, repositories cloned with older git
versions will still use this layout.
Reported-by: Matthieu Moy
Signed-off-by: Jens Lehmann
---
Am 11.10.2013 19:53, schrieb Jens Lehmann:
> Am 11.10.2013 16:29, schrieb Matthieu Moy:
>> I'm getting this warning:
>>
>> warning: Could not find section in .gitmodules where path=XXX
>>
>> whenever I use "git mv" to move a file in a repository containing a
>> submodule. The file is outside the submodule and is completely
>> unrelated, so I do not understand the intent of the warning.
>>
>> My understanding (without looking at the code in detail) is that Git
>> tries to be clever about submodule renames, hence checks whether the
>> source file is a submodule. But then if the lookup fails, it should just
>> silently move on to "normal file move" mode I guess...
>
> Right. Thanks for reporting, I can reproduce that here and am currently
> looking into that.
And this is the fix for it, which I believe is stuff for maint.
builtin/mv.c | 13 +
t/t7001-mv.sh | 26 ++
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/builtin/mv.c b/builtin/mv.c
index aec79d1..2e0e61b 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -55,6 +55,7 @@ static const char *add_slash(const char *path)
}
static struct lock_file lock_file;
+#define SUBMODULE_WITH_GITDIR ((const char *)1)
int cmd_mv(int argc, const char **argv, const char *prefix)
{
@@ -132,6 +133,8 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
submodule_gitfile[i] =
read_gitfile(submodule_dotgit.buf);
if (submodule_gitfile[i])
submodule_gitfile[i] =
xstrdup(submodule_gitfile[i]);
+ else
+ submodule_gitfile[i] =
SUBMODULE_WITH_GITDIR;
strbuf_release(&submodule_dotgit);
} else {
const char *src_w_slash = add_slash(src);
@@ -230,10 +233,12 @@ int cmd_mv(int argc, const char **argv, const char
*prefix)
if (!show_only && mode != INDEX) {
if (rename(src, dst) < 0 && !ignore_errors)
die_errno (_("renaming '%s' failed"), src);
- if (submodule_gitfile[i])
- connect_work_tree_and_git_dir(dst,
submodule_gitfile[i]);
- if (!update_path_in_gitmodules(src, dst))
- gitmodules_modified = 1;
+ if (submodule_gitfile[i]) {
+ if (submodule_gitfile[i] !=
SUBMODULE_WITH_GITDIR)
+ connect_work_tree_and_git_dir(dst,
submodule_gitfile[i]);
+ if (!update_path_in_gitmodules(src, dst))
+ gitmodules_modified = 1;
+ }
}
if (mode == WORKING_DIRECTORY)
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index d432f42..b90e985 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -293,6 +293,32 @@ test_expect_success 'git mv moves a submodule with a .git
directory and no .gitm
git diff-files --quiet
'
+test_expect_success 'git mv moves a submodule with a .git directory and
.gitmodules' '
+ rm -rf mod &&
+ git reset --hard &&
+ git submodule update &&
+ entry="$(git ls-files --stage sub | cut -f 1)" &&
+ (
+ cd sub &&
+ rm -f .git &&
+ cp -a ../.git/modules/sub .git &&
+ GIT_WORK_TREE=. git config --unset core.worktree
+ ) &&
+ mkdir mod &&
+ git mv sub mod/sub &&
+ ! test -e sub &&
+ [ "$entry" = "$(git ls-files --stage mod/sub | cut -f 1)" ] &&
+ (
+ cd mod/sub &&
+ git status
+ ) &&
+ echo mod/sub >expected &&
+ git config -f .gitmodules submodule.sub.path >actual &&
+ test_cmp expected actu
[PATCH] .mailmap: switch to Thomas Rast's personal address
Normalize to my personal address, as my ETH addresses will expire soon. Also add my new corp account to be somewhat futureproof. Note that despite the private address being first, Google owns the copyright as long as I am employed there. Signed-off-by: Thomas Rast --- .mailmap | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/.mailmap b/.mailmap index 1c1f5ec..11057cb 100644 --- a/.mailmap +++ b/.mailmap @@ -218,7 +218,9 @@ Tay Ray Chuan Ted Percival Theodore Ts'o Thomas Ackermann -Thomas Rast +Thomas Rast +Thomas Rast +Thomas Rast Timo Hirvonen Toby Allsopp Tom Grennan -- 1.8.4.1.661.g6b832f5 -- 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
Re: [PATCH] mv: Fix spurious warning when moving a file in presence of submodules
Jens Lehmann writes: > static struct lock_file lock_file; > +#define SUBMODULE_WITH_GITDIR ((const char *)1) I don't like very much hardcoded addresses like this. Are you 100% sure address 1 will never be returned by xstrdup on any platform? The risk is small if not negligible, but I'm unconfortable with this. Isn't there an alternative (NULL, or empty string) that is guaranteed to never happen? > +test_expect_success 'git mv moves a submodule with a .git directory and > .gitmodules' ' This doesn't seem to test the problem I was having (move a file, not a submodule). Is this intentional? In any case, this fixes my problem, thanks! -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
Re: [PATCH] mv: Fix spurious warning when moving a file in presence of submodules
Am 13.10.2013 17:05, schrieb Matthieu Moy: > Jens Lehmann writes: > >> static struct lock_file lock_file; >> +#define SUBMODULE_WITH_GITDIR ((const char *)1) > > I don't like very much hardcoded addresses like this. Are you 100% sure > address 1 will never be returned by xstrdup on any platform? The risk is > small if not negligible, but I'm unconfortable with this. Isn't there an > alternative (NULL, or empty string) that is guaranteed to never happen? All alternatives I could think of would require an extra array storing that information, which I dismissed for performance and memory footprint reasons (NULL is already taken for not being a submodule). I think 1 is one of the safest hard coded addresses as on sane systems accessing the zeropage will trigger a segfault. And if someday someone wants to free the memory I expect the special casing of 1 to be rather obvious. But I'm open to alternatives and would change that if people disagree. >> +test_expect_success 'git mv moves a submodule with a .git directory and >> .gitmodules' ' > > This doesn't seem to test the problem I was having (move a file, not a > submodule). Is this intentional? Yes. The first idea was to simply move the update_path_in_gitmodules() into the "if (submodule_gitfile[i])"-block, but that would have resulted in not updating .gitmodules for submodules with a .git directory, which I would consider a bug. So I thought this was worth an extra test case, while I wasn't sure testing mv of a regular file to not issue a warning is a very useful test case in submodule context. > In any case, this fixes my problem, thanks! Sure, glad to help and thanks for testing! -- 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
Re: [PATCH] clone: local URLs are not for ssh
On 05.10.13 21:48, Torsten Bögershausen wrote:
> On 2013-10-03 03.31, Jeff King wrote:
>>
>> http://article.gmane.org/gmane.comp.version-control.git/235473
What do we think about extending the test a little bit:
git diff 771cf1dab9303bab3c8198b8b6 -- t5602-clone-remote-exec.sh
diff --git a/t/t5602-clone-remote-exec.sh b/t/t5602-clone-remote-exec.sh
index 3f353d9..790896f 100755
--- a/t/t5602-clone-remote-exec.sh
+++ b/t/t5602-clone-remote-exec.sh
@@ -30,5 +30,124 @@ test_expect_success 'clone calls specified git upload-pack
with -u option' '
echo "localhost ./something/bin/git-upload-pack '\''/path/to/repo'\''"
>expected &&
test_cmp expected not_ssh_output
'
+test_expect_success 'setup ssh wrapper' '
+ write_script "$TRASH_DIRECTORY/ssh-wrapper" <<-\EOF &&
+ echo >>"$TRASH_DIRECTORY/ssh-output" "ssh: $*" &&
+ # throw away all but the last argument, which should be the
+ # command
+ while test $# -gt 1; do shift; done
+ eval "$1"
+ EOF
+
+ GIT_SSH="$TRASH_DIRECTORY/ssh-wrapper" &&
+ export GIT_SSH &&
+ export TRASH_DIRECTORY
+'
+
+clear_ssh () {
+ >"$TRASH_DIRECTORY/ssh-output"
+}
+
+expect_ssh () {
+ {
+ case "$1" in
+ none)
+ ;;
+ *)
+ echo "ssh: $1 git-upload-pack '$2'"
+ esac
+ } >"$TRASH_DIRECTORY/ssh-expect" &&
+ (cd "$TRASH_DIRECTORY" && test_cmp ssh-expect ssh-output)
+}
+
+test_expect_success 'create src.git' '
+ mkdir src.git &&
+ (
+ cd src.git &&
+ git init &&
+ >file &&
+ git add file &&
+ git commit -m "add file"
+ )
+'
+
+# git clone could fail, so break the && chain and ignore the exit code
+# clone local
+test_expect_success './foo:bar is not ssh' '
+ clear_ssh &&
+ git clone "./foo:bar" foobar
+ expect_ssh none
+'
+
+test_expect_success './[nohost:123]:src is not ssh' '
+ clear_ssh &&
+ git clone "./[nohost:123]:src" 1_2_3
+ expect_ssh none
+'
+
+test_expect_success '[nohost:234] is not ssh' '
+ clear_ssh &&
+ git clone "[nohost:234]" 2_3_4
+ expect_ssh none
+'
+
+test_expect_success ':345 is not ssh' '
+ clear_ssh &&
+ git clone ":345" 3_4_5
+ expect_ssh none
+'
+
+test_expect_success '456: is not ssh' '
+ clear_ssh &&
+ git clone "456:" 4_5_6
+ expect_ssh none
+'
+
+# clone via ssh
+# the expect_ssh checks that git clone tried to use ssh
+test_expect_success 'myhost:567 is ssh' '
+ clear_ssh &&
+ git clone myhost:567 myhost_567
+ expect_ssh myhost 567
+'
+
+test_expect_success '[myhost:678]:src is ssh' '
+ clear_ssh &&
+ git clone "[myhost:678]:src" myhost_678
+ expect_ssh myhost:678 src
+'
+
+#clone url looks like ssh, but is on disk
+test_expect_success SYMLINKS 'dir:123 on disk' '
+ clear_ssh &&
+ ln -s src.git dir:123 &&
+ git clone dir:123 dir_123 &&
+ expect_ssh none
+'
+
+test_expect_success SYMLINKS '[dir:234]:src on disk' '
+ clear_ssh &&
+ ln -s src.git [dir:234]:src &&
+ git clone [dir:234]:src dir_234_src &&
+ expect_ssh none
+'
+
+test_expect_success 'ssh://host.xz/~user/repo' '
+ clear_ssh &&
+ git clone "ssh://host.xz/~user/repo" user-repo
+ expect_ssh host.xz "~user/repo"
+'
+
+test_expect_success 'ssh://host.xz:22/~user/repo' '
+ clear_ssh &&
+ git clone "ssh://host.xz:22/~user/repo" user-repo
+ expect_ssh "-p 22 host.xz" "~user/repo"
+'
+
+test_expect_success 'ssh://[::1]:22/~user/repo' '
+ clear_ssh &&
+ git clone "ssh://[::1]:22/~user/repo" user-repo6
+ expect_ssh "-p 22 ::1" "~user/repo"
+'
test_done
==
And we need this on top of Duys patch:
diff --git a/connect.c b/connect.c
index e8473f3..09be2b3 100644
--- a/connect.c
+++ b/connect.c
@@ -611,7 +611,7 @@ struct child_process *git_connect(int fd[2], const char
*url_orig,
end = host;
path = strchr(end, c);
- if (path && !has_dos_drive_prefix(end)) {
+ if (path && host != path && !has_dos_drive_prefix(end)) {
if (c == ':') {
if (host != url || path < strchrnul(host, '/')) {
protocol = PROTO_SSH;
--
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
Re: [PATCH v3] diff.c: keep arrow(=>) on show_stats()'s shortened filename part to make rename visible.
Hi,
Yoshioka Tsuneo writes:
> "git diff -M --stat" can detect rename and show renamed file name like
> "foofoofoo => barbarbar", but if destination filename is long the line
> is shortened like "...barbarbar" so there is no way to know whether the
> file is renamed or existed in the source commit.
Thanks for your patch! I think this is indeed something that should be
fixed.
Can you explain the algorithm chosen in the commit message or a block
comment in the code? I find it much easier to follow large code blocks
(like the one you added) with a prior notion of what it tries to do.
[As an aside, Documentation/SubmittingPatches says
The body should provide a meaningful commit message, which:
. explains the problem the change tries to solve, iow, what is wrong
with the current code without the change.
. justifies the way the change solves the problem, iow, why the
result with the change is better.
. alternate solutions considered but discarded, if any.
Observe that you explained the first item very well, but not the
others.]
> This commit makes it visible like "...foo => ...bar".
Also, you should rewrite this to be in the imperative mood:
Make sure there is always an arrow, e.g., "...foo => ...bar".
or some such.
[Again from SubmittingPatches:
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behaviour.]
> Signed-off-by: Tsuneo Yoshioka
> ---
> diff.c | 58 +++---
> 1 file changed, 51 insertions(+), 7 deletions(-)
Can you add a test? Perhaps like the one below. (You can squash it
into your commit if you like it.)
Note that in the test, the generated line looks like this:
{..._does_not_fit_in_a_single_line => .../path1 | 0
I don't want to go all bikesheddey, but I think it's somewhat
unfortunate that the elided parts do not correspond to each other. In
particular, I think the closing brace should not be omitted. Perhaps
something like this would be ideal (making it up on the spot, don't
count characters):
{...a_single_line => ..._as_the_first}/path1 | 0
diff --git a/t/t4001-diff-rename.sh b/t/t4001-diff-rename.sh
index 2f327b7..03d6371 100755
--- a/t/t4001-diff-rename.sh
+++ b/t/t4001-diff-rename.sh
@@ -156,4 +156,16 @@ test_expect_success 'rename pretty print common prefix and
suffix overlap' '
test_i18ngrep " d/f/{ => f}/e " output
'
+test_expect_success 'rename of very long path shows =>' '
+ mkdir long_dirname_that_does_not_fit_in_a_single_line &&
+ mkdir another_extremely_long_path_but_not_the_same_as_the_first &&
+ cp path1 long_dirname*/ &&
+ git add long_dirname*/path1 &&
+ test_commit add_long_pathname &&
+ git mv long_dirname*/path1 another_extremely_*/ &&
+ test_commit move_long_pathname &&
+ git diff -M --stat HEAD^ HEAD >output &&
+ test_i18ngrep "=>.*path1" output
+'
+
test_done
--
Thomas Rast
t...@thomasrast.ch
--
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
Best practices on updating documentation?
If I'm going to be adding an option to a command, should I update the documentation in the same commit or in a separate commit? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Best practices on updating documentation?
On Sun, Oct 13, 2013 at 08:42:40PM +, brian m. carlson wrote: > If I'm going to be adding an option to a command, should I update the > documentation in the same commit or in a separate commit? I would say the same commit, where it can help a reviewer see the code change in the context of the expected user-facing behaviour. -- 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
Re: [PATCH v4 2/2] version-gen: fix versions
On Sat, Oct 12, 2013 at 12:07 AM, Felipe Contreras
wrote:
> Virtually all packaging guidelines would prefer 1.8.4~rc1, over
> 1.8.4.rc1 or 1.8.4-rc1, so it makes sense to use that instead.
>
> In particular, the only packaging we provide, git.spec, generates a
> wrong version, because git-1.8.4 < git-1.8.4.rc1, changing to ~rc1 fixes
> the problem as it's considered newer.
>
> The same happens in dpkg.
>
> Signed-off-by: Felipe Contreras
> ---
> GIT-VERSION-GEN | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
> index e96538d..c04c4de 100755
> --- a/GIT-VERSION-GEN
> +++ b/GIT-VERSION-GEN
> @@ -28,7 +28,7 @@ then
> VN=$(cat version) || VN="$DEF_VER"
> elif test -d ${GIT_DIR:-.git} -o -f .git && describe
> then
> - VN=$(echo "$VN" | sed -e 's/-/./g')
> + VN=$(echo "$VN" | sed -e 's/-/~/g')
> else
> VN="$DEF_VER"
> fi
> --
This seems related:
http://lintian.debian.org/tags/rc-version-greater-than-expected-version.html
Should the RC tags in the Git repo be named v1.2.3~rc4 (tilde-rc#)
instead of dash-rc#, or does that not matter?
If so, would that change anything about this patch, or is it better to
normalize it all here?
The input is subtly different sometimes so I'm curious whether whether
"~" is preferred in all cases (particularly, by all package managers).
e.g.
$ git describe v1.5.0^
v1.5.0-rc4-372-g26cfcfb
$ git describe v1.5.0.1^
v1.5.0-27-g38eb932
--
David
--
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
Re: [PATCH v3] mergetools/diffmerge: support DiffMerge as a git mergetool
Stefan Saasen wrote: > Signed-off-by: Stefan Saasen > Acked-by: David Aguilar Thanks. -- 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
Re: [PATCH v4 1/3] test: use unambigous leading path (/foo) for mingw
2013/10/11 Sebastian Schuberth : >> In test cases for relative_path, path with one leading character >> (such as /a, /x) may be recogonized as "a:/" or "x:/" if there is >> such DOS drive on MINGW platform. Use an umambigous leading path >> "/foo" instead. >> >> Also change two leading slashes (//) to three leading slashes (///), >> otherwize it will be recognized as UNC name on MINGW platform. > > Note that the path mangling comes from MSYS [1], not MinGW, so you should > place "MINGW" with "MSYS" in several places. As a side-note, the official > spelling is "MinGW", not "MINGW". > I will make a reroll. s/MINGW/MSYS/i >> -relative_path /a/b/c/ /a/b/ c/ > > >> +relative_path /foo/a/b/c/ /foo/a/b/ c/ > > > Wouldn't it have been more straight-forward to just replace "a" with "foo", > "b" with "bar" and "c" with "baz" (or whatever)? So that the first line > would say > > relative_path /foo/bar/baz/ /foo/bar/ baz/ > These test cases have been used in some commit logs, such as commit: v1.8.3-rc2-13-gad66df2. And for me (a non-English speaker) a,b,c,x,y,z are more readable than bar, baz, qux, ... -- Jiang Xin -- 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
[PATCH v5 0/3] relative path regression fix
Update since v4: * Update commit logs with the help from Sebastian Schuberth: s/MINGW/MSYS/i s/dos-driver-prefix/dos-drive-prefix/ Jiang Xin (3): test: use unambigous leading path (/foo) for MSYS relative_path should honor dos-drive-prefix Use simpler relative_path when set_git_dir cache.h | 1 + path.c| 65 +++ setup.c | 5 +--- t/t0060-path-utils.sh | 60 +-- 4 files changed, 99 insertions(+), 32 deletions(-) -- 1.8.4 -- 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
[PATCH v5 2/3] relative_path should honor dos-drive-prefix
Tvangeste found that the "relative_path" function could not work
properly on Windows if "in" and "prefix" have DOS drive prefix
(such as "C:/windows"). ($gmane/234434)
E.g., When execute: test-path-utils relative_path "C:/a/b" "D:/x/y",
should return "C:/a/b", but returns "../../C:/a/b", which is wrong.
So make relative_path honor DOS drive prefix, and add test cases
for it in t0060.
Reported-by: Tvangeste
Helped-by: Johannes Sixt
Signed-off-by: Jiang Xin
Signed-off-by: Junio C Hamano
---
path.c| 20
t/t0060-path-utils.sh | 4
2 files changed, 24 insertions(+)
diff --git a/path.c b/path.c
index 7f3324a..0c16dc5 100644
--- a/path.c
+++ b/path.c
@@ -441,6 +441,16 @@ int adjust_shared_perm(const char *path)
return 0;
}
+static int have_same_root(const char *path1, const char *path2)
+{
+ int is_abs1, is_abs2;
+
+ is_abs1 = is_absolute_path(path1);
+ is_abs2 = is_absolute_path(path2);
+ return (is_abs1 && is_abs2 && tolower(path1[0]) == tolower(path2[0])) ||
+ (!is_abs1 && !is_abs2);
+}
+
/*
* Give path as relative to prefix.
*
@@ -461,6 +471,16 @@ const char *relative_path(const char *in, const char
*prefix,
else if (!prefix_len)
return in;
+ if (have_same_root(in, prefix)) {
+ /* bypass dos_drive, for "c:" is identical to "C:" */
+ if (has_dos_drive_prefix(in)) {
+ i = 2;
+ j = 2;
+ }
+ } else {
+ return in;
+ }
+
while (i < prefix_len && j < in_len && prefix[i] == in[j]) {
if (is_dir_sep(prefix[i])) {
while (is_dir_sep(prefix[i]))
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index 92976e0..40dfa2d 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -210,6 +210,10 @@ relative_path foo/a/b/ foo/a/b ./
relative_path foo/afoo/a/b ../
relative_path foo/x/y foo/a/b ../../x/y
relative_path foo/a/c foo/a/b ../c
+relative_path foo/a/b /foo/x/yfoo/a/b
+relative_path /foo/a/b foo/x/y /foo/a/b
+relative_path d:/a/b D:/a/c ../bMINGW
+relative_path C:/a/b D:/a/c C:/a/b MINGW
relative_path foo/a/b "" foo/a/b
relative_path foo/a/b ""foo/a/b
relative_path ""/foo/a/b./
--
1.8.4
--
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
[PATCH v5 1/3] test: use unambigous leading path (/foo) for MSYS
In test cases for relative_path, path with one leading character (such as /a, /x) may be recogonized as "a:/" or "x:/" if there is such DOS drive on MSYS platform. Use an umambigous leading path "/foo" instead. Also change two leading slashes (//) to three leading slashes (///), otherwize it will be recognized as UNC name on MSYS platform. Signed-off-by: Jiang Xin Signed-off-by: Junio C Hamano --- t/t0060-path-utils.sh | 56 +-- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh index 3a48de2..92976e0 100755 --- a/t/t0060-path-utils.sh +++ b/t/t0060-path-utils.sh @@ -190,33 +190,33 @@ test_expect_success SYMLINKS 'real path works on symlinks' ' test "$sym" = "$(test-path-utils real_path "$dir2/syml")" ' -relative_path /a/b/c/ /a/b/ c/ -relative_path /a/b/c/ /a/bc/ -relative_path /a//b//c///a/b// c/ POSIX -relative_path /a/b /a/b./ -relative_path /a/b//a/b./ -relative_path /a /a/b../ -relative_path //a/b/ ../../ -relative_path /a/c /a/b/ ../c -relative_path /a/c /a/b../c -relative_path /x/y /a/b/ ../../x/y -relative_path /a/b "" /a/b -relative_path /a/b ""/a/b -relative_path a/b/c/ a/b/c/ -relative_path a/b/c/ a/b c/ -relative_path a/b//c a//bc -relative_path a/b/ a/b/./ -relative_path a/b/ a/b ./ -relative_path aa/b ../ -relative_path x/y a/b ../../x/y -relative_path a/c a/b ../c -relative_path a/b "" a/b -relative_path a/b ""a/b -relative_path ""/a/b./ -relative_path """" ./ -relative_path """"./ -relative_path "" "" ./ -relative_path "" ""./ -relative_path "" /a/b./ +relative_path /foo/a/b/c/ /foo/a/b/ c/ +relative_path /foo/a/b/c/ /foo/a/bc/ +relative_path /foo/a//b//c////foo/a/b//c/ POSIX +relative_path /foo/a/b /foo/a/b./ +relative_path /foo/a/b//foo/a/b./ +relative_path /foo/a /foo/a/b../ +relative_path //foo/a/b/ ../../../ +relative_path /foo/a/c /foo/a/b/ ../c +relative_path /foo/a/c /foo/a/b../c +relative_path /foo/x/y /foo/a/b/ ../../x/y +relative_path /foo/a/b "" /foo/a/b +relative_path /foo/a/b ""/foo/a/b +relative_path foo/a/b/c/ foo/a/b/c/ +relative_path foo/a/b/c/ foo/a/b c/ +relative_path foo/a/b//c foo/a//bc +relative_path foo/a/b/ foo/a/b/./ +relative_path foo/a/b/ foo/a/b ./ +relative_path foo/afoo/a/b ../ +relative_path foo/x/y foo/a/b ../../x/y +relative_path foo/a/c foo/a/b ../c +relative_path foo/a/b "" foo/a/b +relative_path foo/a/b ""foo/a/b +relative_path ""/foo/a/b./ +relative_path """" ./ +relative_path """"./ +relative_path "" "" ./ +relative_path "" ""./ +relative_path "" /foo/a/b./ test_done -- 1.8.4 -- 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
[PATCH v5 3/3] Use simpler relative_path when set_git_dir
Using a relative_path as git_dir first appears in v1.5.6-1-g044bbbc.
It will make git_dir shorter only if git_dir is inside work_tree,
and this will increase performance. But my last refactor effort on
relative_path function (commit v1.8.3-rc2-12-ge02ca72) changed that.
Always use relative_path as git_dir may bring troubles like
$gmane/234434.
Because new relative_path is a combination of original relative_path
from path.c and original path_relative from quote.c, so in order to
restore the origin implementation, save the original relative_path
as remove_leading_path, and call it in setup.c.
Suggested-by: Karsten Blees
Signed-off-by: Jiang Xin
Signed-off-by: Junio C Hamano
---
cache.h | 1 +
path.c | 45 +
setup.c | 5 +
3 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/cache.h b/cache.h
index 8e42256..94475bd 100644
--- a/cache.h
+++ b/cache.h
@@ -737,6 +737,7 @@ int is_directory(const char *);
const char *real_path(const char *path);
const char *real_path_if_valid(const char *path);
const char *absolute_path(const char *path);
+const char *remove_leading_path(const char *in, const char *prefix);
const char *relative_path(const char *in, const char *prefix, struct strbuf
*sb);
int normalize_path_copy(char *dst, const char *src);
int longest_ancestor_length(const char *path, struct string_list *prefixes);
diff --git a/path.c b/path.c
index 0c16dc5..fa62da5 100644
--- a/path.c
+++ b/path.c
@@ -558,6 +558,51 @@ const char *relative_path(const char *in, const char
*prefix,
}
/*
+ * A simpler implementation of relative_path
+ *
+ * Get relative path by removing "prefix" from "in". This function
+ * first appears in v1.5.6-1-g044bbbc, and makes git_dir shorter
+ * to increase performance when traversing the path to work_tree.
+ */
+const char *remove_leading_path(const char *in, const char *prefix)
+{
+ static char buf[PATH_MAX + 1];
+ int i = 0, j = 0;
+
+ if (!prefix || !prefix[0])
+ return in;
+ while (prefix[i]) {
+ if (is_dir_sep(prefix[i])) {
+ if (!is_dir_sep(in[j]))
+ return in;
+ while (is_dir_sep(prefix[i]))
+ i++;
+ while (is_dir_sep(in[j]))
+ j++;
+ continue;
+ } else if (in[j] != prefix[i]) {
+ return in;
+ }
+ i++;
+ j++;
+ }
+ if (
+ /* "/foo" is a prefix of "/foo" */
+ in[j] &&
+ /* "/foo" is not a prefix of "/foobar" */
+ !is_dir_sep(prefix[i-1]) && !is_dir_sep(in[j])
+ )
+ return in;
+ while (is_dir_sep(in[j]))
+ j++;
+ if (!in[j])
+ strcpy(buf, ".");
+ else
+ strcpy(buf, in + j);
+ return buf;
+}
+
+/*
* It is okay if dst == src, but they should not overlap otherwise.
*
* Performs the following normalizations on src, storing the result in dst:
diff --git a/setup.c b/setup.c
index 0d9ea62..dad39c1 100644
--- a/setup.c
+++ b/setup.c
@@ -360,7 +360,6 @@ int is_inside_work_tree(void)
void setup_work_tree(void)
{
- struct strbuf sb = STRBUF_INIT;
const char *work_tree, *git_dir;
static int initialized = 0;
@@ -380,10 +379,8 @@ void setup_work_tree(void)
if (getenv(GIT_WORK_TREE_ENVIRONMENT))
setenv(GIT_WORK_TREE_ENVIRONMENT, ".", 1);
- set_git_dir(relative_path(git_dir, work_tree, &sb));
+ set_git_dir(remove_leading_path(git_dir, work_tree));
initialized = 1;
-
- strbuf_release(&sb);
}
static int check_repository_format_gently(const char *gitdir, int *nongit_ok)
--
1.8.4
--
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
Re: [PATCH v4 2/2] version-gen: fix versions
On Sun, Oct 13, 2013 at 4:56 PM, David Aguilar wrote:
> On Sat, Oct 12, 2013 at 12:07 AM, Felipe Contreras
> wrote:
>> Virtually all packaging guidelines would prefer 1.8.4~rc1, over
>> 1.8.4.rc1 or 1.8.4-rc1, so it makes sense to use that instead.
>>
>> In particular, the only packaging we provide, git.spec, generates a
>> wrong version, because git-1.8.4 < git-1.8.4.rc1, changing to ~rc1 fixes
>> the problem as it's considered newer.
>>
>> The same happens in dpkg.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> GIT-VERSION-GEN | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
>> index e96538d..c04c4de 100755
>> --- a/GIT-VERSION-GEN
>> +++ b/GIT-VERSION-GEN
>> @@ -28,7 +28,7 @@ then
>> VN=$(cat version) || VN="$DEF_VER"
>> elif test -d ${GIT_DIR:-.git} -o -f .git && describe
>> then
>> - VN=$(echo "$VN" | sed -e 's/-/./g')
>> + VN=$(echo "$VN" | sed -e 's/-/~/g')
>> else
>> VN="$DEF_VER"
>> fi
>> --
>
> This seems related:
>
> http://lintian.debian.org/tags/rc-version-greater-than-expected-version.html
>
> Should the RC tags in the Git repo be named v1.2.3~rc4 (tilde-rc#)
> instead of dash-rc#, or does that not matter?
I thought so first, but then I realized ~ is not allowed in a ref.
> If so, would that change anything about this patch, or is it better to
> normalize it all here?
>
> The input is subtly different sometimes so I'm curious whether whether
> "~" is preferred in all cases (particularly, by all package managers).
> e.g.
All package managers I investigated do handle ~ specially, and thus
recommend it for rc versioning, except pacman. So in pacman,
v1.5.0~rc4 would remain newer than v1.5.0, but that's not different
from the current situation, and there isn't much we can do about that.
> $ git describe v1.5.0^
> v1.5.0-rc4-372-g26cfcfb
>
> $ git describe v1.5.0.1^
> v1.5.0-27-g38eb932
At least both in RPM and dpkg, 1.5.0~27 is newer than 1.5.0~rc4.
--
Felipe Contreras
--
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
Re: [PATCH v4 2/2] version-gen: fix versions
Hi, David Aguilar wrote: > Felipe Contreras wrote: >> Virtually all packaging guidelines would prefer 1.8.4~rc1, over >> 1.8.4.rc1 or 1.8.4-rc1, so it makes sense to use that instead. >> >> In particular, the only packaging we provide, git.spec, generates a >> wrong version, because git-1.8.4 < git-1.8.4.rc1, changing to ~rc1 fixes >> the problem as it's considered newer. A more conservative fix would be to tweak the .spec generation in the Makefile to follow whatever the appropriate Red Hat convention is. For example, something like this: -- >8 -- diff --git i/Makefile w/Makefile index 0f931a2..73bd89d 100644 --- i/Makefile +++ w/Makefile @@ -2385,8 +2385,9 @@ quick-install-html: ### Maintainer's dist rules +GIT_VERSION_RPM = $(subst -rc,~rc,$(GIT_VERSION)) git.spec: git.spec.in GIT-VERSION-FILE - sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@+ + sed -e 's/@@VERSION@@/$(GIT_VERSION_RPM)/g' < $< > $@+ mv $@+ $@ GIT_TARNAME = git-$(GIT_VERSION) -- 8< -- That way, programs that parse the git version by splitting at '.' (there are more than a few, unfortunately) would continue to work, but the packaging system would get the benefit of the proposed versioning style change. >> The same happens in dpkg. Have you tested this? I thought the Debian packaging did not use the GIT-VERSION-GEN generated version in this way. [...] > This seems related: > > http://lintian.debian.org/tags/rc-version-greater-than-expected-version.html If I understand correctly, that page has an exhaustive list of affected packages in the Debian archive and doesn't include git. Thanks and hope that helps, Jonathan -- 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
Re: [PATCH gitk 0/4] gitk support for git log -L
Thomas Rast wrote: > Junio C Hamano writes: >> Thomas Rast writes: >>> Existing gitk chokes on 'gitk -S foo', but works with 'git -Sfoo'. >> >> I somehow thought that we encourage the "stuck/sticked" form, to >> reduce things the users need to remember to cope better with options >> with optional value. > > I just looked into this again, to get it rolling. > > Am I reading you correctly as saying that any support for the unstuck > form is entirely coincidental, and it's okay to support only the stuck > version in new gitk? Sort of. :) gitcli(7) says that the sticked form is to be preferred "when you are scripting git". But most git commands use parse-options, which of course supports both forms and makes life easier for humans. Support for just the sticked form is better than nothing, especially if the gitk(1) manpage gains a note about it. In the long run I guess the ideal would be to add a parse-options-like library to the tcl support. My two cents, Jonathan -- 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
Re: [PATCH] http: enable keepalive on TCP sockets
Daniel Stenberg wrote: > On Sat, 12 Oct 2013, Eric Wong wrote: > > >This is a follow up to commit > >e47a8583a20256851e7fc882233e3bd5bf33dc6e (enable SO_KEEPALIVE for > >connected TCP sockets). > > Just keep in mind that TCP keep-alive is enabled in awkwardly many > different ways on different systems and this patch only supports one > of them. Feel free to take inspiration from libcurl's source code > for doing this. See: > > https://github.com/bagder/curl/blob/master/lib/connect.c#L108 Thanks. I think the Linux-specific TCP_KEEP* knobs are overkill for git. (since this is mainly for non-interactive users, I went at least a day before realizing the process was stuck on my machine). I cannot comment on the knobs for other OSes. -- 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
Re: [PATCH v4 2/2] version-gen: fix versions
On Mon, Oct 14, 2013 at 12:01 AM, Jonathan Nieder wrote: > Hi, > > David Aguilar wrote: >> Felipe Contreras wrote: > >>> Virtually all packaging guidelines would prefer 1.8.4~rc1, over >>> 1.8.4.rc1 or 1.8.4-rc1, so it makes sense to use that instead. >>> >>> In particular, the only packaging we provide, git.spec, generates a >>> wrong version, because git-1.8.4 < git-1.8.4.rc1, changing to ~rc1 fixes >>> the problem as it's considered newer. > > A more conservative fix would be to tweak the .spec generation in the > Makefile to follow whatever the appropriate Red Hat convention is. > For example, something like this: It's not Red Hat's convention, it's RPM, and dpkg, so basically every package manager that most distributions out there use. And I already sent a patch for that which was ignored: http://article.gmane.org/gmane.comp.version-control.git/234794 > -- >8 -- > diff --git i/Makefile w/Makefile > index 0f931a2..73bd89d 100644 > --- i/Makefile > +++ w/Makefile > @@ -2385,8 +2385,9 @@ quick-install-html: > > ### Maintainer's dist rules > > +GIT_VERSION_RPM = $(subst -rc,~rc,$(GIT_VERSION)) That wouldn't work; VERSION doesn't have '-rc', it has '.rc'. and what's the point of creating a new variable? It's a was of space. > git.spec: git.spec.in GIT-VERSION-FILE > - sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@+ > + sed -e 's/@@VERSION@@/$(GIT_VERSION_RPM)/g' < $< > $@+ > mv $@+ $@ > > GIT_TARNAME = git-$(GIT_VERSION) > -- 8< -- > > That way, programs that parse the git version by splitting at '.' > (there are more than a few, unfortunately) would continue to work, Do you have any evidence that such programs exist? Specifically, programs that work with 1.8.4.rc1, but not 1.8.4-rc1 or 1.8.4~rc1. I find that very very very unlikely. Anyway, in the very very very unlikely scenario that somebody's script does break they can report that, and we can revert. What's the problem? > but > the packaging system would get the benefit of the proposed versioning > style change. > >>> The same happens in dpkg. > > Have you tested this? % dpkg --compare-versions 1.8.4 gt 1.8.4~rc1 && echo yes || echo no yes % dpkg --compare-versions 1.8.4 gt 1.8.4-rc1 && echo yes || echo no no > I thought the Debian packaging did not use the > GIT-VERSION-GEN generated version in this way. It doesn't matter. The name of the package would be git-1.8.4~rc1, and 'git --version' would return 1.8.4.rc1, that's inconsistent. Why be inconsistent when we can be consistent? > [...] >> This seems related: >> >> http://lintian.debian.org/tags/rc-version-greater-than-expected-version.html > > If I understand correctly, that page has an exhaustive list of affected > packages in the Debian archive and doesn't include git. Because a) they don't package release candidates, and b) they use a different version (s/\./~/). -- Felipe Contreras -- 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
Re: [PATCH] mv: Fix spurious warning when moving a file in presence of submodules
Matthieu Moy wrote: > Jens Lehmann writes: >> static struct lock_file lock_file; >> +#define SUBMODULE_WITH_GITDIR ((const char *)1) > > I don't like very much hardcoded addresses like this. Are you 100% sure > address 1 will never be returned by xstrdup on any platform? The risk is > small if not negligible, but I'm unconfortable with this. I haven't checked what the standards say, but in practice I think it's okay. An alternative would be to do something like static const char SUBMODULE_WITH_GITDIR[] = "*** (submodule with gitdir) ***"; which is a bit more error-prone because attempts to use it as a string wouldn't crash. We use (void *) 1 in the same way a few places currently. Thanks, both. -- 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
Re: [PATCH v5 1/3] test: use unambigous leading path (/foo) for MSYS
On Mon, Oct 14, 2013 at 4:29 AM, Jiang Xin wrote: > In test cases for relative_path, path with one leading character > (such as /a, /x) may be recogonized as "a:/" or "x:/" if there is > such DOS drive on MSYS platform. Use an umambigous leading path > "/foo" instead. > > Also change two leading slashes (//) to three leading slashes (///), > otherwize it will be recognized as UNC name on MSYS platform. > > Signed-off-by: Jiang Xin > Signed-off-by: Junio C Hamano > --- > t/t0060-path-utils.sh | 56 > +-- > 1 file changed, 28 insertions(+), 28 deletions(-) Thanks, ack. -- Sebastian Schuberth -- 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
