into account in the future.
Thanks,
Michael
[1] Of course, if a patch series has to grow to make the *existing*
changes correct, then that's perfectly OK.
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body
,
+const unsigned char *new_sha1,
+const unsigned char *old_sha1,
+int flags, int have_old);
/*
* Add a reference creation to transaction. new_sha1 is the value
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
- add_to_ref_list(sha1, buf.buf + 41,
header-references);
+ add_to_ref_list(sha1, buf.buf + 41,
header-references);
I think that 41 here is GIT_OID_HEXSZ + 1.
[...]
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com
* rewriting code that works with it.
[...]
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
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
(but not all!) of
the literal constants that are derived from GIT_OID_RAWSZ and GIT_OID_HEXSZ.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
systematically looking for other literal constants that should be
derived from GIT_OID_RAWSZ and GIT_OID_HEXSZ) and, aside from the
problems that I already noted, they looked OK to me.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list
at the command line by
the time we implement pluggable reference backends.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info
*);
+
/* iterate over reflog entries */
typedef int each_reflog_ent_fn(unsigned char *osha1, unsigned char *nsha1,
const char *, unsigned long, int, const char *, void *);
int for_each_reflog_ent(const char *refname, each_reflog_ent_fn fn, void
*cb_data);
Thanks!
Michael
--
Michael Haggerty
On 05/06/2014 08:40 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
It would be pretty annoying to spend a lot of time fetching a big pack,
only to have the fetch fail because one reference out of many couldn't
be updated. This would force the user to download
deletions(-)
+1 Looks good to me. Thanks!
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
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
On 05/09/2014 02:58 AM, Felipe Contreras wrote:
No tests. No chance of ever graduating.
Already out-of-tree.
Cc: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Thank you for your input.
git-multimail is maintained outside of the Git
On 05/09/2014 05:04 PM, David Kastrup wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
On 05/09/2014 02:58 AM, Felipe Contreras wrote:
No tests. No chance of ever graduating.
Already out-of-tree.
Cc: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Felipe Contreras felipe.contre
heart I truly wish you the best in your future endeavors.
Michael
[1] http://article.gmane.org/gmane.comp.version-control.git/227750
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
On 05/12/2014 12:37 PM, Felipe Contreras wrote:
Michael Haggerty wrote:
On 05/12/2014 01:34 AM, Felipe Contreras wrote:
Recently Junio said he was willing to hear the opinion of other people
regarding the move from contrib to the core[1]. This move is already
under way, but suddenly Junio
On 05/12/2014 02:29 PM, Felipe Contreras wrote:
Michael Haggerty wrote:
[...]
2. Moving git-remote-hg into the core would require you to continue your
presence on the Git mailing list.
That is another red herring. Moving them back to the contrib/ area which
is what Junio proposed would
it would be a net win in terms of boilerplate?
if (force !is_null_sha1(prev) hashcmp(prev, object))
printf(_(Updated tag '%s' (was %s)\n), tag,
find_unique_abbrev(prev, DEFAULT_ABBREV));
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com
);
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
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
)
error(_(some local refs could not be updated; try running\n
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
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
On 05/17/2014 05:05 PM, Michael Haggerty wrote:
On 05/16/2014 07:37 PM, Ronnie Sahlberg wrote:
[...]
disk and thus we would not return STORE_REF_ERROR_DF_CONFLICT for this case.
I think this new behaviour is more correct, since if there was a problem
we would not even try to commit
going to have to stop here. FWIW
patches 01-23 looked OK aside from the comments that I have made.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
layer of abstraction
based on the commit object produced by the existing commit parser?
E.g., edit the object it produces, and write the result? Or create a
new commit object out of the parsed commit object and write that?
It's great that you're working on this!
Michael
--
Michael Haggerty
mhag
GIF here [1] :-)
Michael
[1] https://github.com/blog/1691-michael-haggerty-is-a-githubber
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
and reflogs
are stored by the filesystem backend and just grabs at the files rather
than accessing the references using git commands. It will take some
work to clean this up.
[2] http://thread.gmane.org/gmane.comp.version-control.git/243726
--
Michael Haggerty
mhag...@alum.mit.edu
the picked commit which alters that
information. squash and fixup still do not accept user options as the
interplay of `--reset-author` and the author script are yet to be
determined.
[...]
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
To unsubscribe from this list: send the line
On 07/15/2014 10:58 PM, Ronnie Sahlberg wrote:
On Tue, Jul 15, 2014 at 12:34 PM, Ronnie Sahlberg sahlb...@google.com wrote:
On Tue, Jul 15, 2014 at 11:04 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Michael Haggerty wrote:
So...I like the idea of enforcing refname checks at the lowest level
On 08/20/2014 06:28 PM, Ronnie Sahlberg wrote:
On Wed, Aug 20, 2014 at 7:52 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
I'm a little worried that abandoning *all* refname checks could open us
up to somehow trying to delete a reference with a name like
../../../../etc/passwd. Either
On 08/20/2014 09:45 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
I think we can get away with not including broken refnames when
iterating. After all, the main goal of tolerating them is to let them
be deleted, right?
Or read from a ref whose name has
an
alternative would be to do some minimal checks in any case, but make it
possible to turn off the stricter checks (those that mostly exist to
make reference expression parsing possible) when necessary.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
To unsubscribe from this list: send the line
the chance to
rename the local variable ref_name to refname to be consistent with most
of our code, but this is by no means required.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
to be transient).
[...]
I like the idea. I would use this setting on all my repos (information
packrat that I am).
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
to mailing list was a bit awkward.
So, overall I found it pleasant and efficient to review patches in
Gerrit. I would welcome more such experiments. It would have been even
better if Gerrit would generate more useful notification emails.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
() but then store a pointer to the naked string in struct
lock_file. But lock_file objects are often reused. By reusing the
same strbuf, we can avoid having to reallocate the string most times
when a lock_file object is reused.
Helped-by: Torsten Bögershausen tbo...@web.de
Signed-off-by: Michael Haggerty mhag
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 8a63073
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
with.)
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/commit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index a3eaf4b..046be7e 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -315,8 +315,8 @@ static void
without volatile in the filename
case.
Suggested-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
cache.h| 6 +++---
lockfile.c | 2 +-
refs.c | 5 +++--
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/cache.h b/cache.h
index e739482
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
that the lock_file object really is locked.
Helped-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/technical/api-lockfile.txt | 4 +++-
lockfile.c | 3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git
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
-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 983c3ec..00c972c 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -129,6 +129,22 @@ static int lock_file(struct lock_file *lk
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 mhag
. Rename the function accordingly.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 38 --
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index d78b6bf..4c6e720 100644
--- a/lockfile.c
+++ b/lockfile.c
functions, and call it from both
commit_lock_file() and commit_locked_index().
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/technical/api-lockfile.txt | 14 ++
cache.h | 1 +
lockfile.c | 30
series.
[1] http://thread.gmane.org/gmane.comp.version-control.git/245609
[2] http://thread.gmane.org/gmane.comp.version-control.git/245801
[3] http://thread.gmane.org/gmane.comp.version-control.git/246222
Michael Haggerty (32):
unable_to_lock_die(): rename function from unable_to_lock_index_die
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 insertions
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
, unlocked). Previously, the lockfile was
retained until process cleanup in this situation.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lockfile.c b/lockfile.c
index b1c4ba0..d4f165d 100644
--- a/lockfile.c
+++ b
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 b/fast
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
that it is a NOOP.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/technical/api-lockfile.txt | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/Documentation/technical/api-lockfile.txt
b/Documentation/technical/api-lockfile.txt
index 9a94ead..2514559
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
the
inner definition.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/merge.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index ce82eb2..0f5c185 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -669,7 +669,6 @@ static int
for
this purpose. Be careful to set this field only when filename really
contains the name of a file that should be deleted on cleanup.
Helped-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
cache.h | 1 +
lockfile.c | 45
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
...@gmail.com
Helped-by: Ramsay Jones ram...@ramsay1.demon.co.uk
Helped-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Adapted-by: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c| 14
)
{
if (fsync(fd) 0) {
Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
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
On 09/10/2014 12:39 AM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
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
On 09/10/2014 12:41 AM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
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.
Same comment as 06/32 applies here
in this message.
This is an interesting idea.
I wouldn't trust git to handle efficiently commits with thousands of
parents, but it would be easy to knit a huge number of tips together
using multiple layers of, say, 16-parent octopus merges.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
for various reasons (e.g., who is
referencing this object?).
[...]
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
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
On 09/07/2014 04:21 PM, Torsten Bögershausen wrote:
On 2014-09-06 09.50, Michael Haggerty wrote:
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.
No problem with the delay.
The most important
-transaction code is, I think, moving in the direction of
updating all references in a single transaction. This means that we
would need to hold locks for all of the references at once anyway. So it
might be all for naught.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
To unsubscribe from
On 09/12/2014 12:15 AM, Ronnie Sahlberg wrote:
On Sat, Sep 6, 2014 at 12:50 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
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
wouldn't
be deterred for long by not seeing a symbolic constant for the suffix
length. So if it's OK with you I'll leave the constant.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
for me. I really hope to get through the third
series by the end of next week.
so I'll send a reroll of the series as-is in an hour or so.
Jonathan: Is a current version of this patch series set up for review in
Gerrit?
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
To unsubscribe from
On 09/13/2014 09:41 AM, Johannes Sixt wrote:
Am 06.09.2014 um 09:50 schrieb Michael Haggerty:
It's bad manners. Especially since, if unlink_or_warn() failed, the
memory wasn't restored to its original contents.
I do not see how the old code did not restore the file name. Except
On 09/14/2014 08:27 AM, Michael Haggerty wrote:
On 09/13/2014 09:41 AM, Johannes Sixt wrote:
Am 06.09.2014 um 09:50 schrieb Michael Haggerty:
It's bad manners. Especially since, if unlink_or_warn() failed, the
memory wasn't restored to its original contents.
I do not see how the old code
to get rid of the broken reference once it is discovered (short of
opening packed-refs in an editor).
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info
would pass up an
opportunity to delete unneeded cruft from the packed-refs file. But I
can't think of a rational reason to disagree with you, so as far as I'm
concerned your suggestion seems OK.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
To unsubscribe from this list: send the line
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
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
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
. Rename the function accordingly and a bit less tersely.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 38 --
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index e689a84..3d5ab4f 100644
with.)
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/commit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 41f481b..d4228c9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -315,8 +315,8 @@ static void
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
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 b/fast
that the lock_file object really is locked.
Helped-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/technical/api-lockfile.txt | 4 +++-
lockfile.c | 3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git
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
inner definition.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/merge.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 9da9e30..6b430f0 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -668,7 +668,6 @@ static int
for
this purpose. Be careful to set this field only when filename really
contains the name of a file that should be deleted on cleanup.
Helped-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
cache.h | 1 +
lockfile.c | 47
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
---
Documentation/technical
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
---
builtin/update-index.c | 2 +-
cache.h| 2
] http://thread.gmane.org/gmane.comp.version-control.git/256564
Michael Haggerty (35):
unable_to_lock_die(): rename function from unable_to_lock_index_die()
api-lockfile: expand the documentation
rollback_lock_file(): do not clear filename redundantly
rollback_lock_file(): exit early if lock
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 insertions
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
Eliminate a layer of nesting.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Ronnie Sahlberg sahlb...@google.com
---
lockfile.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index a548e08..49179d8 100644
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
---
lockfile.c | 23 +++
1 file changed, 11 insertions(+), 12
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
---
lockfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lockfile.c b
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
401 - 500 of 3087 matches
Mail list logo
