Bug-directors upper letters names.

Hello, My name is Mateusz Maciołek, I am a mobile developer and I am using yours tool in my all projects. Last days I found special case. A changed packages name (all letter to lowercase). After merge with other branch there were still uppercase letters.All the rest code is after refactoring. Is

Re: [RFC PATCHv3 1/4] am: avoid re-directing stdin twice

Stephen Boyd bebar...@gmail.com writes: I see Stephen who wrote the original Thunderbird save-as is already on the Cc list. How about doing it this way instead? It was so long ago I can't even remember writing that patch. But I googled the thread from 4.5 years ago and I see that you

[PATCH v4 28/32] 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 v4 13/32] write_packed_entry_fn(): convert cb_data into a (const int *)

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 --- refs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs.c b/refs.c index

[PATCH v4 26/32] 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 v4 12/32] 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 v4 24/32] 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 v4 01/32] 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 --- builtin/update-index.c | 2 +- cache.h| 2 +- lockfile.c | 6 +++--- refs.c

[PATCH v4 17/32] 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 v4 07/32] 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 --- lockfile.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v4 05/32] 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. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- lockfile.c |

[PATCH v4 08/32] lock_file(): always add lock_file object to lock_file_list

It used to be that if locking failed, lock_file() usually did not register the lock_file object in lock_file_list but sometimes it did. This confusion was compounded if lock_file() was called via hold_lock_file_for_append(), which has its own failure modes. The ambiguity didn't have any ill

[PATCH v4 30/32] 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. Signed-off-by: Michael Haggerty

[PATCH v4 31/32] trim_last_path_elm(): 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 v4 32/32] 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 v4 00/32] Lockfile correctness and refactoring

Sorry for the long delay since v3. This version mostly cleans up a couple more places where the lockfile object was left in an ill-defined state. Thanks to Johannes Sixt and Torsten Bögershausen for their review of v3. I believe that this series addresses all of the comments from v1 [1], v2 [2],

[PATCH v4 02/32] api-lockfile: 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(). Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/technical/api-lockfile.txt | 36 +--- 1 file changed, 33

[PATCH v4 03/32] 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 --- lockfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lockfile.c b/lockfile.c index f1ce154..a548e08 100644 --- a/lockfile.c

[PATCH v4 06/32] 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 v4 11/32] delete_ref_loose(): don't muck around in the lock_file's filename

It's bad manners. Especially since, if unlink_or_warn() failed, the memory wasn't restored to its original contents. So make our own copy to work with. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- refs.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff

[PATCH v4 09/32] 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 --- lockfile.c | 52 1 file changed, 52 insertions(+) diff

[PATCH v4 14/32] 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 --- lockfile.c | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/lockfile.c b/lockfile.c

[PATCH v4 04/32] rollback_lock_file(): exit early if lock is not active

Eliminate a layer of nesting. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- lockfile.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/lockfile.c b/lockfile.c index a548e08..49179d8 100644 --- a/lockfile.c +++ b/lockfile.c @@ -272,10 +272,11 @@ int

[PATCH v4 10/32] 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 v4 19/32] 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 | 18 +++--- 1

[PATCH v4 21/32] 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 --- fast-import.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fast-import.c

[PATCH v4 27/32] 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 | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/lockfile.c b/lockfile.c index f51f73f..f6b3866 100644

[PATCH v4 18/32] commit_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 leaves the lock_file object in a defined state in this error path (namely, unlocked). Signed-off-by: Michael Haggerty mhag...@alum.mit.edu

[PATCH v4 20/32] 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 v4 15/32] remove_lock_file(): call rollback_lock_file()

It does just what we need. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- lockfile.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/lockfile.c b/lockfile.c index 71786c9..dacfc28 100644 --- a/lockfile.c +++ b/lockfile.c @@ -63,12 +63,8 @@ static void

[PATCH v4 16/32] 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 dacfc28..d64cf6b 100644 --- a/lockfile.c +++ b/lockfile.c @@ -306,12 +306,14 @@ int reopen_lock_file(struct lock_file *lk)

[PATCH v4 22/32] 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 | 14 +++--- 1 file changed, 7

[PATCH v4 25/32] 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 v4 23/32] 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 v4 29/32] 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 v4 0/1] Use absolute paths of lockfiles

This patch applies on top of the patch series that I just sent [1]: Lockfile correctness and refactoring, v4 It has the same effect as Duy's [2] Keep .lock file paths absolute, v3 except that my patch series obviates the need for his patches 1/3 and 2/3. So only one patch remains, the

[PATCH v4 1/1] lockfile.c: store absolute path

From: Nguyễn Thái Ngọc Duy pclo...@gmail.com Locked paths can be saved in a linked list so that if something wrong happens, *.lock are removed. For relative paths, this works fine if we keep cwd the same, which is true 99% of time except: - update-index and read-tree hold the lock on

Re: [RFC PATCHv3 1/4] am: avoid re-directing stdin twice

On 2014-09-06 09.34, Junio C Hamano wrote: Stephen Boyd bebar...@gmail.com writes: I see Stephen who wrote the original Thunderbird save-as is already on the Cc list. How about doing it this way instead? It was so long ago I can't even remember writing that patch. But I googled the thread

Re: [PATCH v4 0/1] Use absolute paths of lockfiles

On Sat, Sep 6, 2014 at 5:31 PM, Michael Haggerty mhag...@alum.mit.edu wrote: So I've shamelessly labeled this v4 of his patch series and I've left Duy as the author, because his commit message (which I used directly) has far more intellectual content than the code change. Duy, if that's not OK

Re: Bug-directors upper letters names.

On 2014-09-06 08.05, Mateusz M wrote: Last days I found special case. A changed packages name (all letter to lowercase). After merge with other branch there were still uppercase letters.All the rest code is after refactoring. Is it a bug ? Unless you provide more information what had been

Re: [PATCH v2 7/8] name-hash: allow dir hashing even when !ignore_case

Eric Sunshine sunsh...@sunshineco.com writes: On Sat, Feb 22, 2014 at 4:17 AM, Thomas Rast t...@thomasrast.ch wrote: -static void lazy_init_name_hash(struct index_state *istate) +void init_name_hash(struct index_state *istate, int force_dir_hash) { int nr; if

[PATCH v3 0/8] --remerge-diff

This is a resend of the remerge-diff patch series, previously posted here: http://thread.gmane.org/gmane.comp.version-control.git/242514 Differences to the previous version: - Rebased onto the new {name,dir}_hash maps (7/8 looks very different now). This also allows freeing index entries

[PATCH v3 1/8] merge-recursive: remove dead conditional in update_stages()

From: Thomas Rast tr...@inf.ethz.ch 650467c (merge-recursive: Consolidate different update_stages functions, 2011-08-11) changed the former argument 'clear' to always be true. Remove the useless conditional. Signed-off-by: Thomas Rast tr...@inf.ethz.ch Signed-off-by: Junio C Hamano

[PATCH v3 4/8] combine-diff: do not pass revs-dense_combined_merges redundantly

The existing code passed revs-dense_combined_merges along revs itself into the combine-diff functions, which is rather redundant. Remove the 'dense' argument until much further down the callchain to simplify callers. Note that while the caller in submodule.c needs to do extra work now, the next

[PATCH v3 2/8] merge-recursive: internal flag to avoid touching the worktree

From: Thomas Rast tr...@inf.ethz.ch o-call_depth has a double function: a nonzero call_depth means we want to construct virtual merge bases, but it also means we want to avoid touching the worktree. Introduce a new flag o-no_worktree to trigger only the latter. Signed-off-by: Thomas Rast

[PATCH v3 5/8] Fold all merge diff variants into an enum

The four ways of displaying merge diffs, * none: no diff * -m: against each parent * -c: combined * --cc: combined-condensed were encoded in three flag bits in struct rev_info. Fold them all into a single enum field that captures the variants. This makes it easier to add new merge diff

[PATCH v3 7/8] name-hash: allow dir hashing even when !ignore_case

The directory hash (for fast checks if the index already has a directory) was only used in ignore_case mode and so depended on that flag. Make it generally available on request. Signed-off-by: Thomas Rast t...@thomasrast.ch --- cache.h | 2 ++ name-hash.c | 13 - 2 files

[PATCH v3 6/8] merge-recursive: allow storing conflict hunks in index

Add a --conflicts-in-index option to merge-recursive, which instructs it to always store the 3-way merged result in the index. (Normally it only does so in recursive invocations, but not for the final result.) This serves as a building block for the remerge diff feature coming up in a subsequent

[PATCH v3 3/8] merge-recursive: -Xindex-only to leave worktree unchanged

From: Thomas Rast tr...@inf.ethz.ch Using the new no_worktree flag from the previous commit, we can teach merge-recursive to leave the worktree untouched. Expose this with a new strategy option so that scripts can use it. Signed-off-by: Junio C Hamano gits...@pobox.com ---

[PATCH v3 8/8] log --remerge-diff: show what the conflict resolution changed

Git has --cc as a very fast inspection tool that shows a brief summary of what a conflicted merge looks like, and -c/-m as give me the full information data dumps. But --cc actually loses information: if the merge lost(!) some changes from one side, that hunk would fully agree with the other

[RFC PATCH 1/2] Makefile: add check-headers target

This allows us to ensure that each header can be included individually without needing to include other headers first. Signed-off-by: David Aguilar dav...@gmail.com --- This patch demonstrates how to verify PATCH 2/2. Makefile | 6 ++ check-headers.sh | 26

[RFC PATCH 2/2] headers: include dependent headers

Add dependent headers so that including a header does not require including additional headers. This makes it so that gcc -c $header succeeds for each header. Signed-off-by: David Aguilar dav...@gmail.com --- This patch was prepared by using the check-headers target introduced by PATCH 1/2 to

trace.c, line 219: error: identifier redeclared: trace_strbuf

Build on Solaris 10 of latest git tarball fails thus : CC tag.o CC trace.o trace.c, line 219: error: identifier redeclared: trace_strbuf current : function(pointer to const char, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf})

Re: trace.c, line 219: error: identifier redeclared: trace_strbuf

Am 06.09.2014 um 21:26 schrieb dev: Build on Solaris 10 of latest git tarball fails thus : CC tag.o CC trace.o trace.c, line 219: error: identifier redeclared: trace_strbuf current : function(pointer to const char, pointer to const struct strbuf {unsigned long

Re: [RFC PATCH 1/2] Makefile: add check-headers target

Am 06.09.2014 um 21:20 schrieb David Aguilar: This allows us to ensure that each header can be included individually without needing to include other headers first. Sounds like a good objective. Signed-off-by: David Aguilar dav...@gmail.com --- This patch demonstrates how to verify PATCH

Re: [RFC PATCH 2/2] headers: include dependent headers

Am 06.09.2014 um 21:20 schrieb David Aguilar: Add dependent headers so that including a header does not require including additional headers. This makes it so that gcc -c $header succeeds for each header. Signed-off-by: David Aguilar dav...@gmail.com --- diff --git a/branch.h b/branch.h

Re: [RFC PATCH 1/2] Makefile: add check-headers target

On Sat, Sep 06, 2014 at 11:20:32PM +0200, René Scharfe wrote: Am 06.09.2014 um 21:20 schrieb David Aguilar: This allows us to ensure that each header can be included individually without needing to include other headers first. Sounds like a good objective. Signed-off-by: David Aguilar

Re: [RFC PATCH 1/2] Makefile: add check-headers target

On Sat, Sep 06, 2014 at 03:57:39PM -0700, David Aguilar wrote: This checks all .h files in the top directory. Would it be better to check all files in LIB_H instead? Or even all .h files in the tree (using git ls-files '*.h')? The latter might be difficult because some of the files in

Re: [RFC PATCH 1/2] Makefile: add check-headers target

On Sat, Sep 06, 2014 at 07:58:09PM -0400, Jeff King wrote: On Sat, Sep 06, 2014 at 03:57:39PM -0700, David Aguilar wrote: This checks all .h files in the top directory. Would it be better to check all files in LIB_H instead? Or even all .h files in the tree (using git ls-files

[RFC PATCH v2 1/2] Makefile: add check-headers target

This allows us to ensure that each header can be included individually without needing to include other headers first. Signed-off-by: David Aguilar dav...@gmail.com --- Changes since v1: We now include xdiff, ewah, and vcs-svn headers. Makefile | 6 ++ check-headers.sh | 29

[RFC PATCH v2 2/2] headers: include dependent headers

Add dependent headers so that including a header does not require including additional headers. This makes it so that gcc -c $header succeeds for each header. Signed-off-by: David Aguilar dav...@gmail.com --- Addresses René's note to not include strbuf.h when cache.h is already included.

Same Last Name

A client of mine, that shares the same last name as yours,died without a next of kin ($16,M in my Branch.)More Details.reply: drhraymo...@yahoo.com.hk -- 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