But in `git checkout --patch`

[Benjamin Quorning]

I'm not entirely sure how you like your bug reports, so I'll just the
best I can :-)

$ git --version
git version 2.2.0

$ uname -a
Darwin buzz.local 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17
19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

Reproduction steps:

1. A repository with a changed file, but no staged changes.
2. Execute `git checkout --patch`
3. When asked, press `e` to edit a chunk (opens an external editor in my case)
4. With the editor still open, click ctrl-C in the terminal.
5. The diff that was being edited, and the command prompt ("discard
this hunk from worktree" etc) is printed to the screen, over and over
again.
6. I have to grep and kill this process: /usr/bin/perl
/usr/local/Cellar/git/2.2.0/libexec/git-core/git-add--interactive
--patch=checkout --

--
Benjamin Quorning
--
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] Update documentation occurrences of filename .sh

[Peter van der Does]

Documentation in the completion scripts for Bash and Zsh state the wrong 
filenames.

Signed-off-by: Peter van der Does 

---
 contrib/completion/git-completion.bash | 4 ++--
 contrib/completion/git-completion.zsh  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 2fece98..41608ad 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -16,9 +16,9 @@
 #
 # To use these routines:
 #
-#1) Copy this file to somewhere (e.g. ~/.git-completion.sh).
+#1) Copy this file to somewhere (e.g. ~/.git-completion.bash).
 #2) Add the following line to your .bashrc/.zshrc:
-#source ~/.git-completion.sh
+#source ~/.git-completion.bash
 #3) Consider changing your PS1 to also show the current branch,
 #   see git-prompt.sh for details.
 #
diff --git a/contrib/completion/git-completion.zsh 
b/contrib/completion/git-completion.zsh
index 9f6f0fa..e255413 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -9,7 +9,7 @@
 #
 # If your script is somewhere else, you can configure it on your ~/.zshrc:
 #
-#  zstyle ':completion:*:*:git:*' script ~/.git-completion.sh
+#  zstyle ':completion:*:*:git:*' script ~/.git-completion.zsh
 #
 # The recommended way to install this script is to copy to '~/.zsh/_git', and
 # then add the following to your ~/.zshrc file:
-- 
2.2.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

[PATCH v2] git-gui: fix problem with gui.maxfilesdisplayed

[Csaba Kiraly]

gui.maxfilesdisplayed (added in dd6451f9c7c5a36d3006231b618ac6da06c7c7b4)
was applied brute force on the file list in alphabetic order. As a result,
files that had modifications might not be displayed by git-gui. Even
worse, files that are already in the index might not be displayed, which
makes git-gui hard to use in some workflows.

This fix changes the meaning of gui.maxfilesdisplayed, making it a soft
limit that only applies to "_O" files, i.e. files that are "Untracked,
not staged".

Signed-off-by: Csaba Kiraly 
---
 git-gui.sh | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/git-gui.sh b/git-gui.sh
index 27ce0e3..0e4b05a 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1965,20 +1965,22 @@ proc display_all_files {} {
 
set to_display [lsort [array names file_states]]
set display_limit [get_config gui.maxfilesdisplayed]
-   if {[llength $to_display] > $display_limit} {
-   if {!$files_warning} {
-   # do not repeatedly warn:
-   set files_warning 1
-   info_popup [mc "Displaying only %s of %s files." \
-   $display_limit [llength $to_display]]
-   }
-   set to_display [lrange $to_display 0 [expr {$display_limit-1}]]
-   }
+   set displayed 0
foreach path $to_display {
set s $file_states($path)
set m [lindex $s 0]
set icon_name [lindex $s 1]
 
+   if {$displayed > $display_limit && [string index $m 1] eq {O} } 
{
+   if {!$files_warning} {
+   # do not repeatedly warn:
+   set files_warning 1
+   info_popup [mc "Display limit 
(gui.maxfilesdisplayed = %s) reached, not showing all %s files." \
+   $display_limit [llength $to_display]]
+   }
+   continue
+   }
+
set s [string index $m 0]
if {$s ne {U} && $s ne {_}} {
display_all_files_helper $ui_index $path \
@@ -1993,6 +1995,7 @@ proc display_all_files {} {
if {$s ne {_}} {
display_all_files_helper $ui_workdir $path \
$icon_name $s
+   incr displayed
}
}
 
-- 
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

[PATCH] add--interactive: leave main loop on read error

[Jeff King]

On Mon, Dec 15, 2014 at 03:41:45PM +0100, Benjamin Quorning wrote:

> Reproduction steps:
> 
> 1. A repository with a changed file, but no staged changes.
> 2. Execute `git checkout --patch`
> 3. When asked, press `e` to edit a chunk (opens an external editor in my case)
> 4. With the editor still open, click ctrl-C in the terminal.
> 5. The diff that was being edited, and the command prompt ("discard
> this hunk from worktree" etc) is printed to the screen, over and over
> again.
> 6. I have to grep and kill this process: /usr/bin/perl
> /usr/local/Cellar/git/2.2.0/libexec/git-core/git-add--interactive
> --patch=checkout --

Thanks, I could reproduce this pretty easily with:

  GIT_EDITOR='f() { sleep 60; }; f' git checkout -p

(and then hit 'e', and ^C). Explanation and fix are below.

-- >8 --
The main hunk loop for add--interactive will loop if it does
not get a known input. This is a good thing if the user
typed some invalid input. However, if we have an
uncorrectable read error, we'll end up looping infinitely.
We can fix this by noticing read errors (i.e., 
returns undef) and breaking out of the loop.

One easy way to trigger this is if you have an editor that
does not take over the terminal (e.g., one that spawns a
window in an existing process and waits), start the editor
with the hunk-edit command, and hit ^C to send SIGINT. The
editor process dies due to SIGINT, but the perl
add--interactive process does not (perl suspends SIGINT for
the duration of our system() call).

We return to the main loop, but further reads from stdin
don't work. The SIGINT _also_ killed our parent git process,
which orphans our process group, meaning that further reads
from the terminal will always fail. We loop infinitely,
getting EIO on each read.

Note that there are several other spots where we read from
stdin, too. However, in each of those cases, we do something
sane when the read returns undef (breaking out of the loop,
taking the input as "no", etc). They don't need similar
treatment.

Signed-off-by: Jeff King 
---
 git-add--interactive.perl | 1 +
 1 file changed, 1 insertion(+)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 1fadd69..c725674 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1356,6 +1356,7 @@ sub patch_update_file {
  $patch_mode_flavour{TARGET},
  " [y,n,q,a,d,/$other,?]? ";
my $line = prompt_single_character;
+   last unless defined $line;
if ($line) {
if ($line =~ /^y/i) {
$hunk[$ix]{USE} = 1;
-- 
2.2.0.465.ge0d36f1.dirty

--
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 4/4] attr: avoid heavy work when we know the specified attr is not defined

[Junio C Hamano]

Duy Nguyen  writes:

> On Tue, Dec 09, 2014 at 04:18:57PM -0800, Junio C Hamano wrote:
> ...
>> I smell that a much better split is possible.
>> ...
>
> Something like this? Definitely looks better.

Yeah, I was lazy and did not try it myself to see what the end
result would look like when I commented, but doing it this way
avoids needless repetitions.

The comment block before the collect_*_attrs function need to be
adjusted to match the updated behaviour, though.

Thanks.

> -- 8< --
> diff --git a/attr.c b/attr.c
> index b80e52b..0f828e3 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -33,9 +33,11 @@ struct git_attr {
>   unsigned h;
>   int attr_nr;
>   int maybe_macro;
> + int maybe_real;
>   char name[FLEX_ARRAY];
>  };
>  static int attr_nr;
> +static int cannot_trust_maybe_real;
>  
>  static struct git_attr_check *check_all_attr;
>  static struct git_attr *(git_attr_hash[HASHSIZE]);
> @@ -97,6 +99,7 @@ static struct git_attr *git_attr_internal(const char *name, 
> int len)
>   a->next = git_attr_hash[pos];
>   a->attr_nr = attr_nr++;
>   a->maybe_macro = 0;
> + a->maybe_real = 0;
>   git_attr_hash[pos] = a;
>  
>   REALLOC_ARRAY(check_all_attr, attr_nr);
> @@ -269,6 +272,10 @@ static struct match_attr *parse_attr_line(const char 
> *line, const char *src,
>   /* Second pass to fill the attr_states */
>   for (cp = states, i = 0; *cp; i++) {
>   cp = parse_attr(src, lineno, cp, &(res->state[i]));
> + if (!is_macro)
> + res->state[i].attr->maybe_real = 1;
> + if (res->state[i].attr->maybe_macro)
> + cannot_trust_maybe_real = 1;
>   }
>  
>   return res;
> @@ -713,7 +720,9 @@ static int macroexpand_one(int nr, int rem)
>   * Collect all attributes for path into the array pointed to by
>   * check_all_attr.
>   */
> -static void collect_all_attrs(const char *path)
> +static void collect_some_attrs(const char *path, int num,
> +struct git_attr_check *check)
> +
>  {
>   struct attr_stack *stk;
>   int i, pathlen, rem, dirlen;
> @@ -736,6 +745,19 @@ static void collect_all_attrs(const char *path)
>   prepare_attr_stack(path, dirlen);
>   for (i = 0; i < attr_nr; i++)
>   check_all_attr[i].value = ATTR__UNKNOWN;
> + if (num && !cannot_trust_maybe_real) {
> + rem = 0;
> + for (i = 0; i < num; i++) {
> + if (!check[i].attr->maybe_real) {
> + struct git_attr_check *c;
> + c = check_all_attr + check[i].attr->attr_nr;
> + c->value = ATTR__UNSET;
> + rem++;
> + }
> + }
> + if (rem == num)
> + return;
> + }
>  
>   rem = attr_nr;
>   for (stk = attr_stack; 0 < rem && stk; stk = stk->prev)
> @@ -746,7 +768,7 @@ int git_check_attr(const char *path, int num, struct 
> git_attr_check *check)
>  {
>   int i;
>  
> - collect_all_attrs(path);
> + collect_some_attrs(path, num, check);
>  
>   for (i = 0; i < num; i++) {
>   const char *value = 
> check_all_attr[check[i].attr->attr_nr].value;
> @@ -762,7 +784,7 @@ int git_all_attrs(const char *path, int *num, struct 
> git_attr_check **check)
>  {
>   int i, count, j;
>  
> - collect_all_attrs(path);
> + collect_some_attrs(path, 0, NULL);
>  
>   /* Count the number of attributes that are set. */
>   count = 0;
> -- 8< --
--
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] win32: syslog: prevent potential realloc memory leak

[Junio C Hamano]

Arjun Sreedharan  writes:

> use a temporary variable to free the memory in case
> realloc() fails.
>
> Signed-off-by: Arjun Sreedharan 
> ---
>  compat/win32/syslog.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/compat/win32/syslog.c b/compat/win32/syslog.c
> index d015e43..3409e43 100644
> --- a/compat/win32/syslog.c
> +++ b/compat/win32/syslog.c
> @@ -16,7 +16,7 @@ void openlog(const char *ident, int logopt, int facility)
>  void syslog(int priority, const char *fmt, ...)
>  {
>   WORD logtype;
> - char *str, *pos;
> + char *str, *str_temp, *pos;
>   int str_len;
>   va_list ap;
>  
> @@ -43,9 +43,11 @@ void syslog(int priority, const char *fmt, ...)
>   va_end(ap);
>  
>   while ((pos = strstr(str, "%1")) != NULL) {
> + str_temp = str;
>   str = realloc(str, ++str_len + 1);
>   if (!str) {
>   warning("realloc failed: '%s'", strerror(errno));
> + free(str_temp);
>   return;
>   }

Hmm, the original, 088d8802 (mingw: implement syslog, 2010-11-04),
that introduced the special casing for %1, says:

Syslog does not usually exist on Windows, so implement our own
using Window's ReportEvent mechanism.

Strings containing "%1" gets expanded into them selves by
ReportEvent, resulting in an unreadable string. "%2" and above
is not a problem.  Unfortunately, on Windows an IPv6 address can
contain "%1", so expand "%1" to "% 1" before reporting. "%%1" is
also a problem for ReportEvent, but that string cannot occur in
an IPv6 address.

It is unclear why it says '"%2" and above is not a problem' to me.
Is that because they expand to something not "an unreadable string",
or is that because in the original developer's testing only "%1" was
observed?  It also says "%%1" is a problem, and it does not occur in
an IPv6 address, but that would suggest that every time a new caller
is added to syslog(), this imitation of syslog() can break, as there
is nothing that says the new caller must be reporting something
about an IP address.  Perhaps this loop should cleanse what it
passes to ReportEvent() a bit more aggressively by expanding all "%"
to "%-sp" or something)?

Regardless of that funny %1 business, I notice in


http://msdn.microsoft.com/en-us/library/windows/desktop/aa363679%28v=vs.85%29.aspx

that each element of lpStrings array that is passed to ReportEvent()
is limited to 32k or so.  Wouldn't it make it a lot simpler if we
removed the dynamic allocation and use a fixed sized 32k buffer here
(and truncate the result as necessary)?  That would make the "leak"
disappear automatically.

Having said all that, if we were to still go with the current code
structure, "str_temp" should be scoped inside the loop, as there is
no need to make it available to the remainder of the function, I
think.  Also writing this way may make the intention more clear.

while (...) {
char *new_str = realloc(str, ...);
if (!new_str) {
free(str);
return;
}
memmove(... to shuffle ...);

And after starting to write the above, I notice that the current
code around realloc may be completely bogus.  It goes like this:

while ((pos = strstr(str, "..."))) {
str = realloc(str, ...);
if (!str) { warn and bail; }
memmove(pos + 1, pos + 1, ...);
pos[1] = ' ';
}

If realloc() really allocated a new string, then pos that points
into the original str has no relation to the reallocated str, so
memmove() is not shuffling the string to make room for the SP in the
string that will be given to ReportEvent() at all, no?  This seems
to be a bug introduced by 2a6b149c (mingw: avoid using strbuf in
syslog, 2011-10-06).

It makes me wonder if this codepath ever triggers in the first
place.
--
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 11/23] untracked cache: load from UNTR index extension

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

> +struct untracked_cache *read_untracked_extension(const void *data, unsigned 
> long sz)
> +{
> + const struct ondisk_untracked_cache *ouc;
> + struct untracked_cache *uc;
> + struct read_data rd;
> + const unsigned char *next = data, *end = data + sz;

data + sz is arithmetic on void * which is a no-no.
--
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 3/5] receive-pack.c: use a single ref_transaction for atomic pushes

[Stefan Beller]

From: Ronnie Sahlberg 

Update receive-pack to use an atomic transaction iff the client negotiated
that it wanted atomic-push. This leaves the default behavior to be the old
non-atomic one ref at a time update. This is to cause as little disruption
as possible to existing clients. It is unknown if there are client scripts
that depend on the old non-atomic behavior so we make it opt-in for now.

If it turns out over time that there are no client scripts that depend on the
old behavior we can change git to default to use atomic pushes and instead
offer an opt-out argument for people that do not want atomic pushes.

Signed-off-by: Ronnie Sahlberg 
Signed-off-by: Stefan Beller 
---
 builtin/receive-pack.c | 73 +++---
 1 file changed, 58 insertions(+), 15 deletions(-)

diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 0c642ab..e6cf174 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -67,6 +67,8 @@ static const char *NONCE_SLOP = "SLOP";
 static const char *nonce_status;
 static long nonce_stamp_slop;
 static unsigned long nonce_stamp_slop_limit;
+struct strbuf err = STRBUF_INIT;
+struct ref_transaction *transaction;
 
 static enum deny_action parse_deny_action(const char *var, const char *value)
 {
@@ -832,34 +834,56 @@ static const char *update(struct command *cmd, struct 
shallow_info *si)
cmd->did_not_exist = 1;
}
}
-   if (delete_ref(namespaced_name, old_sha1, 0)) {
-   rp_error("failed to delete %s", name);
-   return "failed to delete";
+   if (!use_atomic_push) {
+   if (delete_ref(namespaced_name, old_sha1, 0)) {
+   rp_error("failed to delete %s", name);
+   return "failed to delete";
+   }
+   } else {
+   if (ref_transaction_delete(transaction,
+  namespaced_name,
+  old_sha1,
+  0, old_sha1 != NULL,
+  "push", &err)) {
+   rp_error("%s", err.buf);
+   strbuf_release(&err);
+   return "failed to delete";
+   }
}
return NULL; /* good */
}
else {
-   struct strbuf err = STRBUF_INIT;
-   struct ref_transaction *transaction;
-
if (shallow_update && si->shallow_ref[cmd->index] &&
update_shallow_ref(cmd, si))
return "shallow error";
 
-   transaction = ref_transaction_begin(&err);
-   if (!transaction ||
-   ref_transaction_update(transaction, namespaced_name,
-  new_sha1, old_sha1, 0, 1, "push",
-  &err) ||
-   ref_transaction_commit(transaction, &err)) {
-   ref_transaction_free(transaction);
-
+   if (!use_atomic_push) {
+   transaction = ref_transaction_begin(&err);
+   if (!transaction) {
+   rp_error("%s", err.buf);
+   strbuf_release(&err);
+   return "failed to start transaction";
+   }
+   }
+   if (ref_transaction_update(transaction,
+  namespaced_name,
+  new_sha1, old_sha1,
+  0, 1, "push",
+  &err)) {
rp_error("%s", err.buf);
strbuf_release(&err);
return "failed to update ref";
}
 
-   ref_transaction_free(transaction);
+   if (!use_atomic_push) {
+   if (ref_transaction_commit(transaction, &err)) {
+   ref_transaction_free(transaction);
+   rp_error("%s", err.buf);
+   strbuf_release(&err);
+   return "failed to update ref";
+   }
+   ref_transaction_free(transaction);
+   }
strbuf_release(&err);
return NULL; /* good */
}
@@ -1059,6 +1083,16 @@ static void execute_commands(struct command *commands,
return;
}
 
+   if (use_atomic_push) {
+   transaction = ref_transaction_begin(&err);
+   if (!transaction) {
+   error("%s", err.buf);
+

[PATCH 1/5] receive-pack.c: add protocol support to negotiate atomic-push

[Stefan Beller]

From: Ronnie Sahlberg 

This adds support to the protocol between send-pack and receive-pack to
* allow receive-pack to inform the client that it has atomic push capability
* allow send-pack to request atomic push back.

There is currently no setting in send-pack to actually request that atomic
pushes are to be used yet. This only adds protocol capability not ability
for the user to activate it.

Signed-off-by: Ronnie Sahlberg 
Signed-off-by: Stefan Beller 
---
 Documentation/technical/protocol-capabilities.txt | 12 ++--
 builtin/receive-pack.c|  6 +-
 send-pack.c   |  6 ++
 3 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/Documentation/technical/protocol-capabilities.txt 
b/Documentation/technical/protocol-capabilities.txt
index 6d5424c..763120c 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -18,8 +18,9 @@ was sent.  Server MUST NOT ignore capabilities that client 
requested
 and server advertised.  As a consequence of these rules, server MUST
 NOT advertise capabilities it does not understand.
 
-The 'report-status', 'delete-refs', 'quiet', and 'push-cert' capabilities
-are sent and recognized by the receive-pack (push to server) process.
+The 'atomic-push', 'report-status', 'delete-refs', 'quiet', and 'push-cert'
+capabilities are sent and recognized by the receive-pack (push to server)
+process.
 
 The 'ofs-delta' and 'side-band-64k' capabilities are sent and recognized
 by both upload-pack and receive-pack protocols.  The 'agent' capability
@@ -244,6 +245,13 @@ respond with the 'quiet' capability to suppress 
server-side progress
 reporting if the local progress reporting is also being suppressed
 (e.g., via `push -q`, or if stderr does not go to a tty).
 
+atomic-push
+---
+
+If the server sends the 'atomic-push' capability, it means it is
+capable of accepting atomic pushes. If the pushing client requests this
+capability, the server will update the refs in one single atomic transaction.
+
 allow-tip-sha1-in-want
 --
 
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 32fc540..0c642ab 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -40,6 +40,7 @@ static int transfer_unpack_limit = -1;
 static int unpack_limit = 100;
 static int report_status;
 static int use_sideband;
+static int use_atomic_push;
 static int quiet;
 static int prefer_ofs_delta = 1;
 static int auto_update_server_info;
@@ -171,7 +172,8 @@ static void show_ref(const char *path, const unsigned char 
*sha1)
struct strbuf cap = STRBUF_INIT;
 
strbuf_addstr(&cap,
- "report-status delete-refs side-band-64k quiet");
+ "report-status delete-refs side-band-64k quiet "
+ "atomic-push");
if (prefer_ofs_delta)
strbuf_addstr(&cap, " ofs-delta");
if (push_cert_nonce)
@@ -1179,6 +1181,8 @@ static struct command *read_head_info(struct sha1_array 
*shallow)
use_sideband = LARGE_PACKET_MAX;
if (parse_feature_request(feature_list, "quiet"))
quiet = 1;
+   if (parse_feature_request(feature_list, "atomic-push"))
+   use_atomic_push = 1;
}
 
if (!strcmp(line, "push-cert")) {
diff --git a/send-pack.c b/send-pack.c
index 949cb61..1ccc84c 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -294,6 +294,8 @@ int send_pack(struct send_pack_args *args,
int use_sideband = 0;
int quiet_supported = 0;
int agent_supported = 0;
+   int atomic_push_supported = 0;
+   int atomic_push = 0;
unsigned cmds_sent = 0;
int ret;
struct async demux;
@@ -314,6 +316,8 @@ int send_pack(struct send_pack_args *args,
agent_supported = 1;
if (server_supports("no-thin"))
args->use_thin_pack = 0;
+   if (server_supports("atomic-push"))
+   atomic_push_supported = 1;
if (args->push_cert) {
int len;
 
@@ -335,6 +339,8 @@ int send_pack(struct send_pack_args *args,
strbuf_addstr(&cap_buf, " side-band-64k");
if (quiet_supported && (args->quiet || !args->progress))
strbuf_addstr(&cap_buf, " quiet");
+   if (atomic_push)
+   strbuf_addstr(&cap_buf, " atomic-push");
if (agent_supported)
strbuf_addf(&cap_buf, " agent=%s", git_user_agent_sanitized());
 
-- 
2.2.0.33.gc2219e3.dirty

--
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 0/5] Add a flag to push atomically

[Stefan Beller]

This patch series adds a flag to git push to update the remote refs atomically.

It was part of a longer patch series[1].
This series applies on top of origin/mh/reflog-expire
It can also be found at [2].

Change since picking the series up from Ronnie.
  * other anchor point (i.e. where the series applies)
  * more tests for this feature, specially testing failures
  * drop the patch to rename ref_transaction_* to transaction_*_ref
  * slight rewording of the additional documentation

[1] http://www.spinics.net/lists/git/msg241214.html
[2] https://github.com/stefanbeller/git/tree/atomic-push-v1

Ronnie Sahlberg (4):
  receive-pack.c: add protocol support to negotiate atomic-push
  send-pack.c: add an --atomic-push command line argument
  receive-pack.c: use a single transaction when atomic-push is
negotiated
  push.c: add an --atomic-push argument

Stefan Beller (1):
  t5543-atomic-push.sh: add basic tests for atomic pushes

 Documentation/git-push.txt|   8 +-
 Documentation/git-send-pack.txt   |   7 +-
 Documentation/technical/protocol-capabilities.txt |  12 +-
 builtin/push.c|   2 +
 builtin/receive-pack.c|  79 +++--
 builtin/send-pack.c   |   6 +-
 remote.h  |   3 +-
 send-pack.c   |  45 +-
 send-pack.h   |   1 +
 t/t5543-atomic-push.sh| 185 ++
 transport.c   |   5 +
 transport.h   |   1 +
 12 files changed, 327 insertions(+), 27 deletions(-)
 create mode 100755 t/t5543-atomic-push.sh

-- 
2.2.0.33.gc2219e3.dirty

--
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 2/5] send-pack.c: add an --atomic-push command line argument

[Stefan Beller]

From: Ronnie Sahlberg 

This adds support to send-pack to negotiate and use atomic pushes
iff the server supports it. Atomic pushes are activated by a new command
line flag --atomic-push.

In order to do this we also need to change the semantics for send_pack()
slightly. The existing send_pack() function actually doesn't send all the
refs back to the server when multiple refs are involved, for example
when using --all. Several of the failure modes for pushes can already be
detected locally in the send_pack client based on the information from the
initial server side list of all the refs as generated by receive-pack.
Any such refs that we thus know would fail to push are thus pruned from
the list of refs we send to the server to update.

For atomic pushes, we have to deal thus with both failures that are detected
locally as well as failures that are reported back from the server. In order
to do so we treat all local failures as push failures too.

We introduce a new status code REF_STATUS_ATOMIC_PUSH_FAILED so we can
flag all refs that we would normally have tried to push to the server
but we did not due to local failures. This is to improve the error message
back to the end user to flag that "these refs failed to update since the
atomic push operation failed."

Signed-off-by: Ronnie Sahlberg 
Signed-off-by: Stefan Beller 
---
 Documentation/git-send-pack.txt |  7 ++-
 builtin/send-pack.c |  6 +-
 remote.h|  3 ++-
 send-pack.c | 39 ++-
 send-pack.h |  1 +
 transport.c |  4 
 6 files changed, 52 insertions(+), 8 deletions(-)

diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index 2a0de42..9296587 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -9,7 +9,7 @@ git-send-pack - Push objects over Git protocol to another 
repository
 SYNOPSIS
 
 [verse]
-'git send-pack' [--all] [--dry-run] [--force] 
[--receive-pack=] [--verbose] [--thin] [:] 
[...]
+'git send-pack' [--all] [--dry-run] [--force] 
[--receive-pack=] [--verbose] [--thin] [--atomic-push] 
[:] [...]
 
 DESCRIPTION
 ---
@@ -62,6 +62,11 @@ be in a separate packet, and the list must end with a flush 
packet.
Send a "thin" pack, which records objects in deltified form based
on objects not included in the pack to reduce network traffic.
 
+--atomic-push::
+   Use an atomic transaction for updating the refs. If any of the refs
+   fails to update then the entire push will fail without changing any
+   refs.
+
 ::
A remote host to house the repository.  When this
part is specified, 'git-receive-pack' is invoked via
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index b564a77..93cb17c 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -13,7 +13,7 @@
 #include "sha1-array.h"
 
 static const char send_pack_usage[] =
-"git send-pack [--all | --mirror] [--dry-run] [--force] 
[--receive-pack=] [--verbose] [--thin] [:] 
[...]\n"
+"git send-pack [--all | --mirror] [--dry-run] [--force] 
[--receive-pack=] [--verbose] [--thin] [--atomic-push] 
[:] [...]\n"
 "  --all and explicit  specification are mutually exclusive.";
 
 static struct send_pack_args args;
@@ -170,6 +170,10 @@ int cmd_send_pack(int argc, const char **argv, const char 
*prefix)
args.use_thin_pack = 1;
continue;
}
+   if (!strcmp(arg, "--atomic-push")) {
+   args.use_atomic_push = 1;
+   continue;
+   }
if (!strcmp(arg, "--stateless-rpc")) {
args.stateless_rpc = 1;
continue;
diff --git a/remote.h b/remote.h
index 8b62efd..f346524 100644
--- a/remote.h
+++ b/remote.h
@@ -115,7 +115,8 @@ struct ref {
REF_STATUS_REJECT_SHALLOW,
REF_STATUS_UPTODATE,
REF_STATUS_REMOTE_REJECT,
-   REF_STATUS_EXPECTING_REPORT
+   REF_STATUS_EXPECTING_REPORT,
+   REF_STATUS_ATOMIC_PUSH_FAILED
} status;
char *remote_status;
struct ref *peer_ref; /* when renaming */
diff --git a/send-pack.c b/send-pack.c
index 1ccc84c..08602a8 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -190,7 +190,7 @@ static void advertise_shallow_grafts_buf(struct strbuf *sb)
for_each_commit_graft(advertise_shallow_grafts_cb, sb);
 }
 
-static int ref_update_to_be_sent(const struct ref *ref, const struct 
send_pack_args *args)
+static int ref_update_to_be_sent(const struct ref *ref, const struct 
send_pack_args *args, int *atomic_push_failed)
 {
if (!ref->peer_ref && !args->send_mirror)
return 0;
@@ -203,6 +203,12 @@ static int ref_update_to_be_sent(const struct ref *ref,

[PATCH 5/5] t5543-atomic-push.sh: add basic tests for atomic pushes

[Stefan Beller]

This adds tests for the atomic push option.
The first four tests check if the atomic option works in
good conditions and the last three patches check if the atomic
option prevents any change to be pushed if just one ref cannot
be updated.

Signed-off-by: Stefan Beller 
---

Notes:
Originally Ronnie had a similar patch prepared. But as I added
more tests and cleaned up the existing tests (e.g. use test_commit
instead of "echo one >file && gitadd file && git commit -a -m 'one'",
removal of dead code), the file has changed so much that I'd rather
take ownership.

 t/t5543-atomic-push.sh | 185 +
 1 file changed, 185 insertions(+)
 create mode 100755 t/t5543-atomic-push.sh

diff --git a/t/t5543-atomic-push.sh b/t/t5543-atomic-push.sh
new file mode 100755
index 000..6cbedc5
--- /dev/null
+++ b/t/t5543-atomic-push.sh
@@ -0,0 +1,185 @@
+#!/bin/sh
+
+test_description='pushing to a repository using the atomic push option'
+
+. ./test-lib.sh
+
+D=`pwd`
+
+mk_repo_pair () {
+   rm -rf workbench upstream thirdparty &&
+   mkdir upstream &&
+   (
+   cd upstream &&
+   git init --bare #&&
+   #git config receive.denyCurrentBranch warn
+   ) &&
+   mkdir workbench &&
+   (
+   cd workbench &&
+   git init &&
+   git remote add up ../upstream
+   )
+}
+
+test_push_failed () {
+   workbench_master=$(cd workbench && git show-ref -s --verify 
refs/heads/master) &&
+   upstream_master=$(cd upstream && git show-ref -s --verify 
refs/heads/master) &&
+   test "$workbench_master" != "$upstream_master" &&
+
+   workbench_second=$(cd workbench && git show-ref -s --verify 
refs/heads/second) &&
+   upstream_second=$(cd upstream && git show-ref -s --verify 
refs/heads/second) &&
+   test "$workbench_second" != "$upstream_second"
+}
+
+test_push_succeeded () {
+   workbench_master=$(cd workbench && git show-ref -s --verify 
refs/heads/master) &&
+   upstream_master=$(cd upstream && git show-ref -s --verify 
refs/heads/master) &&
+   test "$workbench_master" = "$upstream_master"
+
+   workbench_second=$(cd workbench && git show-ref -s --verify 
refs/heads/second) &&
+   upstream_second=$(cd upstream && git show-ref -s --verify 
refs/heads/second) &&
+   test "$workbench_second" = "$upstream_second"
+}
+
+test_expect_success 'atomic push works for a single branch' '
+   mk_repo_pair &&
+   (
+   cd workbench &&
+   test_commit one &&
+   git push --mirror up &&
+   test_commit two &&
+   git push --atomic-push --mirror up
+   ) &&
+   workbench_master=$(cd workbench && git show-ref -s --verify 
refs/heads/master) &&
+   upstream_master=$(cd upstream && git show-ref -s --verify 
refs/heads/master) &&
+   test "$workbench_master" = "$upstream_master"
+'
+
+test_expect_success 'atomic push works for two branches' '
+   mk_repo_pair &&
+   (
+   cd workbench &&
+   test_commit one &&
+   git branch second &&
+   git push --mirror up &&
+   test_commit two &&
+   git checkout second &&
+   test_commit three &&
+   git push --atomic-push --mirror up
+   ) &&
+   test_push_succeeded
+'
+
+test_expect_success 'atomic push works in combination with --mirror' '
+   mk_repo_pair &&
+   ls workbench &&
+   (
+   cd workbench &&
+   test_commit one &&
+   git checkout -b second &&
+   test_commit two &&
+   git push --atomic-push --mirror up
+   ) &&
+   test_push_succeeded
+'
+
+test_expect_success 'atomic push works in combination with --force' '
+   mk_repo_pair &&
+   (
+   cd workbench &&
+   test_commit one &&
+   git checkout -b second &&
+   test_commit two &&
+   test_commit three &&
+   test_commit four &&
+   git push --mirror up &&
+   git reset --hard HEAD^ &&
+   git push --force --atomic-push up master second
+   ) &&
+   test_push_succeeded
+'
+
+# set up two branches where master can be pushed but second can not
+# (non-fast-forward). Since second can not be pushed the whole operation
+# will fail and leave master untouched.
+test_expect_success 'atomic push fails if one branch fails locally' '
+   mk_repo_pair &&
+   (
+   cd workbench &&
+   test_commit one &&
+   git checkout -b second master &&
+   test_commit two &&
+   test_commit three &&
+   test_commit four &&
+   git push --mirror up
+   git reset --hard HEAD~2 &&
+   git checkout master &&
+   test_commit five &&
+   ! git pu

[PATCH 4/5] push.c: add an --atomic-push argument

[Stefan Beller]

From: Ronnie Sahlberg 

Add a command line argument to the git push command to request atomic
pushes.

Signed-off-by: Ronnie Sahlberg 
Signed-off-by: Stefan Beller 
---
 Documentation/git-push.txt | 8 +++-
 builtin/push.c | 2 ++
 transport.c| 1 +
 transport.h| 1 +
 4 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 21b3f29..3e0cb6e 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
 SYNOPSIS
 
 [verse]
-'git push' [--all | --mirror | --tags] [--follow-tags] [-n | --dry-run] 
[--receive-pack=]
+'git push' [--all | --mirror | --tags] [--follow-tags] [--atomic-push] [-n | 
--dry-run] [--receive-pack=]
   [--repo=] [-f | --force] [--prune] [-v | --verbose]
   [-u | --set-upstream] [--signed]
   [--force-with-lease[=[:]]]
@@ -136,6 +136,12 @@ already exists on the remote side.
logged.  See linkgit:git-receive-pack[1] for the details
on the receiving end.
 
+--atomic-push::
+   Using atomic push. If atomic push is negotiated with the server
+   then any push covering multiple refs will be atomic. Either all
+   refs are updated, or on error, no refs are updated. If the server
+   does not support atomic pushes the push will fail.
+
 --receive-pack=::
 --exec=::
Path to the 'git-receive-pack' program on the remote
diff --git a/builtin/push.c b/builtin/push.c
index a076b19..ae393c5 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -518,6 +518,8 @@ int cmd_push(int argc, const char **argv, const char 
*prefix)
OPT_BIT(0, "follow-tags", &flags, N_("push missing but relevant 
tags"),
TRANSPORT_PUSH_FOLLOW_TAGS),
OPT_BIT(0, "signed", &flags, N_("GPG sign the push"), 
TRANSPORT_PUSH_CERT),
+   OPT_BIT(0, "atomic-push", &flags, N_("use atomic push, if 
available"),
+   TRANSPORT_ATOMIC_PUSH),
OPT_END()
};
 
diff --git a/transport.c b/transport.c
index e87481d..ba1499e 100644
--- a/transport.c
+++ b/transport.c
@@ -830,6 +830,7 @@ static int git_transport_push(struct transport *transport, 
struct ref *remote_re
args.dry_run = !!(flags & TRANSPORT_PUSH_DRY_RUN);
args.porcelain = !!(flags & TRANSPORT_PUSH_PORCELAIN);
args.push_cert = !!(flags & TRANSPORT_PUSH_CERT);
+   args.use_atomic_push = !!(flags & TRANSPORT_ATOMIC_PUSH);
args.url = transport->url;
 
ret = send_pack(&args, data->fd, data->conn, remote_refs,
diff --git a/transport.h b/transport.h
index 3e0091e..25fa1da 100644
--- a/transport.h
+++ b/transport.h
@@ -125,6 +125,7 @@ struct transport {
 #define TRANSPORT_PUSH_NO_HOOK 512
 #define TRANSPORT_PUSH_FOLLOW_TAGS 1024
 #define TRANSPORT_PUSH_CERT 2048
+#define TRANSPORT_ATOMIC_PUSH 4096
 
 #define TRANSPORT_SUMMARY_WIDTH (2 * DEFAULT_ABBREV + 3)
 #define TRANSPORT_SUMMARY(x) (int)(TRANSPORT_SUMMARY_WIDTH + strlen(x) - 
gettext_width(x)), (x)
-- 
2.2.0.33.gc2219e3.dirty

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

remote helper example with push/fetch capabilities

[Klein W]

Is there any example of a remote helper [0] with push and fetch capabilities?

The git-remote-testgit.sh example [1] only has import/export capabilities.

Also, what are the advantages and disadvantages of a remote helper
with push/fetch capabilities vs a remote helper with import/export
capabilities?

Thanks.

[0] https://www.kernel.org/pub/software/scm/git/docs/git-remote-helpers.html
[1] https://github.com/git/git/blob/master/git-remote-testgit.sh
--
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

What's cooking in git.git (Dec 2014, #03; Mon, 15)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

The 'next' branch has been rewound and rebuilt on top of 2.2; I
expect this to be a short and light cycle that would not add too
many new things.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[Graduated to "master"]

* da/difftool-mergetool-simplify-reporting-status (2014-11-21) 5 commits
  (merged to 'next' on 2014-12-04 at c3c329f)
 + mergetools: stop setting $status in merge_cmd()
 + mergetool: simplify conditionals
 + difftool--helper: add explicit exit statement
 + mergetool--lib: remove use of $status global
 + mergetool--lib: remove no-op assignment to $status from setup_user_tool

 Code simplification.


* jc/unpack-trees-plug-leak (2014-11-17) 1 commit
  (merged to 'next' on 2014-12-04 at 9f1df30)
 + unpack_trees: plug leakage of o->result


* jk/colors-fix (2014-11-20) 3 commits
  (merged to 'next' on 2014-12-04 at 0d97d69)
 + t4026: test "normal" color
 + config: fix parsing of "git config --get-color some.key -1"
 + docs: describe ANSI 256-color mode
 (this branch is used by jk/colors.)


* jk/no-perl-tests (2014-11-18) 2 commits
  (merged to 'next' on 2014-12-04 at f166620)
 + t960[34]: mark cvsimport tests as requiring perl
 + t0090: mark add-interactive test with PERL prerequisite

 Some tests that depend on perl lacked PERL prerequisite to protect
 them, breaking build with NO_PERL configuration.


* jk/pack-bitmap (2014-11-30) 1 commit
  (merged to 'next' on 2014-12-04 at eb457ad)
 + pack-bitmap: do not use gcc packed attribute


* jk/push-simple (2014-11-30) 1 commit
  (merged to 'next' on 2014-12-04 at 00785c7)
 + push: truly use "simple" as default, not "upstream"

 Git 2.0 was supposed to make the "simple" mode for the default of
 "git push", but it didn't.


* jk/rebuild-perl-scripts-with-no-perl-seting-change (2014-11-18) 3 commits
  (merged to 'next' on 2014-12-04 at 27382d3)
 + Makefile: have python scripts depend on NO_PYTHON setting
 + Makefile: simplify by using SCRIPT_{PERL,SH}_GEN macros
 + Makefile: have perl scripts depend on NO_PERL setting

 The build procedure did not bother fixing perl and python scripts
 when NO_PERL and NO_PYTHON build-time configuration changed.


* mh/config-copy-string-from-git-path (2014-11-17) 1 commit
  (merged to 'next' on 2014-12-04 at 9c9518b)
 + cmd_config(): make a copy of path obtained from git_path()


* po/everyday-doc (2014-11-17) 1 commit
  (merged to 'next' on 2014-12-04 at 39d31fb)
 + Documentation: change "gitlink" typo in git-push


* rt/push-recurse-submodule-usage-string (2014-11-18) 1 commit
  (merged to 'next' on 2014-12-04 at c43e23c)
 + builtin/push.c: fix description of --recurse-submodules option


* sv/typofix-apply-error-message (2014-11-17) 1 commit
  (merged to 'next' on 2014-12-04 at de7547a)
 + apply: fix typo in an error message

--
[New Topics]

* jk/test-asan (2014-12-11) 1 commit
  (merged to 'next' on 2014-12-15 at d24cb92)
 + t: support clang/gcc AddressSanitizer

 Will merge to 'master'.


* nd/split-index (2014-12-11) 1 commit
  (merged to 'next' on 2014-12-15 at ed6490c)
 + index-format.txt: add a missing closing quote

 A typofix to the documentation of a feature already in the release.

 Will merge to 'master'.


* ch/new-gpg-drops-rfc-1991 (2014-12-12) 4 commits
  (merged to 'next' on 2014-12-15 at 32d7d50)
 + tests: squelch noise from GPG machinery set-up
 + tests: replace binary GPG keyrings with ASCII-armored keys
 + tests: skip RFC1991 tests for gnupg 2.1
 + tests: create gpg homedir on the fly

 Recent GPG changes the keyring format and drops support for RFC1991
 formatted signatures, breaking our existing tests.

 Will merge to 'master'.


* jg/prompt-localize-temporary (2014-12-12) 1 commit
  (merged to 'next' on 2014-12-15 at bb9cac9)
 + git-prompt.sh: make $f local to __git_eread()

 "git-prompt" (in contrib/) used a variable from the global scope,
 possibly contaminating end-user's namespace.

 Will merge to 'master'.


* jk/strbuf-doc-to-header (2014-12-12) 4 commits
 - strbuf.h: reorganize api function grouping headers
 - strbuf.h: format asciidoc code blocks as 4-space indent
 - strbuf.h: drop asciidoc list formatting from API docs
 - strbuf: migrate api-strbuf.txt documentation to strbuf.h

 Resolve the "doc vs header" to favor the latter.

 Expecting to be rerolled.


* mh/reflog-expire (2014-12-12) 24 commits
 - refs.c: let fprintf handle the formatting
 - refs.c: don't expose the internal struct ref_lock in the header file
 - lock_any_ref_for_update(): inline function
 - refs.c: remove unlock_ref/close_ref/commit_ref from the refs api
 - reflog_expire(): new function in the reference API
 - expire_reflog(): treat the policy

Re: remote helper example with push/fetch capabilities

[Jonathan Nieder]

Hi,

Klein W wrote:

> Is there any example of a remote helper [0] with push and fetch capabilities?

Sure --- see remote-curl.c.

There's also the "connect" capability.  builtin/remote-ext.c and
builtin/remote-fd.c are examples using that one.

[...]
> Also, what are the advantages and disadvantages of a remote helper
> with push/fetch capabilities vs a remote helper with import/export
> capabilities?

It mainly has to do with what it is convenient for your helper to
produce.  If the helper would find it more convenient to write native
git objects (for example because the remote server speaks a
git-specific protocol, as in the case of remote-curl.c) then the
"fetch" capability will be more convenient.  If the helper wants to
make a batch of new objects then a fast-import stream can be a
convenient way to do this and the "import" capability takes care of
running fast-import to take care of that.

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 1/5] receive-pack.c: add protocol support to negotiate atomic-push

[Junio C Hamano]

Stefan Beller  writes:

> From: Ronnie Sahlberg 
>
> This adds support to the protocol between send-pack and receive-pack to
> * allow receive-pack to inform the client that it has atomic push capability
> * allow send-pack to request atomic push back.
>
> There is currently no setting in send-pack to actually request that atomic
> pushes are to be used yet. This only adds protocol capability not ability
> for the user to activate it.

Hmph, am I reading the patch to send-pack.c correctly?

It detects if the other side supports the capability and leaves it
in atomic_push_supported variable for later use, and also requests
the feature to be activated when atomic_push is set, but I see no
logic to link these two together, e.g. error out when atomic_push
is true and atomic_push_supported is false (or turn it off with a
warning, or whatever).

> diff --git a/send-pack.c b/send-pack.c
> index 949cb61..1ccc84c 100644
> --- a/send-pack.c
> +++ b/send-pack.c
> @@ -294,6 +294,8 @@ int send_pack(struct send_pack_args *args,
>   int use_sideband = 0;
>   int quiet_supported = 0;
>   int agent_supported = 0;
> + int atomic_push_supported = 0;
> + int atomic_push = 0;
>   unsigned cmds_sent = 0;
>   int ret;
>   struct async demux;
> @@ -314,6 +316,8 @@ int send_pack(struct send_pack_args *args,
>   agent_supported = 1;
>   if (server_supports("no-thin"))
>   args->use_thin_pack = 0;
> + if (server_supports("atomic-push"))
> + atomic_push_supported = 1;
>   if (args->push_cert) {
>   int len;
>  
> @@ -335,6 +339,8 @@ int send_pack(struct send_pack_args *args,
>   strbuf_addstr(&cap_buf, " side-band-64k");
>   if (quiet_supported && (args->quiet || !args->progress))
>   strbuf_addstr(&cap_buf, " quiet");
> + if (atomic_push)
> + strbuf_addstr(&cap_buf, " atomic-push");
>   if (agent_supported)
>   strbuf_addf(&cap_buf, " agent=%s", git_user_agent_sanitized());
--
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/5] send-pack.c: add an --atomic-push command line argument

[Junio C Hamano]

Stefan Beller  writes:

> -static int ref_update_to_be_sent(const struct ref *ref, const struct 
> send_pack_args *args)
> +static int ref_update_to_be_sent(const struct ref *ref, const struct 
> send_pack_args *args, int *atomic_push_failed)

Hmph.  Is "atomic push" so special that it deserves a separate
parameter?  When we come up with yet another mode of failure, would
we add another parameter to the callers to this function?

> @@ -203,6 +203,12 @@ static int ref_update_to_be_sent(const struct ref *ref, 
> const struct send_pack_a
>   case REF_STATUS_REJECT_NEEDS_FORCE:
>   case REF_STATUS_REJECT_STALE:
>   case REF_STATUS_REJECT_NODELETE:
> + if (atomic_push_failed) {
> + fprintf(stderr, "Atomic push failed for ref %s. "
> + "Status:%d\n", ref->name, ref->status);
> + *atomic_push_failed = 1;

All other error message that come from the codepaths around here
seem to avoid uppercase.  Also maybe you want to use error() here?

> + if (args->use_atomic_push && !atomic_push_supported) {
> + fprintf(stderr, "Server does not support atomic-push.");
> + return -1;
> + }

This check logically belongs to the previous step, no?

> + atomic_push = atomic_push_supported && args->use_atomic_push;

>  
>   if (status_report)
>   strbuf_addstr(&cap_buf, " report-status");
> @@ -365,7 +376,8 @@ int send_pack(struct send_pack_args *args,
>* the pack data.
>*/
>   for (ref = remote_refs; ref; ref = ref->next) {
> - if (!ref_update_to_be_sent(ref, args))
> + if (!ref_update_to_be_sent(ref, args,
> + args->use_atomic_push ? &atomic_push_failed : NULL))
>   continue;
>  
>   if (!ref->deletion)
> @@ -377,6 +389,23 @@ int send_pack(struct send_pack_args *args,
>   ref->status = REF_STATUS_EXPECTING_REPORT;
>   }
>  
> + if (atomic_push_failed) {
> + for (ref = remote_refs; ref; ref = ref->next) {
> + if (!ref->peer_ref && !args->send_mirror)
> + continue;
> +
> + switch (ref->status) {
> + case REF_STATUS_EXPECTING_REPORT:
> + ref->status = REF_STATUS_ATOMIC_PUSH_FAILED;
> + continue;
> + default:
> + ; /* do nothing */
> + }
> + }
> + fprintf(stderr, "Atomic push failed.");
> + return -1;

The same comment as the other fprintf() applies here.

> @@ -728,6 +728,10 @@ static int print_one_push_status(struct ref *ref, const 
> char *dest, int count, i
>ref->deletion ? NULL : 
> ref->peer_ref,
>"remote failed to report 
> status", porcelain);
>   break;
> + case REF_STATUS_ATOMIC_PUSH_FAILED:
> + print_ref_status('!', "[rejected]", ref, ref->peer_ref,
> +  "atomic-push-failed", 
> porcelain);

Why dashed-words-here?

> + break;
>   case REF_STATUS_OK:
>   print_ok_ref_status(ref, porcelain);
>   break;
--
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 3/5] receive-pack.c: use a single ref_transaction for atomic pushes

[Junio C Hamano]

Stefan Beller  writes:

> @@ -832,34 +834,56 @@ static const char *update(struct command *cmd, struct 
> shallow_info *si)
>   cmd->did_not_exist = 1;
>   }
>   }
> - if (delete_ref(namespaced_name, old_sha1, 0)) {
> - rp_error("failed to delete %s", name);
> - return "failed to delete";
> + if (!use_atomic_push) {
> + if (delete_ref(namespaced_name, old_sha1, 0)) {
> + rp_error("failed to delete %s", name);
> + return "failed to delete";
> + }
> + } else {
> + if (ref_transaction_delete(transaction,
> +namespaced_name,
> +old_sha1,
> +0, old_sha1 != NULL,
> +"push", &err)) {
> + rp_error("%s", err.buf);
> + strbuf_release(&err);
> + return "failed to delete";
> + }

Doesn't the asymmetry between the above (if transaction is there,
use it, otherwise call delete_ref() which conceptually has its sole
operation inside a single transaction by itself) and below (if
transaction is not there, create it and do its thing, and close the
transaction if we created it) bother you?

The above look much simpler, and if it does not switch on
use_atomic_push but on the presense of transaction, it would have
been even better, i.e.

if (transaction
? ref_transaction_delete(transaction, ...)
: delete_ref(...)) {
error(...);
return "failed to delete";
}

I think it makes the code harder to read and maintain if you forced
a caller of the ref API that happen to touch only a single ref to
make three calls to

ref_transaction_begin();
ref_transaction_do_one_thing();
ref_transaction_commit();

instead of making a single call to a simple wrapper

ref_do_one_thing();

I think that I saw Michael make a similar observation in a near-by
thread.

Even if you insist using transactions explicitly in the user of the
ref API, I think a better code organization is possible in this
particular codepath.  Because execute_commands() has the loop over
all the proposed updates, why should the update() even need to know
how to open a new transaction and when?  In other words, can't the
code be more like this?

static update(transaction, ...)
{
/* do my thing in the transaction given to me */
compute what kind of update is needed;
switch (kind) {
case delete:
ref_transaction_delete(transaction, ...);
break;
case update:
ref_transaction_update(transaction, ...);
break;
...
}
}

execute_commands(...)
{
if (atomic)
transaction = ref_transaction_begin(...);
for (cmd = commands; cmd; cmd = cmd->next) {
if (!atomic)
transaction = ref_transaction_begin(...);
update(transaction, ...);
if (!atomic)
ref_transaction_commit(transaction);
}
if (atomic)
ref_transaction_commit(transaction);
}

That is, update() assumes it is always in _some_ transaction, and
execute_commands(), which is what drives multi-ref updates, knows
if it wants its repeated calls to update() to be in a single
transaction or separate transactions.
--
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: remote helper example with push/fetch capabilities

[Klein W]

On Mon, Dec 15, 2014 at 3:47 PM, Jonathan Nieder  wrote:
> Sure --- see remote-curl.c.
>
> There's also the "connect" capability.  builtin/remote-ext.c and
> builtin/remote-fd.c are examples using that one.

Thanks.

>> Also, what are the advantages and disadvantages of a remote helper
>> with push/fetch capabilities vs a remote helper with import/export
>> capabilities?
>
> It mainly has to do with what it is convenient for your helper to
> produce.  If the helper would find it more convenient to write native
> git objects (for example because the remote server speaks a
> git-specific protocol, as in the case of remote-curl.c) then the
> "fetch" capability will be more convenient.  If the helper wants to
> make a batch of new objects then a fast-import stream can be a
> convenient way to do this and the "import" capability takes care of
> running fast-import to take care of that.

I'm trying to write a remote helper for hosting git remotes on Amazon
S3.  Do you have any intuition about which capabilities would work
best for this case?

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: remote helper example with push/fetch capabilities

[Jonathan Nieder]

Klein W wrote:
> On Mon, Dec 15, 2014 at 3:47 PM, Jonathan Nieder  wrote:

>> It mainly has to do with what it is convenient for your helper to
>> produce.  If the helper would find it more convenient to write native
>> git objects (for example because the remote server speaks a
>> git-specific protocol, as in the case of remote-curl.c) then the
>> "fetch" capability will be more convenient.  If the helper wants to
>> make a batch of new objects then a fast-import stream can be a
>> convenient way to do this and the "import" capability takes care of
>> running fast-import to take care of that.
>
> I'm trying to write a remote helper for hosting git remotes on Amazon
> S3.  Do you have any intuition about which capabilities would work
> best for this case?

fetch/push.  I'd suggest looking at the "dumb" HTTP code (fetch_dumb,
push_dav) in remote-curl.c to start.

Thanks,
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: remote helper example with push/fetch capabilities

[Junio C Hamano]

Klein W  writes:

> Is there any example of a remote helper [0] with push and fetch capabilities?
>
> The git-remote-testgit.sh example [1] only has import/export capabilities.
>
> Also, what are the advantages and disadvantages of a remote helper
> with push/fetch capabilities vs a remote helper with import/export
> capabilities?

A helper with push/fetch capabilities is responsible for (and more
importantly, "in control of") packdata creation, while helpers that
use import/export interface rely on fast-import, which is quite dumb
when it comes to storage efficiency of the resulting repository.
The former might be more preferrable from the efficiency point of
view.

BUT.

Unless your foreign SCM is Git itself, however, it is not practical
to write your own pack data generator correctly and efficiently to
support push/fetch capabilities anyway, so the choice is often made
not because of "advantages vs disadvantages" but because of what you
can write in practice.

--
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 4/5] push.c: add an --atomic-push argument

[Junio C Hamano]

Stefan Beller  writes:

> From: Ronnie Sahlberg 
>
> Add a command line argument to the git push command to request atomic
> pushes.
>
> Signed-off-by: Ronnie Sahlberg 
> Signed-off-by: Stefan Beller 
> ---

Makes sense, modulo a nit.

> +--atomic-push::
> + Using atomic push. If atomic push is negotiated with the server
> + then any push covering multiple refs will be atomic. Either all
> + refs are updated, or on error, no refs are updated. If the server
> + does not support atomic pushes the push will fail.

"git push --atomic-push"?  Why should one need to repeat the word?

>   OPT_BIT(0, "signed", &flags, N_("GPG sign the push"), 
> TRANSPORT_PUSH_CERT),
> + OPT_BIT(0, "atomic-push", &flags, N_("use atomic push, if 
> available"),
> + TRANSPORT_ATOMIC_PUSH),

Contrast between the two.  It isn't "git push --signed-push", either ;-)
--
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 5/5] t5543-atomic-push.sh: add basic tests for atomic pushes

[Junio C Hamano]

Stefan Beller  writes:

> This adds tests for the atomic push option.
> The first four tests check if the atomic option works in
> good conditions and the last three patches check if the atomic
> option prevents any change to be pushed if just one ref cannot
> be updated.
>
> Signed-off-by: Stefan Beller 
> ---
>
> Notes:
> Originally Ronnie had a similar patch prepared. But as I added
> more tests and cleaned up the existing tests (e.g. use test_commit
> instead of "echo one >file && gitadd file && git commit -a -m 'one'",
> removal of dead code), the file has changed so much that I'd rather
> take ownership.
>
>  t/t5543-atomic-push.sh | 185 
> +
>  1 file changed, 185 insertions(+)
>  create mode 100755 t/t5543-atomic-push.sh
>
> diff --git a/t/t5543-atomic-push.sh b/t/t5543-atomic-push.sh
> new file mode 100755
> index 000..6cbedc5
> --- /dev/null
> +++ b/t/t5543-atomic-push.sh
> @@ -0,0 +1,185 @@
> +#!/bin/sh
> +
> +test_description='pushing to a repository using the atomic push option'
> +
> +. ./test-lib.sh
> +
> +D=`pwd`

$(pwd)???

> +mk_repo_pair () {
> + rm -rf workbench upstream thirdparty &&
> + mkdir upstream &&
> + (
> + cd upstream &&
> + git init --bare #&&
> + #git config receive.denyCurrentBranch warn

Please drop unused comments; they are distracting.

> + ) &&
> + mkdir workbench &&
> + (
> + cd workbench &&
> + git init &&
> + git remote add up ../upstream
> + )
> +}

Hmph.  Shouldn't you be using test_create_repo to create these, so
that templates are used from the build (not install) location, and
their hooks are disabled?

> +test_push_failed () {

Does that mean "test_push_must_fail"?

> + workbench_master=$(cd workbench && git show-ref -s --verify 
> refs/heads/master) &&
> + upstream_master=$(cd upstream && git show-ref -s --verify 
> refs/heads/master) &&
> + test "$workbench_master" != "$upstream_master" &&
> +
> + workbench_second=$(cd workbench && git show-ref -s --verify 
> refs/heads/second) &&
> + upstream_second=$(cd upstream && git show-ref -s --verify 
> refs/heads/second) &&
> + test "$workbench_second" != "$upstream_second"

So the tests that use this helper always try to update master and
second?  Is "they are different" the only thing that matters?  Or
should you be verifying "They are left as the same value they used
to have before the attempted push that must have failed"?

It might be a good time to use "-C" option, e.g. "git -C workbench show-ref 
...",
a bit more in our tests.

> +}
> +
> +test_push_succeeded () {
> + workbench_master=$(cd workbench && git show-ref -s --verify 
> refs/heads/master) &&
> + upstream_master=$(cd upstream && git show-ref -s --verify 
> refs/heads/master) &&
> + test "$workbench_master" = "$upstream_master"

Broken &&-chain?

> +
> + workbench_second=$(cd workbench && git show-ref -s --verify 
> refs/heads/second) &&
> + upstream_second=$(cd upstream && git show-ref -s --verify 
> refs/heads/second) &&
> + test "$workbench_second" = "$upstream_second"
> +}
> +
> +test_expect_success 'atomic push works for a single branch' '
> + mk_repo_pair &&
> + (
> + cd workbench &&
> + test_commit one &&
> + git push --mirror up &&
> + test_commit two &&
> + git push --atomic-push --mirror up
> + ) &&
> + workbench_master=$(cd workbench && git show-ref -s --verify 
> refs/heads/master) &&
> + upstream_master=$(cd upstream && git show-ref -s --verify 
> refs/heads/master) &&
> + test "$workbench_master" = "$upstream_master"

Hmph.  It is a shame that the nice helper you created cannot be used
here.

> +'
> +
> +test_expect_success 'atomic push works for two branches' '
> + mk_repo_pair &&
> + (
> + cd workbench &&
> + test_commit one &&
> + git branch second &&
> + git push --mirror up &&
> + test_commit two &&
> + git checkout second &&
> + test_commit three &&
> + git push --atomic-push --mirror up
> + ) &&
> + test_push_succeeded
> +'

OK.

> +test_expect_success 'atomic push works in combination with --mirror' '
> + mk_repo_pair &&
> + ls workbench &&

Debugging?

> + (
> + cd workbench &&
> + test_commit one &&
> + git checkout -b second &&
> + test_commit two &&
> + git push --atomic-push --mirror up

It is not wrong per-se, but haven't you already tested in
combination with --mirror in the previous test?

> + ) &&
> + test_push_succeeded
> +'
> +
> +test_expect_success 'atomic push works in combination with --force' '
> + mk_repo_pair &&
> + (
> + cd workbench &&
> + test_commit one &&
> + git checkout -b sec

Re: [PATCH 1/5] receive-pack.c: add protocol support to negotiate atomic-push

[Stefan Beller]

On Mon, Dec 15, 2014 at 12:53 PM, Junio C Hamano  wrote:
> Hmph, am I reading the patch to send-pack.c correctly?
>
> It detects if the other side supports the capability and leaves it
> in atomic_push_supported variable for later use, and also requests
> the feature to be activated when atomic_push is set, but I see no
> logic to link these two together, e.g. error out when atomic_push
> is true and atomic_push_supported is false (or turn it off with a
> warning, or whatever).


This is what you mean by

>
>> + if (args->use_atomic_push && !atomic_push_supported) {
>> + fprintf(stderr, "Server does not support atomic-push.");
>> + return -1;
>> + }
>
> This check logically belongs to the previous step, no?

from the next patch? If so it will be part of the next reroll.

Thanks,
Stefan
--
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 0/5] Add a flag to push atomically

[Junio C Hamano]

Stefan Beller  writes:

> This patch series adds a flag to git push to update the remote refs 
> atomically.
>
> It was part of a longer patch series[1].
> This series applies on top of origin/mh/reflog-expire
> It can also be found at [2].
>
> Change since picking the series up from Ronnie.
>   * other anchor point (i.e. where the series applies)
>   * more tests for this feature, specially testing failures
>   * drop the patch to rename ref_transaction_* to transaction_*_ref
>   * slight rewording of the additional documentation
>
> [1] http://www.spinics.net/lists/git/msg241214.html
> [2] https://github.com/stefanbeller/git/tree/atomic-push-v1
>
> Ronnie Sahlberg (4):
>   receive-pack.c: add protocol support to negotiate atomic-push
>   send-pack.c: add an --atomic-push command line argument
>   receive-pack.c: use a single transaction when atomic-push is
> negotiated
>   push.c: add an --atomic-push argument
>
> Stefan Beller (1):
>   t5543-atomic-push.sh: add basic tests for atomic pushes

Thanks.  I think I like where it is going.
--
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: remote helper example with push/fetch capabilities

[Klein W]

On Mon, Dec 15, 2014 at 4:44 PM, Jonathan Nieder  wrote:
>> I'm trying to write a remote helper for hosting git remotes on Amazon
>> S3.  Do you have any intuition about which capabilities would work
>> best for this case?
>
> fetch/push.  I'd suggest looking at the "dumb" HTTP code (fetch_dumb,
> push_dav) in remote-curl.c to start.

This seems like a good starting point, but are there any simpler
examples that are not clouded by WebDAV/Curl stuff?  Perhaps a remote
helper that reads/writes to the filesystem directly?
--
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] add--interactive: leave main loop on read error

[Junio C Hamano]

Jeff King  writes:

> On Mon, Dec 15, 2014 at 03:41:45PM +0100, Benjamin Quorning wrote:
>
>> Reproduction steps:
>> 
>> 1. A repository with a changed file, but no staged changes.
>> 2. Execute `git checkout --patch`
>> 3. When asked, press `e` to edit a chunk (opens an external editor in my 
>> case)
>> 4. With the editor still open, click ctrl-C in the terminal.
>> 5. The diff that was being edited, and the command prompt ("discard
>> this hunk from worktree" etc) is printed to the screen, over and over
>> again.
>> 6. I have to grep and kill this process: /usr/bin/perl
>> /usr/local/Cellar/git/2.2.0/libexec/git-core/git-add--interactive
>> --patch=checkout --
>
> Thanks, I could reproduce this pretty easily with:
>
>   GIT_EDITOR='f() { sleep 60; }; f' git checkout -p
>
> (and then hit 'e', and ^C). Explanation and fix are below.
>
> -- >8 --
> The main hunk loop for add--interactive will loop if it does
> not get a known input. This is a good thing if the user
> typed some invalid input. However, if we have an
> uncorrectable read error, we'll end up looping infinitely.
> We can fix this by noticing read errors (i.e., 
> returns undef) and breaking out of the loop.
>
> One easy way to trigger this is if you have an editor that
> does not take over the terminal (e.g., one that spawns a
> window in an existing process and waits), start the editor
> with the hunk-edit command, and hit ^C to send SIGINT. The
> editor process dies due to SIGINT, but the perl
> add--interactive process does not (perl suspends SIGINT for
> the duration of our system() call).
>
> We return to the main loop, but further reads from stdin
> don't work. The SIGINT _also_ killed our parent git process,
> which orphans our process group, meaning that further reads
> from the terminal will always fail. We loop infinitely,
> getting EIO on each read.
>
> Note that there are several other spots where we read from
> stdin, too. However, in each of those cases, we do something
> sane when the read returns undef (breaking out of the loop,
> taking the input as "no", etc). They don't need similar
> treatment.
>
> Signed-off-by: Jeff King 
> ---

Thanks.

>  git-add--interactive.perl | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index 1fadd69..c725674 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -1356,6 +1356,7 @@ sub patch_update_file {
> $patch_mode_flavour{TARGET},
> " [y,n,q,a,d,/$other,?]? ";
>   my $line = prompt_single_character;
> + last unless defined $line;
>   if ($line) {
>   if ($line =~ /^y/i) {
>   $hunk[$ix]{USE} = 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 v2 1/2] send-email: align RFC 2047 decoding more closely with the spec

[Junio C Hamano]

Thanks; queued both patches.
--
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

限量$799享受快感，不知不覺就瘦了uzwltcr51tfm

[kesiojhajhwe tdgda]

婁千榮uzwltcr51tfm



「體重老是減不下來」
「總是中途就放棄了」這樣的人，
說不定是因為意識胖子化的原因！
這麼一來， 不管怎麼減都只是浪費時間而已……。
在此要來介紹讓你改變肥胖體質，
百萬人使用成功的方法
http://bit.ly/1vO7tjS










tsunj婁千榮
--
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: Kedves: Webmail Elofizeto

[Maria Kovalska]

 



From: Maria Kovalska
Sent: Tue 12/16/2014 2:01
Subject: Kedves: Webmail Elofizeto


Kedves: Webmail Elofizeto

Felhívjuk figyelmét, hogy az e-mail fiók meghaladta
tárolókapacitás. Ön nem tud küldeni és fogadni e-maileket és a
e-mail fiókja törlésre kerül a szerverünkrol. A probléma elkerülése
érdekében,
   Kattintson ide
   frissítse a számla.


Köszönöm.

Management Team. 
--
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] remote: allow adding remote w same name as alias

[Anastas Dancha]

>From f80bdf3272e7bdf790ee67fb94196a8aa139331f Mon Sep 17 00:00:00 2001
From: Anastas Dancha 
Date: Mon, 15 Dec 2014 16:30:50 -0500
Subject: [PATCH] remote: allow adding remote w same name as alias

When ~/.gitconfig contains an alias (i.e. myremote)
and you are adding a new remote using the same name
for remote, Git will refuse to add the remote with
the same name as one of the aliases, even though the
remote with such name is not setup for current repo.

$ git remote add myremote g...@host.com:team/repo.git
fatal: remote myremote already exists.

The fatal error comes from strcmp(name, remote->url[0])
condition, which compares a name of the new remote with
existing urls of all the remotes, including the ones
from ~/.gitconfig (or global variant).
I'm not sure why that is necessary, unless Git is meant
to prevent users from naming their remotes as their
remote aliases..
Imho, if someone want's to git remote add myremote
myremote, they should, since git-remote always takes
2 arguments, first being the new remote's name and
second being new remote's url (or alias, if set).
Thanks to @mymuss for sanity check and debugging.

Signed-off-by: Anastas Dancha 
---
 builtin/remote.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/builtin/remote.c b/builtin/remote.c
index 7f28f92..7471d0a 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -180,9 +180,8 @@ static int add(int argc, const char **argv)
url = argv[1];
 
remote = remote_get(name);
-   if (remote && (remote->url_nr > 1 || strcmp(name, remote->url[0]) ||
-   remote->fetch_refspec_nr))
-   die(_("remote %s already exists."), name);
+   if (remote && (remote->url_nr > 1 || remote->fetch_refspec_nr))
+   die(_("remote %s %s already exists."), name, url);
 
strbuf_addf(&buf2, "refs/heads/test:refs/remotes/%s/test", name);
if (!valid_fetch_refspec(buf2.buf))
-- 
2.2.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

[PATCH] t5400: remove dead code

[Stefan Beller]

Signed-off-by: Stefan Beller 
---

Notes:
When debugging the atomic push series I wondered if we want to have
tests for the atomic push as well as for atomic send-pack.
So I looked at the t5400 test if I could easily add tests for send-pack.
I don't think I will add tests in here, but I found dead code.
Also I am rambling about the other series this patch is totally unrelated.

Removing dead code is always a joy!

Thanks,
Stefan

 t/t5400-send-pack.sh | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 0736bcb..04cea97 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -76,8 +76,7 @@ test_expect_success 'refuse pushing rewound head without 
--force' '
test "$victim_head" = "$pushed_head"
 '
 
-test_expect_success \
-'push can be used to delete a ref' '
+test_expect_success 'push can be used to delete a ref' '
( cd victim && git branch extra master ) &&
git send-pack ./victim :extra master &&
( cd victim &&
@@ -196,19 +195,6 @@ rewound_push_setup() {
)
 }
 
-rewound_push_succeeded() {
-   cmp ../parent/.git/refs/heads/master .git/refs/heads/master
-}
-
-rewound_push_failed() {
-   if rewound_push_succeeded
-   then
-   false
-   else
-   true
-   fi
-}
-
 test_expect_success 'pushing explicit refspecs respects forcing' '
rewound_push_setup &&
parent_orig=$(cd parent && git rev-parse --verify master) &&
-- 
2.2.0.31.gad78000.dirty

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