Hello Matthieu,
I thought curl was installed correctly on the server, but apparently it
was only the curl binaries (no headers/libs).
So what I did (for the records):
1) compile curl-7.38.0, prefix /usr/local/curl-7.38.0 (so that my system
curl is not impacted)
2) configure git with:
This function is used for other things besides the index, so rename it
accordingly.
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Ronnie Sahlberg sahlb...@google.com
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
---
It's bad manners. Especially since there could be a signal during the
call to unlink_or_warn(), in which case the signal handler will see
the wrong filename and delete the reference file, leaving the lockfile
behind.
So make our own copy to work with.
Signed-off-by: Michael Haggerty
Suggested-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 6 +-
read-cache.c | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index f1ce154..d02c3bf 100644
--- a/lockfile.c
+++
Document a couple more functions and the flags argument as used by
hold_lock_file_for_update() and hold_lock_file_for_append().
Reorganize the document to make it more accessible.
Helped-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Next iteration of my lockfile fixes and refactoring. Thanks to
Jonathan Nieder and Torsten Bögershausen for their comments about v5.
I believe that this series addresses all of the comments from v1 [1],
v2 [2], v3 [3], v4 [4], and v5 [5].
Changes since v4:
* Revise API documentation.
* Split
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index f8205f6..e148227 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -300,12 +300,14 @@ int reopen_lock_file(struct lock_file *lk)
Document the valid states of lock_file objects, how they get into each
state, and how the state is encoded in the object's fields.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Ronnie Sahlberg sahlb...@google.com
---
lockfile.c | 42 ++
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from lock_file_list),
that means we have to be
If the call to adjust_shared_perm() fails, lock_file returns -1, which
to the caller looks like any other failure to lock the file. So in
this case, roll back the lockfile before returning so that the lock
file is deleted immediately and the lockfile object is left in a
predictable state (namely,
Even the one lockfile object needn't be allocated each time the
function is called. Instead, define one statically-allocated
lock_file object and reuse it for every call.
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/merge.c | 14
Avoid relying on the filename length restrictions that are currently
checked by lock_file().
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 89043f5..1dd118f 100644
Callers who don't pass LOCK_DIE_ON_ERROR might want to examine errno
to see what went wrong, so restore errno before returning.
In fact this function only has one caller, add_to_alternates_file(),
and it *does* use LOCK_DIE_ON_ERROR, but, you know, think of future
generations.
Signed-off-by:
Move the interface declaration for the functions in lockfile.c from
cache.h to a new file, lockfile.h. Add #includes where necessary (and
remove some redundant includes of cache.h by files that already
include builtin.h).
Move the documentation of the lock_file state diagram from lockfile.c
to
It is only necessary to clear the lock_file's filename field if it was
not already clear.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Ronnie Sahlberg sahlb...@google.com
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
---
lockfile.c | 2 +-
1 file changed, 1 insertion(+), 1
Declare the return value to be const to make it clear that we aren't
giving callers permission to write over the string that it points at.
(The return value is the filename field of a struct lock_file, which
can be used by a signal handler at any time and therefore shouldn't be
tampered with.)
* remove_lock_file() - remove_lock_files()
* remove_lock_file_on_signal() - remove_lock_files_on_signal()
Suggested-by: Torsten Bögershausen tbo...@web.de
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff
When commit_lock_file() fails, it now always calls
rollback_lock_file() internally, so there is no need to call that
function here.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
---
fast-import.c | 4 +---
1 file changed, 1 insertion(+), 3
This is a bit easier to read than the old version, which nested part
of the non-error code in an if block.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Ronnie Sahlberg sahlb...@google.com
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
---
lockfile.c | 23
Rewrite last_path_elm() to take a strbuf parameter and to trim off the
last path name element in place rather than returning a pointer to the
beginning of the last path name element. This simplifies the function
a bit and makes it integrate better with its caller, which is now also
strbuf-based.
lockfile.c contains the general API for locking any file. Code
specifically about the index file doesn't belong here.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 8
read-cache.c | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git
This makes it obvious that we have no plans to change the integer
pointed to, which is actually the fd field from a struct lock_file.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1
If closing an open lockfile fails, then we cannot be sure of the
contents of the lockfile, so there is nothing sensible to do but
delete it. This change also insures that the lock_file object is left
in a defined state in this error path (namely, unlocked).
The only caller that is ultimately
* Document the behavior of commit_lock_file() when it fails, namely
that it rolls back the lock_file object and sets errno
appropriately.
* Document the behavior of rollback_lock_file() when called for a
lock_file object that has already been committed or rolled back,
namely that it is a
When rolling back the lockfile, call close_lock_file() so that the
lock_file's fd field gets set back to -1. This keeps the lock_file
object in a valid state, which is important because these objects are
allowed to be reused. It also makes it unnecessary to check whether
the file has already been
There are a few places that use these values, so define constants for
them.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
cache.h| 4
lockfile.c | 11 ++-
refs.c | 7 ---
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/cache.h b/cache.h
index
Eliminate a layer of nesting.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Ronnie Sahlberg sahlb...@google.com
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
---
lockfile.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/lockfile.c
After commit_lock_file() is called, then the lock_file object is
necessarily either committed or rolled back. So there is no need to
call rollback_lock_file() again in either of these cases.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
config.c | 1 +
1 file changed, 1 insertion(+)
If there is an error copying the old contents to the lockfile, roll
back the lockfile before exiting so that the lockfile is not held
until process cleanup.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
---
lockfile.c | 4 ++--
1 file
Change resolve_symlink() to take a strbuf rather than a string as
parameter. This simplifies the code and removes an arbitrary pathname
length restriction. It also means that lock_file's filename field no
longer needs to be initialized to a large size.
Helped-by: Torsten Bögershausen
If rename() fails, call rollback_lock_file() to delete the lock file
(in case it is still present) and reset the filename field to the
empty string so that the lockfile object is left in a valid state.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 7 ++-
1 file
It was previously a bug to call commit_lock_file() with a lock_file
object that was not active (an illegal access would happen within the
function). It was presumably never done, but this would be an easy
programming error to overlook. So before continuing, do a consistency
check that the
The purpose of this patch is to make the state diagram for lock_file
objects simpler and deterministic.
If locking fails, lock_file() sometimes leaves the lock_file object
partly initialized, but sometimes not. It sometimes registers the
object in lock_file_list, but sometimes not. This makes the
It does just what we need.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
---
lockfile.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index a8f32e5..f8205f6 100644
--- a/lockfile.c
+++
By the time the if block is entered, the lock_file instance from the
main function block is no longer in use, so re-use that one instead of
allocating a second one.
Note that the lock variable in the if block shadowed the lock
variable at function scope, so the only change needed is to remove the
This makes it harder to misread the name as LOCK_NODE_REF.
Suggested-by: Torsten Bögershausen tbo...@web.de
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/technical/api-lockfile.txt | 4 ++--
cache.h | 2 +-
lockfile.c
The function remove_lock_file_on_signal() is used as a signal handler.
It is not realistic to make the signal handler conform strictly to the
C standard, which is very restrictive about what a signal handler is
allowed to do. But let's increase the likelihood that it will work:
The
Aside from shortening and simplifying the code, this removes another
place where the path name length is arbitrarily limited.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 33 -
1 file changed, 12 insertions(+), 21 deletions(-)
diff --git
For now, we still make sure to allocate at least PATH_MAX characters
for the strbuf because resolve_symlink() doesn't know how to expand
the space for its return value. (That will be fixed in a moment.)
Another alternative would be to just use a strbuf as scratch space in
lock_file() but then
Add a function to return the path of the file that is locked by a
lock_file object. This reduces the knowledge that callers have to have
about the lock_file layout.
Suggested-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
On 07/25/2014 12:43 PM, Nguyễn Thái Ngọc Duy wrote:
This function is used to replaced some code in the next patch that
does this (i.e. keep the errno when read() fails)
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
strbuf.c | 7 +--
1 file changed, 5 insertions(+), 2
Hello,
I have faced a git bug. When I try to clone a git repo it
shows an error protocol error: bad pack header.
This is the full error message which I got while cloning git
project :
Clone: protocol error: bad pack header
$ git clone -v --progress
Michael Haggerty mhag...@alum.mit.edu writes:
* Rebase to current master.
When you say this, could you be a bit more descriptive? Has the
series updated to use something new that appeared on 'master' since
the last series was posted and needed to be rebased? Or did you
just made sure that the
Michael Haggerty mhag...@alum.mit.edu writes:
Document a couple more functions and the flags argument as used by
hold_lock_file_for_update() and hold_lock_file_for_append().
Reorganize the document to make it more accessible.
Helped-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by:
Michael Haggerty mhag...@alum.mit.edu writes:
Even the one lockfile object needn't be allocated each time the
function is called. Instead, define one statically-allocated
lock_file object and reuse it for every call.
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Michael Haggerty
Michael Haggerty mhag...@alum.mit.edu writes:
Next iteration of my lockfile fixes and refactoring. Thanks to
Jonathan Nieder and Torsten Bögershausen for their comments about v5.
I believe that this series addresses all of the comments from v1 [1],
v2 [2], v3 [3], v4 [4], and v5 [5].
Looked
I asked this Q on
http://stackoverflow.com/questions/26068474/what-are-git-subtree-push-assertions
but from previous experiences with git-subtree, people on
stackoverflow (general public) don't really have complete answers so I
resort to you!
* What exactly are these assertions doing, and why
Junio C Hamano gits...@pobox.com writes:
Perhaps like this, with some documentation added (do we have/need
any test???).
-- 8 --
Date: Thu, 25 Sep 2014 18:08:31 -0400
Subject: [PATCH] git-quiltimport.sh: allow declining fuzz with --exact option
And on top of that change, if somebody really
Michael Haggerty mhag...@alum.mit.edu writes:
+If you need to close the file descriptor you obtained from a
+`hold_lock_file_*` function yourself, do so by calling
+`close_lock_file`. You should never call `close(2)` yourself!
This is sometimes untenable, isn't it? A caller may want to
Sergey Organov sorga...@gmail.com writes:
I think you meant to say that we may find a better source to calculate
the exact set of commits to rebase,...
Yes.
It is debatable if we should do the same when the user tells us to
rebase with respect to a specific _branch_ by giving the 'upstream'
On Fri, Sep 26, 2014 at 07:11:35PM +0530, Ajay wrote:
Hello,
I have faced a git bug. When I try to clone a git repo it shows an
error protocol error: bad pack header.
This is the full error message which I got while cloning git
project :
Clone: protocol error: bad
I expect that combining the --intent-to-add and --patch command would open
up the patch interface with all of my current files and untracked files
withing the path specified. However, it seems like the patch command causes
the intent-to-add to be ignored.
❯ git --version
git version 2.0.0
52 matches
Mail list logo
