So the actual backing storage speed isn't really that important. All the
time goes to copying the same packed-refs entries over and over, whether
they hit the disk or not.
Your solution (using a single transaction) is definitely the right one
(and probably should apply to "branch -d&quo
low
> > when removing from packed refs. Use delete_refs instead so all the
> > removals can be done inside a single transaction with a single write.
> >
> > I have a repo with 24,000 tags, most of which are not useful to any
> > developers. Having this many refs slows down m
on each argv. This is painfully slow
> > when removing from packed refs. Use delete_refs instead so all the
> > removals can be done inside a single transaction with a single write.
>
> Nice, thanks for working on this.
>
> > I have a repo with 24,000 tags, most of which ar
can be done inside a single transaction with a single write.
>
> I have a repo with 24,000 tags, most of which are not useful to any
> developers. Having this many refs slows down many operations that
> would otherwise be very fast. Removing these tags when they've been
> acciden
nstead so all the
> removals can be done inside a single transaction with a single write.
Nice, thanks for working on this.
> I have a repo with 24,000 tags, most of which are not useful to any
> developers. Having this many refs slows down many operations that
> would otherwise be ver
On Thu, 8 Aug 2019 at 06:09, Phil Hord wrote:
> I have a repo with 24,000 tags, most of which are not useful to any
> developers. Having this many refs slows down many operations that
> would otherwise be very fast. Removing these tags when they've been
> accidentally fetched again takes about 30
From: Phil Hord
'git tag -d' accepts one or more tag refs to delete, but each deletion
is done by calling `delete_ref` on each argv. This is painfully slow
when removing from packed refs. Use delete_refs instead so all the
removals can be done inside a single transaction with a single
Hello,
Is your email account good enough for a private discussion? I want to
discuss a business transaction with you.
Mr. Wilbert.
.
Hola,
¿Su cuenta de correo electrónico es lo suficientemente buena para una
gt; might make the flow a little simpler, but it introduces a hassle.
> > Earlier parts of files_transaction_prepare() that encounter an error
> > will jump to the cleanup label, and expect that cleaning up the
> > outer transaction will clean up the packed transa
arlier parts of files_transaction_prepare() that encounter an error
> will jump to the cleanup label, and expect that cleaning up the
> outer transaction will clean up the packed transaction, too. We'd
> have to adjust those sites to clean up the packed transaction.
This a
When deleting refs, we hold packed-refs.lock and prepare a packed
transaction to drop the refs from the packed-refs file. If it turns out
that we don't need to rewrite the packed refs (e.g., because none of the
deletions were present in the file), then we abort the transaction.
If that
ched the packed transaction to the files transaction as
backend_data->packed_transaction
- when the prepare step fails, the packed transaction cleans itself
up, putting itself into the CLOSED state
- the error value from preparing the packed transaction lets us know
in files_t
Please did you recieve the email i sent you ?
Michael Haggerty writes:
>> That much I can understand. But it is not explained why (1) we do
>> not pass old_oid anymore and (2) we do give HAVE_NEW.
>>
>> Presumably the justification for (1) is something like "because we
>> are not passing HAVE_OLD, we shouldn't have been passing old_oid a
The files backend uses `ref_update::flags` for several internal flags.
But those flags have no meaning to the packed backend. So when adding
updates for the packed-refs transaction, only use flags that make
sense to the packed backend.
`REF_NODEREF` is part of the public interface, and it&#
On 10/30/2017 05:44 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> The files backend uses `ref_update::flags` for several internal flags.
>> But those flags have no meaning to the packed backend. So when adding
>> updates for the packed-refs transaction,
Michael Haggerty writes:
> The files backend uses `ref_update::flags` for several internal flags.
> But those flags have no meaning to the packed backend. So when adding
> updates for the packed-refs transaction, only use flags that make
> sense to the packed backend.
>
> `RE
The files backend uses `ref_update::flags` for several internal flags.
But those flags have no meaning to the packed backend. So when adding
updates for the packed-refs transaction, only use flags that make
sense to the packed backend.
`REF_NODEREF` is part of the public interface, and it&#
Use a `packed_ref_store` transaction in the implementation of
`files_initial_transaction_commit()` rather than using internal
features of the packed ref store. This further decouples
`files_ref_store` from `packed_ref_store`.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 29
When processing a `files_ref_store` transaction, it is sometimes
necessary to delete some references from the "packed-refs" file. Do
that using a reference transaction conducted against the
`packed_ref_store`.
This change further decouples `files_ref_store` from
`packed_ref_store`. It
Now that the packed reference store supports transactions, we can use
a transaction to write the packed versions of references that we want
to pack. This decreases the coupling between `files_ref_store` and
`packed_ref_store`.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 24
lock is held, the
> references being created/updated have their reflogs written and are
> renamed into place. I don't see how that can be shortened without
> compromising on correctness (in particular, that we want to process
> creates/updates before deletions to try to preserve re
ness (in particular, that we want to process
creates/updates before deletions to try to preserve reachability as much
as possible during the transaction). As an added optimization, the
packed-refs lock is not acquired at all if no references are being deleted.
> Are there other callers who tak
On 09/08/2017 09:27 AM, Jeff King wrote:
> On Tue, Aug 29, 2017 at 10:20:30AM +0200, Michael Haggerty wrote:
>
>> Used a `packed_ref_store` transaction in the implementation of
>> `files_initial_transaction_commit()` rather than using internal
>> features of the packed
On Tue, Aug 29, 2017 at 10:20:32AM +0200, Michael Haggerty wrote:
> First, the old code didn't obtain the `packed-refs` lock until
> `files_transaction_finish()`. This means that a failure to acquire the
> `packed-refs` lock (e.g., due to contention with another process)
> wasn't detected until it
On Tue, Aug 29, 2017 at 10:20:30AM +0200, Michael Haggerty wrote:
> Used a `packed_ref_store` transaction in the implementation of
> `files_initial_transaction_commit()` rather than using internal
> features of the packed ref store. This further decouples
> `files_ref
When processing a `files_ref_store` transaction, it is sometimes
necessary to delete some references from the "packed-refs" file. Do
that using a reference transaction conducted against the
`packed_ref_store`.
This change further decouples `files_ref_store` from
`packed_ref_store`. It
Used a `packed_ref_store` transaction in the implementation of
`files_initial_transaction_commit()` rather than using internal
features of the packed ref store. This further decouples
`files_ref_store` from `packed_ref_store`.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 29
Now that the packed reference store supports transactions, we can use
a transaction to write the packed versions of references that we want
to pack. This decreases the coupling between `files_ref_store` and
`packed_ref_store`.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 24
Move the check that `transaction->state` is valid from
`files_transaction_commit()` to `ref_transaction_commit()`, where
other future reference backends can benefit from it as well.
Signed-off-by: Michael Haggerty
---
refs.c | 12
refs/files-backend.c | 3 ---
..71139ba74e 100644
--- a/refs.c
+++ b/refs.c
@@ -848,7 +848,7 @@ struct ref_transaction *ref_transaction_begin(struct strbuf
*err)
void ref_transaction_free(struct ref_transaction *transaction)
{
- int i;
+ size_t i;
if (!transaction)
return;
diff --git a/refs
On 05/17/2017 06:59 PM, Stefan Beller wrote:
> On Wed, May 17, 2017 at 5:05 AM, Michael Haggerty
> wrote:
>
> Now this would want to have some selling words for it?
> I do not see an advantage of this patch as-is.
>
> I mean technically we don't need a sign, so we use that extra bit
> to be abl
On Wed, May 17, 2017 at 5:05 AM, Michael Haggerty wrote:
Now this would want to have some selling words for it?
I do not see an advantage of this patch as-is.
I mean technically we don't need a sign, so we use that extra bit
to be able to process transactions up to twice the size. But I doubt
th
*ref_transaction_begin(struct strbuf
*err)
void ref_transaction_free(struct ref_transaction *transaction)
{
- int i;
+ size_t i;
if (!transaction)
return;
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 4925e698d8..893029f9dc 100644
--- a/refs/files
On Sat, Apr 1, 2017 at 11:54 AM, Michael Haggerty wrote:
> On 03/26/2017 04:42 AM, Nguyễn Thái Ngọc Duy wrote:
>> The transaction struct now takes a ref store at creation and will
>> operate on that ref store alone.
>
> Having worked downstream of this patch series for
On 03/26/2017 04:42 AM, Nguyễn Thái Ngọc Duy wrote:
> The transaction struct now takes a ref store at creation and will
> operate on that ref store alone.
Having worked downstream of this patch series for a while, I started to
wonder why a `ref_store` has to be baked into a `ref_transacti
The transaction struct now takes a ref store at creation and will
operate on that ref store alone.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 55
refs.h | 9 +
refs/refs-internal.h | 1 +
3 files
The transaction struct now takes a ref store at creation and will
operate on that ref store alone.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 55
refs.h | 9 +
refs/refs-internal.h | 1 +
3 files
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> The transaction struct now takes a ref store at creation and will
> operate on that ref store alone.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> refs.c | 54
> -
The transaction struct now takes a ref store at creation and will
operate on that ref store alone.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 54
refs.h | 8
refs/refs-internal.h | 1 +
3 files
,
cleanup_fn, policy_cb_data);
}
+
+int initial_ref_transaction_commit(struct ref_transaction *transaction,
+ struct strbuf *err)
+{
+ struct ref_store *refs = get_ref_store(NULL);
+
+ return refs->be->initial_transaction_commi
, policy_cb_data);
}
+
+int initial_ref_transaction_commit(struct ref_transaction *transaction,
+ struct strbuf *err)
+{
+ struct ref_store *refs = get_ref_store(NULL);
+
+ return refs->be->initial_transaction_commit(refs, transaction, err);
+}
diff -
initial_ref_transaction_commit(struct ref_transaction *transaction,
+ struct strbuf *err)
+{
+ return the_refs_backend->initial_transaction_commit(transaction, err);
+}
diff --git a/refs/files-backend.c b/refs/files-backend.c
index a25fda4..1906875 100644
--- a/refs/files-backen
From: Ronnie Sahlberg
Add a ref structure for storage backend methods. Start by adding a
method pointer for the transaction commit function.
Add a function set_refs_backend to switch between storage
backends. The files based storage backend is the default.
Signed-off-by: Ronnie Sahlberg
On Fri, 2016-02-26 at 23:06 -0500, Jeff King wrote:
> On Wed, Feb 24, 2016 at 05:58:37PM -0500, David Turner wrote:
>
> > +int set_ref_storage_backend(const char *name)
> > +{
> > + struct ref_storage_be *be;
> > +
> > + for (be = refs_backends; be; be = be->next)
> > + if (!strcmp(b
On Wed, Feb 24, 2016 at 05:58:37PM -0500, David Turner wrote:
> +int set_ref_storage_backend(const char *name)
> +{
> + struct ref_storage_be *be;
> +
> + for (be = refs_backends; be; be = be->next)
> + if (!strcmp(be->name, name)) {
> + the_refs_backend = b
On Thu, 2016-02-25 at 12:34 -0800, Junio C Hamano wrote:
> David Turner writes:
>
> > I thought it would be better in the api docs, since it's a design
> > decision that all backends should follow.
>
> Makes sense; as this describes an already available API, it
> shouldn't have to wait for the r
r' (or even to 'maint' if we wanted to), right?
> On Thu, 2016-02-25 at 15:05 -0500, David Turner wrote:
>> Add some comments on ref transaction semantics to refs.h
>>
>> Signed-off-by: David Turner
>> ---
>> refs.h | 12
>> 1
I thought it would be better in the api docs, since it's a design
decision that all backends should follow.
On Thu, 2016-02-25 at 15:05 -0500, David Turner wrote:
> Add some comments on ref transaction semantics to refs.h
>
> Signed-off-by: David Turner
> ---
> refs.h |
Add some comments on ref transaction semantics to refs.h
Signed-off-by: David Turner
---
refs.h | 12
1 file changed, 12 insertions(+)
diff --git a/refs.h b/refs.h
index c0964f5..9b3eaf3 100644
--- a/refs.h
+++ b/refs.h
@@ -112,6 +112,11 @@ extern int dwim_log(const char *str, int
ref_transaction *transaction,
+ struct strbuf *err)
+{
+ return the_refs_backend->initial_transaction_commit(transaction, err);
+}
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 5e44b10..7621a41 100644
--- a/refs/files-backend.c
+++ b/refs/files-backen
From: Ronnie Sahlberg
Add a ref structure for storage backend methods. Start by adding a
method pointer for the transaction commit function.
Add a function set_refs_backend to switch between storage
backends. The files based storage backend is the default.
Signed-off-by: Ronnie Sahlberg
From: Ronnie Sahlberg
Add a ref structure for storage backend methods. Start by adding a
method pointer for the transaction commit function.
Add a function set_refs_backend to switch between storage
backends. The files based storage backend is the default.
Signed-off-by: Ronnie Sahlberg
ref_transaction *transaction,
+ struct strbuf *err)
+{
+ return the_refs_backend->initial_transaction_commit(transaction, err);
+}
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 149f6a2..2a663af 100644
--- a/refs/files-backend.c
+++ b/refs/files-backen
ref_transaction *transaction,
+ struct strbuf *err)
+{
+ return the_refs_backend->initial_transaction_commit(transaction, err);
+}
diff --git a/refs/files-backend.c b/refs/files-backend.c
index b3372e6..723127e 100644
--- a/refs/files-backend.c
+++ b/refs/files-backen
From: Ronnie Sahlberg
Add a ref structure for storage backend methods. Start by adding a
method pointer for the transaction commit function.
Add a function set_refs_backend to switch between storage
backends. The files based storage backend is the default.
Signed-off-by: Ronnie Sahlberg
David Turner writes:
> diff --git a/refs.c b/refs.c
> index 0f7628d..babba8a 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -10,6 +10,31 @@
> #include "tag.h"
>
> /*
> + * We always have a files backend and it is the default.
> + */
> +extern struct ref_be refs_be_files;
It is customary to s/exte
ref_transaction *transaction,
+ struct strbuf *err)
+{
+ return the_refs_backend->initial_transaction_commit(transaction, err);
+}
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 1f76e34..44ad632 100644
--- a/refs/files-backend.c
+++ b/refs/files-backen
From: Ronnie Sahlberg
Add a ref structure for backend methods. Start by adding a method pointer
for the transaction commit function.
Add a function set_refs_backend to switch between backends. The files
based backend is the default.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: David Turner
From: David Turner
The common ref code will build up a ref transaction. Backends will
then commit it. So the transaction creation and update functions
should be in the common code.
The backends will also need access to some constants and structs that,
until now, were defined within refs.c and
On Sun, 2015-11-01 at 09:17 +0100, Michael Haggerty wrote:
> On 10/28/2015 03:14 AM, David Turner wrote:
> > The common ref code will build up a ref transaction. Backends will
> > then commit it. So the transaction creation and update functions should
> > be in the common c
On 10/28/2015 03:14 AM, David Turner wrote:
> The common ref code will build up a ref transaction. Backends will
> then commit it. So the transaction creation and update functions should
> be in the common code. We also need to move the ref structs into
> the common code so th
The common ref code will build up a ref transaction. Backends will
then commit it. So the transaction creation and update functions should
be in the common code. We also need to move the ref structs into
the common code so that alternate backends can access them.
Later, we will modify struct
The common ref code will build up a ref transaction. Backends will
then commit it. So the transaction creation and update functions should
be in the common code. We also need to move the ref structs into
the common code so that alternate backends can access them.
Later, we will modify struct
On Tue, 2015-10-13 at 18:21 -0400, David Turner wrote:
> On Tue, 2015-10-13 at 13:29 +0200, Michael Haggerty wrote:
> > I reviewed the patches up to here pretty carefully, and aside from the
> > comments I already sent, they look good.
> >
> > I like the new approach where the ref_transaction-buil
On Tue, 2015-10-13 at 13:29 +0200, Michael Haggerty wrote:
> I reviewed the patches up to here pretty carefully, and aside from the
> comments I already sent, they look good.
>
> I like the new approach where the ref_transaction-building code is
> shared across backends.
>
> It seems to me that a
On 10/13/2015 08:28 PM, David Turner wrote:
> On Tue, 2015-10-13 at 09:56 +0200, Michael Haggerty wrote:
>> On 10/12/2015 11:51 PM, David Turner wrote:
>>> [...]
>>> +extern struct ref_be refs_be_files;
>>
>> I don't think that refs_be_files is needed in the public interface.
>
> We use refs_be_lm
On Tue, 2015-10-13 at 09:56 +0200, Michael Haggerty wrote:
> On 10/12/2015 11:51 PM, David Turner wrote:
> > From: Ronnie Sahlberg
> >
> > Add a ref structure for backend methods. Start by adding a method pointer
> > for the transaction commit function.
> >
&g
I reviewed the patches up to here pretty carefully, and aside from the
comments I already sent, they look good.
I like the new approach where the ref_transaction-building code is
shared across backends.
It seems to me that a good breaking point for the first batch of patches
would be here, just b
On 10/12/2015 11:51 PM, David Turner wrote:
> From: Ronnie Sahlberg
>
> Add a ref structure for backend methods. Start by adding a method pointer
> for the transaction commit function.
>
> Add a function set_refs_backend to switch between backends. The files
> based b
On 10/12/2015 11:51 PM, David Turner wrote:
> The common ref code will build up a ref transaction. Backends will
> then commit it. So the transaction creation and update functions should
> be in the common code. We also need to move the ref structs into
> the common code so th
Please disregard this one; I rewrorded the commit message and forgot to
delete this patch.
On Mon, 2015-10-12 at 17:51 -0400, David Turner wrote:
> From: Ronnie Sahlberg
>
> Add a ref structure for backend methods. Start by adding a method pointer
> for the transaction com
From: Ronnie Sahlberg
Add a ref structure for backend methods. Start by adding a method pointer
for the transaction commit function.
Add a function set_refs_backend to switch between backends. The files
based backend is the default.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: David Turner
From: Ronnie Sahlberg
Add a ref structure for backend methods. Start by adding a method pointer
for the transaction commit function.
Add a function set_refs_backend to switch between backends. The files
based backend is the default.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: David Turner
The common ref code will build up a ref transaction. Backends will
then commit it. So the transaction creation and update functions should
be in the common code. We also need to move the ref structs into
the common code so that alternate backends can access them.
Later, we will modify struct
+++ b/refs-be-files.c
@@ -3317,8 +3317,8 @@ void files_init_backend(void *data)
/* do nothing */
}
-int initial_ref_transaction_commit(struct ref_transaction *transaction,
- struct strbuf *err)
+static int files_initial_transaction_commit(struct
On Mon, 2015-10-05 at 10:25 -0700, Junio C Hamano wrote:
> Michael Haggerty writes:
>
> >> +/* refs backends */
> >> +typedef struct ref_transaction *(*ref_transaction_begin_fn)(struct strbuf
> >> *err);
> >
> > Hmmm, I thought our convention was to define typedefs for functions
> > themselves,
Michael Haggerty writes:
>> +/* refs backends */
>> +typedef struct ref_transaction *(*ref_transaction_begin_fn)(struct strbuf
>> *err);
>
> Hmmm, I thought our convention was to define typedefs for functions
> themselves, not for the pointer-to-function; e.g.,
>
> typedef struct ref_transac
On 09/29/2015 12:01 AM, David Turner wrote:
> From: Ronnie Sahlberg
>
> Add a ref structure for backend methods. Start by adding method pointers
> for the transaction functions.
>
> Add a function set_refs_backend to switch between backends. The files
> based backend is the
+++ b/refs-be-files.c
@@ -3517,8 +3517,8 @@ static int ref_present(const char *refname,
return string_list_has_string(affected_refnames, refname);
}
-int initial_ref_transaction_commit(struct ref_transaction *transaction,
- struct strbuf *err)
+static int
From: Ronnie Sahlberg
Add a ref structure for backend methods. Start by adding method pointers
for the transaction functions.
Add a function set_refs_backend to switch between backends. The files
based backend is the default.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: David Turner
+3501,8 @@ static int ref_present(const char *refname,
return string_list_has_string(affected_refnames, refname);
}
-int initial_ref_transaction_commit(struct ref_transaction *transaction,
- struct strbuf *err)
+static int files_initial_transaction_commit
From: Ronnie Sahlberg
Add a ref structure for backend methods. Start by adding method pointers
for the transaction functions.
Add a function set_refs_backend to switch between backends. The files
based backend is the default.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: David Turner
--
For your kind attention, I will be very glad if you do assist me to
relocate a sum of (15 Million USD)to your personal bank account for the
benefit of both of us.
You will be entitled to have 35% of this fund as my foreign partner,
since
you will provide a bank account where this money will
All looked sensible from a cursory read.
Will replace, wait for a few days and will merge to 'next' unless I
hear otherwise from others.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://v
This is v3 of the patch series; I think I have addressed all of the
feedback raised about v1 [1] and v2 [2]. Thanks to Stefan Beller and
Junio for their feedback about v2.
There are only two significant changes since v2:
* Add a new patch [03/13] that changes a lot of "flags" variables from
"in
Modulo minor nits, this round looks nicely done.
--
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
reference
transaction update functions.
This branch is also available in my GitHub account [2] as branch
"refs-have-new".
Michael
[1] http://thread.gmane.org/gmane.comp.version-control.git/263522
[2] https://github.com/mhagger/git
Michael Haggerty (12):
refs: move REF_DELETING to ref
Michael Haggerty writes:
> On 02/09/2015 08:05 PM, Stefan Beller wrote:
>> On Mon, Feb 9, 2015 at 10:41 AM, Junio C Hamano wrote:
>>> Michael Haggerty writes:
[...]
This patch series applies on top of master merged together with
sb/atomic-push, which in turn depends on mh/reflog-
On Mon, Feb 9, 2015 at 12:40 PM, Michael Haggerty wrote:
>
>> I am not sure what advantages this would bring. A better history
>> for bisection? I cannot speak for Michael, but my understanding was
>> to have mh/reflog-expire and sb/atomic-push-fix merged now that 2.3
>> is out and everything els
top is unclear/rerolled/discussed as needed.
Stefan, I think you mean sb/atomic-push, not sb/atomic-push-fix, right?
>> We may even want to rebase/reroll mh/reflog-expire on top of v2.3
>> while doing so to adjust to the transaction stuff, if that makes
>> some of the changes in t
/reflog-expire and sb/atomic-push-fix merged now that 2.3
is out and everything else on top is unclear/rerolled/discussed as needed.
>
> We may even want to rebase/reroll mh/reflog-expire on top of v2.3
> while doing so to adjust to the transaction stuff, if that makes
> some of the change
es and this series to fix and clean it?
We may even want to rebase/reroll mh/reflog-expire on top of v2.3
while doing so to adjust to the transaction stuff, if that makes
some of the changes in the two new series unnecessary (if these "fix
and clean up" changes made in mh/reflog-expire
The main purpose of this series is to simplify the interface to
reference transactions as follows:
* Remove the need to supply an explicit have_old parameter to
ref_transaction_update() and ref_transaction_delete(). Instead,
check the old_sha1 if and only if it is non-NULL.
* Allow NULL to be
This moves all code related to transactions into the
execute_commands_non_atomic function. This includes
beginning and committing the transaction as well as
dealing with the errors which may occur during the
begin and commit phase of a transaction.
No functional changes intended.
Helped-by: Eric
This moves all code related to transactions into the
execute_commands_non_atomic function. This includes
beginning and committing the transaction as well as
dealing with the errors which may occur during the
begin and commit phase of a transaction.
No functional changes intended.
Helped-by: Eric
On Tue, Dec 30, 2014 at 1:45 PM, Stefan Beller wrote:
> On Tue, Dec 30, 2014 at 12:36 AM, Eric Sunshine
> wrote:
>> On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
>>> No functional changes intended.
>>
>> Secondary information can be demoted to the end of the commit message.
>
> I think
On Tue, Dec 30, 2014 at 12:36 AM, Eric Sunshine wrote:
> On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
>> Subject: receive-pack.c: move transaction handling in a central place
>
> This is very generic, and doesn't really explain what this patch is
> about. (See bel
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
> Subject: receive-pack.c: move transaction handling in a central place
This is very generic, and doesn't really explain what this patch is
about. (See below.)
> No functional changes intended.
Secondary information can be dem
1 - 100 of 674 matches
Mail list logo
