On 02/12/2015 07:04 PM, Stefan Beller wrote:
On Thu, Feb 12, 2015 at 8:52 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
However, another important question is whether other Git implementations
have copied this unusual locking policy. If so, that would be a reason
not to change it. I just
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 reflog expire HEAD might grab
refs/heads/master.lock then start rewriting
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 that not
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 that not locking the underlying ref,
as long as we have a lock on the symref, is
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
On 02/13/2015 08:12 PM, Junio C Hamano wrote:
[...]
As we are trying to see a way to move forward to do the right thing
around reflog, I was wondering if locking only the symbolic ref is a
sensible endgame. The right thing being:
When a symbolic ref S points at underlying ref R, and if
Stefan Beller sbel...@google.com writes:
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,
Michael Haggerty mhag...@alum.mit.edu writes:
Now back to the real world. Currently, if R is changed *through* a
symbolic reference S, then the reflogs for both R and S are updated, but
not the reflogs for any other symbolic references that might point at R.
If R is changed directly, then no
On 02/13/2015 10:53 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Now back to the real world. Currently, if R is changed *through* a
symbolic reference S, then the reflogs for both R and S are updated, but
not the reflogs for any other symbolic references that 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
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...@alum.mit.edu
wrote:
When processing the reflog of a symbolic ref, hold the
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, not on
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, not on the reference that it points to.
I am not sure if that makes sense.
So
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
When processing the reflog of a symbolic ref, hold the lock on the
symbolic reference itself, not on the reference that it points to.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index
16 matches
Mail list logo
