The remote-fd expects the transport to pass half-closes. So you can't
close all at once.
Let there be pipes W and R and transport connection C.
- W-read should be closed after being passed to remote-fd.
- R-write should be closed after being passed to remote-fd.
- Upon receiving no more
On Sun, Dec 28, 2014 at 11:36 PM, Randy J. Ray rj...@blackperl.com wrote:
I use git on MacOS via homebrew (http://brew.sh/), and a custom Perl
installation built and managed via perlbrew (http://perlbrew.pl/). At some
point, commands like git add -i broke. I say at some point, because I'm
not
On 2014-12-28 23.36, Randy J. Ray wrote:
I use git on MacOS via homebrew (http://brew.sh/), and a custom Perl
installation built and managed via perlbrew (http://perlbrew.pl/). At some
point, commands like git add -i broke. I say at some point, because I'm
not a git power-user and I only
Eric Sunshine sunsh...@sunshineco.com writes:
+ (git am --abort || true)
Why (x || y)? Is 'x' so unreliable that we do not know how should exit?
Should this be test_must_fail git am --abort?
+ (cd submodule git rev-parse HEAD ../actual)
git -C submodule rev-parse HEAD actual
Eric Sunshine sunsh...@sunshineco.com writes:
Just a few comments and observations below. Alone, they are not
necessarily worth a re-roll, but if you happen to re-roll for some
other reason, perhaps take them into consideration.
I actually think everything you said in this review makes sense
Sitaram Chamarty sitar...@gmail.com writes:
Any chance I could persuade you to set the GIT_PUSH_CERT* environment
variables for the update (and post-update) hooks also?
I do not think of a fundamental reason why we shouldn't give these
environment variables to update or other hooks. It should
On Mon, Dec 22, 2014 at 9:55 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
This adds an explanation of why you want to have the --notes option
given to git format-patch.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
with optionally
René Scharfe l@web.de writes:
Signed-off-by: Rene Scharfe l@web.de
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 5fcacc6..ed3b2cb 100644
--- a/refs.c
+++ b/refs.c
@@ -2334,7 +2334,7 @@ static struct ref_lock
This adds more explanation of why you want to have the --notes option
given to git format-patch.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
Changes v2:
* s/you are encouraged to/you may want to/
* a stronger hint to use the git notes and then
--notes for
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
git-send-email.perl | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 82c6fea..60dcd8d 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1275,10
Christoph Junghans ott...@gentoo.org writes:
Ok, I drafted a first version of the suggest --grep-begin ...
--grep-end syntax.
I am somewhat surprised that it was doable that cleanly.
The syntax, as I already said, is a bit too ugly to live in that
form I suggested, though ;-).
However, I
On Thu, Dec 25, 2014 at 11:17 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 12/19/2014 08:39 PM, Stefan Beller wrote:
Add a command line argument to the git push command to request atomic
pushes.
[...]
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index
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
Alexander Kuleshov kuleshovm...@gmail.com writes:
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
git-send-email.perl | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 82c6fea..60dcd8d 100755
---
Eric Sunshine sunsh...@sunshineco.com writes:
Fix this by taking advantage of write_name_quoted_relative() to recover
the original name properly, rather than assuming that it can be
recovered by skipping strlen(prefix) bytes.
Nice; I was wondering if we already had that helper when I saw the
Christian Couder chrisc...@tuxfamily.org writes:
When running for example git bisect bad HEAD or
git bisect good master, the parameter passed to
git bisect (bad|good) has to be parsed into a
commit hash before checking if it is the expected
commit or not.
Hmm, is that because you wrote
On Mon, Dec 29, 2014 at 10:47:58AM +0100, Jiri Sevcik wrote:
The remote-fd expects the transport to pass half-closes. So you can't
close all at once.
Let there be pipes W and R and transport connection C.
- W-read should be closed after being passed to remote-fd.
- R-write should be
Michael Haggerty mhag...@alum.mit.edu writes:
I'd like to discuss the big picture around this feature. I don't think
that any of these questions are blockers, with the possible exception of
the question of whether --atomic should fall back to non-atomic if the
server doesn't support atomic
On 12/29/14, 7:21 AM, Ævar Arnfjörð Bjarmason wrote:
[CC'd the perlbrew author]
This is a bit of a tricky issue.
Using whatever perl is defined in the environment is just as likely to
break, in general the build process tries to pick these assets at
compile-time. Imagine you're experimenting
On Mon, Dec 29, 2014 at 09:37:43AM -0800, Junio C Hamano wrote:
René Scharfe l@web.de writes:
Signed-off-by: Rene Scharfe l@web.de
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 5fcacc6..ed3b2cb 100644
--- a/refs.c
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
It has been understandably somewhat a slow week, and this will be
the last issue of What's cooking report for this year. See you
all in the
This renames ref_update_to_be_sent to check_to_send_update and inverts
the meaning of the return value. Having the return value inverted we
can have different values for the error codes. This is useful in a
later patch when we want to know if we hit the CHECK_REF_STATUS_REJECTED
case.
No functional changes intended.
This moves all code related to transactions into the execute_commands_loop
function which was factored out of execute_commands. This includes
beginning and committing the transaction as well as dealing with the
errors which may occur during the begin and commit
This enables the atomic protocol option as implemented in the previous
patches.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v7:
* new with v7 of the patch series.
* this was part of the first patch in the series, moved back here
for bisectability
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 sbel...@google.com
---
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
No functional changes intended.
This commit shortens execute_commands by moving some parts of the code
to extra functions.
Suggested-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v7:
new in v7 as in v7 I'd split up the previous
The patch
[PATCH 4/7] receive-pack.c: receive-pack.c: use a single
ref_transaction for atomic pushes
was dropped and redone as 3 separate patches. This wasn't just done for doing
it,
but the end result has also changed. We have more smaller functions doing
one thing instead of these
From: Ronnie Sahlberg sahlb...@google.com
This documents the protocol option 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
From: Ronnie Sahlberg sahlb...@google.com
Add a command line argument to the git push command to request atomic
pushes.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
Changes v1 - v2
It's --atomic now! (dropping the
From: Ronnie Sahlberg sahlb...@google.com
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.
In order to do this we also need to change the semantics for send_pack()
slightly. The existing
please ignore this series. I'm sorry for the noise.
--
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
On 12/29/14, 7:40 AM, Torsten Bögershausen wrote:
Having problems with different perl installations is not an unknown problem
in Git, I would say.
And Git itself is prepared to handle this situation:
In Makefile I can read:
# Define PERL_PATH to the path of your Perl binary (usually
From: Junio C Hamano gits...@pobox.com
Christian Couder chrisc...@tuxfamily.org writes:
When running for example git bisect bad HEAD or
git bisect good master, the parameter passed to
git bisect (bad|good) has to be parsed into a
commit hash before checking if it is the expected
commit or
Signed-off-by: Stefan Beller sbel...@google.com
---
Documentation/git-rebase.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 924827d..ffadb0b 100644
--- a/Documentation/git-rebase.txt
+++
On Sun, Dec 28, 2014 at 5:28 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
I'm doing some work in this area, so I should be able to work on the
bugfix in the not-too-distant future. My feeling is that the bug is
unlikely to affect many current users, though it definitely should be
fixed
On 12/29/14, 7:21 AM, Ævar Arnfjörð Bjarmason wrote:
[CC'd the perlbrew author]
This is a bit of a tricky issue.
Using whatever perl is defined in the environment is just as likely to
break, in general the build process tries to pick these assets at
compile-time. Imagine you're
On Mon, Dec 29, 2014 at 10:57 PM, Randy J. Ray rj...@blackperl.com wrote:
On 12/29/14, 7:40 AM, Torsten Bögershausen wrote:
Having problems with different perl installations is not an unknown
problem
in Git, I would say.
And Git itself is prepared to handle this situation:
In Makefile I
On Mon, Dec 29, 2014 at 12:42 PM, Stefan Beller sbel...@google.com wrote:
This adds more explanation of why you want to have the --notes option
given to git format-patch.
Signed-off-by: Stefan Beller sbel...@google.com
---
diff --git a/Documentation/SubmittingPatches
On Mon, Dec 29, 2014 at 3:18 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Mon, Dec 29, 2014 at 12:42 PM, Stefan Beller sbel...@google.com wrote:
This adds more explanation of why you want to have the --notes option
given to git format-patch.
Signed-off-by: Stefan Beller
From: Junio C Hamano gits...@pobox.com
* po/doc-core-ignorestat (2014-12-12) 1 commit
(merged to 'next' on 2014-12-23 at d2b3e84)
+ doc: core.ignoreStat clarify the --assume-unchanged effect
Will merge to 'master'.
I was hoping to re-roll but family Christmas / New Year visits have
Hi,
so I have been sending commits to the git mailing list occasionally
for quite some time. In the last couple of weeks I send more and more
patches to the mailing list as it's part of my job now. Here is a
collection of practices I am following (or want to follow) and they
seem to be effective.
From: Ronnie Sahlberg sahlb...@google.com
This documents the protocol option 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
No functional changes intended.
This moves all code related to transactions into the execute_commands_loop
function which was factored out of execute_commands. This includes
beginning and committing the transaction as well as dealing with the
errors which may occur during the begin and commit
From: Ronnie Sahlberg sahlb...@google.com
Add a command line argument to the git push command to request atomic
pushes.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v8:
no changes
v7:
Use OPT_BOOL instead
This enables the atomic protocol option as implemented in the previous
patches.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v8:
no changes
v7:
* new with v7 of the patch series.
* this was part of the first patch in the series, moved back here
for
This renames ref_update_to_be_sent to check_to_send_update and inverts
the meaning of the return value. Having the return value inverted we
can have different values for the error codes. This is useful in a
later patch when we want to know if we hit the CHECK_REF_STATUS_REJECTED
case.
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
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 sbel...@google.com
---
From: Ronnie Sahlberg sahlb...@google.com
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.
In order to do this we also need to change the semantics for send_pack()
slightly. The existing
The patch
[PATCH 4/7] receive-pack.c: receive-pack.c: use a single
ref_transaction for atomic pushes
was dropped and redone as 3 separate patches. This wasn't just done for doing
it,
but the end result has also changed. We have more smaller functions doing
one thing instead of these
No functional changes intended.
This commit shortens execute_commands by moving some parts of the code
to extra functions.
Suggested-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v8: no change
v7:
new in v7 as in v7 I'd
Hello,
Just wanted to say there's a little script at [1] that saves the certificate
blobs generated on the server side by git push --signed.
Quoting from the source:
# Collects the cert blob on push and saves it, then, if a certain number of
# signed pushes have been seen, processes all the
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller sbel...@google.com wrote:
No functional changes intended.
This is useful to know but is of secondary importance, thus should be
placed after the explanation and justification of the change.
Subject: receive-pack.c: simplify execute_commands
This
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller sbel...@google.com wrote:
Subject: receive-pack.c: add documentation for atomic push support
This patch is doing a lot more than merely adding documentation. It's
also updating send-pack and receive-pack to be able to negotiate the
new protocol
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller sbel...@google.com wrote:
No functional changes intended.
This commit shortens execute_commands by moving some parts of the code
to extra functions.
Suggested-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Stefan Beller
56 matches
Mail list logo
