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 sahlb...@google.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
Changes v1 - v2:
* Name it atomic instead of atomic-push
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
-by: Stefan Beller sbel...@google.com
---
Notes:
This was introduced with the [PATCHv2] series.
Changes v2 - v3:
* Rename to check_to_send_update
* Negative error values.
* errors values are #define'd and not raw numbers.
send-pack.c | 18 +++---
1 file changed
):
receive-pack.c: add protocol support to negotiate atomic-push
send-pack.c: add --atomic command line argument
receive-pack.c: use a single transaction when atomic-push is
negotiated
push.c: add an --atomic argument
Stefan Beller (2):
send-pack: Rename ref_update_to_be_sent
I am not sure if there was any improvement since then, but Junio
wrote about alternates 2 years ago
http://git-blame.blogspot.com/2012/08/bringing-bit-more-sanity-to-alternates.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Wed, Dec 17, 2014 at 3:26 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
@@ -1086,8 +1100,25 @@ static void execute_commands(struct command *commands,
if (cmd-skip_update)
continue;
-
+ if (!use_atomic
On Wed, Dec 17, 2014 at 3:51 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
On Tue, Dec 16, 2014 at 11:46 AM, Junio C Hamano gits...@pobox.com wrote:
+ (
+ cd upstream git config receive.denyCurrentBranch warn
+ )
I was wondering
The Developers Certificate of Origin has a mixture of tabs and white
spaces which is annoying to view if your editor explicitly views white
space characters.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
I'll also try to send it upstream to linux.
Documentation
The Developers Certificate of Origin has a mixture of tabs and white
spaces which is annoying to view if your editor explicitly views white
space characters.
Signed-off-by: Stefan Beller sbel...@google.com
---
Documentation/SubmittingPatches | 12 ++--
1 file changed, 6 insertions(+), 6
for people that do not want atomic pushes.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Stefan Beller sbel...@google.com
---
v4 of the series only resends this patch as the others did not get any
feedback to improve.
Notes:
Changes v1 - v2:
* update
for people that do not want atomic pushes.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
Changes v1 - v2:
* update(...) assumes to be always in a transaction
* Caring about when to begin/commit transactions is put
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 sahlb...@google.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
Changes v1 - v2:
* Name it atomic instead of atomic-push
.
Inspired-by: Ronnie Sahlberg sahlb...@google.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
Changes in v6:
This is a complete rewrite of the patch essentially.
Eric suggested to split up the flow into functions, so
atomic-push
send-pack.c: add --atomic command line argument
push.c: add an --atomic argument
Stefan Beller (4):
send-pack: Rename ref_update_to_be_sent to check_to_send_update
receive-pack.c: receive-pack.c: use a single ref_transaction for
atomic pushes
receive-pack: move
-by: Stefan Beller sbel...@google.com
---
Notes:
This was introduced with the [PATCHv2] series.
Changes v2 - v3:
* Rename to check_to_send_update
* Negative error values.
* errors values are #define'd and not raw numbers.
skipped v4 v5
v6:
* negative
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
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
---
Notes
is taking lots of
code that was once in execute_commands.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
This patch is new with v6 of the series
As execute_commands_non_atomic is larger than execute_commands, the diff
is not moving around execute_commands_non_atomic
to the end user to flag that these refs failed to update since the
atomic push operation failed.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
Notes:
Changes v1 - v2:
* Now we only need a very small change
On 22.12.2014 14:52, Eric Sunshine wrote:
On Fri, Dec 19, 2014 at 2:38 PM, Stefan Beller sbel...@google.com wrote:
From: Ronnie Sahlberg sahlb...@google.com
This adds support to the protocol between send-pack and receive-pack to
* allow receive-pack to inform the client that it has atomic
On 22.12.2014 13:22, Junio C Hamano wrote:
Loic Dachary l...@dachary.org writes:
Hi,
Steps to reproduce:
$ git --version
git version 1.9.1
$ wc -l /tmp/1
9090 /tmp/1
$ head /tmp/1
delete refs/pull/1/head
create refs/heads/pull/1 86b715f346e52920ca7c9dfe65424eb9946ebd61
delete
I tried all four diff options as listed in the man page of
format-diff. I forget which one I used, but there was no large
difference w.r.t. reviewability if I remember correctly.
On Mon, Dec 22, 2014 at 10:19 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes
On 22.12.2014 13:22, Junio C Hamano wrote:
Loic Dachary l...@dachary.org writes:
Hi,
Steps to reproduce:
$ git --version
git version 1.9.1
$ wc -l /tmp/1
9090 /tmp/1
$ head /tmp/1
delete refs/pull/1/head
create refs/heads/pull/1 86b715f346e52920ca7c9dfe65424eb9946ebd61
delete
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
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
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 21b3f29
-by: Stefan Beller sbel...@google.com
---
Notes:
This was introduced with the [PATCHv2] series.
Changes v2 - v3:
* Rename to check_to_send_update
* Negative error values.
* errors values are #define'd and not raw numbers.
skipped v4 v5
v6:
* negative
phase of a transaction.
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v7:
new in v7, this is part of the previous [PATCH 4/7]
receive-pack.c: receive-pack.c: use a single ref_transaction for atomic
pushes
This covers
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
builtin
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
---
Notes
.
Inspired-by: Ronnie Sahlberg sahlb...@google.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
Changes in v7:
Eric suggested to replace [PATCH 4/7] receive-pack.c:
receive-pack.c: use a single ref_transaction
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
documentation for atomic push support
send-pack.c: add --atomic command line argument
push.c: add an --atomic argument
Stefan Beller (6):
send-pack: Rename ref_update_to_be_sent to check_to_send_update
receive-pack.c: simplify execute_commands
receive-pack.c: move transaction handling
request that atomic
pushes are to be used yet. This only adds protocol capability not ability
for the user to activate it. The capability is also not yet advertised
by receive-pack as git doesn't know how to handle it yet.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Stefan
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
to the end user to flag that these refs failed to update since the
atomic push operation failed.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
Notes:
Changes v1 - v2:
* Now we only need a very small change
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
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
+++ b/Documentation
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 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 sbel
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.
request that atomic
pushes are to be used yet. This only adds protocol capability not ability
for the user to activate it. The capability is also not yet advertised
by receive-pack as git doesn't know how to handle it yet.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Stefan
phase of a transaction.
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v8:
move execute_commands_loop before execute_commands, so it compiles/links
without warnings.
v7:
new in v7, this is part of the previous
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
-by: Stefan Beller sbel...@google.com
---
Notes:
This was introduced with the [PATCHv2] series.
Changes v2 - v3:
* Rename to check_to_send_update
* Negative error values.
* errors values are #define'd and not raw numbers.
skipped v4 v5
v6:
* negative
.
Inspired-by: Ronnie Sahlberg sahlb...@google.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
Changes in v8:
removed superflous } to make it compile again
Changes in v7:
Eric suggested to replace [PATCH 4/7
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
---
Notes
to the end user to flag that these refs failed to update since the
atomic push operation failed.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
Notes:
Changes v1 - v2:
* Now we only need a very small change
documentation for atomic push support
send-pack.c: add --atomic command line argument
push.c: add an --atomic argument
Stefan Beller (6):
send-pack: rename ref_update_to_be_sent to check_to_send_update
receive-pack.c: simplify execute_commands
receive-pack.c: move transaction handling in a central
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
On Mon, Dec 29, 2014 at 11:08 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
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
reply to all instead of reply to Eric only.
On Mon, Dec 29, 2014 at 10:11 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
In v6, you considered this a fatal error in the atomic case, which
caused the entire transaction to be rolled back. However, in this
version, this error has no effect
On Mon, Dec 29, 2014 at 11:46 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
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
On Tue, Dec 30, 2014 at 9:33 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
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
On Tue, Dec 30, 2014 at 12:36 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller sbel...@google.com wrote:
Subject: receive-pack.c: move transaction handling in a central place
This is very generic, and doesn't really explain what this patch
On Tue, Dec 30, 2014 at 10:25 AM, Stefan Beller sbel...@google.com wrote:
Should this be s/current/previous/. Technically the current commit seems
correct to me, but it was crafted in the previous lines of the instruction
sheet
so it feels like it's a commit which is already done and we're
On Tue, Dec 30, 2014 at 12:12 PM, Robert Dailey
rcdailey.li...@gmail.com wrote:
I was surprised to find today that the following didn't work as expected:
$ git show master@{1 year ago}:Path/To/File.h
It gave me the following warning which did not make the problem obvious at
all:
warning:
On Mon, Dec 29, 2014 at 10:11 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
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
sunsh...@sunshineco.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v9:
* simplified should_process_cmd to be a one liner
* check_shallow_bugs doesn't check of shallow_update being set, rather
the function is just called if that option is set.
v8: no change
-pack.c: negotiate atomic push support
send-pack.c: add --atomic command line argument
push.c: add an --atomic argument
Stefan Beller (6):
receive-pack.c: shorten the execute_commands loop over all commands
receive-pack.c: move iterating over all commands outside
execute_commands
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, v9:
no changes
v7:
Use OPT_BOOL
the
protocol capabilities of the server.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v9:
This was once part of [PATCH 1/7] receive-pack.c:
add protocol support to negotiate atomic-push
but now it only touches the receive-pack.c part
and doesn't bother
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
---
Notes
Sunshine sunsh...@sunshineco.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v9:
This was split up into the patch before and this one.
This patch only deals with the transactions now.
v8:
move execute_commands_loop before execute_commands, so it compiles
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v9:
Because the patches have been reordered, we introduce use_atomic
in this patch, but don't touch it.
Minor comment: This cleanup code is repeated in both the success and
fail branches. It _might_
-by: Stefan Beller sbel...@google.com
---
Notes:
v7, v8, v9:
* no changes
v6:
* negative #define'd values
skipped v4 v5
This was introduced with the [PATCHv2] series.
Changes v2 - v3:
* Rename to check_to_send_update
* Negative error values
to the end user to flag that these refs failed to update since the
atomic push operation failed.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v9:
This patch now incorporates parts of the very first patch of
the previous
This commit allows us in a later patch to easily distinguish between
the non atomic way to update the received refs and the atomic way which
is introduced in a later patch.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v9:
new and shiny. But makes the next patch easier
. CodingGuidelines contains
rule that the star must side with variable name.
The whole series is
Reviewed-by: Stefan Beller sbel...@google.com
--
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
and the last patch
fixes the bug and also marks the bugs as resolved in the
test suite.
Unfortunately this applies on top of origin/next.
Any feedback would be welcome!
Thanks,
Stefan
Stefan Beller (6):
update-ref: test handling large transactions properly
t7004: rename ULIMIT test prerequisite
Signed-off-by: Stefan Beller sbel...@google.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Notes:
v2-v3:
no changes
t/t1400-update-ref.sh | 28
1 file changed, 28 insertions(+)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index
-by: Stefan Beller sbel...@google.com
---
Notes:
version3:
* Do not reopen the files after closing them. Make sure we have
written all necessary information before closing the file.
Doing it that way enabled us to drop the patch [PATCH 4/6]
refs.c: Have a write_in_full_to_lock_file
By moving the functions up we don't need to have to declare them first
when using them in a later patch.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
new in v3
refs.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/refs.c b
. This is a first step to split up
write_ref_sha1 into the write and commit phase which is done in a
later patch.
There is a call in each code path after write_ref_sha1 now. Even in
the last hunk in the error case, the 'goto cleanup;' will make sure
there is a call to unlock_ref.
Signed-off-by: Stefan Beller
During creation of the patch series our discussion we could have a
more descriptive name for the prerequisite for the test so it stays
unique when other limits of ulimit are introduced.
Signed-off-by: Stefan Beller sbel...@google.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Notes
On Fri, Jan 23, 2015 at 10:35 AM, Arup Rakshit
arupraks...@rocketmail.com wrote:
On Friday, January 23, 2015 11:31:40 AM you wrote:
Arup Rakshit arupraks...@rocketmail.com writes:
I asked git not to track any changes to the file .gitignore. To do
so I did use the command - git update-index
The 'lock_fd' is the same as 'lk-fd'. No need to store it twice so remove
it. You may argue this introduces more coupling as we need to know more
about the internals of the lock file mechanism, but this will be solved in
a later patch.
No functional changes intended.
Signed-off-by: Stefan Beller
On Fri, Jan 23, 2015 at 4:38 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
On Fri, Jan 23, 2015 at 4:14 PM, Junio C Hamano gits...@pobox.com wrote:
yeah that's the goal. Though as we're in one transaction, as soon
as we have an early exit
On Fri, Jan 23, 2015 at 1:14 PM, Junio C Hamano gits...@pobox.com wrote:
Good answer for .gitignore. In general, you do not ignore local
changes to tracked paths.
I assumed Arup would want to ignore more than is in the upstream project,
so you'd come up with an appendix to the .gitignore
On Fri, Jan 23, 2015 at 2:26 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
Assuming you want to ignore less than the upstream project (delete some
lines from .gitignore) it get's tricky in my opinion.
Why? Doesn't info/exclude allow negative ignore
and new sha1 values being the same has been moved to a helper
function so that check is not part of write_ref_sha1 or commit_ref any
more.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v1:
applies on top of origin/sb/atomic-push-fix (79370dd9656)
This undoes
On Mon, Feb 2, 2015 at 3:27 PM, Junio C Hamano gits...@pobox.com wrote:
+ test_must_fail git apply --index patch
+
+'
Is the empty line between the last test_must_fail and the closing `'`
intentional?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
2015-02-02 11:15 GMT-08:00 Junio C Hamano gits...@pobox.com:
Stefan Beller stefanbel...@gmail.com writes:
On 01.02.2015 14:51, /#!/JoePea wrote:
I have this in my .gitignore:
./*.js
I would expect that to cause git to ignore .js files in the same
folder as .gitignore, but it doesn't do
On Fri, Feb 6, 2015 at 3:06 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
+ die(_(sorry, cannot apply a 'copying' patch in
reverse (yet)));
Is it wise to give the reader of the output hope that this is not
implemented (yet)
but may
On Tue, Feb 3, 2015 at 11:37 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
On Mon, Feb 2, 2015 at 3:27 PM, Junio C Hamano gits...@pobox.com wrote:
+ test_must_fail git apply --index patch
+
+'
Is the empty line between the last test_must_fail
Regarding patch 1 - 9:
Reviewed-by: Stefan Beller sbel...@google.com
for what it's worth.
--
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 Thu, Jan 15, 2015 at 2:46 PM, Jeff King p...@peff.net wrote:
On Thu, Jan 15, 2015 at 02:36:11PM -0800, Stefan Beller wrote:
So for here is my proposal for small transactions:
(just one ref [and/or reflog] touched):
The implication being that a large transaction is any with more than
one
For everyday use we want git to be fast. Creating one commit should not
touch the packed refs file. If we do other stuff involving more than
one ref, we may accept touching the packed refs file and have a process
which takes slightly longer but can handle more complex requests correctly,
such as
anybody else also run into
such a problem?
Running ulimit -{n,s} manually in a shell (/bin/sh) as well as bash does
work as expected as it correctly reports with ulimit -a as well as breaking
the tests I try to write.
Thanks,
Stefan
Signed-off-by: Stefan Beller sbel...@google.com
---
t/t7004-tag.sh
The 'lock_fd' is the same as 'lk-fd'. No need to store it twice so remove
it. You may argue this introduces more coupling as we need to know more
about the internals of the lock file mechanism, but this will be solved in
a later patch.
No functional changes intended.
Signed-off-by: Stefan Beller
On Wed, Jan 21, 2015 at 3:38 PM, Jeff King p...@peff.net wrote:
On Wed, Jan 21, 2015 at 03:23:42PM -0800, Stefan Beller wrote:
There is another occurrence where we could have used write_str_in_full
(line 3107: write_in_full(lock-lk-fd, term, 1)), so the current state
is inconsistent
On Wed, Jan 21, 2015 at 11:03 AM, Jeff King p...@peff.net wrote:
in your debugging statement (and of course use run_with... for the
actual git command you want to limit).
Thanks for that hint, its now part of the bugfix series.
Stefan
--
To unsubscribe from this list: send the line
of origin/next.
Any feedback would be welcome!
Thanks,
Stefan
Stefan Beller (6):
update-ref: Test handling large transactions properly
refs.c: remove lock_fd from struct ref_lock
refs.c: replace write_str_in_full by write_in_full
refs.c: Have a write_in_full_to_lock_file wrapping
.
No functional changes intended.
Signed-off-by: Stefan Beller sbel...@google.com
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index e905f51..8281bed 100644
--- a/refs.c
+++ b/refs.c
@@ -4080,7 +4080,7 @@ int reflog_expire(const char *refname, const unsigned
Signed-off-by: Stefan Beller sbel...@google.com
---
t/t1400-update-ref.sh | 28
1 file changed, 28 insertions(+)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 6805b9e..ea98b9b 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
By closing the file descriptors after creating the lock file we are not
limiting the size of the transaction by the number of available file
descriptors.
Signed-off-by: Stefan Beller sbel...@google.com
---
refs.c| 14 +-
t/t1400-update-ref.sh | 4 ++--
2 files
open for appending.
No functional changes intended.
Signed-off-by: Stefan Beller sbel...@google.com
---
refs.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/refs.c b/refs.c
index 311599b..0161667 100644
--- a/refs.c
+++ b/refs.c
@@ -3078,8 +3078,8 @@ static
Now we only have one place where we need to touch the internals of
the lock_file struct.
No functional changes intended.
Signed-off-by: Stefan Beller sbel...@google.com
---
refs.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 8281bed
By closing the file descriptors after creating the lock file we are not
limiting the size of the transaction by the number of available file
descriptors.
Signed-off-by: Stefan Beller sbel...@google.com
---
refs.c| 17 +
t/t1400-update-ref.sh | 4 ++--
2 files
501 - 600 of 7730 matches
Mail list logo
