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 | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/refs.c b/refs.c
index
)
First a test case is introduced to demonstrate the failure,
the patches 2-6 are little refactoring 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
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
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 7b4707b..47d2fe9 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -973,4
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
---
t/t7004-tag.sh | 4 ++--
1 file changed, 2 insertions
On Thu, Jan 15, 2015 at 3:34 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
In ref_transaction_commit
* commit the .lock file to its destination
* in case this is a deletion:
* remove the loose ref
* and repack
On Thu, Jan 15, 2015 at 3:53 PM, Jeff King p...@peff.net wrote:
On Thu, Jan 15, 2015 at 03:24:15PM -0800, Stefan Beller wrote:
I see the performance problem as well as the contention problem
you're pointing out. Dealing with loose refs however creates other
problems such as directory/file
in the error case, the 'goto cleanup;' will make sure
there is a call to unlock_ref.
Signed-off-by: Stefan Beller sbel...@google.com
---
refs.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/refs.c b/refs.c
index aae3b66..4580919 100644
--- a/refs.c
+++ b
topic2 3459
update master 6787 9878
EOF
git update-ref --stdin stdin_pipe
Internally update-ref would be easy to implement when all you
have left are lock files you'd need to commit.
Any feedback welcome!
Thanks,
Stefan
Stefan Beller (5):
fixup for refs.c: enable large
This makes write_ref_sha1 only write the the lock file, committing
needs to be done outside of that function. This will help us change
the ref_transaction_commit in a later patch.
Signed-off-by: Stefan Beller sbel...@google.com
---
refs.c | 22 +-
1 file changed, 13
in the first loop of
ref_transaction_commit (/* Acquire all locks while verifying
old values */), while the renameing is left to the next loop.
Signed-off-by: Stefan Beller sbel...@google.com
---
refs.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index
On Thu, Jan 22, 2015 at 3:42 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
-* it might with whitespace fuzz. We haven't been asked to
+* it might with whitespace fuzz. We weren't asked to
(not a native speaker):
A quick websearch
On Thu, Jan 22, 2015 at 2:58 PM, Junio C Hamano gits...@pobox.com wrote:
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/apply.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 622ee16..31f8733 100644
---
This will fix the warnings Ramsay Jones pointed out.
Signed-off-by: Stefan Beller sbel...@google.com
---
refs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index 9fc0e60..aae3b66 100644
--- a/refs.c
+++ b/refs.c
@@ -3058,12 +3058,12 @@ static int
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
---
refs.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/refs.c b/refs.c
index 4580919
Test if we can do arbitrary large transactions. Currently this is a known
bug that we cannot do large transactions, so document it at least in the
test suite.
Signed-off-by: Stefan Beller sbel...@google.com
---
t/t1400-update-ref.sh | 27 +++
1 file changed, 27 insertions
On Tue, Jan 20, 2015 at 5:20 PM, Stefan Beller sbel...@google.com wrote:
Test if we can do arbitrary large transactions. Currently this is a known
bug that we cannot do large transactions, so document it at least in the
test suite.
Signed-off-by: Stefan Beller sbel...@google.com
---
t
Add more test coverage to the atomic push option. It turns out there is a
breakage when renaming branches within an atomic push. The breakage occurs
because it cannot lock the refs v/v as well as x.
Signed-off-by: Stefan Beller sbel...@google.com
---
t/t5543-atomic-push.sh | 49
sparse running?
As for the fix, would it be sufficient to check != NULL instead of 0?
Thanks,
Stefan
On Thu, Jan 22, 2015 at 4:59 AM, Ramsay Jones
ram...@ramsay1.demon.co.uk wrote:
On 22/01/15 02:32, Stefan Beller wrote:
By closing the file descriptors after creating the lock file we
On Thu, Jan 22, 2015 at 8:33 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 01/22/2015 02:10 PM, Jeff King wrote:
On Thu, Jan 22, 2015 at 12:24:23PM +0100, Michael Haggerty wrote:
I can't figure out where to apply this series or where to fetch it from,
so I can't see these changes in
cc Johannes Schindelin johannes.schinde...@gmx.de who is working in
the fsck at the moment
cc Peter Wu pe...@lekensteyn.nl who worked on builtin/remote.c a few weeks ago
I just compiled origin/pu to test and also found a problem (doesn't
happen in origin/master):
http.c: In function
On Thu, Jan 22, 2015 at 9:58 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
v2 applies to sb/atomic-push instead of next and will result in a one
line merge conflict with next.
I acctually tried to apply on 'next' and also on 'sb/atomic-push'
and both
On Thu, Jan 22, 2015 at 12:13 PM, Ramsay Jones
ram...@ramsay1.demon.co.uk wrote:
Notice the [-Wextra] warnings above. ;-)
ATB,
Ramsay Jones
Thanks, I put that into my config.mak
Though recompiling the whole project yields
4 [-Wempty-body]
477 [-Wmissing-field-initializers]
On Thu, Jan 22, 2015 at 12:00 AM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
On Wed, Jan 21, 2015 at 03:23:39PM -0800, Stefan Beller wrote:
(reported as: git update-ref --stdin : too many open files, 2014-12-20)
First a test case is introduced to demonstrate
On Wed, Feb 11, 2015 at 10:10 AM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
On the other hand, there's this [1] and this [2] from the FSF, which
recommend a copyright blurb at the beginning of every source file.
Though actually the recommendation is
On Wed, Feb 11, 2015 at 2:49 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
When processing the reflog of a symbolic ref, hold the lock on the
symbolic reference itself
On Thu, Feb 12, 2015 at 1:34 AM, Jeff King p...@peff.net wrote:
The beginnings of the Google Summer of Code deadlines are upon us again.
Organization applications are due February 20th (next Friday).
- Do we want to do it?
- Who would like to volunteer to be the org admin?
I would
On Thu, Feb 12, 2015 at 3:12 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
Committing involves the following steps:
1. Determine the current value of HEAD (if any).
2. Create the new commit object.
3. Update HEAD.
Please note that step 2 can take arbitrarily long, because it might
On Thu, Feb 12, 2015 at 8:52 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 02/12/2015 12:25 AM, Stefan Beller wrote:
On Wed, Feb 11, 2015 at 2:49 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag
On Thu, Feb 12, 2015 at 3:12 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
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://vger.kernel.org/majordomo
-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://vger.kernel.org/majordomo-info.html
This fixes a memory leak, when building the cache entries as
refresh_cache_entry may decide to return NULL in case of
I am not sure how severe this memory leak is as it was found by
scan.coverity.com, CID 290041.
Signed-off-by: Stefan Beller sbel...@google.com
---
read-cache.c | 10
On Tue, Feb 17, 2015 at 10:14 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
This fixes a memory leak, when building the cache entries as
refresh_cache_entry may decide to return NULL in case of
in case of what?
Yeah, I got distracted when rewriting
On Wed, Feb 18, 2015 at 6:54 PM, Junio C Hamano gits...@pobox.com wrote:
On Wed, Feb 18, 2015 at 4:43 PM, Shawn Pearce spea...@spearce.org wrote:
This fails from a JGit server because the ref advertisement for an
empty repository differs and disagrees with the format used by
git-core. The
On Thu, Feb 19, 2015 at 1:26 PM, Stephen Morton
stephen.c.mor...@gmail.com wrote:
I posted this to comp.version-control.git.user and didn't get any response. I
think the question is plumbing-related enough that I can ask it here.
I'm evaluating the feasibility of moving my team from SVN to
On Mon, Jan 26, 2015 at 7:22 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
I can redo the atomic-push-fix series with this cleanup merged
into the appropriate patches or you could just queue it on top
of said series.
Yeah, I do not think we
On Fri, Jan 23, 2015 at 4:39 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
On Fri, Jan 23, 2015 at 3:57 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
-static int commit_ref(struct ref_lock *lock)
+static int
On Fri, Jan 23, 2015 at 3:57 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
-static int commit_ref(struct ref_lock *lock)
+static int commit_ref(struct ref_lock *lock, const unsigned char *sha1)
{
+ if (!lock-force_write !hashcmp(lock-old_sha1
On Fri, Jan 23, 2015 at 4:14 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
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.
When closing the file
On 01.02.2015 19:18, Junio C Hamano wrote:
When a commit creates new file B by copying the contents of an
existing file A and making a small edit and makes large edit to A,
This part is hard to parse
When ... and making a small edit and makes a large edit
So large or small? It's a bit hard to
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 anything. However, this works:
/*.js
I'm not sure what this actually means because a leading slash
On 09.01.2015 17:52, Junio C Hamano wrote:
Stefan Beller sbel...@google.com writes:
If the server is configured to not advertise push certificates,
a push certificate that gets pushed nevertheless will not be fully
recorded because push_cert_nonce is NULL.
Sorry, but I do not quite see
non NULL.
Without this patch an unsolicited nonce never makes to the stage when
being exported with GIT_PUSH_CERT_NONCE_STATUS, because in the unsolicited
case push_cert_nonce is always NULL.
Signed-off-by: Stefan Beller sbel...@google.com
---
builtin/receive-pack.c | 12 ++--
1 file
On Fri, Jan 9, 2015 at 2:39 PM, Junio C Hamano gits...@pobox.com wrote:
The patched code will make it fail by hoping that queue_command()
that only handles 40-hex 40-hex ref will reject the line that
begins with push-cert. Instead of relying on such a hidden
dependency, wouldn't it be cleaner
the flaw could not be abused.
I am not saying there is a problem now, but I am rather saying patches
similar to this one would buy us time in case of problems arising.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
As I discovered the idea while composing the
atomic push series
On Tue, Jan 6, 2015 at 10:57 AM, Junio C Hamano gits...@pobox.com wrote:
You said it yourself above, didn't you? While perfecting your
branch and while perfecting reroll of your branch.
* After doing changes, wait at least 12 hours for second self-review
This is certainly once-per-series.
in some situations. Sound the message more like a
This Cannot Happen, Please Investigate! instead of giving advice to
remove refs. Running 'git fsck' should not cause any problems though.
Suggested-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes
'warn_if_skipped_connectivity_check' warns if we have forgotten to
run a connectivity check on a ref which is shallow for the client
which would be a bug.
This will help us to duplicate less code in a later patch when we make
a second copy of the execute_commands loop.
No functional change intended.
Signed-off-by: Stefan
On Mon, Jan 12, 2015 at 3:29 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
Is this needed only to support the tests you add in t5543, or do you
intend it to be useful to end users?
If it is for end users, then it deserves to be documented. Is also
deserves proper mention and justification
This was missing in 1b70fe5d3054 (2015-01-07, receive-pack.c: negotiate
atomic push support) as I squashed the option in very late in the patch
series.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v1:
This goes on top of origin/sb/atomic-push
Documentation/config.txt | 5
On Sun, Feb 8, 2015 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
Instead, if old_sha1 is non-NULL, verify it; otherwise, don't.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com apart from the commit message.
--
To unsubscribe from
On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
Creating a reference requires a new_sha1 that is not NULL and not
null_sha1.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
--
To unsubscribe from this list: send
On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
It makes no sense to delete a reference that is already known not to
exist.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
--
To unsubscribe from this list: send
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://vger.kernel.org/majordomo-info.html
On Sun, Feb 8, 2015 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
It is only used internally now. Document it a little bit better, too.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
--
To unsubscribe from this list: send the line
On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
diff --git a/t/t7516-commit-races.sh b/t/t7516-commit-races.sh
new file mode 100755
index 000..5efa351
--- /dev/null
+++ b/t/t7516-commit-races.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+#
+# Copyright (c) 2014 Michael
the version without commas makes it way easier to read for me.)
Otherwise
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://vger.kernel.org/majordomo
On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
By the way, both of these patch series conflict with
sb/atomic-push-fix, which is in pu. My understanding is that Stefan
wants to rework that patch series anyway, but if not I would be happy
to show how to resolve
On Sun, Feb 8, 2015 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
There is no reason to reserve a gap between the public and private
flags values.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
/*
- * Add a reference update to transaction. new_sha1 is the value that
- * the reference should have after the update, or null_sha1 if it should
- * be deleted. If old_sha1 is non-NULL, then it the value
- *
On Sun, Feb 8, 2015 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
Instead, if old_sha1 is non-NULL, verify it; otherwise, don't.
parsing error on that commit message. I needed to read the code to understand
what you want to say here.
The code itself is
Reviewed-by: Stefan Beller sbel
On Fri, Feb 13, 2015 at 10:26 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
On Fri, Feb 13, 2015 at 10:05 AM, Junio C Hamano gits...@pobox.com wrote:
We convinced ourselves that not locking the symref is wrong, but
have we actually convinced us
On Fri, Feb 13, 2015 at 8:26 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
What is the best way forward?
Switching to holding only HEAD.lock while updating logs/HEAD is the
right solution, but it would introduce an incompatibility with old
versions of Git and libgit2 (and maybe JGit?)
On Fri, Feb 13, 2015 at 10:05 AM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
I also realized that Git's current policy is probably not tenable if one
process is re-seating a symref at the same time as another process is
expiring its reflog. The git
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
When this patch series is applied, you only have 3 occurences of
force_write.
1. In the struct as an undocumented int.
2. In lock_ref_sha1_basic:
if ((flags REF_NODEREF) (type REF_ISSYMREF
me or anybody knows what they're
doing), but as this function (write_ref_sha1) is not widely exposed
any more since aae383db8 (Apr 28, refs.c: make write_ref_sha1 static),
I think it's safe to assume changes affecting this call are well
understood in the future.
so
Reviewed-by: Stefan Beller sbel
On Mon, Feb 9, 2015 at 12:40 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
I am not sure what advantages this would bring. A better history
for bisection? I cannot speak for Michael, but my understanding was
to have mh/reflog-expire and sb/atomic-push-fix merged now that 2.3
is out and
Hi Erik,
this is not a bug but a feature. ;) Actually rejecting HTML is one of
the easiest ways to avoid 95 % of spam mails. If you want email to
send via gmail, you can do so by enabling text only mode for sending
mails.
That is good for general discussion. But if you intend to send a
patch,
On Thu, Feb 12, 2015 at 8:08 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 02/11/2015 01:44 AM, Stefan Beller wrote:
On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
If we are expiring reflog entries for a symbolic reference, then how
should --updateref
On Fri, Feb 13, 2015 at 1:41 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
41 bytes is the exact number of bytes needed for having the returned
hex string represented. 50 seems to be an arbitrary number, such
that there are no benefits from alignment
41 bytes is the exact number of bytes needed for having the returned
hex string represented. 50 seems to be an arbitrary number, such
that there are no benefits from alignment to certain address boundaries.
Signed-off-by: Stefan Beller sbel...@google.com
---
hex.c | 2 +-
1 file changed, 1
On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
If a reference is missing, its SHA-1 will be null_sha1, which can't
possibly match a new value that ref_transaction_commit() is trying to
update it to. So there is no need to set force_write in this scenario.
This
On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
Update the git reflog usage documentation in the manpage and the
command help to match the current reality.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
---all::
- Instead of listing refs explicitly, prune all refs.
+--stale-fix::
+ This revamps the logic -- the definition of broken commit
+ becomes: a commit that is not reachable from any of the
On Tue, Feb 10, 2015 at 4:05 PM, Jeff King p...@peff.net wrote:
On Tue, Feb 10, 2015 at 03:24:47PM -0800, Stefan Beller wrote:
On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
If a reference is missing, its SHA-1 will be null_sha1, which can't
possibly match
On Mon, Feb 9, 2015 at 10:41 AM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
The main purpose of this series is to simplify the interface to
reference transactions as follows:
* Remove the need to supply an explicit have_old parameter to
On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
If we are expiring reflog entries for a symbolic reference, then how
should --updateref be handled if the newest reflog entry is expired?
Option 1: Update the referred-to reference. (This is what the current
code
On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
When processing the reflog of a symbolic ref, hold the lock on the
symbolic reference itself, not on the reference that it points to.
I am not sure if that makes sense.
So when expiring HEAD, you want to have a
On Thu, Feb 5, 2015 at 11:22 AM, Sebastian Schuberth
sschube...@gmail.com wrote:
On Thu, Feb 5, 2015 at 8:19 PM, Sebastian Schuberth
sschube...@gmail.com wrote:
Is that an improvement? Is the plural of dup (used as an
abbreviation of duplicate) dupes not dups?
My view is that the
be found at https://github.com/stefanbeller/git/tree/atomic-push-v12
Any comment is welcome!
Thanks,
Stefan
Ronnie Sahlberg (3):
receive-pack.c: negotiate atomic push support
send-pack.c: add --atomic command line argument
push.c: add an --atomic argument
Stefan Beller (7):
receive
the
protocol capabilities of the server.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v10, v11, v12:
* no changes
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
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:
v10, v11, v12:
* no changes
v8, v9
in some situations. Sound the message more like a
This Cannot Happen, Please Investigate! instead of giving advice to
remove refs.
Suggested-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v12:
* no advice in case we die.
v11
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:
v10, v11, v12:
* no changes
v9:
This patch now incorporates parts
'warn_if_skipped_connectivity_check' warns if we have forgotten to
run a connectivity check on a ref which is shallow for the client
which would be a bug.
This will help us to duplicate less code in a later patch when we make
a second copy of the execute_commands loop.
No functional change intended.
Signed-off-by: Stefan
Sunshine sunsh...@sunshineco.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v10, v11, v12:
no changes
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
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
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:
v10, v11, v12:
no changes
v9:
new
-by: Stefan Beller sbel...@google.com
---
Notes:
v10, v11, v12:
* no changes
v7, v8, v9:
* no changes
v6:
* negative #define'd values
skipped v4 v5
This was introduced with the [PATCHv2] series.
Changes v2 - v3:
* Rename
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v10, v11, v12:
* no changes
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
On Sat, Jan 3, 2015 at 1:53 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jan 3, 2015 at 9:20 AM, Jonathan Nieder jrnie...@gmail.com wrote:
- if (shallow_update !checked_connectivity)
- error(BUG: run 'git fsck' for safety.\n
- If there are errors, try to
' warns if we have forgotten to run a
connectivity check on a ref which is shallow for the client which
would be a bug.
This will help us to duplicate less code in a later patch when we make
a second copy of the execute_commands loop.
No functional change intended.
Signed-off-by: Stefan Beller sbel
Discussion on the previous patch revealed we rather want to err on the
safe side. To do so we need to stop receive-pack in case of the possible
future bug when connectivity is not checked on a shallow push.
Suggested-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Stefan Beller sbel
if you want to send out the coverletter with
untouched
subject line (*** SUBJECT HERE***).
Not-signed-off-by: Stefan Beller sbel...@google.com as it's RFC.
---
builtin/log.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index
On Mon, Dec 29, 2014 at 1:28 PM, Junio C Hamano gits...@pobox.com wrote:
* sb/copy-fd-errno (2014-11-17) 1 commit
- copy.c: make copy_fd preserve meaningful errno
Will be rerolled as a part of a larger series.
I am not expecting to reroll this as part of a larger series any more.
So if
On Mon, Jan 5, 2015 at 12:22 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Stefan Beller wrote:
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
[...]
@@ -1077,27 +1100,15 @@ static void execute_commands(struct command
*commands,
[...]
+ if (shallow_update
On Mon, Jan 5, 2015 at 12:17 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Stefan Beller wrote:
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -1055,15 +1055,15 @@ static void assure_connectivity_checked(struct
command *commands,
for (cmd = commands; cmd; cmd = cmd
On Wed, Jan 7, 2015 at 3:26 PM, Dmitry Bykov pvr...@gmail.com wrote:
Hello,
Recently I installed 1.9.5 git version and faced the problem that one
of the files in my cloned repository with a name ICON~714.PNG is
marked as deleted even repository was freshly cloned. Trying to do
anything with
On Tue, Jan 6, 2015 at 4:58 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Hi all,
While toying with the tab completion script for bash, I found a couple
of things missing that cannot be completed:
- git config --includes
- git config branch.$BRANCH_NAME.description
Attached are
On Tue, Jan 6, 2015 at 2:37 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
When sending out patch series one of the last things doing is writing
the cover letter. The cover letter would be a good place to remind
people to check the todo list for sending
601 - 700 of 7730 matches
Mail list logo
