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
Thanks!
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 erro
Sergey Organov 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'
>> argument,
Michael Haggerty 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
freopen(3) a stream on
Junio C Hamano 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 wants to e
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 do
Michael Haggerty 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 quite good. Wi
Michael Haggerty 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
> Signed-off-by: Michael Haggerty
> ---
> ...
> - hold_locke
Michael Haggerty 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
> Signed-off-by: Michael Haggerty
> ---
> Documentat
Michael Haggerty 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 series applied on t
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
http://dev.galaxy
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
> ---
> strbuf.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
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
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-lockfile.txt | 5 +
cache.h
This makes it harder to misread the name as LOCK_NODE_REF.
Suggested-by: Torsten Bögershausen
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-lockfile.txt | 4 ++--
cache.h | 2 +-
lockfile.c | 2 +-
refs.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 lock_file_list
Aside from shortening and simplifying the code, this removes another
place where the path name length is arbitrarily limited.
Signed-off-by: Michael Haggerty
---
lockfile.c | 33 -
1 file changed, 12 insertions(+), 21 deletions(-)
diff --git a/lockfile.c b/lockfi
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 sto
commit_locked_index(), when writing to an alternate index file,
duplicates (poorly) the code in commit_lock_file(). And anyway, it
shouldn't have to know so much about the internal workings of lockfile
objects. So extract a new function commit_lock_file_to() that does the
work common to the two fun
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 rem
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
Reviewed-by: Jonathan Nieder
---
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
+++ b/lockfile.c
@@ -53,12 +53,8 @@ static vo
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 lock_fi
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
---
config.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.
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
Reviewed-by: Jonathan Nieder
---
lockfile.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
dif
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
Signed-off
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
---
lockfile.c | 7 ++-
1 file changed, 6 insertions(+), 1
There are a few places that use these values, so define constants for
them.
Signed-off-by: Michael Haggerty
---
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 07682cb..9f09a89 100
Eliminate a layer of nesting.
Signed-off-by: Michael Haggerty
Reviewed-by: Ronnie Sahlberg
Reviewed-by: Jonathan Nieder
---
lockfile.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 5330d6a..e55149a 100644
--- a/lockfile.c
+++ b/
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 c
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
---
lockfile.c | 8
read-cache.c | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/lockfile.c b/lockfile.c
i
* remove_lock_file() -> remove_lock_files()
* remove_lock_file_on_signal() -> remove_lock_files_on_signal()
Suggested-by: Torsten Bögershausen
Signed-off-by: Michael Haggerty
---
lockfile.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lockfile.c b/lockfile.c
in
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
Reviewed-by: Jonathan Nieder
---
fast-import.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fast-import.c
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
Reviewed-by: Ronnie Sahlberg
Reviewed-by: Jonathan Nieder
---
lockfile.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
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. Re
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 affec
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
Signed-off-by: Michael Haggerty
---
builtin/merge.c | 14 +++---
1 file changed, 7 insertio
Avoid relying on the filename length restrictions that are currently
checked by lock_file().
Signed-off-by: Michael Haggerty
---
lockfile.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 89043f5..1dd118f 100644
--- a/lockfile.c
+++
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: Mich
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 the
It is only necessary to clear the lock_file's filename field if it was
not already clear.
Signed-off-by: Michael Haggerty
Reviewed-by: Ronnie Sahlberg
Reviewed-by: Jonathan Nieder
---
lockfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lockfile.c b/lockfile.c
index d
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.)
Sig
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
Reviewed-by: Ronnie Sahlberg
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index
* 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 N
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 careful
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
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-lockfile.txt | 199 +
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 ou
Signed-off-by: Michael Haggerty
---
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)
int commit_lock_file
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
Reviewed-by: Ronnie Sahlberg
---
lockfile.c | 42 ++
1 file changed, 42 insertions(+)
diff
This function is used for other things besides the index, so rename it
accordingly.
Suggested-by: Jeff King
Signed-off-by: Michael Haggerty
Reviewed-by: Ronnie Sahlberg
Reviewed-by: Jonathan Nieder
---
builtin/update-index.c | 2 +-
cache.h| 2 +-
lockfile.c | 6 ++
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
---
refs.c
Suggested-by: Jonathan Nieder
Signed-off-by: Michael Haggerty
---
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
+++ b/lockfile.c
@@ -233,6 +233,10 @@ int hold_loc
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: CC=/opt/S
53 matches
Mail list logo
