On 04/01/2014 05:58 PM, Michael Haggerty wrote:
Reduce the amount of code that has to know about the lock_file's
filename field.
Signed-off-by: Michael Haggerty
---
config.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/config.c b/config.c
index 6821cef..1ea3
On Wed, Apr 02, 2014 at 08:52:17AM +0200, Torsten Bögershausen wrote:
> + /*
> + * loose. The loose file name is the same as the
> + * lockfile name, minus ".lock":
> + */
> + char *loose_filename = xmemdupz(lock->lk->filename,
> +
[]
diff --git a/refs.c b/refs.c
index 28d5eca..11ad23e 100644
--- a/refs.c
+++ b/refs.c
@@ -2485,12 +2485,14 @@ static int repack_without_ref(const char *refname)
static int delete_ref_loose(struct ref_lock *lock, int flag)
{
if (!(flag & REF_ISPACKED) || flag & REF_ISSYMREF) {
-
[]
diff --git a/lockfile.c b/lockfile.c
index c1af65b..1928e5e 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -148,9 +148,11 @@ static int lock_file(struct lock_file *lk, const char
*path, int flags)
lock_file_list = lk;
lk->on_list = 1;
When we are sending a packfile to a remote, we currently try
to reuse a whole chunk of packfile without bothering to look
at the individual objects. This can make things like initial
clones much lighter on the server, as we can just dump the
packfile bytes.
However, it's possible that the other si
On Wed, Apr 2, 2014 at 12:54 AM, Junio C Hamano wrote:
>
>> +test_expect_success '--trim-empty without config' '
>> + cat >expected <<-\EOF &&
>> + ack: Peff
>> + Acked-by: Johan
>> + EOF
>> + git interpret-trailers --trim-empty "ack = Peff" "Reviewed-by"
>> "A
Hi,
On Wed, Apr 2, 2014 at 2:39 AM, Jonathan Nieder wrote:
> (culling cc list)
> Hi,
>
> Christian Couder wrote:
>
>> [Subject: Documentation: add documentation for 'git interpret-trailers']
>>
>> Signed-off-by: Christian Couder
>
> This should be squashed into the patch that introduces the
> in
On 04/01/2014 09:53 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> This is consistent with the usual nomenclature.
>
> I am of two minds.
>
> Looking for "\(\.\|->\)ref_name" used to ignore refname fields of
> other structures and let us focus on the ref_update structure. Yes,
> the
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> I haven't reverted the merge of that "submodule update" topic yet; I
>> should do that soonish.
>> ...
>
> Sigh... This is giving me a lot of headache.
>
> As 23d25e48 (submodule: explicit local branch creation in
> module_clone, 2014-01-26)
On 04/01/2014 09:46 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> This change is mostly clerical: the parse_cmd_*() functions need to
>> use local variables rather than a struct ref_update to collect the
>> arguments needed for each update, and then call ref_transaction_*() to
>> queu
On 04/01/2014 09:39 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Build out the API for dealing with a bunch of reference checks and
>> changes within a transaction. Define an opaque ref_transaction type
>> that is managed entirely within refs.c. Introduce functions for
>> beginning
On Wed, Apr 02, 2014 at 01:29:13AM +0200, Max Horn wrote:
>
> On 01.04.2014, at 15:15, Jeff King wrote:
>
> > On Tue, Apr 01, 2014 at 10:07:03PM +0900, Mike Hommey wrote:
> >
> >>> For my own curiosity, how does this differ from what is in
> >>> contrib/remote-helpers/git-remote-hg?
> >>
> >>
(culling cc list)
Hi,
Christian Couder wrote:
> [Subject: Documentation: add documentation for 'git interpret-trailers']
>
> Signed-off-by: Christian Couder
This should be squashed into the patch that introduces the
interpret-trailers command, IMHO (or if it should be reviewed
separately, it ca
On Wed, Apr 2, 2014 at 2:17 AM, Junio C Hamano wrote:
>> Unfortunately, this multiple checkout thing conflicts with how I
>> use emacs (--daemon) so I'm not one of its heavy users either. I
>> only occastionally make new, short-lived checkouts to test things.
>
> FWIW, I do keep a permanent multi-
On 01.04.2014, at 15:15, Jeff King wrote:
> On Tue, Apr 01, 2014 at 10:07:03PM +0900, Mike Hommey wrote:
>
>>> For my own curiosity, how does this differ from what is in
>>> contrib/remote-helpers/git-remote-hg?
>>
>> contrib/remote-helpers/git-remote-hg does a local mercurial clone before
>>
On Tue, Apr 01, 2014 at 03:32:49PM -0700, Junio C Hamano wrote:
> [Footnote]
>
> *1* I am still not sure how useful the feature would be outside
> slurping from Hg and Git---for obvious reasons, though. As long as
> the change is to a cleanly isolated codepath, it would be OK, I
> guess.
That's
On Apr 1, 2014, at 2:37 PM, Junio C Hamano wrote:
>> D Mdeleted from index
>
> I doubt this is possible in practice ...
>
>> D Dunmerged, both deleted
>> A Uunmerged, added by us
>> U Aunmerged, added by them
>
> ... you would not see t
Christian Couder writes:
> +test_expect_success '--trim-empty without config' '
> + cat >expected <<-\EOF &&
> + ack: Peff
> + Acked-by: Johan
> + EOF
> + git interpret-trailers --trim-empty "ack = Peff" "Reviewed-by"
> "Acked-by: Johan" "sob:" >actual &&
> +
Junio C Hamano writes:
> Christian Couder writes:
>
>> +test_expect_success '--trim-empty without config' '
>> +cat >expected <<-\EOF &&
>> +ack: Peff
>> +Acked-by: Johan
>> +EOF
>> +git interpret-trailers --trim-empty "ack = Peff" "Reviewed-by"
>> "Acked-by:
Mike Hommey writes:
> On Tue, Apr 01, 2014 at 10:14:02AM -0700, Junio C Hamano wrote:
> ...
>> Unless you already have your change in the xdelta on hand, or the
>> format your foreign change is in gives sufficient information to
>> produce a corresponding xdelta without looking at the content tha
Michael Toy wrote:
> https://gist.github.com/the-michael-toy/9907309
Two nits:
- Please use --porcelain (implied by -z in the absence of another
format option) instead of --short. --short is meant to be human
readable and details of the output might change some day.
- Depending on what
On Tue, Apr 01, 2014 at 10:14:02AM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > On Tue, Apr 01, 2014 at 09:15:12AM -0400, Jeff King wrote:
> >> > It seems to me fast-import keeps a kind of human readable format for its
> >> > protocol, i wonder if xdelta format would fit the bill. Tha
Junio C Hamano writes:
> I haven't reverted the merge of that "submodule update" topic yet; I
> should do that soonish.
> ...
Sigh... This is giving me a lot of headache.
As 23d25e48 (submodule: explicit local branch creation in
module_clone, 2014-01-26) has been in 'master' since fairly early
On 1. 4. 2014 22:23, Jens Lehmann wrote:
> Am 01.04.2014 01:35, schrieb Ronald Weiss:
>> On 1. 4. 2014 0:50, Ronald Weiss wrote:
>>> On 31. 3. 2014 23:47, Ronald Weiss wrote:
On Mon, Mar 31, 2014 at 8:58 PM, Jens Lehmann wrote:
> As Junio mentioned it would be great if you could teach the
Michael Toy writes:
> Of the 24 possibilities (not counting ignored) in git-status,
> there are 7 that I can't figure out how to generate.
As the post [*1*] that triggered e92e9cd3 (Documentation
improvements for the description of short format., 2010-04-23),
which is where the bulk of the forma
On Tue, Apr 01, 2014 at 11:17:14PM +0200, René Scharfe wrote:
> >So are you saying we should set EOVERFLOW ourselves, or does FreeBSD
> >set EOVERFLOW for us in this case and we do not have to worry?
>
> If we correct the return value then we should correct errno as well.
> gmtime() on FreeBSD 10
Am 01.04.2014 21:08, schrieb Junio C Hamano:
René Scharfe writes:
Am 01.04.2014 09:42, schrieb Jeff King:
diff --git a/compat/gmtime.c b/compat/gmtime.c
new file mode 100644
index 000..ffcabf4
--- /dev/null
+++ b/compat/gmtime.c
@@ -0,0 +1,26 @@
+#include "../git-compat-util.h"
+#undef gm
On Tue, Apr 01, 2014 at 05:58:08PM +0200, Michael Haggerty wrote:
> I've had this patch series kicking around for a long time, along with
> some followup patches to fix a race in reference deletion. I haven't
> had the time to get everything done and tested, but let me at least
> push this first
On Tue, Apr 01, 2014 at 05:58:30PM +0200, Michael Haggerty wrote:
> Add a new option flag, LOCK_SEPARATE_STAGING_FILE, that can be passed
> to hold_lock_file_for_update() or hold_lock_file_for_append() to use a
> staging file that is independent of the lock file.
>
> Add a new function activate_s
On Tue, Apr 01, 2014 at 05:58:22PM +0200, Michael Haggerty wrote:
> /*
> - * p = path that may be a symlink
> - * s = full size of p
> - *
> - * If p is a symlink, attempt to overwrite p with a path to the real
> - * file or directory (which may or may not exist), following a chain of
> - * symli
Am 01.04.2014 01:35, schrieb Ronald Weiss:
> On 1. 4. 2014 0:50, Ronald Weiss wrote:
>> On 31. 3. 2014 23:47, Ronald Weiss wrote:
>>> On Mon, Mar 31, 2014 at 8:58 PM, Jens Lehmann wrote:
As Junio mentioned it would be great if you could teach the add
command also honor the --ignore-submo
On Tue, Apr 01, 2014 at 05:58:20PM +0200, Michael Haggerty wrote:
> 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.
Sounds good...
> if (!(flag & REF_ISPACKED) || flag & REF_ISSY
On Tue, Apr 01, 2014 at 05:58:17PM +0200, Michael Haggerty wrote:
> +unable_to_lock_error::
> +
> + Emit an error describing that there was an error locking the
> + specified path. The err parameter should be the errno of the
> + problem that caused the failure.
> +
> +unable_to_lock_
On Tue, Apr 01, 2014 at 05:58:15PM +0200, Michael Haggerty wrote:
> diff --git a/lockfile.c b/lockfile.c
> index e679e4c..c989f6c 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -130,6 +130,22 @@ static int lock_file(struct lock_file *lk, const char
> *path, int flags)
>*/
> stati
I also have this question posted to stack overflow (
http://stackoverflow.com/questions/22792906/how-do-i-produce-every-possible-git-status
), but perhaps this is a better place to ask this question.
In working on some code which provides an interface to existing git
repositories the question I
On Tue, Apr 01, 2014 at 04:02:42PM -0400, Jeff King wrote:
> On Tue, Apr 01, 2014 at 05:58:13PM +0200, Michael Haggerty wrote:
>
> > 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 b
Michael Haggerty writes:
> This is temporary space for ref_transaction_commit().
>
> Signed-off-by: Michael Haggerty
> ---
I was about to complain to "*Add* type" that does not say what it is
used for at all, with "Please do not add something for unknown purpose
only to utilise it in a later pa
On Tue, Apr 01, 2014 at 05:58:10PM +0200, Michael Haggerty wrote:
> 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 used t
On Tue, Apr 01, 2014 at 05:58:13PM +0200, Michael Haggerty wrote:
> 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 i
On Tue, Apr 01, 2014 at 05:58:12PM +0200, Michael Haggerty wrote:
> When rolling back the lockfile, call close_lock_file() so that the
> lock_file's fd field gets set back to -1. This could help prevent
> confusion in the face of hypothetical future programming errors.
This also solves a race. W
Michael Haggerty writes:
> Signed-off-by: Michael Haggerty
> ---
> refs.c | 15 ++-
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index d72d0ab..2b80f6d 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -3274,11 +3274,11 @@ static int update_ref_write(
On Tue, Apr 01, 2014 at 10:18:55AM -0400, Phillip Susi wrote:
> I have seen some discussion about various changes to the format of the
> index and pack files over time, but can't find anything about it in
> the man pages. Are the different formats documented anywhere, and how
> to tell which forma
Michael Haggerty writes:
> This is consistent with the usual nomenclature.
I am of two minds.
Looking for "\(\.\|->\)ref_name" used to ignore refname fields of
other structures and let us focus on the ref_update structure. Yes,
there is the ref_lock structure that shares ref_name to contaminat
On Tue, Apr 01, 2014 at 05:58:09PM +0200, Michael Haggerty wrote:
> When deleting a reference, it might be that another process already
> holds the lock on the loose reference file and/or the packed-refs
> file. In those cases, there is no alternative but for the delete to
> fail. Verify that in
Michael Haggerty writes:
> It has been superseded by reference transactions. This also means
> that struct ref_update can become private.
Good.
--
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://
Michael Haggerty writes:
> This change is mostly clerical: the parse_cmd_*() functions need to
> use local variables rather than a struct ref_update to collect the
> arguments needed for each update, and then call ref_transaction_*() to
> queue the change rather than building up the list of chang
On Tue, Apr 01, 2014 at 12:07:22PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Fri, Mar 28, 2014 at 12:30:02PM -0700, Junio C Hamano wrote:
> >
> >> Let's just deal with a simple known cases (like FreeBSD) in the real
> >> code that everybody exercises at runtime, and have the new
Michael Haggerty writes:
> Build out the API for dealing with a bunch of reference checks and
> changes within a transaction. Define an opaque ref_transaction type
> that is managed entirely within refs.c. Introduce functions for
> beginning a transaction, adding updates to a transaction, and
>
Parse the trailer command line arguments and put
the result into an arg_tok doubly linked list.
Signed-off-by: Christian Couder
---
trailer.c | 103 ++
1 file changed, 103 insertions(+)
diff --git a/trailer.c b/trailer.c
index f7714d5.
Michael Haggerty writes:
> Use temporary variables in the for-loop blocks to simplify expressions
> in the rest of the loop.
Shouldn't the summary of the change "simplify expressions"? Use of
temporary variables is a means to the end. If you have enough room
to say "achieve X by doing Y", plea
Read trailers from stdin, parse them and put the result into a doubly linked
list.
Signed-off-by: Christian Couder
---
trailer.c | 76 +++
1 file changed, 76 insertions(+)
diff --git a/trailer.c b/trailer.c
index 743ff23..953ae51 10064
---
Documentation/git-rev-parse.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index e05e6b3..377d9d7 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -363,7 +363,7 @@ us
We will use a doubly linked list to store all information
about trailers and their configuration.
This way we can easily remove or add trailers to or from
trailer lists while traversing the lists in either direction.
Signed-off-by: Christian Couder
---
Makefile | 1 +
trailer.c | 49 +
This patch series implements a new command:
git interpret-trailers
and an infrastructure to process trailers that can be reused,
for example in "commit.c".
1) Rationale:
This command should help with RFC 822 style headers, called
"trailers", that are found at the end of commit messages.
This patch adds the process_trailers() function that
calls all the previously added processing functions
and then prints the results on the standard output.
Signed-off-by: Christian Couder
---
trailer.c | 49 +
trailer.h | 6 ++
2 files change
Signed-off-by: Christian Couder
---
Documentation/git-interpret-trailers.txt | 123 +++
1 file changed, 123 insertions(+)
create mode 100644 Documentation/git-interpret-trailers.txt
diff --git a/Documentation/git-interpret-trailers.txt
b/Documentation/git-interpret-
This patch adds the "git interpret-trailers" command.
This command uses the previously added process_trailers()
function in trailer.c.
Signed-off-by: Christian Couder
---
.gitignore | 1 +
Makefile | 1 +
builtin.h| 1 +
builtin/interp
Let the user specify a command that will give on its standard output
the value to use for the specified trailer.
Signed-off-by: Christian Couder
---
trailer.c | 63 +++
1 file changed, 63 insertions(+)
diff --git a/trailer.c b/trailer.
Signed-off-by: Christian Couder
---
t/t7513-interpret-trailers.sh | 71 +++
1 file changed, 71 insertions(+)
diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
index 417a4f3..0a1f3b6 100755
--- a/t/t7513-interpret-trailers.sh
+++ b/
Implement the logic to process trailers from stdin and arguments.
At the beginning trailers from stdin are in their own in_tok
doubly linked list, and trailers from arguments are in their own
arg_tok doubly linked list.
The lists are traversed and when an arg_tok should be "applied",
it is remove
Signed-off-by: Christian Couder
---
t/t7513-interpret-trailers.sh | 336 ++
1 file changed, 336 insertions(+)
create mode 100755 t/t7513-interpret-trailers.sh
diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
new file mode 100755
Read the configuration to get trailer information, and then process
it and storing it in a doubly linked list.
The config information is stored in the list whose first item is
pointed to by:
static struct trailer_item *first_conf_item;
Signed-off-by: Christian Couder
---
trailer.c | 146 ++
Duy Nguyen writes:
> The basic support is there. Some bells and whistles (e.g. listing
> checkouts) are not, but we can add them when we see the needs. Eric
> and Torsten helped review but no, there hasn't much discussion about
> it, which may be because it's already perfect, or people are not
>
René Scharfe writes:
> Am 01.04.2014 09:42, schrieb Jeff King:
>> diff --git a/compat/gmtime.c b/compat/gmtime.c
>> new file mode 100644
>> index 000..ffcabf4
>> --- /dev/null
>> +++ b/compat/gmtime.c
>> @@ -0,0 +1,26 @@
>> +#include "../git-compat-util.h"
>> +#undef gmtime
>> +#undef gmtime_
Jeff King writes:
> On Fri, Mar 28, 2014 at 12:30:02PM -0700, Junio C Hamano wrote:
>
>> Let's just deal with a simple known cases (like FreeBSD) in the real
>> code that everybody exercises at runtime, and have the new test only
>> check we do not segfault on a value we used to segfault upon see
Justin Lebar writes:
[administrivia: please do not top-post]
> On Mon, Mar 31, 2014 at 4:19 PM, Junio C Hamano wrote:
>> Four patches queued on 'pu' as-is (but retitled). I didn't read
>> everything very carefully, though.
>>
>> Thanks.
>
> It's unclear to me: Are we done with this patch queue
> >> For some people it is also a norm to keep files that have been
> >> modified from HEAD and/or index without committing for a long time
> >> (e.g. earlier, Linus said that the version in Makefile is updated and
> >> kept modified in the working tree long before a new release is
> >> committed w
Am 01.04.2014 09:42, schrieb Jeff King:
diff --git a/compat/gmtime.c b/compat/gmtime.c
new file mode 100644
index 000..ffcabf4
--- /dev/null
+++ b/compat/gmtime.c
@@ -0,0 +1,26 @@
+#include "../git-compat-util.h"
+#undef gmtime
+#undef gmtime_r
+
+struct tm *git_gmtime(const time_t *timep)
+{
Junio C Hamano wrote:
> Assuming that you do have and are willing to read the original file,
> you have three possible (and one impractical) approaches:
[...]
> - Apply the foreign changes to the original file yourself, and feed
>the resulting content to fast-import in full, letting fast-impo
Mike Hommey writes:
> On Tue, Apr 01, 2014 at 09:15:12AM -0400, Jeff King wrote:
>> > It seems to me fast-import keeps a kind of human readable format for its
>> > protocol, i wonder if xdelta format would fit the bill. That being said,
>> > I also wonder if i shouldn't just try to write a pack o
Thanks a lot, Junio.
It's unclear to me: Are we done with this patch queue, or do I need to
worry about getting these patches into another branch? If the latter,
I'll update patch v5 per your comments.
-Justin
On Mon, Mar 31, 2014 at 4:19 PM, Junio C Hamano wrote:
> Four patches queued on 'pu'
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
---
lockfile.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lockfile.c b/lockfil
Signed-off-by: Michael Haggerty
---
lockfile.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 4a9ceda..4e3ada8 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -178,14 +178,17 @@ static char *resolve_symlink(char *p, size_t s)
retu
Reduce the amount of code that has to know about the lock_file's
filename field.
Signed-off-by: Michael Haggerty
---
config.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/config.c b/config.c
index 6821cef..1ea3f39 100644
--- a/config.c
+++ b/config.c
@@ -1303,9
Change struct lock_file's filename field from a fixed-length buffer
into a strbuf. This:
* Make buffer overflows a bit less likely
* Removes arbitrary limitations on the length of the path in some
places, though the restrictions still have to be removed from other
places to make a real diffe
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
---
lockfile.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index c1ca5b1..87b40c4 100644
When rolling back the lockfile, call close_lock_file() so that the
lock_file's fd field gets set back to -1. This could help prevent
confusion in the face of hypothetical future programming errors.
Signed-off-by: Michael Haggerty
---
lockfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
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 effect
I've had this patch series kicking around for a long time, along with
some followup patches to fix a race in reference deletion. I haven't
had the time to get everything done and tested, but let me at least
push this first series out there. I especially want to submit it in
case we accept a GSoC
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 that (nam
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 used to shadow the
"lock" variable at function scope, so the only change needed is
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
---
refs.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/refs.c b/refs.c
This removes another place where the path name is arbitrarily limited.
This gets rid of a warning
%s: symlink too long
even though strbuf_readlink() in fact still limits the length of what
it can handle to something like 2*PATH_MAX. But (1) the limit is now
much longer, and (2) strbuf_readl
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
---
lockfile.c | 52
1 file changed, 52 insertions(+)
diff --git a/lockfile.c b
When deleting a reference, it might be that another process already
holds the lock on the loose reference file and/or the packed-refs
file. In those cases, there is no alternative but for the delete to
fail. Verify that in such cases the reference values are left
unchanged.
But in fact, when the
It is only necessary to clear the lock_file's filename field if it was
not already clear.
Signed-off-by: Michael Haggerty
---
lockfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lockfile.c b/lockfile.c
index 8fbcb6a..d26711f 100644
--- a/lockfile.c
+++ b/lockfile.c
@@
Allocate temporary space to hold result_file instead of storing it in
a fixed-length buffer. This removes the last arbitrary path-length
limitation, so remove the path length check in lock_file().
Signed-off-by: Michael Haggerty
---
lockfile.c | 19 ---
1 file changed, 8 inserti
It does exactly what we need.
Signed-off-by: Michael Haggerty
---
lockfile.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 3974137..852d717 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -72,12 +72,8 @@ static void remove_lock_file(void)
Signed-off-by: Michael Haggerty
---
lockfile.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 852d717..c06e134 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -85,6 +85,14 @@ static void remove_lock_file_on_signal(in
Add a new option flag, LOCK_SEPARATE_STAGING_FILE, that can be passed
to hold_lock_file_for_update() or hold_lock_file_for_append() to use a
staging file that is independent of the lock file.
Add a new function activate_staging_file() that activates the contents
that have been written to the stagi
Now that the filename is stored separately, the external users of this
field only use it as the filename to which they are trying to write.
Soon it will not necessarily be the name of the lock file, so rename
the field more generically.
Signed-off-by: Michael Haggerty
---
builtin/commit.c | 12 +
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
---
Documentation/technical/api-lockfile.txt | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
di
This makes space for other bits.
Signed-off-by: Michael Haggerty
---
cache.h| 2 +-
lockfile.c | 9 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index 107ac61..08d0e48 100644
--- a/cache.h
+++ b/cache.h
@@ -537,7 +537,7 @@ struct lock_file {
This reduces the amount of string editing gyrations and makes it
unnecessary for callers to know how to derive the filename from the
lock_filename.
Signed-off-by: Michael Haggerty
---
cache.h| 1 +
lockfile.c | 57 -
refs.c | 10 ++
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have seen some discussion about various changes to the format of the
index and pack files over time, but can't find anything about it in
the man pages. Are the different formats documented anywhere, and how
to tell which format you are using?
-
On Tue, Apr 01, 2014 at 09:15:12AM -0400, Jeff King wrote:
> > It seems to me fast-import keeps a kind of human readable format for its
> > protocol, i wonder if xdelta format would fit the bill. That being said,
> > I also wonder if i shouldn't just try to write a pack on my own...
>
> The fast-i
Hi,
I found something which seems to be a bug to me (or well, maybe I'm
doing something wrong...). When I revert a commit with -n/--no-commit
and there's a conflict, when doing "git revert --continue" I get an
editor, even though I wouldn't expect that to happen.
Example:
$ git init
Init
On Tue, Apr 01, 2014 at 10:07:03PM +0900, Mike Hommey wrote:
> > For my own curiosity, how does this differ from what is in
> > contrib/remote-helpers/git-remote-hg?
>
> contrib/remote-helpers/git-remote-hg does a local mercurial clone before
> doing the git conversion. While this is not really a
On Tue, Apr 01, 2014 at 07:45:03AM -0400, Jeff King wrote:
> On Tue, Apr 01, 2014 at 07:25:54PM +0900, Mike Hommey wrote:
>
> > I am currently prototyping a "native" mercurial remote handler for git,
>
> For my own curiosity, how does this differ from what is in
> contrib/remote-helpers/git-remot
Jeff King wrote
> At the point you see that message, git has received the whole contents
> from the remote side and written them to disk. It's then trying to read
> back the data it just wrote to do some checks on it. However, your
> filesystem has reported a low-level I/O error, which may indicate
1 - 100 of 114 matches
Mail list logo
