date:20151123

From: GIRARD Etienne 

When "p4 submit" command fails in P4Submit.applyCommit, the
workspace is left with the changes.  We already have code to revert
the changes to the workspace when the user decides to cancel
submission by aborting the editor that edits the change description,
and we should treat the "p4 submit" failure the same way.

Clean the workspace if p4_write_pipe raised SystemExit, so that the
user don't have to do it themselves.

Signed-off-by: GIRARD Etienne 
Signed-off-by: Junio C Hamano 
Signed-off-by: Luke Diamand 
---
 git-p4.py| 71 +---
 t/t9807-git-p4-submit.sh |  2 +-
 2 files changed, 38 insertions(+), 35 deletions(-)

diff --git a/git-p4.py b/git-p4.py
index 0093fa3..d535904 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1538,44 +1538,47 @@ class P4Submit(Command, P4UserMap):
 #
 # Let the user edit the change description, then submit it.
 #
-if self.edit_template(fileName):
-# read the edited message and submit
-ret = True
-tmpFile = open(fileName, "rb")
-message = tmpFile.read()
-tmpFile.close()
-if self.isWindows:
-message = message.replace("\r\n", "\n")
-submitTemplate = message[:message.index(separatorLine)]
-p4_write_pipe(['submit', '-i'], submitTemplate)
-
-if self.preserveUser:
-if p4User:
-# Get last changelist number. Cannot easily get it from
-# the submit command output as the output is
-# unmarshalled.
-changelist = self.lastP4Changelist()
-self.modifyChangelistUser(changelist, p4User)
-
-# The rename/copy happened by applying a patch that created a
-# new file.  This leaves it writable, which confuses p4.
-for f in pureRenameCopy:
-p4_sync(f, "-f")
+submitted = False
 
-else:
+try:
+if self.edit_template(fileName):
+# read the edited message and submit
+tmpFile = open(fileName, "rb")
+message = tmpFile.read()
+tmpFile.close()
+if self.isWindows:
+message = message.replace("\r\n", "\n")
+submitTemplate = message[:message.index(separatorLine)]
+p4_write_pipe(['submit', '-i'], submitTemplate)
+
+if self.preserveUser:
+if p4User:
+# Get last changelist number. Cannot easily get it from
+# the submit command output as the output is
+# unmarshalled.
+changelist = self.lastP4Changelist()
+self.modifyChangelistUser(changelist, p4User)
+
+# The rename/copy happened by applying a patch that created a
+# new file.  This leaves it writable, which confuses p4.
+for f in pureRenameCopy:
+p4_sync(f, "-f")
+submitted = True
+
+finally:
 # skip this patch
-ret = False
-print "Submission cancelled, undoing p4 changes."
-for f in editedFiles:
-p4_revert(f)
-for f in filesToAdd:
-p4_revert(f)
-os.remove(f)
-for f in filesToDelete:
-p4_revert(f)
+if not submitted:
+print "Submission cancelled, undoing p4 changes."
+for f in editedFiles:
+p4_revert(f)
+for f in filesToAdd:
+p4_revert(f)
+os.remove(f)
+for f in filesToDelete:
+p4_revert(f)
 
 os.remove(fileName)
-return ret
+return submitted
 
 # Export git tags as p4 labels. Create a p4 label and then tag
 # with that.
diff --git a/t/t9807-git-p4-submit.sh b/t/t9807-git-p4-submit.sh
index 1f74a88..5931528 100755
--- a/t/t9807-git-p4-submit.sh
+++ b/t/t9807-git-p4-submit.sh
@@ -389,7 +389,7 @@ test_expect_success 'description with Jobs section and 
bogus following text' '
(
cd "$cli" &&
p4 revert desc6 &&
-   rm desc6
+   rm -f desc6
)
 '
 
-- 
2.6.3.492.g06488d6

--
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

[PATCHv2] git-p4: Handle p4 submit failure

This is a small reroll of Etienne's earlier patch to clean up
the p4 repo on submit failure.

The only difference is to fix the t9807- test. This test
was trying to remove a file which had already been cleaned
up as a result of this change.

GIRARD Etienne (1):
  git-p4: clean up after p4 submit failure

 git-p4.py| 71 +---
 t/t9807-git-p4-submit.sh |  2 +-
 2 files changed, 38 insertions(+), 35 deletions(-)

-- 
2.6.3.492.g06488d6

--
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] blame: add support for --[no-]progress option

2015-11-23 Thread Torsten Bögershausen


On 11/24/2015 02:07 AM, Edmundo Carmona Antoranz wrote:

diff --git a/builtin/blame.c b/builtin/blame.c
index 83612f5..1d43b52 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -28,6 +28,7 @@
  #include "line-range.h"
  #include "line-log.h"
  #include "dir.h"
+#include "progress.h"
  
  static char blame_usage[] = N_("git blame [] [] [] [--] ");
  
@@ -50,6 +51,7 @@ static int incremental;

  static int xdl_opts;
  static int abbrev = -1;
  static int no_whole_file_rename;
+static int show_progress;
  
  static struct date_mode blame_date_mode = { DATE_ISO8601 };

  static size_t blame_date_width;
@@ -127,6 +129,11 @@ struct origin {
char path[FLEX_ARRAY];
  };
  
+struct progress_info {

+   struct progress *progress;
+   int blamed_lines;
+};
+
  static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b, long ctxlen,
  xdl_emit_hunk_consume_func_t hunk_func, void *cb_data)
  {
@@ -1746,7 +1753,8 @@ static int emit_one_suspect_detail(struct origin 
*suspect, int repeat)
   * The blame_entry is found to be guilty for the range.
   * Show it in incremental output.
   */
-static void found_guilty_entry(struct blame_entry *ent)
+static void found_guilty_entry(struct blame_entry *ent,
+  struct progress_info * pi)
Minor remark: The '*' should be close to the variable: "struct 
progress_info *pi"




--
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

Fwd: Git clone fails during pre-commit hook due to GIT_WORK_TREE=. (regression 2.5 -> 2.6)

2015-11-23 Thread Anthony Sottile

* Short description of the problem *

It seems GIT_WORK_DIR is now exported invariantly when calling git
hooks such as pre-commit.  If these hooks involve cloning repositories
they will not fail due to this exported environment variable.  This
was not the case in prior versions (such as v2.5.0).

* Simple reproduction *

```
$ cat test.sh
#!/usr/bin/env bash
set -ex

rm -rf test

# Exit non {0, 1} to abort git bisect
make -j 8 > /dev/null || exit 2

# Put our new git on the path
PATH="$(pwd):$PATH"

git init test

pushd test
mkdir -p .git/hooks
echo 'git clone git://github.com/asottile/css-explore css-explore' >
.git/hooks/pre-commit
chmod 755 .git/hooks/pre-commit

git commit -m foo --allow-empty || exit 1
```

* Under 2.6.3 *

```
$ ./test.sh

...

+ git init test
warning: templates not found /home/anthony/share/git-core/templates
Initialized empty Git repository in /home/anthony/workspace/git/test/.git/
+ pushd test
~/workspace/git/test ~/workspace/git
+ mkdir -p .git/hooks
+ echo 'git clone git://github.com/asottile/css-explore css-explore'
+ chmod 755 .git/hooks/pre-commit
+ git commit -m foo --allow-empty
fatal: working tree '.' already exists.
+ exit 1
```

* Under 2.5 *

```
$ ./test.sh

...

+ git init test
warning: templates not found /home/anthony/share/git-core/templates
Initialized empty Git repository in /home/anthony/workspace/git/test/.git/
+ pushd test
~/workspace/git/test ~/workspace/git
+ mkdir -p .git/hooks
+ echo 'git clone git://github.com/asottile/css-explore css-explore'
+ chmod 755 .git/hooks/pre-commit
+ git commit -m foo --allow-empty
Cloning into 'css-explore'...
warning: templates not found /home/anthony/share/git-core/templates
remote: Counting objects: 214, done.
remote: Total 214 (delta 0), reused 0 (delta 0), pack-reused 214
Receiving objects: 100% (214/214), 25.89 KiB | 0 bytes/s, done.
Resolving deltas: 100% (129/129), done.
Checking connectivity... done.
[master (root-commit) 5eb999d] foo
```


* Bisect *

```
$ git bisect good v2.5.0
$ git bisect bad origin/master
$ git bisect run ./test.sh

...

d95138e695d99d32dcad528a2a7974f434c51e79 is the first bad commit
commit d95138e695d99d32dcad528a2a7974f434c51e79
Author: Nguyễn Thái Ngọc Duy 
Date:   Fri Jun 26 17:37:35 2015 +0700

setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR

In the test case, we run setup_git_dir_gently() the first time to read
$GIT_DIR/config so that we can resolve aliases. We'll enter
setup_discovered_git_dir() and may or may not call set_git_dir() near
the end of the function, depending on whether the detected git dir is
".git" or not. This set_git_dir() will set env var $GIT_DIR.

For normal repo, git dir detected via setup_discovered_git_dir() will be
".git", and set_git_dir() is not called. If .git file is used however,
the git dir can't be ".git" and set_git_dir() is called and $GIT_DIR
set. This is the key of this problem.

If we expand an alias (or autocorrect command names), then
setup_git_dir_gently() is run the second time. If $GIT_DIR is not set in
the first run, we run the same setup_discovered_git_dir() as before.
Nothing to see. If it is, however, we'll enter setup_explicit_git_dir()
this time.

This is where the "fun" is.  If $GIT_WORK_TREE is not set but
$GIT_DIR is, you are supposed to be at the root level of the
worktree.  But if you are in a subdir "foo/bar" (real worktree's top
is "foo"), this rule bites you: your detected worktree is now
"foo/bar", even though the first run correctly detected worktree as
"foo". You get "internal error: work tree has already been set" as a
result.

Bottom line is, when $GIT_DIR is set, $GIT_WORK_TREE should be set too
unless there's no work tree. But setting $GIT_WORK_TREE inside
set_git_dir() may backfire. We don't know at that point if work tree is
already configured by the caller. So set it when work tree is
detected. It does not harm if $GIT_WORK_TREE is set while $GIT_DIR is
not.

Reported-by: Bjørnar Snoksrud 
Signed-off-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Junio C Hamano 

:100644 100644 9daa0ba4a36ced9f63541203e7bcc2ab9e1eae56
36fbba57fc83afd36d99bf5d4f3a1fc3feefba09 Menvironment.c
:04 04 1d7c4bf77e0fd49ca315271993cb69a8b055c3aa
145d85895cb6cb0810597e1854a7721ccfc8f457 Mt
bisect run success
```

Causing me a few headaches in
https://github.com/pre-commit/pre-commit/issues/300
I'm working around it in https://github.com/pre-commit/pre-commit/pull/301

Thanks,

Anthony
--
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 rm --recursive

On Wed, Nov 18, 2015 at 10:06 AM, Hans Ginzel  wrote:
> I have added the --recursive alias for the -r option to the rm command.

When sending a patch, separate the patch itself from the above
commentary with a scissor line (--- 8< ---) so that git-am can extract
the patch automatically. Alternately, appease git-am by placing the
commentary below the "---" line just above the diffstat.

> From 83f197151c04164b0dfd4d127e72439aebaf8b71 Mon Sep 17 00:00:00 2001
> From: Hans Ginzel 
> Date: Wed, 18 Nov 2015 15:44:56 +0100

All three above lines should be dropped. "From SHA1" is meaningful
only in your repository, thus not helpful in the patch. "From:" is the
same as the email address from which you sent the patch, so git-am can
just pick it up from the email envelope. On this project, the
important date is when the maintainer applies the patch, so the above
"Date:" is not interesting.

> Subject: [PATCH] builtin: rm: add --recursive to be consistent with GNU rm

The body of the commit message (following the subject) would be a good
place to explain why --recursive is desirable. Consistency with GNU
'rm' may be reasonable, but you may need to be more persuasive to
convince people that the project should support yet another alias for
an existing option and that whatever future maintenance that involves
(documentation and code) is really worthwhile, especially since nobody
has expressed interest in such an alias as yet.

Also, if you're aiming for consistency with GNU 'rm' (or even BSD
'rm'), wouldn't you want to support -R, as well?

Similarly, git-rm's -f option behaves differently than -f of Unix 'rm'
in that even with -f, git-rm still expects the named path to exist,
whereas Unix 'rm' does not. Is that difference also worth addressing,
or is that an argument against trying to make git-rm consistent with
GNU 'rm'?

Your Signed-off-by: is missing. See Documentation/SubmittingPatches.

More below...

> diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
> @@ -47,6 +47,7 @@ OPTIONS
> -r::
> +--recursive::
> Allow recursive removal when a leading directory name is
> given.
>
> diff --git a/builtin/rm.c b/builtin/rm.c
> @@ -269,7 +269,7 @@ static struct option builtin_rm_options[] = {
> -   OPT_BOOL('r', NULL, &recursive,  N_("allow recursive
> removal")),
> +   OPT_BOOL('r', "recursive",  &recursive,  N_("allow recursive
> removal")),
> diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
> @@ -207,12 +207,25 @@ test_expect_success 'Recursive with -r but dirty' '
> test -f frotz/nitfol
> '
>
> +test_expect_success 'Recursive with --recursive but dirty' '
> +   echo qfwfq >>frotz/nitfol &&
> +   test_must_fail git rm --recursive frotz &&
> +   test -d frotz &&
> +   test -f frotz/nitfol
> +'

This copy/pasted test isn't doing what you think it's doing. It would
pass even if you had totally botched the implementation of
--recursive. That's because it actively expects "git rm --recursive"
to fail, so it would "succeed" for any failure, for instance, due to a
botched implementation.

What you probably want to do instead is create a test which verifies
that "git rm" alone fails when attempting to remove a directory, and
that "git rm --recursive" succeeds.

> test_expect_success 'Recursive with -r -f' '
> git rm -f -r frotz &&
> ! test -f frotz/nitfol &&
> ! test -d frotz
> '
>
> +test_expect_success 'Recursive with --recursive -f' '
> +   git rm -f --recursive frotz &&
> +   ! test -f frotz/nitfol &&
> +   ! test -d frotz
> +'

This copy/pasted test is in even worse shape. It doesn't pass at all,
even with a perfectly operational --recursive implementation. (I'm
guessing that you didn't run the tests after adding this.) This is
because the preceding test, from which this was copied, destroys state
prepared by the earlier "Recursive test setup" test upon which this
new test depends. Without that state, the test can not pass.

Anyhow, if you follow the advice above and just craft a new test which
ensures that "git rm" fails on a directory and "git rm --recursive"
succeeds, then that should be sufficient to verify that --recursive
works as an alias for -r, and you can drop these two (bogus)
copy/pasted tests.

> test_expect_success 'Remove nonexistent file returns nonzero exit status' '
> test_must_fail git rm nonexistent
> '
> --
> 1.9.1
--
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] blame: add support for --[no-]progress option

2015-11-23 Thread Edmundo Carmona Antoranz

On Mon, Nov 23, 2015 at 7:07 PM, Edmundo Carmona Antoranz
 wrote:
>  {
> struct rev_info *revs = sb->revs;
> struct commit *commit = prio_queue_get(&sb->commits);
> +   struct progress_info *pi = NULL;

Switched to using  pointer to make it more elegant.
--
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 v4] blame: add support for --[no-]progress option

2015-11-23 Thread Edmundo Carmona Antoranz

* created struct progress_info in builtin/blame.c
  this struct holds the information used to display progress so
  that only one additional parameter is passed to
  found_guilty_entry().

* --[no-]progress option is also inherited by git-annotate.

Signed-off-by: Edmundo Carmona Antoranz 
---
 Documentation/blame-options.txt |  7 +++
 Documentation/git-blame.txt |  3 ++-
 builtin/blame.c | 40 
 3 files changed, 45 insertions(+), 5 deletions(-)

diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index 760eab7..ef642b9 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -69,6 +69,13 @@ include::line-range-format.txt[]
iso format is used. For supported values, see the discussion
of the --date option at linkgit:git-log[1].
 
+--[no-]progress::
+   Progress status is reported on the standard error stream
+   by default when it is attached to a terminal. This flag
+   enables progress reporting even if not attached to a
+   terminal. Progress information won't be displayed if using
+   `--porcelain` or `--incremental`.
+
 -M||::
Detect moved or copied lines within a file. When a commit
moves or copies a block of lines (e.g. the original file
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index e6e947c..b0154c2 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -10,7 +10,8 @@ SYNOPSIS
 [verse]
 'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] 
[--incremental]
[-L ] [-S ] [-M] [-C] [-C] [-C] [--since=]
-   [--abbrev=] [ | --contents  | --reverse ] [--] 

+   [--[no-]progress] [--abbrev=] [ | --contents  | 
--reverse ]
+   [--] 
 
 DESCRIPTION
 ---
diff --git a/builtin/blame.c b/builtin/blame.c
index 83612f5..1d43b52 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -28,6 +28,7 @@
 #include "line-range.h"
 #include "line-log.h"
 #include "dir.h"
+#include "progress.h"
 
 static char blame_usage[] = N_("git blame [] [] [] 
[--] ");
 
@@ -50,6 +51,7 @@ static int incremental;
 static int xdl_opts;
 static int abbrev = -1;
 static int no_whole_file_rename;
+static int show_progress;
 
 static struct date_mode blame_date_mode = { DATE_ISO8601 };
 static size_t blame_date_width;
@@ -127,6 +129,11 @@ struct origin {
char path[FLEX_ARRAY];
 };
 
+struct progress_info {
+   struct progress *progress;
+   int blamed_lines;
+};
+
 static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b, long ctxlen,
  xdl_emit_hunk_consume_func_t hunk_func, void *cb_data)
 {
@@ -1746,7 +1753,8 @@ static int emit_one_suspect_detail(struct origin 
*suspect, int repeat)
  * The blame_entry is found to be guilty for the range.
  * Show it in incremental output.
  */
-static void found_guilty_entry(struct blame_entry *ent)
+static void found_guilty_entry(struct blame_entry *ent,
+  struct progress_info * pi)
 {
if (incremental) {
struct origin *suspect = ent->suspect;
@@ -1758,6 +1766,8 @@ static void found_guilty_entry(struct blame_entry *ent)
write_filename_info(suspect->path);
maybe_flush_or_die(stdout, "stdout");
}
+   if (pi)
+   display_progress(pi->progress, pi->blamed_lines += 
ent->num_lines);
 }
 
 /*
@@ -1768,6 +1778,16 @@ static void assign_blame(struct scoreboard *sb, int opt)
 {
struct rev_info *revs = sb->revs;
struct commit *commit = prio_queue_get(&sb->commits);
+   struct progress_info *pi = NULL;
+
+   if (show_progress) {
+   pi = malloc(sizeof(*pi));
+   if (pi) {
+   pi->progress = start_progress_delay(_("Blaming lines"),
+   sb->num_lines, 50, 
1);
+   pi->blamed_lines = 0;
+   }
+   }
 
while (commit) {
struct blame_entry *ent;
@@ -1809,7 +1829,7 @@ static void assign_blame(struct scoreboard *sb, int opt)
suspect->guilty = 1;
for (;;) {
struct blame_entry *next = ent->next;
-   found_guilty_entry(ent);
+   found_guilty_entry(ent, pi);
if (next) {
ent = next;
continue;
@@ -1825,6 +1845,11 @@ static void assign_blame(struct scoreboard *sb, int opt)
if (DEBUG) /* sanity */
sanity_check_refcnt(sb);
}
+
+   if (pi) {
+   stop_progress(&pi->progress);
+   free(pi);
+   };
 }
 
 static const char *format_time(unsigned long time, const char *tz_str,
@@ -2520,6 +2545,7 @@ int cmd_blame(int argc, c

Re: [PATCH] git-send-email.perl: Fixed sending of many/huge changes/patches

2015-11-23 Thread Stefan Agner

On 2015-09-30 10:51, Junio C Hamano wrote:
> Lars Wendler  writes:
> 
>> It seems to me that there is a size limit, after cutting down the patch
>> to ~16K, sending started to work. I cut it twice, once by removing lines
>> from the head and once from the bottom, in both cases at the size of
>> around 16K I could send the patch.
>>
>> See also original report:
>> http://permalink.gmane.org/gmane.comp.version-control.git/274569
>>
>> Reported-by: Juston Li 
>> Tested-by: Markos Chandras 
>> Signed-off-by: Lars Wendler 
>> ---
>>  git-send-email.perl | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index e3ff44b..e907e0ea 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -1365,7 +1365,11 @@ Message-Id: $message_id
>>  $smtp->mail( $raw_from ) or die $smtp->message;
>>  $smtp->to( @recipients ) or die $smtp->message;
>>  $smtp->data or die $smtp->message;
>> -$smtp->datasend("$header\n$message") or die $smtp->message;
>> +$smtp->datasend("$header\n") or die $smtp->message;
>> +my @lines = split /^/, $message;
>> +foreach my $line (@lines) {
>> +$smtp->datasend("$line") or die $smtp->message;
>> +}
> 
> Thanks.  One and a half comments.
> 
>  * If 16k is the limit, and smtp payload line limit is much much
>shorter than that, is it sensible to send data line by line?
> 
>  * Has this been reported to Net::Cmd::datasend() upstream?

I still constantly run in to this issue. Fixing it locally, and next
time git gets updated and I send a larger patch, it happens again.

Just dig a bit more into that, it seems that this is a documented Perl
limitation:
http://search.cpan.org/~sullr/IO-Socket-SSL-2.020/lib/IO/Socket/SSL.pod#syswrite

All examples use datasend line wise, so I guess it is not a all to bad
choice...

--
Stefan


> 
>>  $smtp->dataend() or die $smtp->message;
>>  $smtp->code =~ /250|200/ or die "Failed to send 
>> $subject\n".$smtp->message;
>>  }
--
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 2/2] send-email: expand paths in sendemail.{to,cc}cmd config

On Tue, Nov 17, 2015 at 5:01 PM, John Keeping  wrote:
> These configuration variables specify the paths to commands so we should
> support tilde-expansion for files inside a user's home directory.

Hmm, I don't see anything in the documentation which says that these
are paths to commands, and the code itself treats them purely as
commands to be invoked, not as paths to commands. What is the
behavior, for instance, with --tocmd='foobar -x zopp' or even
--tocmd='foobar -x ~/zopp'?

> Signed-off-by: John Keeping 
> ---
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 719c715..8e4c0e1 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -242,9 +242,7 @@ my %config_settings = (
>  "smtpdomain" => \$smtp_domain,
>  "smtpauth" => \$smtp_auth,
>  "to" => \@initial_to,
> -"tocmd" => \$to_cmd,
>  "cc" => \@initial_cc,
> -"cccmd" => \$cc_cmd,
>  "aliasfiletype" => \$aliasfiletype,
>  "bcc" => \@bcclist,
>  "suppresscc" => \@suppress_cc,
> @@ -259,6 +257,8 @@ my %config_settings = (
>  my %config_path_settings = (
>  "aliasesfile" => \@alias_files,
>  "smtpsslcertpath" => \$smtp_ssl_cert_path,
> +"tocmd" => \$to_cmd,
> +"cccmd" => \$cc_cmd,
>  );
--
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/RFC 01/10] ref-filter: introduce a parsing function for each atom in valid_atom

On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak  wrote:
> Introduce a parsing function for each atom in valid_atom. Using this
> we can define special parsing functions for each of the atoms. Since
> we have a third field in valid_atom structure, we now fill out missing
> cmp_type values.

I don't get it. Why do you need to "fill out missing cmp_type values"
considering that you're never assigning the third field in this patch?
Are you planning on filling in the third field in a future patch?

> Signed-off-by: Karthik Nayak 
> ---
> diff --git a/ref-filter.c b/ref-filter.c
> @@ -19,42 +19,43 @@ typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } 
> cmp_type;
>  static struct {
> const char *name;
> cmp_type cmp_type;
> +   void (*parser)(struct used_atom *atom);

Compiler diagnostic:

warning: declaration of 'struct used_atom' will not be
visible outside of this function [-Wvisibility]

Indeed, it seems rather odd to introduce the new field in this patch
but never actually do anything with it. It's difficult to understand
the intention.

>  } valid_atom[] = {
> -   { "refname" },
> -   { "objecttype" },
> +   { "refname", FIELD_STR },
> +   { "objecttype", FIELD_STR },
> { "objectsize", FIELD_ULONG },
> -   { "objectname" },
> -   { "tree" },
> -   { "parent" },
> +   { "objectname", FIELD_STR },
> +   { "tree", FIELD_STR },
> +   { "parent", FIELD_STR },
> { "numparent", FIELD_ULONG },
> -   { "object" },
> -   { "type" },
> -   { "tag" },
> -   { "author" },
> -   { "authorname" },
> -   { "authoremail" },
> +   { "object", FIELD_STR },
> +   { "type", FIELD_STR },
> +   { "tag", FIELD_STR },
> +   { "author", FIELD_STR },
> +   { "authorname", FIELD_STR },
> +   { "authoremail", FIELD_STR },
> { "authordate", FIELD_TIME },
> -   { "committer" },
> -   { "committername" },
> -   { "committeremail" },
> +   { "committer", FIELD_STR },
> +   { "committername", FIELD_STR },
> +   { "committeremail", FIELD_STR },
> { "committerdate", FIELD_TIME },
> -   { "tagger" },
> -   { "taggername" },
> -   { "taggeremail" },
> +   { "tagger", FIELD_STR },
> +   { "taggername", FIELD_STR },
> +   { "taggeremail", FIELD_STR },
> { "taggerdate", FIELD_TIME },
> -   { "creator" },
> +   { "creator", FIELD_STR },
> { "creatordate", FIELD_TIME },
> -   { "subject" },
> -   { "body" },
> -   { "contents" },
> -   { "upstream" },
> -   { "push" },
> -   { "symref" },
> -   { "flag" },
> -   { "HEAD" },
> -   { "color" },
> -   { "align" },
> -   { "end" },
> +   { "subject", FIELD_STR },
> +   { "body", FIELD_STR },
> +   { "contents", FIELD_STR },
> +   { "upstream", FIELD_STR },
> +   { "push", FIELD_STR },
> +   { "symref", FIELD_STR },
> +   { "flag", FIELD_STR },
> +   { "HEAD", FIELD_STR },
> +   { "color", FIELD_STR },
> +   { "align", FIELD_STR },
> +   { "end", FIELD_STR },
>  };
>
>  #define REF_FORMATTING_STATE_INIT  { 0, NULL }
> --
> 2.6.2
--
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

[PATCHv3] run-command: detect finished children by closed pipe rather than waitpid

Detect if a child stopped working by checking if their stderr pipe
was closed instead of checking their state with waitpid. This resembles
the way we work with child processes in the non-parallel case.

Having a better consistency between the different methods to run
child processes, is the main advantage, though there are more:
* Previously we leaked the open read pipe of finished children.
* waitpid(-1, ...) is not implemented in Windows, this is an approach
  which allows for better cross platform operation.
* less lines of code.

The old way missed some messages on an early abort. We just killed the
children and did not bother to look what was left over. With this approach
we'd send a signal to the children and wait for them to close the pipe to
have all the messages (including possible "killed by signal 15" messages).

To have the test suite passing as before, we allow for real graceful
abortion now. In case the user wishes to abort parallel execution
the user needs to provide either the signal used to kill all children
or the children are let run until they finish normally.

Signed-off-by: Stefan Beller 
---
 
 * applies on top of submodule-parallel-fetch
 * updated the commit message to address Jonathans concerns, using the
   words of Johannes.
 * did not rename code to anything else, as I do not see the need for it.
 
 run-command.c  | 141 +++--
 run-command.h  |  12 +++--
 submodule.c|   3 --
 test-run-command.c |   3 --
 4 files changed, 69 insertions(+), 90 deletions(-)
 
 

diff --git a/run-command.c b/run-command.c
index 07424e9..db4d916 100644
--- a/run-command.c
+++ b/run-command.c
@@ -858,6 +858,12 @@ int capture_command(struct child_process *cmd, struct 
strbuf *buf, size_t hint)
return finish_command(cmd);
 }
 
+enum child_state {
+   GIT_CP_FREE,
+   GIT_CP_WORKING,
+   GIT_CP_WAIT_CLEANUP,
+};
+
 static struct parallel_processes {
void *data;
 
@@ -869,7 +875,7 @@ static struct parallel_processes {
task_finished_fn task_finished;
 
struct {
-   unsigned in_use : 1;
+   enum child_state state;
struct child_process process;
struct strbuf err;
void *data;
@@ -923,7 +929,7 @@ static void kill_children(struct parallel_processes *pp, 
int signo)
int i, n = pp->max_processes;
 
for (i = 0; i < n; i++)
-   if (pp->children[i].in_use)
+   if (pp->children[i].state == GIT_CP_WORKING)
kill(pp->children[i].process.pid, signo);
 }
 
@@ -967,7 +973,7 @@ static struct parallel_processes *pp_init(int n,
for (i = 0; i < n; i++) {
strbuf_init(&pp->children[i].err, 0);
child_process_init(&pp->children[i].process);
-   pp->pfd[i].events = POLLIN;
+   pp->pfd[i].events = POLLIN | POLLHUP;
pp->pfd[i].fd = -1;
}
sigchain_push_common(handle_children_on_signal);
@@ -1000,39 +1006,46 @@ static void pp_cleanup(struct parallel_processes *pp)
  *  0 if a new task was started.
  *  1 if no new jobs was started (get_next_task ran out of work, non critical
  *problem with starting a new command)
- * -1 no new job was started, user wishes to shutdown early.
+ * <0 no new job was started, user wishes to shutdown early. Use negative code
+ *to signal the children.
  */
 static int pp_start_one(struct parallel_processes *pp)
 {
-   int i;
+   int i, code;
 
for (i = 0; i < pp->max_processes; i++)
-   if (!pp->children[i].in_use)
+   if (pp->children[i].state == GIT_CP_FREE)
break;
if (i == pp->max_processes)
die("BUG: bookkeeping is hard");
 
-   if (!pp->get_next_task(&pp->children[i].data,
-  &pp->children[i].process,
-  &pp->children[i].err,
-  pp->data)) {
+   code = pp->get_next_task(&pp->children[i].data,
+&pp->children[i].process,
+&pp->children[i].err,
+pp->data);
+   if (!code) {
strbuf_addbuf(&pp->buffered_output, &pp->children[i].err);
strbuf_reset(&pp->children[i].err);
return 1;
}
+   pp->children[i].process.err = -1;
+   pp->children[i].process.stdout_to_stderr = 1;
+   pp->children[i].process.no_stdin = 1;
 
if (start_command(&pp->children[i].process)) {
-   int code = pp->start_failure(&pp->children[i].process,
-&pp->children[i].err,
-pp->data,
-&pp->children[i].data);
+   code = pp->start_failure(&pp->children[i].process,
+

[PATCH] merge-file: consider core.crlf when writing merge markers

2015-11-23 Thread Beat Bolli

When merging files in repos with core.eol = crlf, git merge-file inserts
just a LF at the end of the merge markers. Files with mixed line endings
cause trouble in Windows editors and e.g. contrib/git-jump, where an
unmerged file in a run of "git jump merge" is reported as simply "binary
file matches".

Fixing this improves Git's behavior under Windows.

Signed-off-by: Beat Bolli 
Cc: Johannes Schindelin 
---
 builtin/merge-file.c  |  1 +
 ll-merge.c|  1 +
 t/t6023-merge-file.sh |  7 +++
 xdiff/xdiff.h |  1 +
 xdiff/xmerge.c| 29 +++--
 5 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/builtin/merge-file.c b/builtin/merge-file.c
index 5544705..c534c91 100644
--- a/builtin/merge-file.c
+++ b/builtin/merge-file.c
@@ -81,6 +81,7 @@ int cmd_merge_file(int argc, const char **argv, const char 
*prefix)
argv[i]);
}
 
+   xmp.crlf = (core_eol == EOL_CRLF);
xmp.ancestor = names[1];
xmp.file1 = names[0];
xmp.file2 = names[2];
diff --git a/ll-merge.c b/ll-merge.c
index 0338630..a548a29 100644
--- a/ll-merge.c
+++ b/ll-merge.c
@@ -111,6 +111,7 @@ static int ll_xdl_merge(const struct ll_merge_driver 
*drv_unused,
xmp.style = git_xmerge_style;
if (marker_size > 0)
xmp.marker_size = marker_size;
+   xmp.crlf = (core_eol == EOL_CRLF);
xmp.ancestor = orig_name;
xmp.file1 = name1;
xmp.file2 = name2;
diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
index 190ee90..245359a 100755
--- a/t/t6023-merge-file.sh
+++ b/t/t6023-merge-file.sh
@@ -346,4 +346,11 @@ test_expect_success 'conflict at EOF without LF resolved 
by --union' \
 printf "line1\nline2\nline3x\nline3y" >expect.txt &&
 test_cmp expect.txt output.txt'
 
+
+test_expect_success 'conflict markers contain CRLF when core.eol=crlf' '
+   test_must_fail git -c core.eol=crlf merge-file -p \
+   nolf-diff1.txt nolf-orig.txt nolf-diff2.txt >output.txt &&
+   test $(sed -n "/\.txt\r$/p" output.txt | wc -l) = 3
+'
+
 test_done
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index c033991..a5bea4a 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -122,6 +122,7 @@ typedef struct s_xmparam {
int level;
int favor;
int style;
+   int crlf;
const char *ancestor;   /* label for orig */
const char *file1;  /* label for mf1 */
const char *file2;  /* label for mf2 */
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 625198e..4ff0db4 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -146,7 +146,7 @@ static int xdl_orig_copy(xdfenv_t *xe, int i, int count, 
int add_nl, char *dest)
 static int fill_conflict_hunk(xdfenv_t *xe1, const char *name1,
  xdfenv_t *xe2, const char *name2,
  const char *name3,
- int size, int i, int style,
+ int size, int i, int style, int crlf,
  xdmerge_t *m, char *dest, int marker_size)
 {
int marker1_size = (name1 ? strlen(name1) + 1 : 0);
@@ -161,7 +161,7 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char 
*name1,
  dest ? dest + size : NULL);
 
if (!dest) {
-   size += marker_size + 1 + marker1_size;
+   size += marker_size + 1 + crlf + marker1_size;
} else {
memset(dest + size, '<', marker_size);
size += marker_size;
@@ -170,6 +170,8 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char 
*name1,
memcpy(dest + size + 1, name1, marker1_size - 1);
size += marker1_size;
}
+   if (crlf)
+   dest[size++] = '\r';
dest[size++] = '\n';
}
 
@@ -180,7 +182,7 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char 
*name1,
if (style == XDL_MERGE_DIFF3) {
/* Shared preimage */
if (!dest) {
-   size += marker_size + 1 + marker3_size;
+   size += marker_size + 1 + crlf + marker3_size;
} else {
memset(dest + size, '|', marker_size);
size += marker_size;
@@ -189,6 +191,8 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char 
*name1,
memcpy(dest + size + 1, name3, marker3_size - 
1);
size += marker3_size;
}
+   if (crlf)
+   dest[size++] = '\r';
dest[size++] = '\n';
}
size += xdl_orig_copy(xe1, m->i0, m->chg0, 1,
@@ -196,10 +200,12 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char 
*name1,
}
 
if (!dest) {
-   size += m

Re: Best practice setup for github projects on server

On Mon, Nov 23, 2015 at 3:19 AM, Matthew Leach  wrote:
> Hi,
>
> I was hoping that somebody could give me advice since I'm new to git.
>
> I'll be installing a couple of projects from github on our servers, and 
> adding some features.

So you take source code from github and improve it...

>
> Should I create a repository on our server (e.g. in /opt/git/), add the 
> github project as a remote, and create a branch?

You can certainly do that. Why would you want to keep it on your
server though? (Is it not worth to be open because it's highly company
specific stuff? Is it closed intentionally because it would reveal
core company secrets? Is it just for backup, because you don't trust
githubs uptime?) Having 2 remotes (github and your server) makes the
workflow slightly more complicated, but if you don't mind a
complicated workflow that's no problem. But be sure to know why/what
benefits you gain from that. You could also go with your github fork,
which could be set to private, I'd guess.

> Then on my local machine add our server as the remote and then pull / push 
> with that?

Sure, sounds fine.

>
> On the server there will be two web directories: stable and dev.  I was 
> planning for these to be branches, and then just pull from the server 
> repository using the local protocol.

Beware of that. There are quite a lot of servers serving the contents
of the .git directory, you may or may not want to expose the history.
(Certainly it looks odd)
For a private server I'd have the git directory somewhere non-public
(outside of /var/www, so maybe in the home directory of the git user)
and then a hook like this:

$cat .git/hooks/post-update
GIT_WORK_TREE=/var/www/your-stable-web-dir git checkout stable-branch
GIT_WORK_TREE=/var/www/your-dev-web-dir git checkout dev-branch

That's one way to do it. And outdated by now (as I just wrote down the
config I have in a personal server).
Git has learned a push-to-deploy[1], which should do what you want there, too.

[1] https://github.com/blog/1994-git-2-4-atomic-pushes-push-to-deploy-and-more

>
> I think it would mean sorting out merge actions on the server.  I'm hoping to 
> be able to fetch and integrate updates from the developer's github 
> repository, but without making things more complicated than they need to be.
>
> Does anyone have any suggestions?  I drew a diagram if it helps 
> (https://drive.google.com/file/d/0B7JhUXLbxPT9RkVNMUV6cjJNVnc/view?usp=sharing)

As said above, what exactly do you solve by having yet another line in
the diagram (with /opt/git/proj.git) ?
You can directly pull from github to the local developers workspace
(and sort out merge conflicts there)
and then push to deploy from the workspace, too.

If you need a place to share for just the subset of people in your
company, you could use the /opt/git/proj.git for sure, but you'd
pull&resolve merge conflicts to your workstation and then push for
sharing to your server.
(Also think about external hosting solutions, if they make sense there)

If you dislike the push-to-deploy approach (not everybody should be
able to push a new version, only a subset of people should be able to,
that should also work the same way as you would restrict the "pull
dev" and "pull stable", I'd guess)
--
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 v6 0/6] Add Travis CI support


On 19/11/15 08:58, larsxschnei...@gmail.com wrote:

From: Lars Schneider 

diff to v5:
* check if PID file still exists on P4D cleanup (thanks Luke)
* fix space/tab formatting error
* add sleep to timeout loops (thanks Luke)
* replace 'date +%s' with platform independent Python function (thanks Eric and 
Luke)


The first three of these (which fix the git-p4 tests) all look good to 
me. With these changes, running the t98* tests in parallel now works, 
which it did not used to do. The changes are not pretty but I think 
that's inevitable.


Ack from me.

Luke

--
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] ls-files: Add eol diagnostics

On Mon, Nov 23, 2015 at 2:45 PM, Sebastian Schuberth
 wrote:
> On Mon, Nov 23, 2015 at 6:05 PM, Torsten Bögershausen  wrote:
>> git ls-files -o --eol
>> i/  w/binaryattr/  zlib.o
>
> I see, somewhat convincing I have to agree.
>
> On another note, how about making the prefix either all just one
> letter (i.e. "attr/" becomes "a/"), or all multi-letter abbreviations
> (i.e. "i/" becomes "idx/" and "w/" becomes "wt/" or "wtree/" or
> "tree/")?

The latter is answered by [1].

[1]: http://article.gmane.org/gmane.comp.version-control.git/280647
--
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] ls-files: Add eol diagnostics

2015-11-23 Thread Sebastian Schuberth

On Mon, Nov 23, 2015 at 6:05 PM, Torsten Bögershausen  wrote:

> or, as another example:
> git ls-files -o --eol
> i/  w/binaryattr/  zlib.o

I see, somewhat convincing I have to agree.

On another note, how about making the prefix either all just one
letter (i.e. "attr/" becomes "a/"), or all multi-letter abbreviations
(i.e. "i/" becomes "idx/" and "w/" becomes "wt/" or "wtree/" or
"tree/")?

-- 
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

Re: [PATCHv2] run-command: detect finished children by closed pipe rather than waitpid

On Mon, Nov 23, 2015 at 10:44 AM, Stefan Beller  wrote:
> On Fri, Nov 20, 2015 at 10:58 PM, Torsten Bögershausen  wrote:
>> On 2015-11-20 22.08, Stefan Beller wrote:
>> The patch looks good at first glance, one minor remark below:
>>>
>>> diff --git a/run-command.c b/run-command.c
>>
>>> @@ -1071,70 +1089,31 @@ static void pp_output(struct parallel_processes *pp)
>>>
>>>  static int pp_collect_finished(struct parallel_processes *pp)
>>>  {
>>> - int i = 0;
>>> - pid_t pid;
>>> - int wait_status, code;
>>> + int i, code;
>>
>> code is probably "return code"?
>> woud "ret_value", "res" or "rc" make that more clear ?
>>
>

Although looking through the code, we have lots of functions
having a local `code` variable, so we may want to preserve consistency
across the different functions to have a `code`which contains the return
value of the process or function invoked.

We had the `code` already in pp_collect_finished, so I'd like to not
rename a variable (which was used for the same purpose) in this patch.

In pp_start_one we introduce a new variable `code` which contains
the return from the user callback function, so I would understand if
we were arguing there.

That said, I plan to resend with a reworded commit message later today.
--
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: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"

2015-11-23 Thread Marc Strapetz

On 23.11.2015 18:04, Carlos Martín Nieto wrote:

Hello Mark,

On 23 Nov 2015, at 12:04, Marc Strapetz wrote:

There is a strange "branch --set-upstream-to" failure for "clones" which haven't been created using "git
clone" but constructed using "git init", "git remote add" and "git fetch".

Following script first creates a "main" repository and then constructs the clone.
Finally, in the clone branches origin/1 and origin/2 will be present, however it's not possible to
invoke "git branch --set-upstream-to" for origin/2 (it works fine for origin/1).

I guess the behavior is related to following line in .git/config:

fetch = refs/heads/1:refs/remotes/origin/1

However, I don't understand what's the problem for Git here? Definitely the error
"starting point 'origin/2' is not a branch" is wrong.

That is indeed the issue. The configuration which is stored in the
configuration is a remote+branch pair. If there is no fetch refspec configured
which would create the ‘origin/2’ remote-tracking branch, the command does not
know which remote and branch that would correspond to.

Thanks, Carlos, I understand now.

My goal is to have a clone which will only fetch specific branches, so I
guess I have to stick with "refs/heads/1:refs/remotes/origin/1" for the
beginning and for every new branch X add another
"refs/heads/X:refs/remotes/origin/X"? Or is there a better way?

-Marc

--
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 v6 0/6] Add Travis CI support

On Fri, Nov 20, 2015 at 12:56:04PM +, Luke Diamand wrote:

> >>>  git-p4: retry kill/cleanup operations in tests with timeout
> >>>  git-p4: add p4d timeout in tests
> >>>  git-p4: add trap to kill p4d on test exit
> >>
> >> These are all fairly gross, and I don't have p4d to test with myself.
> >> But if we assume they're all necessary, I suppose it's the best we can
> >> do.
> >
> > Unfortunately I think they are necessary. However, if someone finds a 
> > better way for stable p4d tests then I would be happy to see them go away, 
> > again.
> 
> I think that's just how p4d is I'm afraid. It doesn't like being
> stopped and started quickly (I guess it's not a normal use-case for
> most p4 users). I've made various unsuccessful attempts in the past to
> make these tests work reliably, and Lars' changes are far better than
> anything I ever managed.

Thanks for the extra context. I hope I didn't sound too negative in my
initial assessment. It was meant to be "this is lamentable but probably
necessary".

-Peff
--
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: What's cooking in git.git (Nov 2015, #03; Fri, 20)

On Mon, Nov 23, 2015 at 09:06:32AM +, Luke Diamand wrote:

> >  Some commits need better explanation.
> >
> >  Waiting for a reroll.
> >
> >
> >* ld/p4-detached-head (2015-09-09) 2 commits
> >  - git-p4: work with a detached head
> >  - git-p4: add failing test for submit from detached head
> 
> Rerolled on the 21st.

Thanks, I"ll pick that up in the next cycle.

-Peff
--
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: What's cooking in git.git (Nov 2015, #03; Fri, 20)

On Mon, Nov 23, 2015 at 12:02:35AM +0530, Karthik Nayak wrote:

> > * kn/for-each-branch-remainder (2015-10-02) 9 commits
> >  - branch: implement '--format' option
> >  - branch: use ref-filter printing APIs
> >  - ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
> >  - ref-filter: introduce format_ref_array_item()
> >  - ref-filter: adopt get_head_description() from branch.c
> >  - ref-filter: modify "%(objectname:short)" to take length
> >  - ref-filter: add support for %(path) atom
> >  - ref-filter: implement %(if:equals=) and %(if:notequals=)
> >  - ref-filter: implement %(if), %(then), and %(else) atoms
> >
> >  More unification among "branch -l", "tag -l" and "for-each-ref --format".
> >
> >  Expecting a reroll.
> >  ($gmane/278926)
> >
> 
> This series is supposed to follow this:
> http://thread.gmane.org/gmane.comp.version-control.git/281180 which I
> recently sent.
> So replace "for-each-branch-remainder" with this in "Whats cooking"?

Thanks, it was on my "leftover topics to pick up" list. I'll make sure
it gets updated in the next cycle.

-Peff
--
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: What's cooking in git.git (Nov 2015, #03; Fri, 20)

On Mon, Nov 23, 2015 at 02:09:42PM +0100, Johannes Schindelin wrote:

> On Fri, 20 Nov 2015, Jeff King wrote:
> 
> > * pt/http-socks-proxy (2015-11-20) 1 commit
> >   (merged to 'next' on 2015-11-20 at dc6ae48)
> >  + remote-http(s): support SOCKS proxies
> > 
> >  Add support for talking http/https over socks proxy.
> > 
> >  Will cook in 'next'.
> 
> With all due respect, I do not thing this needs more cooking, as it
> 
> 1. was tested extensively by yours truly in the Git for Windows context,
>and it
> 
> 2. cannot possibly break anything because it tests specifically for the
>"socks:" prefix. It is a pure new feature.

Any time I want to say "cannot possibly" I start to get very worried
that I have missed something. :)

I do think this topic looks OK, but it just made it into next during the
last integration cycle (it was waiting on Pat's signoff, which I
amended). I think it should be OK to cook in next for a few days and
then merge to master (i.e., plenty of time for v2.7).

Thanks (and thank you for extra feedback; especially because of the
maintainer switch I do not have full context on all of the topics).

-Peff
--
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: [PATCHv2] run-command: detect finished children by closed pipe rather than waitpid

On Fri, Nov 20, 2015 at 10:58 PM, Torsten Bögershausen  wrote:
> On 2015-11-20 22.08, Stefan Beller wrote:
> The patch looks good at first glance, one minor remark below:
>>
>> diff --git a/run-command.c b/run-command.c
>
>> @@ -1071,70 +1089,31 @@ static void pp_output(struct parallel_processes *pp)
>>
>>  static int pp_collect_finished(struct parallel_processes *pp)
>>  {
>> - int i = 0;
>> - pid_t pid;
>> - int wait_status, code;
>> + int i, code;
>
> code is probably "return code"?
> woud "ret_value", "res" or "rc" make that more clear ?
>

The return value of invoked process, yes.
"ret_value", "res" sound too much like our own future return value
(by convention of naming its own return value ret_value or similar).

Instead of return code, I may settle with `exit_status`?
--
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] ls-files: Add eol diagnostics

On Sat, Nov 21, 2015 at 2:36 AM, Torsten Bögershausen  wrote:
> When working in a cross-platform environment, a user wants to
> check if text files are stored normalized in the repository and if
> .gitattributes are set appropriately.
>
> Make it possible to let Git show the line endings in the index and
> in the working tree and the effective text/eol attributes

s/$/./

> [...]
> Signed-off-by: Torsten Bögershausen 
> ---
> diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> @@ -147,6 +148,18 @@ a space) at the start of each line:
> possible for manual inspection; the exact format may change at
> any time.
>
> +--eol::
> +   Show line endings ("eolinfo") and the text/eol attributes 
> ("texteolattr") of files.
> +   "eolinfo" is the file content identification used by Git when
> +   the "text" attribute is "auto", or core.autocrlf != false.
> +
> +   "eolinfo" is either "" (when the the info is not avaiable"), or one 
> of "binary",

s/avaiable/available/

> +   "text-no-eol", "text-lf", "text-crlf" or "text-crlf-lf".
> +   The "texteolattr" can be "", "-text", "text", "text=auto", "eol=lf", 
> "eol=crlf".
> +
> +   Both the content in the index ("i/") and the content in the working 
> tree ("w/")
> +   are shown for regular files, followed by the "exteolattr ("attr/").

s/exteolattr/texteolattr/

Should the documentation mention that with --eol ls-files becomes a
much more expensive operation since it now has to read all blobs
referenced by trees? (genuine question)

> diff --git a/builtin/check-attr.c b/builtin/check-attr.c
> @@ -51,6 +53,23 @@ static void output_attr(int cnt, struct git_attr_check 
> *check,
> +static void output_eol_attr(const char *file)
> +{
> +   struct stat st;
> +   if (lstat(file, &st) || (!S_ISREG(st.st_mode)))
> +   return;
> +   if (nul_term_line) {
> +   printf("%s:", file);
> +   if (!lstat(file, &st) && (S_ISREG(st.st_mode)))
> +   printf(": %-13s ", get_convert_attr_ascii(file));

Why the trailing space in the format string?

> +   printf("%c", 0);

putc('\0') perhaps?

> +   } else {
> +   quote_c_style(file, NULL, stdout, 0);
> +   printf(": %-13s ", get_convert_attr_ascii(file));

Ditto regarding trailing space.

> +   printf("\n");

Is there a reason the "\n" isn't incorporated into the preceding
printf's format string?

> +   }
> +}
> diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
> @@ -213,7 +238,18 @@ checkout_files () {
> git -c core.eol=$eol checkout $src$f.txt
> fi
> done
> -
> +   test_expect_success "ls-files --eol $lfname ${pfx}LF.txt" "
> +   echo i/text-lf w/$(stats_ascii $lfname) ${src}LF.txt >e &&
> +   echo i/text-crlf w/$(stats_ascii $crlfname) ${src}CRLF.txt 
> >>e &&
> +   echo i/text-crlf-lf w/$(stats_ascii $lfmixcrlf) 
> ${src}CRLF_mix_LF.txt >>e &&
> +   echo i/binary w/$(stats_ascii $lfmixcr) ${src}LF_mix_CR.txt 
> >>e &&
> +   echo i/binary w/$(stats_ascii $crlfnul) ${src}CRLF_nul.txt 
> >>e &&
> +   echo i/binary w/$(stats_ascii $crlfnul) ${src}LF_nul.txt >>e 
> &&

I wonder if a here-doc would make this a bit more readable and maintainable...

echo >e <<-EOF &&
i/text-lf w/$(stats_ascii $lfname) ${src}LF.txt
i/text-crlf w/$(stats_ascii $crlfname) ${src}CRLF.txt
i/text-crlf-lf w/$(stats_ascii $lfmixcrlf) ${src}CRLF_mix_LF.txt
i/binary w/$(stats_ascii $lfmixcr) ${src}LF_mix_CR.txt
i/binary w/$(stats_ascii $crlfnul) ${src}CRLF_nul.txt
i/binary w/$(stats_ascii $crlfnul) ${src}LF_nul.txt
EOF

> +   sort exp &&
> +   git ls-files --eol $src* | sed -e 's!attr/[=a-z-]*!!g' -e 's/ 
>  */ /g' | sort >act &&
> +   test_cmp exp act &&
> +   rm e exp act
> +   "
> @@ -231,6 +267,35 @@ checkout_files () {
> "
>  }
>
> +# Test control characters
> +# NUL SOH CR EOF==^Z
> +test_expect_success 'ls-files --eol -o Text/Binary' '
> +   test_when_finished "rm e exp act TeBi_*" &&
> +   STRT=AAA &&
> +   STR=$STRT$STRT$STRT$STRT &&
> +   printf "${STR}BBB\001" >TeBi_127_S &&
> +   printf "${STR}\001">TeBi_128_S &&
> +   printf "${STR}BBB\032" >TeBi_127_E &&
> +   printf "\032${STR}BBB" >TeBi_E_127 &&
> +   printf "${STR}\000">TeBi_128_N &&
> +   printf "${STR}BBB\012">TeBi_128_L &&
> +   printf "${STR}BBB\015">TeBi_127_C &&
> +   printf "${STR}BB\015\012" >TeBi_126_CL &&
> +   printf "${STR}BB\015\012\015" >TeBi_126_CLC &&
> +   echo i/ w/binary TeBi_127_S >e &&
> +   echo i/ w/text-no-eol TeBi_128_S >>e &&
> +   echo i/ w/text-no-eol TeBi_127_E >>e &&
> +   echo i/ w/binary TeBi_E_127 >>e &&
> +   echo i/ w/binary TeBi_128_N >>e &&
> +   ech

Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"

2015-11-23 Thread Carlos Martín Nieto

Hello Mark,

On 23 Nov 2015, at 12:04, Marc Strapetz  wrote:

> There is a strange "branch --set-upstream-to" failure for "clones" which 
> haven't been created using "git clone" but constructed using "git init", "git 
> remote add" and "git fetch".
> 
> Following script first creates a "main" repository and then constructs the 
> clone. Finally, in the clone branches origin/1 and origin/2 will be present, 
> however it's not possible to invoke "git branch --set-upstream-to" for 
> origin/2 (it works fine for origin/1).
> 
> I guess the behavior is related to following line in .git/config:
> 
> fetch = refs/heads/1:refs/remotes/origin/1
> 
> However, I don't understand what's the problem for Git here? Definitely the 
> error "starting point 'origin/2' is not a branch" is wrong.
> 

That is indeed the issue. The configuration which is stored in the 
configuration is a remote+branch pair. If there is no fetch refspec configured 
which would create the ‘origin/2’ remote-tracking branch, the command does not 
know which remote and branch that would correspond to.

If you had ‘refs/heads/2:refs/remotes/origin/2’ then it would know, but other 
remote-tracking branches (e.g. ‘origin/3’) would still have an unknown source.

The error message is indeed bogus; it’s likely one of the functions assuming 
how it’s going to be used.

   cmn

--
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] ls-files: Add eol diagnostics

2015-11-23 Thread Torsten Bögershausen

On 22.11.15 09:20, Sebastian Schuberth wrote:
> On 21.11.2015 08:36, Torsten Bögershausen wrote:
> 
>> git ls-files --eol gives an output like this:
>>
>> i/text-no-eol   w/text-no-eol   attr/text=auto t/t5100/empty
> 
> I'm sorry if this has been discussed before, but hav you considered to use a 
> header line and omit the prefixed from the columns instead? Like
> 
> index working tree attributesfile
> 
> binarybinary   -text t/test-binary-2.png
> text-lf   text-lf  eol=lft/t5100/rfc2047-info-0007
> text-lf   text-crlfeol=crlf  doit.bat
> text-crlf-lf  text-crlf-lf   locale/XX.po
> 
> I believe this would be both easier to read for humans, and easier to parse 
> for scripts that e.g. want to compare line endings in the index and working 
> tree.
> 
The problem I see is to make sure that there is always a separator, even when a 
field empty:

rm zlib.c; git ls-file --eol #will include a line like this:
i/text-lf   w/  attr/  zlib.c

or, as another example:
git ls-files -o --eol
i/  w/binaryattr/  zlib.o


And if there is no separator, it is harder to make it machine-parsable,
if we e.g. extend the attributes to support "*text=autocrlf", or 
"*.text=autoinput"
(But that is another story)

If we replace "/[-a-z]" with "\t", the line has always a separator,
but needs a somewhat wider screen:
text-lf text-lf   zlib.c




>> +echo huh $1
[] good catch, 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: What's cooking in git.git (Nov 2015, #03; Fri, 20)

2015-11-23 Thread Victor Leschuk



On 11/20/2015 05:09 PM, Jeff King wrote:

* vl/grep-configurable-threads (2015-11-01) 1 commit
  - grep: add --threads= option and grep.threads configuration

  "git grep" can now be configured (or told from the command line)
  how many threads to use when searching in the working tree files.

  I haven't reviewed v6 yet. More eyes are welcome.
Actually v6 includes only changes to special meaning of "0" (0 is now 
default behavior - 8 threads), little corrections to documentation and 
getting rid of online_cpus() in decision-tree. All as discussed in 
comments for v4/5.


--
Victor
--
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: What's cooking in git.git (Nov 2015, #03; Fri, 20)

2015-11-23 Thread Johannes Schindelin

Hi Peff,

On Fri, 20 Nov 2015, Jeff King wrote:

> * pt/http-socks-proxy (2015-11-20) 1 commit
>   (merged to 'next' on 2015-11-20 at dc6ae48)
>  + remote-http(s): support SOCKS proxies
> 
>  Add support for talking http/https over socks proxy.
> 
>  Will cook in 'next'.

With all due respect, I do not thing this needs more cooking, as it

1. was tested extensively by yours truly in the Git for Windows context,
   and it

2. cannot possibly break anything because it tests specifically for the
   "socks:" prefix. It is a pure new feature.

Ciao,
Johannes
--
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] filter-branch: deal with object name vs. pathname ambiguity in tree-filter

2015-11-23 Thread SZEDER Gábor

'git filter-branch' fails complaining about an ambiguous argument, if
a tree-filter renames a path and the new pathname happens to match an
existing object name.

After the tree-filter has been applied, 'git filter-branch' looks for
changed paths by running:

  git diff-index -r --name-only --ignore-submodules $commit

which then, because of the lack of disambiguating double-dash, can't
decide whether to treat '$commit' as revision or path and errors out.

Add that disambiguating double-dash after 'git diff-index's revision
argument to make sure that '$commit' is interpreted as a revision.

Signed-off-by: SZEDER Gábor 
---
 git-filter-branch.sh | 2 +-
 t/t7003-filter-branch.sh | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 27c9c54fbd..cefd1452c6 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -349,7 +349,7 @@ while read commit parents; do
die "tree filter failed: $filter_tree"
 
(
-   git diff-index -r --name-only --ignore-submodules 
$commit &&
+   git diff-index -r --name-only --ignore-submodules 
$commit -- &&
git ls-files --others
) > "$tempdir"/tree-state || exit
git update-index --add --replace --remove --stdin \
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 377c648e04..869e0bf073 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -418,4 +418,11 @@ test_expect_success 'filter commit message without 
trailing newline' '
test_cmp expect actual
 '
 
+test_expect_success 'tree-filter deals with object name vs pathname ambiguity' 
'
+   test_when_finished "git reset --hard original" &&
+   ambiguous=$(git rev-list -1 HEAD) &&
+   git filter-branch --tree-filter "mv file.t $ambiguous" HEAD^.. &&
+   git show HEAD:$ambiguous
+'
+
 test_done
-- 
2.6.3.416.g766831e

--
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

add support for --show-signature in gitk

2015-11-23 Thread Daniel Fahlke

Hi,

the cli command `git log --show-signatures` has the nice feature of
showing additional informations for signed commits.
I want to add this informations into the gitk view of a commit.

I already have finished a first draft of this here
https://github.com/Flyingmana/git/commit/21a93f15e65765bfa98a28538da641877aa9843a
This only works, when gitk is called together with --show-signature, so
my question now is, how to best add it, and should I add it as config
like the "display nearby tags/heads" one?

I also think about adding it to the commit list somehow, but have no
idea yet how it would fit in a good way there.

Now I hope for a bit of feedback if it is the right direction, or if
there is another attempt to prefer.
--
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] http: treat config options sslCAPath and sslCAInfo as paths

2015-11-23 Thread charles

From: Charles Bailey 

This enables ~ and ~user expansion for these config options.

Signed-off-by: Charles Bailey 
---

In the only place that we (optionally) test https specifically, we also
turn off SSL verification so I couldn't see a sensible way to add an
automated test.

The change is fairly simple and I've tested manually and the effects are
as I expected - I can point to a certificate bundle or directory in my
home directory using a ~/ prefix in my .gitconfig.

 http.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/http.c b/http.c
index 42f29ce..5e37252 100644
--- a/http.c
+++ b/http.c
@@ -214,10 +214,10 @@ static int http_options(const char *var, const char 
*value, void *cb)
 #endif
 #if LIBCURL_VERSION_NUM >= 0x070908
if (!strcmp("http.sslcapath", var))
-   return git_config_string(&ssl_capath, var, value);
+   return git_config_pathname(&ssl_capath, var, value);
 #endif
if (!strcmp("http.sslcainfo", var))
-   return git_config_string(&ssl_cainfo, var, value);
+   return git_config_pathname(&ssl_cainfo, var, value);
if (!strcmp("http.sslcertpasswordprotected", var)) {
ssl_cert_password_required = git_config_bool(var, value);
return 0;
-- 
2.6.0

--
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 v7 1/2] config.mak.uname: Darwin: define NO_GETTEXT for OS X 10.9 and later

2015-11-23 Thread Torsten Bögershausen


On 11/23/2015 09:25 AM, larsxschnei...@gmail.com wrote:

From: Lars Schneider 

At least since OS X 10.9 Mavericks "libintl.h" is not available on OS X
anymore. Disable the support with the NO_GETTEXT flag.

Signed-off-by: Lars Schneider 
---
  config.mak.uname | 5 +
  1 file changed, 5 insertions(+)

diff --git a/config.mak.uname b/config.mak.uname
index f34dcaa..f3d98bb 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -102,9 +102,14 @@ ifeq ($(uname_S),Darwin)
ifeq ($(shell expr "$(uname_R)" : '[15]\.'),2)
NO_STRLCPY = YesPlease
endif
+   # MacOS 10.7 Lion and higher
ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 11 
&& echo 1),1)
HAVE_GETDELIM = YesPlease
endif
+   # MacOS 10.9 Mavericks and higher
+   ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 13 
&& echo 1),1)
+   NO_GETTEXT = YesPlease
+   endif
NO_MEMMEM = YesPlease
USE_ST_TIMESPEC = YesPlease
HAVE_DEV_TTY = YesPlease
Unless I'm wrong, no Mac OS X had libintl.h, and the "unwritten 
agreement (?)" was

that either
a) libintl ist installed in some way (fink, mac ports, brew, other ways)
or
b) people use
NO_GETTEXT=yes make

Doesn't this patch close the door for b), making it impossible to build 
Git against libintl ?

A better test may if libintl is installed may help, or better documentation.


--
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 practice setup for github projects on server

2015-11-23 Thread Matthew Leach

Hi,

I was hoping that somebody could give me advice since I'm new to git.

I'll be installing a couple of projects from github on our servers, and adding 
some features.

Should I create a repository on our server (e.g. in /opt/git/), add the github 
project as a remote, and create a branch?  Then on my local machine add our 
server as the remote and then pull / push with that?

On the server there will be two web directories: stable and dev.  I was 
planning for these to be branches, and then just pull from the server 
repository using the local protocol.

I think it would mean sorting out merge actions on the server.  I'm hoping to 
be able to fetch and integrate updates from the developer's github repository, 
but without making things more complicated than they need to be.

Does anyone have any suggestions?  I drew a diagram if it helps 
(https://drive.google.com/file/d/0B7JhUXLbxPT9RkVNMUV6cjJNVnc/view?usp=sharing)

Thanks

Matthew


Matthew Leach 
BSc. PhD. PGCert. FHEA
Innovation Developer

Academic Innovation Hub
Room 107, Enterprise Centre, 37 Bridge Street, Derby, DE1 3LD

The University of Derby has a published policy regarding email and reserves the 
right to monitor email traffic. If you believe this was sent to you in error, 
please select unsubscribe.

Unsubscribe and Security information contact:   info...@derby.ac.uk
For all FOI requests please contact:   f...@derby.ac.uk
All other Contacts are at http://www.derby.ac.uk/its/contacts/
--
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

branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"

2015-11-23 Thread Marc Strapetz

There is a strange "branch --set-upstream-to" failure for "clones" which 
haven't been created using "git clone" but constructed using "git init", 
"git remote add" and "git fetch".


Following script first creates a "main" repository and then constructs 
the clone. Finally, in the clone branches origin/1 and origin/2 will be 
present, however it's not possible to invoke "git branch 
--set-upstream-to" for origin/2 (it works fine for origin/1).


I guess the behavior is related to following line in .git/config:

fetch = refs/heads/1:refs/remotes/origin/1

However, I don't understand what's the problem for Git here? Definitely 
the error "starting point 'origin/2' is not a branch" is wrong.




$ git --version
git version 2.5.0.windows.1

$ cd /tmp/gittest
$ mkdir main
$ cd main
$ git init
$ touch file
$ git add file
$ git commit -m "import"
$ git branch 1
$ git branch 2
$ git branch
  1
  2
* master

$ cd /tmp/gittest
$ mkdir clone
$ cd clone
$ git init
Initialized empty Git repository in /tmp/gittest/clone/.git/
$ git remote add origin /tmp/gittest/main
$ git config remote.origin.fetch refs/heads/1:refs/remotes/origin/1
$ git fetch origin
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /tmp/gittest/main
 * [new branch]  1  -> origin/1

$ git fetch origin refs/heads/2:refs/remotes/origin/2
From /tmp/gittest/main
 * [new branch]  2  -> origin/2

$ git branch --no-track 2 refs/remotes/origin/2
$ git branch
  2

# HERE COMES THE STRANGE FAILURE:
$ git branch --set-upstream-to=origin/2 2
fatal: Cannot setup tracking information; starting point 'origin/2' is 
not a branch.


# THIS WORKS AS EXPECTED:
$ git branch --set-upstream-to=origin/1 2
Branch 2 set up to track remote branch 1 from origin by rebasing.

-Marc
--
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: What's cooking in git.git (Nov 2015, #03; Fri, 20)