> 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
On Sun, Dec 28, 2014 at 11:36 PM, 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-
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
Eric Sunshine 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" perhaps?
Eric Sunshine 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 and
will make the res
Sitaram Chamarty 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 just be
the matt
On Mon, Dec 22, 2014 at 9:55 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> This adds an explanation of why you want to have the --notes option
>> given to git format-patch.
>>
>> Signed-off-by: Stefan Beller
>> ---
>>
>> Notes:
>> > with optionally update Documentation/SubmittingPat
René Scharfe writes:
> Signed-off-by: Rene Scharfe
> ---
> 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 *lock_ref_sha1_basic(const char
This adds more explanation of why you want to have the --notes option
given to git format-patch.
Signed-off-by: Stefan Beller
---
Notes:
Changes v2:
* s/you are encouraged to/you may want to/
* a stronger hint to use the git notes and then
--notes for format-patch.
Documen
Signed-off-by: Alexander Kuleshov
---
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 +1275,10 @@ X-Mailer: git-s
Christoph Junghans 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 could not find a
On Thu, Dec 25, 2014 at 11:17 PM, Michael Haggerty 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 21b3f29..da63
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 writes:
> Signed-off-by: Alexander Kuleshov
> ---
> 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-emai
Eric Sunshine 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
initial report of the
Christian Couder 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 commit object nam
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-wri
Michael Haggerty 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 pushes.
>
> 1. Sh
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 wi
On Mon, Dec 29, 2014 at 09:37:43AM -0800, Junio C Hamano wrote:
> René Scharfe writes:
>
> > Signed-off-by: Rene Scharfe
> > ---
> > 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 n
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.
Signed-off-b
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 phase
This enables the atomic protocol option as implemented in the previous
patches.
Signed-off-by: Stefan Beller
---
Notes:
v7:
* new with v7 of the patch series.
* this was part of the first patch in the series, moved back here
for bisectability
builtin/receive-pack.c | 3 ++-
1
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:
v7: no change
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
No functional changes intended.
This commit shortens execute_commands by moving some parts of the code
to extra functions.
Suggested-by: Eric Sunshine
Signed-off-by: Stefan Beller
---
Notes:
v7:
new in v7 as in v7 I'd split up the previous
[PATCH 4/7] receive-pack.c: receive-pack
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 larg
From: Ronnie Sahlberg
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 request that atomic
pu
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
---
Notes:
Changes v1 -> v2
It's --atomic now! (dropping the -push)
v2->v3:
* s/atomic-push/atomic/
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.
In order to do this we also need to change the semantics for send_pack()
slightly. The existing send_pack() functio
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 /usr/bin/pe
From: Junio C Hamano
> Christian Couder 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
Signed-off-by: Stefan Beller
---
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
+++ b/Documentation/git-rebase.txt
@@ -3
On Sun, Dec 28, 2014 at 5:28 PM, Michael Haggerty 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 before sb/atomic-p
> 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 yo
On Mon, Dec 29, 2014 at 10:57 PM, Randy J. Ray 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 can
On Mon, Dec 29, 2014 at 12:42 PM, Stefan Beller wrote:
> This adds more explanation of why you want to have the --notes option
> given to git format-patch.
>
> Signed-off-by: Stefan Beller
> ---
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index e3c942e..f42c
On Mon, Dec 29, 2014 at 3:18 PM, Eric Sunshine wrote:
> On Mon, Dec 29, 2014 at 12:42 PM, Stefan Beller wrote:
>> This adds more explanation of why you want to have the --notes option
>> given to git format-patch.
>>
>> Signed-off-by: Stefan Beller
>> ---
>> diff --git a/Documentation/Submitting
From: "Junio C Hamano"
* 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
disrupted plans.
Could
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
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 request that atomic
pu
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 phase
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
---
Notes:
v8:
no changes
v7:
Use OPT_BOOL instead of OPT_BIT.
This allows for --no-atomic option on
This enables the atomic protocol option as implemented in the previous
patches.
Signed-off-by: Stefan Beller
---
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 bisectability
buil
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.
Signed-off-b
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
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:
v7, v8: no ch
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.
In order to do this we also need to change the semantics for send_pack()
slightly. The existing send_pack() functio
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 large
No functional changes intended.
This commit shortens execute_commands by moving some parts of the code
to extra functions.
Suggested-by: Eric Sunshine
Signed-off-by: Stefan Beller
---
Notes:
v8: no change
v7:
new in v7 as in v7 I'd split up the previous
[PATCH 4/7] recei
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 "s
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller 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 commit shortens
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller 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 capability "atomic". T
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
> No functional changes intended.
>
> This commit shortens execute_commands by moving some parts of the code
> to extra functions.
>
> Suggested-by: Eric Sunshine
> Signed-off-by: Stefan Beller
> ---
> diff --git a/builtin/receive-pack.c b/bu
56 matches
Mail list logo
