Re: [PATCH v6 02/39] api-lockfile: revise and expand the documentation

On 09/30/2014 07:39 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: I was being repetitive because I didn't want the docs to depend on the user remembering what the bss section is (which, technically, is also not part of the C standard). I think a better way would be

Re: [PATCH v6 02/39] api-lockfile: revise and expand the documentation

On 09/30/2014 07:47 PM, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Tue, Sep 30, 2014 at 03:41:55PM +0200, Michael Haggerty wrote: I didn't fix it because IMO the correct fix is to add a stdio-oriented entry point to the lockfile API, and teach the lockfile code to handle

[PATCH 1/2] sha1-array: add test-sha1-array and basic tests

Signed-off-by: Rene Scharfe l@web.de --- .gitignore| 1 + Makefile | 1 + t/t0064-sha1-array.sh | 64 +++ test-sha1-array.c | 34 +++ 4 files changed, 100 insertions(+) create mode 100755

[PATCH 2/2] sha1-lookup: fix handling of duplicates in sha1_pos()

If the first 18 bytes of the SHA1's of all entries are the same then sha1_pos() dies and reports that the lower and upper limits of the binary search were the same that this wasn't supposed to happen. This is wrong because the remaining two bytes could still differ. Furthermore: It wouldn't be a

[PATCH 1/3] daemon: handle gethostbyname() error

If the user-supplied hostname can't be found then we should not use it. We already avoid doing that in the non-NO_IPV6 case by checking if the return value of getaddrinfo() is zero (success). Do the same in the NO_IPV6 case and make sure the return value of gethostbyname() isn't NULL before

[PATCH 2/3] daemon: fix error message after bind()

Signed-off-by: Rene Scharfe l@web.de --- daemon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemon.c b/daemon.c index a6f467e..090f6a4 100644 --- a/daemon.c +++ b/daemon.c @@ -924,7 +924,7 @@ static int setup_named_sock(char *listen_addr, int listen_port, struct

[PATCH 3/3] daemon: remove write-only variable maxfd

It became unused when 6573faff (NO_IPV6 support for git daemon) replaced select() with poll(). Signed-off-by: Rene Scharfe l@web.de --- daemon.c | 4 1 file changed, 4 deletions(-) diff --git a/daemon.c b/daemon.c index 090f6a4..54a03bd 100644 --- a/daemon.c +++ b/daemon.c @@ -815,7

[PATCH v7 01/38] unable_to_lock_die(): rename function from unable_to_lock_index_die()

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 ---

[PATCH v7 11/38] cache.h: define constants LOCK_SUFFIX and LOCK_SUFFIX_LEN

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

[PATCH v7 00/38] Lockfile correctness and refactoring

Yet another iteration of my lockfile fixes and refactoring. Thanks to Junio for his comments about v6. I believe that this series addresses all of the comments from v1 [1], v2 [2], v3 [3], v4 [4], v5 [5], and v6 [6]. Changes since v6: * Rebased on current master to resolve conflicts with

[PATCH v7 03/38] close_lock_file(): exit (successfully) if file is already closed

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 +++

[PATCH v7 12/38] delete_ref_loose(): don't muck around in the lock_file's filename

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

[PATCH v7 13/38] prepare_index(): declare return value to be (const char *)

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.)

[PATCH v7 02/38] api-lockfile: revise and expand the documentation

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 Helped-by: Junio Hamano gits...@pobox.com Signed-off-by: Michael

[PATCH v7 04/38] rollback_lock_file(): do not clear filename redundantly

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

[PATCH v7 30/38] resolve_symlink(): take a strbuf parameter

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

[PATCH v7 34/38] lockfile.c: rename static functions

* 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

[PATCH v7 31/38] trim_last_path_component(): replace last_path_elm()

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.

[PATCH v7 33/38] Rename LOCK_NODEREF to LOCK_NO_DEREF

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

[PATCH v7 20/38] api-lockfile: document edge cases

* 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

[PATCH v7 23/38] lockfile: avoid transitory invalid states

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

[PATCH v7 24/38] struct lock_file: declare some fields volatile

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

[PATCH v7 35/38] get_locked_file_path(): new function

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 ---

[PATCH v7 26/38] try_merge_strategy(): use a statically-allocated lock_file object

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

[PATCH v7 36/38] hold_lock_file_for_append(): restore errno before returning

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:

[PATCH v7 17/38] commit_lock_file(): die() if called for unlocked lockfile object

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

[PATCH v7 38/38] lockfile.h: extract new header file for the functions in lockfile.c

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

[PATCH v7 21/38] dump_marks(): remove a redundant call to rollback_lock_file()

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

[PATCH v7 27/38] commit_lock_file(): use a strbuf to manage temporary space

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

[PATCH v7 32/38] Extract a function commit_lock_file_to()

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

[PATCH v7 25/38] try_merge_strategy(): remove redundant lock_file allocation

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

[PATCH v7 37/38] Move read_index() definition to read-cache.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 mhag...@alum.mit.edu --- lockfile.c | 8 read-cache.c | 8 2 files changed, 8 insertions(+), 8 deletions(-) diff --git

[PATCH v7 29/38] resolve_symlink(): use a strbuf for internal scratch space

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

[PATCH v7 28/38] Change lock_file::filename into a strbuf

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

[PATCH v7 16/38] commit_lock_file(): inline temporary variable

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)

[PATCH v7 08/38] hold_lock_file_for_append(): release lock on errors

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

[PATCH v7 19/38] commit_lock_file(): rollback lock file on failure to rename

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

[PATCH v7 10/38] lockfile.c: document the various states of lock_file objects

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 ++

[PATCH v7 22/38] git_config_set_multivar_in_file(): avoid call to rollback_lock_file()

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(+)

[PATCH v7 14/38] lock_file(): exit early if lockfile cannot be opened

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

[PATCH v7 09/38] lock_file(): always initialize and register lock_file object

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

[PATCH v7 18/38] close_lock_file(): if close fails, roll back

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

[PATCH v7 07/38] lockfile: unlock file if lockfile permissions cannot be adjusted

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,

[PATCH v7 05/38] rollback_lock_file(): exit early if lock is not active

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

[PATCH v7 15/38] remove_lock_file(): call rollback_lock_file()

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 +++

[PATCH v7 06/38] rollback_lock_file(): set fd to -1

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

Re: [PATCH 2/2] sha1-lookup: fix handling of duplicates in sha1_pos()

On Wed, Oct 01, 2014 at 11:43:21AM +0200, René Scharfe wrote: If the first 18 bytes of the SHA1's of all entries are the same then sha1_pos() dies and reports that the lower and upper limits of the binary search were the same that this wasn't supposed to happen. This is wrong because the

Re: [PATCH 2/2] sha1-lookup: fix handling of duplicates in sha1_pos()

Am 01.10.2014 um 12:50 schrieb Jeff King: On Wed, Oct 01, 2014 at 11:43:21AM +0200, René Scharfe wrote: If the first 18 bytes of the SHA1's of all entries are the same then sha1_pos() dies and reports that the lower and upper limits of the binary search were the same that this wasn't supposed

[PATCH 3/3] commit_packed_refs(): reimplement using fdopen_lock_file()

Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- refs.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/refs.c b/refs.c index 1d73f1d..a77458f 100644 --- a/refs.c +++ b/refs.c @@ -2309,16 +2309,13 @@ int commit_packed_refs(void) if (!packed_ref_cache-lock)

[PATCH 2/3] dump_marks(): reimplement using fdopen_lock_file()

Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- fast-import.c | 21 ++--- 1 file changed, 2 insertions(+), 19 deletions(-) diff --git a/fast-import.c b/fast-import.c index deadc33..fee7906 100644 --- a/fast-import.c +++ b/fast-import.c @@ -1794,20 +1794,18 @@ static void

[PATCH 1/3] fdopen_lock_file(): access a lockfile using stdio

Add a new function, fdopen_lock_file(), which returns a FILE pointer open to the lockfile. If a stream is open on a lock_file object, it is closed using fclose() on commit, rollback, or close_lock_file(). This change will allow callers to use stdio to write to a lockfile without having to muck

[PATCH 0/3] Support stdio access to lockfiles

This series applies on top of the series Lockfile correctness and refactoring (Junio's branch mh/lockfile). There are already two callers that write to lockfiles using stdio. But they currently need intimate knowledge of the lockfile implementation to work correctly; for example, they have to

Re: [PATCH v7 09/38] lock_file(): always initialize and register lock_file object

Am 01.10.2014 um 12:28 schrieb Michael Haggerty: 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

Re: [PATCH v7 09/38] lock_file(): always initialize and register lock_file object

On 10/01/2014 01:27 PM, René Scharfe wrote: Am 01.10.2014 um 12:28 schrieb Michael Haggerty: 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

Re: [PATCH 2/2] sha1-lookup: fix handling of duplicates in sha1_pos()

On Wed, Oct 01, 2014 at 01:10:12PM +0200, René Scharfe wrote: I wonder if it is worth adding a test (you test only that not found produces a negative index, but not which index). Like: api-sha1-array.txt says about sha1_array_lookup: If not found, returns a negative integer, and that's what

Re: [PATCH 1/3] fdopen_lock_file(): access a lockfile using stdio

On Wed, Oct 01, 2014 at 01:14:47PM +0200, Michael Haggerty wrote: I thought about adding second stdio-oriented entrance points analogous to hold_lock_file_for_update(), hold_lock_file_for_append(), and reopen_lock_file(), but it seemed simpler to add just the one new function instead of three

Re: [PATCH 0/3] Support stdio access to lockfiles

On Wed, Oct 01, 2014 at 01:14:46PM +0200, Michael Haggerty wrote: This series applies on top of the series Lockfile correctness and refactoring (Junio's branch mh/lockfile). There are already two callers that write to lockfiles using stdio. But they currently need intimate knowledge of the

Re: [PATCH 1/2] sha1-array: add test-sha1-array and basic tests

On Wed, Oct 1, 2014 at 5:40 AM, René Scharfe l@web.de wrote: Signed-off-by: Rene Scharfe l@web.de --- diff --git a/t/t0064-sha1-array.sh b/t/t0064-sha1-array.sh new file mode 100755 index 000..bd68789 --- /dev/null +++ b/t/t0064-sha1-array.sh @@ -0,0 +1,64 @@ +#!/bin/sh +

Re: [PATCH 2/2] sha1-lookup: fix handling of duplicates in sha1_pos()

On Wed, Oct 1, 2014 at 5:43 AM, René Scharfe l@web.de wrote: If the first 18 bytes of the SHA1's of all entries are the same then sha1_pos() dies and reports that the lower and upper limits of the binary search were the same that this wasn't supposed to happen. This is wrong because the

Re: [PATCH 1/2] sha1-array: add test-sha1-array and basic tests

Am 01.10.2014 um 16:11 schrieb Eric Sunshine: On Wed, Oct 1, 2014 at 5:40 AM, René Scharfe l@web.de wrote: Signed-off-by: Rene Scharfe l@web.de --- diff --git a/t/t0064-sha1-array.sh b/t/t0064-sha1-array.sh new file mode 100755 index 000..bd68789 --- /dev/null +++

Re: [PATCH 1/2] sha1-array: add test-sha1-array and basic tests

On Wed, Oct 01, 2014 at 10:11:04AM -0400, Eric Sunshine wrote: +echo20() { + prefix=$1 + shift + while test $# -gt 0 + do + echo $prefix$1$1$1$1$1$1$1$1$1$1$1$1$1$1$1$1$1$1$1$1 Each caller of echo20() manually includes a space at the end of

[PATCH v2 1/2] sha1-array: add test-sha1-array and basic tests

Helped-by: Jeff King p...@peff.net Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Rene Scharfe l@web.de --- Added a test for looking up a non-existing entry in an array that contains duplicates, as suggested by Jeff. Changed echo20() to add a space after the prefix as needed,

[PATCH v2 2/2] sha1-lookup: handle duplicates in sha1_pos()

If the first 18 bytes of the SHA1's of all entries are the same then sha1_pos() dies and reports that the lower and upper limits of the binary search were the same that this wasn't supposed to happen. This is wrong because the remaining two bytes could still differ. Furthermore: It wouldn't be a

Re: [PATCH v2 1/2] sha1-array: add test-sha1-array and basic tests

On Wed, Oct 01, 2014 at 05:00:33PM +0200, René Scharfe wrote: Helped-by: Jeff King p...@peff.net Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Rene Scharfe l@web.de --- Added a test for looking up a non-existing entry in an array that contains duplicates, as suggested

Re: [PATCH v3 19/32] setup.c: support multi-checkout repo setup

Am 28.09.2014 um 03:22 schrieb Nguyễn Thái Ngọc Duy: +test_expect_success 'GIT_DIR set (2)' ' + echo gitdir: repo.git/repos/foo gitfile + echo $TRASH_DIRECTORY/repo.git repo.git/repos/foo/commondir + ( + cd work + GIT_DIR=../gitfile git rev-parse

Re: [PATCH v3 23/32] prune: strategies for linked checkouts

Am 28.09.2014 um 03:22 schrieb Nguyễn Thái Ngọc Duy: +test_expect_success 'prune directories with gitdir pointing to nowhere' ' + mkdir -p .git/worktrees/def/abc + : .git/worktrees/def/def + echo $TRASH_DIRECTORY/nowhere .git/worktrees/def/gitdir + git prune --worktrees

Can you git clone -partial? I am looking to make a mobile app and it would be nice to have.

i am thinking about developing an app and I want to integrate it with git but I only want to store a portion of the file on disk. It is going to be in a mobile enviornment and I want to just get one file or a small group of files. I read that you can clone and then only look at one peice but is

Re: [PATCH] init - Honour the global core.filemode setting

Hilco Wijbenga hilco.wijbe...@gmail.com writes: Perhaps I completely misunderstand the meaning of core.filemode but I thought it determined whether Git cared about changes in file properties? By setting it to false, you tell Git that the filesystem you placed the repository does not correctly

Re: Can you git clone -partial? I am looking to make a mobile app and it would be nice to have.

James Hancock ja...@bookstobrains.com writes: i am thinking about developing an app and I want to integrate it with git but I only want to store a portion of the file on disk. It is going to be in a mobile enviornment and I want to just get one file or a small group of files. I read that

Re: [PATCH] git-prompt.sh: shorter equal upstream branch name

Richard Hansen rhan...@bbn.com writes: and there is no hope to fix them to stick to the bare-minimum POSIX, I don't think it'd be hard to convert it to pure POSIX if there was a desire to do so. Not necessarily; if you make it so slow to be usable as a prompt script, that is not a

Re: [PATCH 1/3] daemon: handle gethostbyname() error

All three look trivially correct. Thanks. -- 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

Re: [PATCH v7 09/38] lock_file(): always initialize and register lock_file object

Michael Haggerty mhag...@alum.mit.edu writes: Junio, if another reroll is not necessary, would you mind fixing this when applying? No, I wouldn't. -- 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

VERY IMPORTANT!

Greetings, I am Sir Koffi Agogo. I saw your profile on LinkedIn.com and decided to contact you. I have something very important to discuss with you. It is a vital detail that will help you. I have sent you an e-mail two days ago but have not received your reply. You should contact me by

Re: [PATCH v7 00/38] Lockfile correctness and refactoring

Overall I am very happy with this round ;-) Especially the last one, although I briefly debated myself if cache.h should include the new lockfile.h to reduce the churn, but I think that it is better without, so I like what you did there, too. Thanks. -- To unsubscribe from this list: send the

Re: [PATCH 1/3] fdopen_lock_file(): access a lockfile using stdio

Jeff King p...@peff.net writes: On Wed, Oct 01, 2014 at 01:14:47PM +0200, Michael Haggerty wrote: ... If using stdio on lockfiles becomes more popular, we might want to add some helper functions to make it a bit more convenient. I think it makes sense to wait until we see more potential

Re: Can you git clone -partial? I am looking to make a mobile app and it would be nice to have.

I see what you are saying with the file thing. I am not a git master and I am afraid that is showing in the words I use... The app I want to build is actually part of testing a Mobile Markdown Editor I am working on. I thought a good way to prove the system would be to make a simple app that

Concurrent fetches and pushes

Are concurrent pushes and fetches to the same repository via HTTP supported? Considering this architecture: git --(smart HTTP protocol)-- apache - git-http-backend git version is 2.1.1 on client and server. Multiple clients are fetching from and pushing to the same repositories, sometimes

Kedves Email felhasználói;

-- Kedves Email felhasználói; Túllépte a határt 23.432 tárolása az e-postafiók beállítva a WEB SERVICE / Administrator, és akkor problémái küldött és a bejövő üzenetek, amíg meg újból érvényesíti az e-mail címét. A szükséges eljárások nyújtottak be az alábbi a véleménye, ellenőrizze kattintva

Re: $GIT_CONFIG should either apply to all commands, or none at all

Hi, Frédéric Brière wrote[1]: This kind of stuff caused me a lot of hair-pulling: $ git config core.abbrev 32 git log --pretty=oneline --abbrev-commit 89be foo Here's the source of the discrepancy: $ grep abbrev $GIT_CONFIG .git/config git.conf: abbrev=32 .git/config:

[PATCH v22 0/24] rs/ref-transaction

Jonathan Nieder wrote: Jonathan Nieder wrote: The next series from Ronnie's collection is available at https://code-review.googlesource.com/#/q/topic:ref-transaction in case someone wants a fresh series to look at. Here is the outcome of that review. It could use another set of eyes

[PATCH 01/24] mv test: recreate mod/ directory instead of relying on stale copy

Date: Wed, 10 Sep 2014 14:01:46 -0700 The tests for 'git mv moves a submodule' functionality often run commands like git mv sub mod/sub to move a submodule into a subdirectory. Just like plain /bin/mv, this is supposed to succeed if the mod/ parent directory exists and fail if it

[PATCH 02/24] wrapper.c: remove/unlink_or_warn: simplify, treat ENOENT as success

From: Ronnie Sahlberg sahlb...@google.com Date: Wed, 16 Jul 2014 11:01:18 -0700 Simplify the function warn_if_unremovable slightly. Additionally, change behaviour slightly. If we failed to remove the object because the object does not exist, we can still return success back to the caller since

[PATCH 03/24] wrapper.c: add a new function unlink_or_msg

From: Ronnie Sahlberg sahlb...@google.com Date: Wed, 16 Jul 2014 11:20:36 -0700 This behaves like unlink_or_warn except that on failure it writes the message to its 'err' argument, which the caller can display in an appropriate way or ignore. Signed-off-by: Ronnie Sahlberg sahlb...@google.com

[PATCH 04/24] refs.c: add an err argument to delete_ref_loose

From: Ronnie Sahlberg sahlb...@google.com Date: Thu, 15 May 2014 08:25:23 -0700 Add an err argument to delete_loose_ref so that we can pass a descriptive error string back to the caller. Pass the err argument from transaction commit to this function so that transaction users will have a nice

[PATCH 06/24] rename_ref: don't ask read_ref_full where the ref came from

From: Ronnie Sahlberg sahlb...@google.com Date: Wed, 30 Apr 2014 12:41:04 -0700 We call read_ref_full with a pointer to flags from rename_ref but since we never actually use the returned flags we can just pass NULL here instead. Signed-off-by: Ronnie Sahlberg sahlb...@google.com Signed-off-by:

[PATCH 05/24] refs.c: pass the ref log message to _create/delete/update instead of _commit

From: Ronnie Sahlberg sahlb...@google.com Date: Wed, 30 Apr 2014 12:22:42 -0700 Change the ref transaction API so that we pass the reflog message to the create/delete/update functions instead of to ref_transaction_commit. This allows different reflog messages for each ref update in a multi-ref

[PATCH 07/24] refs.c: refuse to lock badly named refs in lock_ref_sha1_basic

From: Ronnie Sahlberg sahlb...@google.com Date: Thu, 1 May 2014 10:40:10 -0700 Move the check for check_refname_format from lock_any_ref_for_update to lock_ref_sha1_basic. At some later stage we will get rid of lock_any_ref_for_update completely. This has no visible impact to callers except for

[PATCH 08/24] refs.c: call lock_ref_sha1_basic directly from commit

From: Ronnie Sahlberg sahlb...@google.com Date: Thu, 1 May 2014 10:43:39 -0700 Skip using the lock_any_ref_for_update wrapper and call lock_ref_sha1_basic directly from the commit function. Signed-off-by: Ronnie Sahlberg sahlb...@google.com Signed-off-by: Jonathan Nieder jrnie...@gmail.com

[PATCH 09/24] refs.c: pass a list of names to skip to is_refname_available

From: Ronnie Sahlberg sahlb...@google.com Date: Thu, 1 May 2014 11:16:07 -0700 Change is_refname_available to take a list of strings to exclude when checking for conflicts instead of just one single name. We can already exclude a single name for the sake of renames. This generalizes that support.

[PATCH 10/24] refs.c: ref_transaction_commit: distinguish name conflicts from other errors

From: Ronnie Sahlberg sahlb...@google.com Date: Fri, 16 May 2014 14:14:38 -0700 In _commit, ENOTDIR can happen in the call to lock_ref_sha1_basic, either when we lstat the new refname or if the name checking function reports that the same type of conflict happened. In both cases, it means that

[PATCH 11/24] fetch.c: change s_update_ref to use a ref transaction

From: Ronnie Sahlberg sahlb...@google.com Date: Mon, 28 Apr 2014 13:49:07 -0700 Change s_update_ref to use a ref transaction for the ref update. Signed-off-by: Ronnie Sahlberg sahlb...@google.com Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- Since v21: - tweaked handling of

[PATCH 12/24] refs.c: make write_ref_sha1 static

From: Ronnie Sahlberg sahlb...@google.com Date: Mon, 28 Apr 2014 15:36:58 -0700 No external users call write_ref_sha1 any more so let's declare it static. Signed-off-by: Ronnie Sahlberg sahlb...@google.com Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- Since v21: - punctuation fix in

[PATCH 14/24] reflog test: test interaction with detached HEAD

From: Junio C Hamano gits...@pobox.com A proposed patch produced broken HEAD reflog entries when checking out anything other than a branch. The testsuite still passed, so it took a few days for the bug to be noticed. Add tests checking the content of the reflog after detaching and reattaching

[PATCH 13/24] refs.c: change resolve_ref_unsafe reading argument to be a flags field

From: Ronnie Sahlberg sahlb...@google.com Date: Tue, 15 Jul 2014 12:59:36 -0700 resolve_ref_unsafe takes a boolean argument for reading (a nonexistent ref resolves successfully for writing but not for reading). Change this to be a flags field instead, and pass the new constant

[PATCH 15/24] branch -d: avoid repeated symref resolution

From: Jonathan Nieder jrnie...@gmail.com Date: Wed, 10 Sep 2014 18:22:48 -0700 If a repository gets in a broken state with too much symref nesting, it cannot be repaired with git branch -d: $ git symbolic-ref refs/heads/nonsense refs/heads/nonsense $ git branch -d nonsense error: branch

[PATCH 16/24] branch -d: simplify by using RESOLVE_REF_READING flag

From: Ronnie Sahlberg sahlb...@google.com Date: Thu, 11 Sep 2014 10:34:36 -0700 When git branch -d reads the branch it is about to delete, it used to avoid passing the RESOLVE_REF_READING ('treat missing ref as error') flag because a symref pointing to a nonexistent ref would show up as missing

[PATCH 17/24] packed-ref cache: forbid dot-components in refnames

Since v1.7.9-rc1~10^2 (write_head_info(): handle extra refs locally, 2012-01-06), this trick to keep track of .have refs that are only valid on the wire and not on the filesystem is not needed any more. Simplify by removing support for the REFNAME_DOT_COMPONENT flag. This means we'll be slightly

[PATCH 18/24] test: put tests for handling of bad ref names in one place

From: Ronnie Sahlberg sahlb...@google.com There's no straightforward way to grep for all tests dealing with invalid refs. Put them in a single test script so it is easy to see what functionality has not been exercised with bad ref names yet. Signed-off-by: Ronnie Sahlberg sahlb...@google.com

[PATCH 19/24] refs.c: allow listing and deleting badly named refs

From: Ronnie Sahlberg sahlb...@google.com Date: Wed, 3 Sep 2014 11:45:43 -0700 We currently do not handle badly named refs well: $ cp .git/refs/heads/master .git/refs/heads/master.@\*@\\. $ git branch fatal: Reference has invalid format: 'refs/heads/master.@*@\.' $ git branch

[PATCH 20/24] for-each-ref.c: improve message before aborting on broken ref

From: Ronnie Sahlberg sahlb...@google.com Date: Fri, 5 Sep 2014 14:35:17 -0700 Print a warning message for any badly named refs we find in the repo. Signed-off-by: Ronnie Sahlberg sahlb...@google.com Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- As before. builtin/for-each-ref.c | 5

  1   2   >