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
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
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
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
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
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.)
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
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
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
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
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 |
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
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
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.
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
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],
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
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
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,
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
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
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
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
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
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
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
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
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
* 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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
---
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
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
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
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})
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
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
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
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
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
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
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
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.
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
62 matches
Mail list logo