Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

I know that a review-update cycle is still going in the dark at

  https://code-review.googlesource.com/#/q/topic:ref-transaction

for this series.  Are we almost there for v22 which hopefully be the
final before we merge it to 'next' and go incremental?  
--
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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Jonathan Nieder]

Junio C Hamano wrote:

 I know that a review-update cycle is still going in the dark at

   https://code-review.googlesource.com/#/q/topic:ref-transaction

 for this series.

Eh, it's at least public and doesn't flood the list with rebased
versions of the series.

Would you prefer if there were some list archived on gmane with the
automated mails from gerrit, to make it easier to look back at later?

  Are we almost there for v22 which hopefully be the
 final before we merge it to 'next' and go incremental?

The patch fix handling of badly named refs[1] is still undergoing
heavy churn.

I think it's worth getting that one right.

Thanks,
Jonathan

[1] https://code-review.googlesource.com/1070
--
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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Jonathan Nieder jrnie...@gmail.com writes:

 The patch fix handling of badly named refs[1] is still undergoing
 heavy churn.

 I think it's worth getting that one right.

Oh, no question about it.  I was only making sure that I didn't miss
availability of updates for larger series we saw during this cycle.

--
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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Michael Haggerty mhag...@alum.mit.edu writes:

 On 09/13/2014 01:57 AM, Jonathan Nieder wrote:
 Michael Haggerty wrote:
 Jonathan Nieder jrnie...@gmail.com writes:
 
 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?
 
 Yes.
 (https://code-review.googlesource.com/#/q/project:git+topic:ref-transaction)

 I just worked through the patch series, leaving lots of comments in
 Gerrit. Overall it looks pretty good and makes a lot of very worthwhile
 progress. The only patch that gives me a bit of heartburn is

 [PATCH 15/19] refs.c: fix handling of badly named refs

 not because it is necessarily wrong, but because it has a lot of
 non-local effects that are hard to evaluate. I made a bunch of comments
 in Gerrit about that patch, too, and will wait for a response before
 having another go at it.

 Thanks for all your hard and detailed work, Ronnie and Jonathan!

 Michael

Jonathan: Is a current version of this patch series set up to be
fetched so that it can be reviewed outside Gerrit?

Running ls-remote against https://code.googlesource.com/git shows
many refs under refs/changes/* but it is unclear to me if there is a
coherent single here is the latest and greatest, dependents rebased
on dependeds in the right order thing that I can fetch and look at
with log -p master...



--
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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Jonathan Nieder]

Junio C Hamano wrote:

 Jonathan: Is a current version of this patch series set up to be
 fetched so that it can be reviewed outside Gerrit?

The current tip is 06d707cb63e34fc55a18ecc47e668f3c44acae57 from
https://code.googlesource.com/git (fetch-by-sha1 should work).  Each
reroll gets its own refname of the form refs/changes/62/1062/number
with number increasing.  The Download widget in the top-right
corner of https://code-review.googlesource.com/1062 shows the refname.

There are plenty of unaddressed comments from Michael, so I'd hold off
on picking up the latest for pu for now.

Thanks,
Jonathan
--
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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Jonathan Nieder jrnie...@gmail.com writes:

 Junio C Hamano wrote:

 Jonathan: Is a current version of this patch series set up to be
 fetched so that it can be reviewed outside Gerrit?

 The current tip is 06d707cb63e34fc55a18ecc47e668f3c44acae57 from
 https://code.googlesource.com/git (fetch-by-sha1 should work).  Each
 reroll gets its own refname of the form refs/changes/62/1062/number
 with number increasing.  The Download widget in the top-right
 corner of https://code-review.googlesource.com/1062 shows the refname.

While I am showing my naiveté, how does one figure out that 1062 is
the last one in the series?

Does the order of changes that appear in

https://code-review.googlesource.com/#/q/project:git+branch:master+topic:ref-transaction

have any significance?  e.g. is a topic supposed to be a single
strand of pearls on top of the branch, and the top one is the tip,
or something?

 There are plenty of unaddressed comments from Michael, so I'd hold off
 on picking up the latest for pu for now.

Oh, the request was not for that.  I simply cannot read the patch
with only limited context in the web browser without having a ready
access to a coherent whole, i.e. a full tree with history, to review
a change like this.
--
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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Jonathan Nieder]

Junio C Hamano wrote:

 Does the order of changes that appear in

 https://code-review.googlesource.com/#/q/project:git+branch:master+topic:ref-transaction

 have any significance?  e.g. is a topic supposed to be a single
 strand of pearls on top of the branch, and the top one is the tip,
 or something?

Alas no, though that would be a good feature.

Search results are ordered by which was last updated (for example when
someone adds a comment).

The 'Related Changes' shown on the change screen are in topological
order, with the tip at the top.

Jonathan
--
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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Michael Haggerty]

On 09/13/2014 01:57 AM, Jonathan Nieder wrote:
 Michael Haggerty wrote:
 Jonathan Nieder jrnie...@gmail.com writes:
 
 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?
 
 Yes.
 (https://code-review.googlesource.com/#/q/project:git+topic:ref-transaction)

I just worked through the patch series, leaving lots of comments in
Gerrit. Overall it looks pretty good and makes a lot of very worthwhile
progress. The only patch that gives me a bit of heartburn is

[PATCH 15/19] refs.c: fix handling of badly named refs

not because it is necessarily wrong, but because it has a lot of
non-local effects that are hard to evaluate. I made a bunch of comments
in Gerrit about that patch, too, and will wait for a response before
having another go at it.

Thanks for all your hard and detailed work, Ronnie and Jonathan!

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-info.html

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Junio C Hamano gits...@pobox.com writes:

 I noticed that with this series merged to the version I use daily,
 detaching HEAD (i.e. git checkout HEAD^0) breaks my HEAD reflog,
 which made me redo the integration ejecting the series out of 'pu'.

 Not happy, as my workflow relies fairly heavily on detached HEAD
 X-.

Just FYI.

Bisecting the series using the attached as a test script points
branch -d: avoid repeated symref resolution as a possible culprit.
Perhaps these tests may want to be added to t3200 which is touched
by the said commit (or add them earlier in the series)?

-- 8 --

#!/bin/sh

test_description='reflog not nuked with co HEAD^0'
. ./test-lib.sh

check_reflog () {
while read name
do
git rev-parse --verify $name
done expect 
if test -f $2
then
while read object rest
do
git rev-parse --verify $object
done expect $2
fi 
while read object rest
do
git rev-parse --verify $object
done actual $1 
test_cmp expect actual
}

test_expect_success setup '
test_tick 
git commit --allow-empty -m initial 
git branch side 
test_tick 
git commit --allow-empty -m second 
git log -g --oneline baseline 
check_reflog baseline -\EOF
master
master^
EOF
'

test_expect_success 'switch to branch' '
git checkout side 
git log -g --oneline switched 
check_reflog switched baseline -\EOF
side
EOF
'

test_expect_success 'detach to other' '
git checkout master^0 
git log -g --oneline detach-1 
check_reflog detach-1 switched -\EOF
master
EOF
'

test_expect_success 'attach to self' '
git checkout master 
git log -g --oneline detach-2 
check_reflog detach-2 detach-1 -\EOF
master
EOF
'

test_expect_success 'detach to self' '
git checkout master^0 
git log -g --oneline detach-3 
check_reflog detach-3 detach-2 -\EOF
master
EOF
'

test_expect_success 'attach to other' '
git checkout HEAD^0 
git checkout side 
git log -g --oneline detach-4 
check_reflog detach-4 detach-3 -\EOF
side
EOF
'

test_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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Jonathan Nieder jrnie...@gmail.com writes:

 Junio C Hamano wrote:
 Jonathan Nieder jrnie...@gmail.com writes:

 These patches are also available from the git repository at

   git://repo.or.cz/git/jrn.git tags/rs/ref-transaction

 The tag fetched and built as-is seems to break 5514 among other
 things (git remote rm segfaults).

 Yeah, I noticed that right after sending the series out. :/

 The patch below fixes it[1].

Is this meant to replace anything, or is it Oops, the previous ones
are broken, and this is to patch it up on top?

 -- 8 --
 From: Ronnie Sahlberg sahlb...@google.com
 Date: Thu, 11 Sep 2014 08:42:57 -0700
 Subject: remote rm/prune: print a message when writing packed-refs fails

 Until v2.1.0-rc0~22^2~11 (refs.c: add an err argument to
 repack_without_refs, 2014-06-20), repack_without_refs forgot to
 provide an error message when commit_packed_refs fails.  Even today,
 it only provides a message for callers that pass a non-NULL err
 parameter.  Internal callers in refs.c pass non-NULL err but
 git remote does not.

 That means that git remote rm and git remote prune can fail
 without printing a message about why.  Fix them by passing in a
 non-NULL err parameter and printing the returned message.

 This is the last caller to a ref handling function passing err ==
 NULL.  A later patch can drop support for err == NULL, avoiding such
 problems in the future.

 Change-Id: Ifb8a726ef03d0aa282a25a102313064d2e8ec283
 Signed-off-by: Ronnie Sahlberg sahlb...@google.com
 Signed-off-by: Jonathan Nieder jrnie...@gmail.com
 ---
 [1] https://code-review.googlesource.com/1110
 https://code-review.googlesource.com/1060

  builtin/remote.c | 15 +++
  1 file changed, 11 insertions(+), 4 deletions(-)

 diff --git a/builtin/remote.c b/builtin/remote.c
 index 6eaeee7..ef1ffc3 100644
 --- a/builtin/remote.c
 +++ b/builtin/remote.c
 @@ -750,13 +750,16 @@ static int mv(int argc, const char **argv)
  
  static int remove_branches(struct string_list *branches)
  {
 + struct strbuf err = STRBUF_INIT;
   const char **branch_names;
   int i, result = 0;
  
   branch_names = xmalloc(branches-nr * sizeof(*branch_names));
   for (i = 0; i  branches-nr; i++)
   branch_names[i] = branches-items[i].string;
 - result |= repack_without_refs(branch_names, branches-nr, NULL);
 + if (repack_without_refs(branch_names, branches-nr, err))
 + result |= error(%s, err.buf);
 + strbuf_release(err);
   free(branch_names);
  
   for (i = 0; i  branches-nr; i++) {
 @@ -1333,9 +1336,13 @@ static int prune_remote(const char *remote, int 
 dry_run)
   delete_refs = xmalloc(states.stale.nr * sizeof(*delete_refs));
   for (i = 0; i  states.stale.nr; i++)
   delete_refs[i] = states.stale.items[i].util;
 - if (!dry_run)
 - result |= repack_without_refs(delete_refs,
 -   states.stale.nr, NULL);
 + if (!dry_run) {
 + struct strbuf err = STRBUF_INIT;
 + if (repack_without_refs(delete_refs, states.stale.nr,
 + err))
 + result |= error(%s, err.buf);
 + strbuf_release(err);
 + }
   free(delete_refs);
   }
--
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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Jonathan Nieder]

Junio C Hamano wrote:
 Jonathan Nieder jrnie...@gmail.com writes:
  Junio C Hamano wrote:

 The tag fetched and built as-is seems to break 5514 among other
 things (git remote rm segfaults).

 Yeah, I noticed that right after sending the series out. :/

 The patch below fixes it[1].

 Is this meant to replace anything, or is it Oops, the previous ones
 are broken, and this is to patch it up on top?

It's Oops, the next one (refs.c: do not permit err == NULL) is broken,
and this is to patch it up in advance. :)

But it should apply on top, too.

There were a few other minor changes, and I think with them the series
should be ready for next.  My send and hope that more reviewers
appear strategy didn't really work, so I'll send a reroll of the
series as-is in an hour or so.

Here's an interdiff as a preview.

diff --git a/builtin/branch.c b/builtin/branch.c
index 5d5bc56..4bf931e 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -238,9 +238,7 @@ static int delete_branches(int argc, const char **argv, int 
force, int kinds,
RESOLVE_REF_READING
| RESOLVE_REF_NODEREF
| RESOLVE_REF_ALLOW_BAD_NAME);
-   if (!target ||
-   (!(flags  (REF_ISSYMREF|REF_ISBROKEN)) 
-is_null_sha1(sha1))) {
+   if (!target) {
error(remote_branch
  ? _(remote branch '%s' not found.)
  : _(branch '%s' not found.), bname.buf);
@@ -268,8 +266,8 @@ static int delete_branches(int argc, const char **argv, int 
force, int kinds,
   ? _(Deleted remote branch %s (was %s).\n)
   : _(Deleted branch %s (was %s).\n),
   bname.buf,
-  (flags  REF_ISSYMREF)
-  ? target
+  (flags  REF_ISBROKEN) ? broken
+  : (flags  REF_ISSYMREF) ? target
   : find_unique_abbrev(sha1, DEFAULT_ABBREV));
}
delete_branch_config(bname.buf);
diff --git a/builtin/remote.c b/builtin/remote.c
index 6eaeee7..ef1ffc3 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -750,13 +750,16 @@ static int mv(int argc, const char **argv)
 
 static int remove_branches(struct string_list *branches)
 {
+   struct strbuf err = STRBUF_INIT;
const char **branch_names;
int i, result = 0;
 
branch_names = xmalloc(branches-nr * sizeof(*branch_names));
for (i = 0; i  branches-nr; i++)
branch_names[i] = branches-items[i].string;
-   result |= repack_without_refs(branch_names, branches-nr, NULL);
+   if (repack_without_refs(branch_names, branches-nr, err))
+   result |= error(%s, err.buf);
+   strbuf_release(err);
free(branch_names);
 
for (i = 0; i  branches-nr; i++) {
@@ -1333,9 +1336,13 @@ static int prune_remote(const char *remote, int dry_run)
delete_refs = xmalloc(states.stale.nr * sizeof(*delete_refs));
for (i = 0; i  states.stale.nr; i++)
delete_refs[i] = states.stale.items[i].util;
-   if (!dry_run)
-   result |= repack_without_refs(delete_refs,
- states.stale.nr, NULL);
+   if (!dry_run) {
+   struct strbuf err = STRBUF_INIT;
+   if (repack_without_refs(delete_refs, states.stale.nr,
+   err))
+   result |= error(%s, err.buf);
+   strbuf_release(err);
+   }
free(delete_refs);
}
 
--
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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Jonathan Nieder jrnie...@gmail.com writes:

 It's Oops, the next one (refs.c: do not permit err == NULL) is broken,
 and this is to patch it up in advance. :)

 But it should apply on top, too.

I think in advance makes sense for this one, too.

 There were a few other minor changes, and I think with them the series
 should be ready for next.  My send and hope that more reviewers
 appear strategy didn't really work,...

You sent them just a few days ago.  Expecting anybody to have a
solid time to sit thru a 19-patch series inside that timeframe is
not so realistic.

 so I'll send a reroll of the series as-is in an hour or so.

OK.  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://vger.kernel.org/majordomo-info.html

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Junio C Hamano gits...@pobox.com writes:

 Jonathan Nieder jrnie...@gmail.com writes:

 It's Oops, the next one (refs.c: do not permit err == NULL) is broken,
 and this is to patch it up in advance. :)

 But it should apply on top, too.

 I think in advance makes sense for this one, too.

 There were a few other minor changes, and I think with them the series
 should be ready for next.  My send and hope that more reviewers
 appear strategy didn't really work,...

 You sent them just a few days ago.  Expecting anybody to have a
 solid time to sit thru a 19-patch series inside that timeframe is
 not so realistic.

 so I'll send a reroll of the series as-is in an hour or so.

 OK.  Thanks.

I do not think I have enough time to pick a reroll up to redo the
day's integration, so please take time to make it perfect.

I noticed that with this series merged to the version I use daily,
detaching HEAD (i.e. git checkout HEAD^0) breaks my HEAD reflog,
which made me redo the integration ejecting the series out of 'pu'.

Not happy, as my workflow relies fairly heavily on detached HEAD
X-.

--
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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Michael Haggerty]

On 09/12/2014 09:56 PM, Junio C Hamano wrote:
 Jonathan Nieder jrnie...@gmail.com writes:
 [...]
 There were a few other minor changes, and I think with them the series
 should be ready for next.  My send and hope that more reviewers
 appear strategy didn't really work,...
 
 You sent them just a few days ago.  Expecting anybody to have a
 solid time to sit thru a 19-patch series inside that timeframe is
 not so realistic.

It's hard to tell from my glacial (tectonic?) pace, but I really do plan
to work through all of Ronnie's ref-related patches. Of course it's up
to you whether to wait 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 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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Jonathan Nieder]

Michael Haggerty wrote:
 Jonathan Nieder jrnie...@gmail.com writes:

 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?

Yes.
(https://code-review.googlesource.com/#/q/project:git+topic:ref-transaction)

Thanks,
Jonathan
--
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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Jonathan Nieder jrnie...@gmail.com writes:

 Jonathan Nieder wrote:

 The next series from Ronnie's collection is available at
 https://code-review.googlesource.com/#/q/topic:ref-transaction in case
 someone wants a fresh series to look at.

 Here is the outcome of that review.  It could use another set of eyes
 (hint, hint) but should be mostly ready.  Interdiff below.  This is meant
 to replace rs/ref-transaction in 'pu' and I'd prefer to wait a little
 for more comments before merging to 'next'.

Alright.  I'd assume that all the other rs/ref-transaction* topics
that depends on rs/ref-transaction series will be rerolled on top of
this new round when ready.

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://vger.kernel.org/majordomo-info.html

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Jonathan Nieder jrnie...@gmail.com writes:

 These patches are also available from the git repository at

   git://repo.or.cz/git/jrn.git tags/rs/ref-transaction

The tag fetched and built as-is seems to break 5514 among other
things (git remote rm segfaults).
--
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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Jonathan Nieder]

Junio C Hamano wrote:
 Jonathan Nieder jrnie...@gmail.com writes:

 These patches are also available from the git repository at

   git://repo.or.cz/git/jrn.git tags/rs/ref-transaction

 The tag fetched and built as-is seems to break 5514 among other
 things (git remote rm segfaults).

Yeah, I noticed that right after sending the series out. :/

The patch below fixes it[1].

-- 8 --
From: Ronnie Sahlberg sahlb...@google.com
Date: Thu, 11 Sep 2014 08:42:57 -0700
Subject: remote rm/prune: print a message when writing packed-refs fails

Until v2.1.0-rc0~22^2~11 (refs.c: add an err argument to
repack_without_refs, 2014-06-20), repack_without_refs forgot to
provide an error message when commit_packed_refs fails.  Even today,
it only provides a message for callers that pass a non-NULL err
parameter.  Internal callers in refs.c pass non-NULL err but
git remote does not.

That means that git remote rm and git remote prune can fail
without printing a message about why.  Fix them by passing in a
non-NULL err parameter and printing the returned message.

This is the last caller to a ref handling function passing err ==
NULL.  A later patch can drop support for err == NULL, avoiding such
problems in the future.

Change-Id: Ifb8a726ef03d0aa282a25a102313064d2e8ec283
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
[1] https://code-review.googlesource.com/1110
https://code-review.googlesource.com/1060

 builtin/remote.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/builtin/remote.c b/builtin/remote.c
index 6eaeee7..ef1ffc3 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -750,13 +750,16 @@ static int mv(int argc, const char **argv)
 
 static int remove_branches(struct string_list *branches)
 {
+   struct strbuf err = STRBUF_INIT;
const char **branch_names;
int i, result = 0;
 
branch_names = xmalloc(branches-nr * sizeof(*branch_names));
for (i = 0; i  branches-nr; i++)
branch_names[i] = branches-items[i].string;
-   result |= repack_without_refs(branch_names, branches-nr, NULL);
+   if (repack_without_refs(branch_names, branches-nr, err))
+   result |= error(%s, err.buf);
+   strbuf_release(err);
free(branch_names);
 
for (i = 0; i  branches-nr; i++) {
@@ -1333,9 +1336,13 @@ static int prune_remote(const char *remote, int dry_run)
delete_refs = xmalloc(states.stale.nr * sizeof(*delete_refs));
for (i = 0; i  states.stale.nr; i++)
delete_refs[i] = states.stale.items[i].util;
-   if (!dry_run)
-   result |= repack_without_refs(delete_refs,
- states.stale.nr, NULL);
+   if (!dry_run) {
+   struct strbuf err = STRBUF_INIT;
+   if (repack_without_refs(delete_refs, states.stale.nr,
+   err))
+   result |= error(%s, err.buf);
+   strbuf_release(err);
+   }
free(delete_refs);
}
 
-- 
2.1.0.rc2.206.gedb03e5

--
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

[PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Jonathan Nieder]

Jonathan Nieder wrote:

 The next series from Ronnie's collection is available at
 https://code-review.googlesource.com/#/q/topic:ref-transaction in case
 someone wants a fresh series to look at.

Here is the outcome of that review.  It could use another set of eyes
(hint, hint) but should be mostly ready.  Interdiff below.  This is meant
to replace rs/ref-transaction in 'pu' and I'd prefer to wait a little
for more comments before merging to 'next'.

These patches are also available from the git repository at

  git://repo.or.cz/git/jrn.git tags/rs/ref-transaction

Use ref transactions, part 3

Ronnie explains:

This is the third and final part of the original 48 patch
series for basic transaction support.  This version implements
some changes suggested by mhagger for the warn_if_unremovable
changes.  It also adds a new patch fix handling of badly
named refs that repairs the handling of badly named refs.

This includes some improvements to the transaction API (in
particular allowing different reflog messages per ref update in
a transaction), some cleanups and consistency improvements, and
preparation for an implementation of ref renaming in terms of
the transaction API.

It also improves handling of refs with invalid names.  Today git
branch --list and git for-each-ref do not provide a way to discover
refs with invalid names and git branch -d and git update-ref -d
cannot delete them.  After this series, such bad refs will be
discoverable and deletable again as in olden times.

Jonathan Nieder (5):
  mv test: recreate mod/ directory instead of relying on stale copy
  branch -d: avoid repeated symref resolution
  refs.c: do not permit err == NULL
  lockfile: remove unable_to_lock_error
  ref_transaction_commit: bail out on failure to remove a ref

Ronnie Sahlberg (14):
  wrapper.c: remove/unlink_or_warn: simplify, treat ENOENT as success
  wrapper.c: add a new function unlink_or_msg
  refs.c: add an err argument to delete_ref_loose
  refs.c: pass the ref log message to _create/delete/update instead of
_commit
  rename_ref: don't ask read_ref_full where the ref came from
  refs.c: move the check for valid refname to lock_ref_sha1_basic
  refs.c: call lock_ref_sha1_basic directly from commit
  refs.c: pass a skip list to name_conflict_fn
  refs.c: ref_transaction_commit: distinguish name conflicts from other
errors
  fetch.c: change s_update_ref to use a ref transaction
  refs.c: make write_ref_sha1 static
  refs.c: change resolve_ref_unsafe reading argument to be a flags field
  refs.c: fix handling of badly named refs
  for-each-ref.c: improve message before aborting on broken ref

 branch.c|   6 +-
 builtin/blame.c |   2 +-
 builtin/branch.c|  19 ++-
 builtin/checkout.c  |   6 +-
 builtin/clone.c |   2 +-
 builtin/commit.c|   6 +-
 builtin/fetch.c |  34 +++--
 builtin/fmt-merge-msg.c |   2 +-
 builtin/for-each-ref.c  |  12 +-
 builtin/fsck.c  |   2 +-
 builtin/log.c   |   3 +-
 builtin/merge.c |   2 +-
 builtin/notes.c |   2 +-
 builtin/receive-pack.c  |   9 +-
 builtin/remote.c|   5 +-
 builtin/replace.c   |   5 +-
 builtin/show-branch.c   |   6 +-
 builtin/symbolic-ref.c  |   2 +-
 builtin/tag.c   |   4 +-
 builtin/update-ref.c|  16 ++-
 bundle.c|   2 +-
 cache.h |  31 +++--
 fast-import.c   |   8 +-
 git-compat-util.h   |  16 ++-
 http-backend.c  |   3 +-
 lockfile.c  |  10 --
 notes-merge.c   |   2 +-
 reflog-walk.c   |   5 +-
 refs.c  | 321 ++--
 refs.h  |  18 ++-
 remote.c|  10 +-
 sequencer.c |   8 +-
 t/t1400-update-ref.sh   |  16 +++
 t/t1402-check-ref-format.sh |  48 +++
 t/t3200-branch.sh   |   9 ++
 t/t7001-mv.sh   |  15 ++-
 transport-helper.c  |   4 +-
 transport.c |   5 +-
 upload-pack.c   |   2 +-
 walker.c|   5 +-
 wrapper.c   |  28 ++--
 wt-status.c |   2 +-
 42 files changed, 487 insertions(+), 226 deletions(-)
---
Changes since last appearance:

diff --git c/branch.c w/branch.c
index 76a8ec9..ba3e1c1 100644
--- c/branch.c
+++ w/branch.c
@@ -186,7 +186,7 @@ int validate_new_branchname(const char *name, struct strbuf 
*ref,
const char *head;
unsigned char sha1[20];
 
-   head = resolve_ref_unsafe(HEAD, sha1, 0, NULL);
+   head = resolve_ref_unsafe(HEAD, sha1, NULL, 0);
if (!is_bare_repository()  head  !strcmp(head, ref-buf))
die(_(Cannot force update the current branch.));
}
diff --git c/builtin/blame.c 

Re: [PATCH 0/20] rs/ref-transaction-1 (Re: Transaction patch series overview)

[Junio C Hamano]

Jonathan Nieder jrnie...@gmail.com writes:

 Jonathan Nieder wrote:

 This series teaches the tag, replace, commit, cherry-pick,
 fast-import, checkout -b, branch, receive-pack, and http-fetch
 commands and all update_ref and delete_ref callers to use the ref
 transaction API instead of lock_ref_sha1.

 The main user-visible change should be some cosmetic changes to error
 messages.  The series also combines multiple ref updates into a single
 transaction in 'git http-fetch -w' and when writing tags in
 fast-import but otherwise doesn't change the granularity of
 transactions.

 Reviewed at https://code-review.googlesource.com/#/q/topic:ref-transaction-1

Thanks.

Will queue, but the some other topics may have to disappear from my
tree while I try to rebase them on top (or while I wait for you guys
to send a reroll, making it unnecesary to do the rebase myself).

--
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

Using Gerrit to review Git patches (was: Re: Transaction patch series overview)

[Michael Haggerty]

On 08/26/2014 02:03 AM, Jonathan Nieder wrote:
 Jonathan Nieder wrote:
 [...]
 I've having trouble keeping track of how patches change, which patches
 have been reviewed and which haven't, unaddressed comments, and so on,
 so as an experiment I've pushed this part of the series to the Gerrit
 server at

  https://code-review.googlesource.com/#/q/topic:ref-transaction-1
 
 Outcome of the experiment: patches gained some minor changes and then
 [...]
 
 I found the web UI helpful in seeing how each patch evolved since I
 last looked at it.  Interdiff relative to the version in pu is below.
 I'm still hoping for a tweak in response to a minor comment and then I
 can put up a copy of the updated series to pull.

Thanks for organizing this experiment. I was one of the guinea pigs
:-) I have wanted to review more of Ronnie's patches (actually, all of
them!) but have been overwhelmed by the number of iterations and the
number of patch series flying around in parallel. I was also interested
to try out Gerrit, which I haven't used before. So I took up Jonathan's
invitation and reviewed the first patch series in Gerrit. Here are some
of my first impressions.

* Overall, I found it easier to review commits in Gerrit than on the
mailing list, especially a long patch series like this one that has seen
so much flux. It was easier to see the comments from all reviewers that
apply to a patch, which is difficult on the mailing list when comments
are scattered over the many iterations of the patch series. It was
easier to incrementally increase the context around a patch. It was easy
to use the copy-paste commands provided in the download menu to fetch
the commit that I was reviewing into my local Git repository, and from
there to build it or investigate it using other tools.

* The Gerrit interface is very busy. It was somewhat overwhelming to me
as a beginner. On the other hand, the help menus (? key) are good and
the keyboard shortcuts are convenient. I didn't have to read much
documentation to get started doing review in Gerrit, at least at a basic
level.

* During two of my big Gerrit sessions the website was very responsive
and pleasant to use. During the third, it was terribly slow, like 5 - 15
seconds per page update. If I had only experienced the slow behavior, I
would have rejected Gerrit immediately. I hope that the slow behavior
was a rare anomaly.

* Gerrit sends out an endless flood of emails that mostly seem pretty
useless to me. I wish it weren't so chatty and that its emails were
better organized.

* At one point a back-and-forth in a line comment grew into a more
general issue that was more appropriate for the mailing list. The
transition from Gerrit 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

--
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

Re: [PATCH 0/20] rs/ref-transaction-1 (Re: Transaction patch series overview)

[Junio C Hamano]

Junio C Hamano gits...@pobox.com writes:

 Jonathan Nieder jrnie...@gmail.com writes:

 Jonathan Nieder wrote:

 This series teaches the tag, replace, commit, cherry-pick,
 fast-import, checkout -b, branch, receive-pack, and http-fetch
 commands and all update_ref and delete_ref callers to use the ref
 transaction API instead of lock_ref_sha1.

 The main user-visible change should be some cosmetic changes to error
 messages.  The series also combines multiple ref updates into a single
 transaction in 'git http-fetch -w' and when writing tags in
 fast-import but otherwise doesn't change the granularity of
 transactions.

 Reviewed at https://code-review.googlesource.com/#/q/topic:ref-transaction-1

 Thanks.

 Will queue, but the some other topics may have to disappear from my
 tree while I try to rebase them on top (or while I wait for you guys
 to send a reroll, making it unnecesary to do the rebase myself).

I managed to rebase all the rs/ref-transaction* topics and pushed
out the result in 'pu'.  Please eyeball the result.

I had to bump nd/multiple-work-trees, which Duy asked to kick out of
'next' earlier, out of 'pu' because I did not want to deal with
conflict resolution that will go to waste when the topic is rerolled
which would happen soon.

--
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

Re: Using Gerrit to review Git patches (was: Re: Transaction patch series overview)

[Shawn Pearce]

On Wed, Aug 27, 2014 at 2:53 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
 On 08/26/2014 02:03 AM, Jonathan Nieder wrote:
 Jonathan Nieder wrote:
 [...]
 I've having trouble keeping track of how patches change, which patches
 have been reviewed and which haven't, unaddressed comments, and so on,
 so as an experiment I've pushed this part of the series to the Gerrit
 server at

  https://code-review.googlesource.com/#/q/topic:ref-transaction-1

 Outcome of the experiment: patches gained some minor changes and then
 [...]

 I found the web UI helpful in seeing how each patch evolved since I
 last looked at it.  Interdiff relative to the version in pu is below.
 I'm still hoping for a tweak in response to a minor comment and then I
 can put up a copy of the updated series to pull.

 Thanks for organizing this experiment. I was one of the guinea pigs
 :-) I have wanted to review more of Ronnie's patches (actually, all of
 them!) but have been overwhelmed by the number of iterations and the
 number of patch series flying around in parallel. I was also interested
 to try out Gerrit, which I haven't used before. So I took up Jonathan's
 invitation and reviewed the first patch series in Gerrit. Here are some
 of my first impressions.

Thank you for making this writeup. It contains many valuable nuggets
that we should follow up on.

 * Overall, I found it easier to review commits in Gerrit than on the
 mailing list, especially a long patch series like this one that has seen
 so much flux. It was easier to see the comments from all reviewers that
 apply to a patch, which is difficult on the mailing list when comments
 are scattered over the many iterations of the patch series. It was
 easier to incrementally increase the context around a patch. It was easy
 to use the copy-paste commands provided in the download menu to fetch
 the commit that I was reviewing into my local Git repository, and from
 there to build it or investigate it using other tools.

 * The Gerrit interface is very busy. It was somewhat overwhelming to me
 as a beginner.

Very astute observation. I have been using it for 5+ years so its hard
for me to see things like this.

Unfortunately many parts of the UI have grown over the years.
Contributors come along and want to add X, months later another adds
field Y. Suddenly we have the entire alphabet and we don't know how it
got that way. Sounds like git reset --{hard|soft|mixed|wtf}. :)

Its not an excuse. The UI should be less overwhelming. Its going to be
a challenge.

 On the other hand, the help menus (? key) are good and
 the keyboard shortcuts are convenient. I didn't have to read much
 documentation to get started doing review in Gerrit, at least at a basic
 level.

Yay!

 * During two of my big Gerrit sessions the website was very responsive
 and pleasant to use. During the third, it was terribly slow, like 5 - 15
 seconds per page update. If I had only experienced the slow behavior, I
 would have rejected Gerrit immediately. I hope that the slow behavior
 was a rare anomaly.

This third session was a rare anomaly unique to
code-review.googlesource.com. It isn't typical for Gerrit Code Review.

We have a server set in Europe that was mostly answering you in the
first two sessions. During the third session this server set was
temporarily offline. Requests degraded to a server set in the US,
which pushed us into a worst-case scenario due to a misconfiguration
of our load balancers. The lag you experienced was mostly due to this
misconfiguration, not EU-US networking.

Earlier today I brought back up the European server set, so latency
should be reduced again.

Unfortunately I haven't figured out how to fix the load balancer
misconfiguration. :(

 * Gerrit sends out an endless flood of emails that mostly seem pretty
 useless to me. I wish it weren't so chatty and that its emails were
 better organized.

Absolutely agree.

 * At one point a back-and-forth in a line comment grew into a more
 general issue that was more appropriate for the mailing list. The
 transition from Gerrit to mailing list was a bit awkward.

We find this a bit awkward in JGit too. Our solution has been to
(mostly) keep discussion within the code review context. This has to
some extent forced more discussion to be around specific code, and
avoid wandering off into the philosophical weeds. Without concrete
code to talk about, there is nothing to say. :)

A nice feature of Gerrit is another contributor can add their own
iterations to the same commit in the series, offering up alternative
proposals. Like on the mailing list, this allows someone to just say
what if you did it this way..., and give everyone a concrete chunk
of code to consider and discuss. Again this avoids wandering off into
the weeds.

 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.

One idea has 

Re: Transaction patch series overview

[Junio C Hamano]

Jonathan Nieder jrnie...@gmail.com writes:

  https://code-review.googlesource.com/#/q/topic:ref-transaction-1

 Outcome of the experiment: patches gained some minor changes and then

  1-12
   Reviewed-by: Jonathan Nieder jrnie...@gmail.com

  13
   Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
   Reviewed-by: Jonathan Nieder jrnie...@gmail.com

  14
   Reviewed-by: Jonathan Nieder jrnie...@gmail.com

  15-16
   Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
   Reviewed-by: Jonathan Nieder jrnie...@gmail.com

  17
   Reviewed-by: Michael Haggerty mhag...@alum.mit.edu

  18
   Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
   Reviewed-by: Jonathan Nieder jrnie...@gmail.com

  19
   Reviewed-by: Jonathan Nieder jrnie...@gmail.com

  20
   Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
   Reviewed-by: Jonathan Nieder jrnie...@gmail.com

 I found the web UI helpful in seeing how each patch evolved since I
 last looked at it.  Interdiff relative to the version in pu is below.

Thanks for the interdiff, it really helps to be able to take a
glance without having to click around.

It seems that I can hold the topic in 'pu' a bit longer and expect a
reroll from this effort before merging it to 'next'?

 The next series from Ronnie's collection is available at
 https://code-review.googlesource.com/#/q/topic:ref-transaction in case
 someone wants a fresh series to look at.

Thanks.

 diff --git a/builtin/commit.c b/builtin/commit.c
 index 668fa6a..9bf1003 100644
 --- a/builtin/commit.c
 +++ b/builtin/commit.c
 @@ -1765,8 +1765,8 @@ int cmd_commit(int argc, const char **argv, const char 
 *prefix)
   transaction = ref_transaction_begin(err);
   if (!transaction ||
   ref_transaction_update(transaction, HEAD, sha1,
 -current_head ?
 -current_head-object.sha1 : NULL,
 +current_head
 +? current_head-object.sha1 : NULL,
  0, !!current_head, err) ||
   ref_transaction_commit(transaction, sb.buf, err)) {
   rollback_index_files();

Perhaps this is nicer, but probably most people would not care.

 diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
 index 91099ad..224fadc 100644
 --- a/builtin/receive-pack.c
 +++ b/builtin/receive-pack.c
 @@ -580,18 +580,18 @@ static char *update(struct command *cmd, struct 
 shallow_info *si)
  
   if (shallow_update  si-shallow_ref[cmd-index] 
   update_shallow_ref(cmd, si))
 - return xstrdup(shallow error);
 + return shallow error;
  
   transaction = ref_transaction_begin(err);
   if (!transaction ||
   ref_transaction_update(transaction, namespaced_name,
  new_sha1, old_sha1, 0, 1, err) ||
   ref_transaction_commit(transaction, push, err)) {
 - char *str = strbuf_detach(err, NULL);
   ref_transaction_free(transaction);
  
 - rp_error(%s, str);
 - return str;
 + rp_error(%s, err.buf);
 + strbuf_release(err);
 + return failed to update ref;
   }

I am guessing that the purpose of this change is to make sure that
cmd-error_string is taken from a fixed set of strings, not an
arbitrary collection of errors from the transaction subsystem, but
what is the significance of doing so?  Do the other side i18n while
running print_ref_status() or something?

 diff --git a/refs.h b/refs.h
 index aad846c..69ef28c 100644
 --- a/refs.h
 +++ b/refs.h
 @@ -180,8 +180,7 @@ extern int peel_ref(const char *refname, unsigned char 
 *sha1);
   */
  #define REF_NODEREF  0x01
  /*
 - * Locks any ref (for 'HEAD' type refs) and sets errno to something
 - * meaningful on failure.
 + * This function sets errno to something meaningful on failure.
   */
  extern struct ref_lock *lock_any_ref_for_update(const char *refname,
   const unsigned char *old_sha1,

To contrast this function with lock_ref_sha1() that only allowed
refs under refs/ hierarchy, the comment may have made sense, but now
that other function is gone, losing the comment makes sense.

I removed from the above the interdiff hunks I did not have any
comments or questions on.

Thanks again.
--
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

Re: Transaction patch series overview

[Jonathan Nieder]

Hi again,

Junio C Hamano wrote:

 It seems that I can hold the topic in 'pu' a bit longer and expect a
 reroll from this effort before merging it to 'next'?

Sorry for the delay.  The following changes on top of master
(refs.c: change ref_transaction_update() to do error checking and
return status, 2014-07-14) are available in the git repository at

  git://repo.or.cz/git/jrn.git tags/rs/ref-transaction-1

for you to fetch changes up to 432ad1f39fd773b37757dd8f10b3075dc3d0d0a2:

  refs.c: make delete_ref use a transaction (2014-08-26 14:22:53 -0700)


Use ref transactions, early part

Ronnie explains:

This patch series expands on the transaction API. It converts
ref updates, inside refs.c as well as external, to use the
transaction API for updates. This makes most ref updates
atomic when there are failures locking or writing to a ref.

This series teaches the tag, replace, commit, cherry-pick,
fast-import, checkout -b, branch, receive-pack, and http-fetch
commands and all update_ref and delete_ref callers to use the ref
transaction API instead of lock_ref_sha1.

The main user-visible change should be some cosmetic changes to error
messages.  The series also combines multiple ref updates into a single
transaction in 'git http-fetch -w' and when writing tags in
fast-import but otherwise doesn't change the granularity of
transactions.

Reviewed at https://code-review.googlesource.com/#/q/topic:ref-transaction-1


Ronnie Sahlberg (20):
  refs.c: change ref_transaction_create to do error checking and return 
status
  refs.c: update ref_transaction_delete to check for error and return status
  refs.c: make ref_transaction_begin take an err argument
  refs.c: add transaction.status and track OPEN/CLOSED
  tag.c: use ref transactions when doing updates
  replace.c: use the ref transaction functions for updates
  commit.c: use ref transactions for updates
  sequencer.c: use ref transactions for all ref updates
  fast-import.c: change update_branch to use ref transactions
  branch.c: use ref transaction for all ref updates
  refs.c: change update_ref to use a transaction
  receive-pack.c: use a reference transaction for updating the refs
  fast-import.c: use a ref transaction when dumping tags
  walker.c: use ref transaction for ref updates
  refs.c: make lock_ref_sha1 static
  refs.c: remove the update_ref_lock function
  refs.c: remove the update_ref_write function
  refs.c: remove lock_ref_sha1
  refs.c: make prune_ref use a transaction to delete the ref
  refs.c: make delete_ref use a transaction

 branch.c   |  31 ---
 builtin/commit.c   |  25 +++--
 builtin/receive-pack.c |  25 +++--
 builtin/replace.c  |  14 +--
 builtin/tag.c  |  16 ++--
 builtin/update-ref.c   |  14 ++-
 fast-import.c  |  54 +++
 refs.c | 244 -
 refs.h |  77 
 sequencer.c|  26 --
 walker.c   |  70 --
 11 files changed, 367 insertions(+), 229 deletions(-)

[...]
 Jonathan Nieder jrnie...@gmail.com writes:

 --- a/builtin/receive-pack.c
 +++ b/builtin/receive-pack.c
 @@ -580,18 +580,18 @@ static char *update(struct command *cmd, struct 
 shallow_info *si)
[...]
  if (!transaction ||
  ref_transaction_update(transaction, namespaced_name,
 new_sha1, old_sha1, 0, 1, err) ||
  ref_transaction_commit(transaction, push, err)) {
 -char *str = strbuf_detach(err, NULL);
  ref_transaction_free(transaction);
  
 -rp_error(%s, str);
 -return str;
 +rp_error(%s, err.buf);
 +strbuf_release(err);
 +return failed to update ref;
  }

 I am guessing that the purpose of this change is to make sure that
 cmd-error_string is taken from a fixed set of strings, not an
 arbitrary collection of errors from the transaction subsystem, but
 what is the significance of doing so?  Do the other side i18n while
 running print_ref_status() or something?

It's about keeping the message in parentheses on the ! rejected
master - master line short and simple, since the more detailed
diagnosis is redundant next to the full message that is sent over
sideband earlier and gets a line to itself.

Side effects:

 * a less invasive patch --- no more need to change the calling
   convention to return a dynamically allocated string, with
   assertions throughout the file that check for leaks

 * using the same all lowercase and brief convention makes the
   message less jarring next to other statuses for ! rejected lines,
   like 

[PATCH 0/20] rs/ref-transaction-1 (Re: Transaction patch series overview)

[Jonathan Nieder]

Jonathan Nieder wrote:

 This series teaches the tag, replace, commit, cherry-pick,
 fast-import, checkout -b, branch, receive-pack, and http-fetch
 commands and all update_ref and delete_ref callers to use the ref
 transaction API instead of lock_ref_sha1.

 The main user-visible change should be some cosmetic changes to error
 messages.  The series also combines multiple ref updates into a single
 transaction in 'git http-fetch -w' and when writing tags in
 fast-import but otherwise doesn't change the granularity of
 transactions.

 Reviewed at https://code-review.googlesource.com/#/q/topic:ref-transaction-1

 
 Ronnie Sahlberg (20):
   refs.c: change ref_transaction_create to do error checking and return 
 status
   refs.c: update ref_transaction_delete to check for error and return 
 status
   refs.c: make ref_transaction_begin take an err argument
   refs.c: add transaction.status and track OPEN/CLOSED
   tag.c: use ref transactions when doing updates
   replace.c: use the ref transaction functions for updates
   commit.c: use ref transactions for updates
   sequencer.c: use ref transactions for all ref updates
   fast-import.c: change update_branch to use ref transactions
   branch.c: use ref transaction for all ref updates
   refs.c: change update_ref to use a transaction
   receive-pack.c: use a reference transaction for updating the refs
   fast-import.c: use a ref transaction when dumping tags
   walker.c: use ref transaction for ref updates
   refs.c: make lock_ref_sha1 static
   refs.c: remove the update_ref_lock function
   refs.c: remove the update_ref_write function
   refs.c: remove lock_ref_sha1
   refs.c: make prune_ref use a transaction to delete the ref
   refs.c: make delete_ref use a transaction

And here are the patches.
--
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

Re: Transaction patch series overview

[Jonathan Nieder]

Jonathan Nieder wrote:
 Ronnie Sahlberg wrote:

 ref-transaction-1 (2014-07-16) 20 commits
 -
 Second batch of ref transactions

  - refs.c: make delete_ref use a transaction
  - refs.c: make prune_ref use a transaction to delete the ref
  - refs.c: remove lock_ref_sha1
  - refs.c: remove the update_ref_write function
  - refs.c: remove the update_ref_lock function
  - refs.c: make lock_ref_sha1 static
  - walker.c: use ref transaction for ref updates
  - fast-import.c: use a ref transaction when dumping tags
  - receive-pack.c: use a reference transaction for updating the refs
  - refs.c: change update_ref to use a transaction
  - branch.c: use ref transaction for all ref updates
  - fast-import.c: change update_branch to use ref transactions
  - sequencer.c: use ref transactions for all ref updates
  - commit.c: use ref transactions for updates
  - replace.c: use the ref transaction functions for updates
  - tag.c: use ref transactions when doing updates
  - refs.c: add transaction.status and track OPEN/CLOSED/ERROR
  - refs.c: make ref_transaction_begin take an err argument
  - refs.c: update ref_transaction_delete to check for error and return status
  - refs.c: change ref_transaction_create to do error checking and return 
 status
  (this branch is used by rs/ref-transaction, rs/ref-transaction-multi,
 rs/ref-transaction-reflog and rs/ref-transaction-rename.)
[...]
 I've having trouble keeping track of how patches change, which patches
 have been reviewed and which haven't, unaddressed comments, and so on,
 so as an experiment I've pushed this part of the series to the Gerrit
 server at

  https://code-review.googlesource.com/#/q/topic:ref-transaction-1

Outcome of the experiment: patches gained some minor changes and then

 1-12
Reviewed-by: Jonathan Nieder jrnie...@gmail.com

 13
Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Jonathan Nieder jrnie...@gmail.com

 14
Reviewed-by: Jonathan Nieder jrnie...@gmail.com

 15-16
Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Jonathan Nieder jrnie...@gmail.com

 17
Reviewed-by: Michael Haggerty mhag...@alum.mit.edu

 18
Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Jonathan Nieder jrnie...@gmail.com

 19
Reviewed-by: Jonathan Nieder jrnie...@gmail.com

 20
Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Jonathan Nieder jrnie...@gmail.com

I found the web UI helpful in seeing how each patch evolved since I
last looked at it.  Interdiff relative to the version in pu is below.
I'm still hoping for a tweak in response to a minor comment and then I
can put up a copy of the updated series to pull.

The next series from Ronnie's collection is available at
https://code-review.googlesource.com/#/q/topic:ref-transaction in case
someone wants a fresh series to look at.

diff --git a/branch.c b/branch.c
index c1eae00..37ac555 100644
--- a/branch.c
+++ b/branch.c
@@ -305,6 +305,7 @@ void create_branch(const char *head,
ref_transaction_commit(transaction, msg, err))
die(%s, err.buf);
ref_transaction_free(transaction);
+   strbuf_release(err);
}
 
if (real_ref  track)
diff --git a/builtin/commit.c b/builtin/commit.c
index 668fa6a..9bf1003 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1765,8 +1765,8 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
transaction = ref_transaction_begin(err);
if (!transaction ||
ref_transaction_update(transaction, HEAD, sha1,
-  current_head ?
-  current_head-object.sha1 : NULL,
+  current_head
+  ? current_head-object.sha1 : NULL,
   0, !!current_head, err) ||
ref_transaction_commit(transaction, sb.buf, err)) {
rollback_index_files();
@@ -1801,5 +1801,6 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
if (!quiet)
print_summary(prefix, sha1, !current_head);
 
+   strbuf_release(err);
return 0;
 }
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 91099ad..224fadc 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -194,7 +194,7 @@ static void write_head_info(void)
 
 struct command {
struct command *next;
-   char *error_string;
+   const char *error_string;
unsigned int skip_update:1,
 did_not_exist:1;
int index;
@@ -468,7 +468,7 @@ static int update_shallow_ref(struct command *cmd, struct 
shallow_info *si)
return 0;
 }
 
-static char *update(struct command *cmd, struct shallow_info *si)
+static const char *update(struct command *cmd, struct 

Re: Transaction patch series overview

[Jonathan Nieder]

Hi,

Ronnie Sahlberg wrote:

 List, please see here an overview and ordering of the ref transaction
 patch series.

Thanks much for this.

[...]
 rs/ref-transaction-0
[...]
 Has been merged into next.

This is even part of master now, so if people have review comments
then they can make them most easily by submitting new patches on top.

 ref-transaction-1 (2014-07-16) 20 commits
 -
 Second batch of ref transactions

  - refs.c: make delete_ref use a transaction
  - refs.c: make prune_ref use a transaction to delete the ref
  - refs.c: remove lock_ref_sha1
  - refs.c: remove the update_ref_write function
  - refs.c: remove the update_ref_lock function
  - refs.c: make lock_ref_sha1 static
  - walker.c: use ref transaction for ref updates
  - fast-import.c: use a ref transaction when dumping tags
  - receive-pack.c: use a reference transaction for updating the refs
  - refs.c: change update_ref to use a transaction
  - branch.c: use ref transaction for all ref updates
  - fast-import.c: change update_branch to use ref transactions
  - sequencer.c: use ref transactions for all ref updates
  - commit.c: use ref transactions for updates
  - replace.c: use the ref transaction functions for updates
  - tag.c: use ref transactions when doing updates
  - refs.c: add transaction.status and track OPEN/CLOSED/ERROR
  - refs.c: make ref_transaction_begin take an err argument
  - refs.c: update ref_transaction_delete to check for error and return status
  - refs.c: change ref_transaction_create to do error checking and return 
 status
  (this branch is used by rs/ref-transaction, rs/ref-transaction-multi,
 rs/ref-transaction-reflog and rs/ref-transaction-rename.)

  The second batch of the transactional ref update series.

 Has been merged into pu

Last reviewed at
http://thread.gmane.org/gmane.comp.version-control.git/252226, if
I am using gmane search correctly.

Are there any pending questions for this part?

I've having trouble keeping track of how patches change, which patches
have been reviewed and which haven't, unaddressed comments, and so on,
so as an experiment I've pushed this part of the series to the Gerrit
server at

 https://code-review.googlesource.com/#/q/topic:ref-transaction-1

It's running a copy of gerrit code review
(https://code.google.com/p/gerrit).

Maybe this can be useful as a way of keeping track of the state of
long and long-lived series like this one.  It works something like
this:

Preparation
---
Get a password from https://code-review.googlesource.com/new-password
and put it in netrc.

Install the hook from
https://code-review.googlesource.com/tools/hooks/commit-msg to
.git/hooks/commit-msg.  This automatically populates a Change-Id
line in the commit message if none is present so gerrit can
tell when you are uploading a new version of an existing patch.

(The commit-msg hook can be annoying when not working with gerrit
code review.  To turn it off, use 'git config gerrit.createChangeId false'.)

Uploading patches
-
Write a patch series against 'maint' or 'master' as usual, then push:

git push https://code.googlesource.com/git \
HEAD:refs/for/master; # or refs/for/maint

There can be a parameter '%topic=name' after the refs/for/branch
(e.g., refs/for/master%topic=ref-transaction-1) if the series should
be labelled with a topic name, or that can be set in the web UI or
using the HTTP API after the fact.

Commenting on patches
-
Visit https://code-review.googlesource.com.  Patches can be found
under All - Open.  Patches you're involved with somehow are
at My - Changes.

To prepare inline comments, choose a file, highlight the text to comment
on or click a line number, and comment.

To publish comments, go back up to the change overview screen (using
the up arrow button or by pressing u), click Reply, and say
something.

'?' brings up keyboard shortcuts.

Downloading patches
---
In the change overview screen, there's a 'Download' menu in the
top-right corner with commands to download the patch.

Revising patches

After modifying a patch locally using the usual tools such as rebase
--interactive, push again:

git push https://code.googlesource.com/git \
HEAD:refs/for/master; # or refs/for/maint

When a patch seems polished
---
Get rid of the Change-Id lines --- they shouldn't be needed any
more.  Send the patches or a request to pull from a public git
repository, as usual.  A link (in the top-left corner where it says
'Change 1000', the 1000 is a link to the change) can be helpful
for letting people on-list see how the patch got into the form it's
in today.

Maybe it can be useful.

Thanks,
Jonathan
--
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

Re: Transaction patch series overview

[Ronnie Sahlberg]

List, please see here an overview and ordering of the ref transaction
patch series.
These series build on each other and needs to be applied in the order
listed below.

This is an update.




rs/ref-transaction-0
---
Early part of the ref transaction topic.

* rs/ref-transaction-0:
  refs.c: change ref_transaction_update() to do error checking and
return status
  refs.c: remove the onerr argument to ref_transaction_commit
  update-ref: use err argument to get error from ref_transaction_commit
  refs.c: make update_ref_write update a strbuf on failure
  refs.c: make ref_update_reject_duplicates take a strbuf argument
for errors
  refs.c: log_ref_write should try to return meaningful errno
  refs.c: make resolve_ref_unsafe set errno to something meaningful on error
  refs.c: commit_packed_refs to return a meaningful errno on failure
  refs.c: make remove_empty_directories always set errno to something sane
  refs.c: verify_lock should set errno to something meaningful
  refs.c: make sure log_ref_setup returns a meaningful errno
  refs.c: add an err argument to repack_without_refs
  lockfile.c: make lock_file return a meaningful errno on failurei
  lockfile.c: add a new public function unable_to_lock_message
  refs.c: add a strbuf argument to ref_transaction_commit for error logging
  refs.c: allow passing NULL to ref_transaction_free
  refs.c: constify the sha arguments for
ref_transaction_create|delete|update
  refs.c: ref_transaction_commit should not free the transaction
  refs.c: remove ref_transaction_rollback

Has been merged into next.



ref-transaction-1 (2014-07-16) 20 commits
-
Second batch of ref transactions

 - refs.c: make delete_ref use a transaction
 - refs.c: make prune_ref use a transaction to delete the ref
 - refs.c: remove lock_ref_sha1
 - refs.c: remove the update_ref_write function
 - refs.c: remove the update_ref_lock function
 - refs.c: make lock_ref_sha1 static
 - walker.c: use ref transaction for ref updates
 - fast-import.c: use a ref transaction when dumping tags
 - receive-pack.c: use a reference transaction for updating the refs
 - refs.c: change update_ref to use a transaction
 - branch.c: use ref transaction for all ref updates
 - fast-import.c: change update_branch to use ref transactions
 - sequencer.c: use ref transactions for all ref updates
 - commit.c: use ref transactions for updates
 - replace.c: use the ref transaction functions for updates
 - tag.c: use ref transactions when doing updates
 - refs.c: add transaction.status and track OPEN/CLOSED/ERROR
 - refs.c: make ref_transaction_begin take an err argument
 - refs.c: update ref_transaction_delete to check for error and return status
 - refs.c: change ref_transaction_create to do error checking and return status
 (this branch is used by rs/ref-transaction, rs/ref-transaction-multi,
rs/ref-transaction-reflog and rs/ref-transaction-rename.)

 The second batch of the transactional ref update series.

Has been merged into pu



rs/ref-transaction (2014-07-17) 12 commits
-
 - refs.c: fix handling of badly named refs
 - refs.c: make write_ref_sha1 static
 - fetch.c: change s_update_ref to use a ref transaction
 - refs.c: propagate any errno==ENOTDIR from _commit back to the callers
 - refs.c: pass a skip list to name_conflict_fn
 - refs.c: call lock_ref_sha1_basic directly from commit
 - refs.c: move the check for valid refname to lock_ref_sha1_basic
 - refs.c: pass NULL as *flags to read_ref_full
 - refs.c: pass the ref log message to _create/delete/update instead of _commit
 - refs.c: add an err argument to delete_ref_loose
 - wrapper.c: add a new function unlink_or_msg
 - wrapper.c: simplify warn_if_unremovable
 (this branch is used by rs/ref-transaction-multi,
rs/ref-transaction-reflog and rs/ref-transaction-rename; uses
rs/ref-transaction-1.)

The third and final part of the basic ref-transaction work.

Has been merged into pu.




rs/ref-transaction-reflog (2014-07-23) 15 commits
---
 - refs.c: allow deleting refs with a broken sha1
 - refs.c: remove lock_any_ref_for_update
 - refs.c: make unlock_ref/close_ref/commit_ref static
 - refs.c: rename log_ref_setup to create_reflog
 - reflog.c: use a reflog transaction when writing during expire
 - refs.c: allow multiple reflog updates during a single transaction
 - refs.c: only write reflog update if msg is non-NULL
 - refs.c: add a flag to allow reflog updates to truncate the log
 - refs.c: add a transaction function to append a reflog entry
 - lockfile.c: make hold_lock_file_for_append preserve meaningful errno
 - refs.c: add a function to append a reflog entry to a fd
 - refs.c: add a new update_type field to ref_update
 - refs.c: rename the transaction functions
 - 

Re: Transaction patch series overview

[Junio C Hamano]

Ronnie Sahlberg sahlb...@google.com writes:

 List, please see here an overview and ordering of the ref transaction
 patch series.
 These series build on each other and needs to be applied in the order
 listed below.

 This is an update.

 rs/ref-transaction-0
 ---
 Early part of the ref transaction topic.

 * rs/ref-transaction-0:
   refs.c: change ref_transaction_update() to do error checking and
 return status
   refs.c: remove the onerr argument to ref_transaction_commit
   update-ref: use err argument to get error from ref_transaction_commit
   refs.c: make update_ref_write update a strbuf on failure
   refs.c: make ref_update_reject_duplicates take a strbuf argument
 for errors
   refs.c: log_ref_write should try to return meaningful errno
   refs.c: make resolve_ref_unsafe set errno to something meaningful on 
 error
   refs.c: commit_packed_refs to return a meaningful errno on failure
   refs.c: make remove_empty_directories always set errno to something sane
   refs.c: verify_lock should set errno to something meaningful
   refs.c: make sure log_ref_setup returns a meaningful errno
   refs.c: add an err argument to repack_without_refs
   lockfile.c: make lock_file return a meaningful errno on failurei
   lockfile.c: add a new public function unable_to_lock_message
   refs.c: add a strbuf argument to ref_transaction_commit for error 
 logging
   refs.c: allow passing NULL to ref_transaction_free
   refs.c: constify the sha arguments for
 ref_transaction_create|delete|update
   refs.c: ref_transaction_commit should not free the transaction
   refs.c: remove ref_transaction_rollback

 Has been merged into next.

I gave a quick re-read-thru on this and did not find anything
questionable, nor recall any issue pending.  Unless somebody
objects in the coming few days, let's move it to 'master' as part of
the first batch for 2.2.

 ref-transaction-1 (2014-07-16) 20 commits
 ...
  The second batch of the transactional ref update series.

 Has been merged into pu

 rs/ref-transaction (2014-07-17) 12 commits
 ...
 The third and final part of the basic ref-transaction work.
 
 Has been merged into pu.

I'll re-read these two before deciding to merge them to 'next'.  Any
pending issues from the previous discussions?

 This series is for once the previous transaction changes are in and
 this series will add
 a new backend for refs: refs-be-db.c which offloads all refs access to
 an external database daemon.
 An example reference implementation for an external daemon is also
 provided and can be used as basis for
 creating a daemon to plug into, say, a SQL database or similar.

A filesystem based backend/external daemon that is compatible with
the traditional on-disk format might be another fun demonstration.

Looking forward to shepherding the whole thing ahead ;-)  The most
fun part awaits us but there is a long way.

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://vger.kernel.org/majordomo-info.html

Re: Transaction patch series overview

[Ronnie Sahlberg]

List, please see here an overview and ordering of the ref transaction
patch series.
These series build on each other and needs to be applied in the order
listed below.

This is an update.




rs/ref-transaction-0
---
Early part of the ref transaction topic.

* rs/ref-transaction-0:
  refs.c: change ref_transaction_update() to do error checking and
return status
  refs.c: remove the onerr argument to ref_transaction_commit
  update-ref: use err argument to get error from ref_transaction_commit
  refs.c: make update_ref_write update a strbuf on failure
  refs.c: make ref_update_reject_duplicates take a strbuf argument
for errors
  refs.c: log_ref_write should try to return meaningful errno
  refs.c: make resolve_ref_unsafe set errno to something meaningful on error
  refs.c: commit_packed_refs to return a meaningful errno on failure
  refs.c: make remove_empty_directories always set errno to something sane
  refs.c: verify_lock should set errno to something meaningful
  refs.c: make sure log_ref_setup returns a meaningful errno
  refs.c: add an err argument to repack_without_refs
  lockfile.c: make lock_file return a meaningful errno on failurei
  lockfile.c: add a new public function unable_to_lock_message
  refs.c: add a strbuf argument to ref_transaction_commit for error logging
  refs.c: allow passing NULL to ref_transaction_free
  refs.c: constify the sha arguments for
ref_transaction_create|delete|update
  refs.c: ref_transaction_commit should not free the transaction
  refs.c: remove ref_transaction_rollback

Has been merged into next.



ref-transaction-1 (2014-07-16) 20 commits
-
Second batch of ref transactions

 - refs.c: make delete_ref use a transaction
 - refs.c: make prune_ref use a transaction to delete the ref
 - refs.c: remove lock_ref_sha1
 - refs.c: remove the update_ref_write function
 - refs.c: remove the update_ref_lock function
 - refs.c: make lock_ref_sha1 static
 - walker.c: use ref transaction for ref updates
 - fast-import.c: use a ref transaction when dumping tags
 - receive-pack.c: use a reference transaction for updating the refs
 - refs.c: change update_ref to use a transaction
 - branch.c: use ref transaction for all ref updates
 - fast-import.c: change update_branch to use ref transactions
 - sequencer.c: use ref transactions for all ref updates
 - commit.c: use ref transactions for updates
 - replace.c: use the ref transaction functions for updates
 - tag.c: use ref transactions when doing updates
 - refs.c: add transaction.status and track OPEN/CLOSED/ERROR
 - refs.c: make ref_transaction_begin take an err argument
 - refs.c: update ref_transaction_delete to check for error and return status
 - refs.c: change ref_transaction_create to do error checking and return status
 (this branch is used by rs/ref-transaction, rs/ref-transaction-multi,
rs/ref-transaction-reflog and rs/ref-transaction-rename.)

 The second batch of the transactional ref update series.

Has been merged into pu



rs/ref-transaction (2014-07-17) 12 commits
-
 - refs.c: fix handling of badly named refs
 - refs.c: make write_ref_sha1 static
 - fetch.c: change s_update_ref to use a ref transaction
 - refs.c: propagate any errno==ENOTDIR from _commit back to the callers
 - refs.c: pass a skip list to name_conflict_fn
 - refs.c: call lock_ref_sha1_basic directly from commit
 - refs.c: move the check for valid refname to lock_ref_sha1_basic
 - refs.c: pass NULL as *flags to read_ref_full
 - refs.c: pass the ref log message to _create/delete/update instead of _commit
 - refs.c: add an err argument to delete_ref_loose
 - wrapper.c: add a new function unlink_or_msg
 - wrapper.c: simplify warn_if_unremovable
 (this branch is used by rs/ref-transaction-multi,
rs/ref-transaction-reflog and rs/ref-transaction-rename; uses
rs/ref-transaction-1.)

The third and final part of the basic ref-transaction work.

Has been merged into pu.




rs/ref-transaction-reflog (2014-07-23) 15 commits
---
 - refs.c: allow deleting refs with a broken sha1
 - refs.c: remove lock_any_ref_for_update
 - refs.c: make unlock_ref/close_ref/commit_ref static
 - refs.c: rename log_ref_setup to create_reflog
 - reflog.c: use a reflog transaction when writing during expire
 - refs.c: allow multiple reflog updates during a single transaction
 - refs.c: only write reflog update if msg is non-NULL
 - refs.c: add a flag to allow reflog updates to truncate the log
 - refs.c: add a transaction function to append a reflog entry
 - lockfile.c: make hold_lock_file_for_append preserve meaningful errno
 - refs.c: add a function to append a reflog entry to a fd
 - refs.c: add a new update_type field to ref_update
 - refs.c: rename the transaction functions
 - 

Re: Transaction patch series overview

[Ronnie Sahlberg]

List, please see here an overview and ordering of the ref transaction
patch series.
These series build on each other and needs to be applied in the order
listed below.

This is an update.



rs/ref-transaction-0
---
Early part of the ref transaction topic.

* rs/ref-transaction-0:
  refs.c: change ref_transaction_update() to do error checking and
return status
  refs.c: remove the onerr argument to ref_transaction_commit
  update-ref: use err argument to get error from ref_transaction_commit
  refs.c: make update_ref_write update a strbuf on failure
  refs.c: make ref_update_reject_duplicates take a strbuf argument
for errors
  refs.c: log_ref_write should try to return meaningful errno
  refs.c: make resolve_ref_unsafe set errno to something meaningful on error
  refs.c: commit_packed_refs to return a meaningful errno on failure
  refs.c: make remove_empty_directories always set errno to something sane
  refs.c: verify_lock should set errno to something meaningful
  refs.c: make sure log_ref_setup returns a meaningful errno
  refs.c: add an err argument to repack_without_refs
  lockfile.c: make lock_file return a meaningful errno on failurei
  lockfile.c: add a new public function unable_to_lock_message
  refs.c: add a strbuf argument to ref_transaction_commit for error logging
  refs.c: allow passing NULL to ref_transaction_free
  refs.c: constify the sha arguments for
ref_transaction_create|delete|update
  refs.c: ref_transaction_commit should not free the transaction
  refs.c: remove ref_transaction_rollback

Has been merged into next.



ref-transaction-1 (2014-07-16) 20 commits
-
Second batch of ref transactions

 - refs.c: make delete_ref use a transaction
 - refs.c: make prune_ref use a transaction to delete the ref
 - refs.c: remove lock_ref_sha1
 - refs.c: remove the update_ref_write function
 - refs.c: remove the update_ref_lock function
 - refs.c: make lock_ref_sha1 static
 - walker.c: use ref transaction for ref updates
 - fast-import.c: use a ref transaction when dumping tags
 - receive-pack.c: use a reference transaction for updating the refs
 - refs.c: change update_ref to use a transaction
 - branch.c: use ref transaction for all ref updates
 - fast-import.c: change update_branch to use ref transactions
 - sequencer.c: use ref transactions for all ref updates
 - commit.c: use ref transactions for updates
 - replace.c: use the ref transaction functions for updates
 - tag.c: use ref transactions when doing updates
 - refs.c: add transaction.status and track OPEN/CLOSED/ERROR
 - refs.c: make ref_transaction_begin take an err argument
 - refs.c: update ref_transaction_delete to check for error and return status
 - refs.c: change ref_transaction_create to do error checking and return status
 (this branch is used by rs/ref-transaction, rs/ref-transaction-multi,
rs/ref-transaction-reflog and rs/ref-transaction-rename.)

 The second batch of the transactional ref update series.

Has been merged into pu



rs/ref-transaction (2014-07-17) 12 commits
-
 - refs.c: fix handling of badly named refs
 - refs.c: make write_ref_sha1 static
 - fetch.c: change s_update_ref to use a ref transaction
 - refs.c: propagate any errno==ENOTDIR from _commit back to the callers
 - refs.c: pass a skip list to name_conflict_fn
 - refs.c: call lock_ref_sha1_basic directly from commit
 - refs.c: move the check for valid refname to lock_ref_sha1_basic
 - refs.c: pass NULL as *flags to read_ref_full
 - refs.c: pass the ref log message to _create/delete/update instead of _commit
 - refs.c: add an err argument to delete_ref_loose
 - wrapper.c: add a new function unlink_or_msg
 - wrapper.c: simplify warn_if_unremovable
 (this branch is used by rs/ref-transaction-multi,
rs/ref-transaction-reflog and rs/ref-transaction-rename; uses
rs/ref-transaction-1.)

The third and final part of the basic ref-transaction work.

Has been merged into pu.




rs/ref-transaction-reflog (2014-07-23) 15 commits
---
 - refs.c: allow deleting refs with a broken sha1
 - refs.c: remove lock_any_ref_for_update
 - refs.c: make unlock_ref/close_ref/commit_ref static
 - refs.c: rename log_ref_setup to create_reflog
 - reflog.c: use a reflog transaction when writing during expire
 - refs.c: allow multiple reflog updates during a single transaction
 - refs.c: only write reflog update if msg is non-NULL
 - refs.c: add a flag to allow reflog updates to truncate the log
 - refs.c: add a transaction function to append a reflog entry
 - lockfile.c: make hold_lock_file_for_append preserve meaningful errno
 - refs.c: add a function to append a reflog entry to a fd
 - refs.c: add a new update_type field to ref_update
 - refs.c: rename the transaction functions
 - 

Transaction patch series overview

[Ronnie Sahlberg]

List, please see here an overview and ordering of the ref transaction
patch series.
These series build on each other and needs to be applied in the order
listed below.


rs/ref-transaction-0
---
Early part of the ref transaction topic.

* rs/ref-transaction-0:
  refs.c: change ref_transaction_update() to do error checking and
return status
  refs.c: remove the onerr argument to ref_transaction_commit
  update-ref: use err argument to get error from ref_transaction_commit
  refs.c: make update_ref_write update a strbuf on failure
  refs.c: make ref_update_reject_duplicates take a strbuf argument
for errors
  refs.c: log_ref_write should try to return meaningful errno
  refs.c: make resolve_ref_unsafe set errno to something meaningful on error
  refs.c: commit_packed_refs to return a meaningful errno on failure
  refs.c: make remove_empty_directories always set errno to something sane
  refs.c: verify_lock should set errno to something meaningful
  refs.c: make sure log_ref_setup returns a meaningful errno
  refs.c: add an err argument to repack_without_refs
  lockfile.c: make lock_file return a meaningful errno on failurei
  lockfile.c: add a new public function unable_to_lock_message
  refs.c: add a strbuf argument to ref_transaction_commit for error logging
  refs.c: allow passing NULL to ref_transaction_free
  refs.c: constify the sha arguments for
ref_transaction_create|delete|update
  refs.c: ref_transaction_commit should not free the transaction
  refs.c: remove ref_transaction_rollback

Has been merged into next.



ref-transaction-1 (2014-07-16) 20 commits
-
Second batch of ref transactions

 - refs.c: make delete_ref use a transaction
 - refs.c: make prune_ref use a transaction to delete the ref
 - refs.c: remove lock_ref_sha1
 - refs.c: remove the update_ref_write function
 - refs.c: remove the update_ref_lock function
 - refs.c: make lock_ref_sha1 static
 - walker.c: use ref transaction for ref updates
 - fast-import.c: use a ref transaction when dumping tags
 - receive-pack.c: use a reference transaction for updating the refs
 - refs.c: change update_ref to use a transaction
 - branch.c: use ref transaction for all ref updates
 - fast-import.c: change update_branch to use ref transactions
 - sequencer.c: use ref transactions for all ref updates
 - commit.c: use ref transactions for updates
 - replace.c: use the ref transaction functions for updates
 - tag.c: use ref transactions when doing updates
 - refs.c: add transaction.status and track OPEN/CLOSED/ERROR
 - refs.c: make ref_transaction_begin take an err argument
 - refs.c: update ref_transaction_delete to check for error and return status
 - refs.c: change ref_transaction_create to do error checking and return status
 (this branch is used by rs/ref-transaction, rs/ref-transaction-multi,
rs/ref-transaction-reflog and rs/ref-transaction-rename.)

 The second batch of the transactional ref update series.

Has been merged into pu



rs/ref-transaction (2014-07-17) 12 commits
-
 - refs.c: fix handling of badly named refs
 - refs.c: make write_ref_sha1 static
 - fetch.c: change s_update_ref to use a ref transaction
 - refs.c: propagate any errno==ENOTDIR from _commit back to the callers
 - refs.c: pass a skip list to name_conflict_fn
 - refs.c: call lock_ref_sha1_basic directly from commit
 - refs.c: move the check for valid refname to lock_ref_sha1_basic
 - refs.c: pass NULL as *flags to read_ref_full
 - refs.c: pass the ref log message to _create/delete/update instead of _commit
 - refs.c: add an err argument to delete_ref_loose
 - wrapper.c: add a new function unlink_or_msg
 - wrapper.c: simplify warn_if_unremovable
 (this branch is used by rs/ref-transaction-multi,
rs/ref-transaction-reflog and rs/ref-transaction-rename; uses
rs/ref-transaction-1.)

The third and final part of the basic ref-transaction work.

Has been merged into pu.




rs/ref-transaction-reflog (2014-07-23) 15 commits
---
 - refs.c: allow deleting refs with a broken sha1
 - refs.c: remove lock_any_ref_for_update
 - refs.c: make unlock_ref/close_ref/commit_ref static
 - refs.c: rename log_ref_setup to create_reflog
 - reflog.c: use a reflog transaction when writing during expire
 - refs.c: allow multiple reflog updates during a single transaction
 - refs.c: only write reflog update if msg is non-NULL
 - refs.c: add a flag to allow reflog updates to truncate the log
 - refs.c: add a transaction function to append a reflog entry
 - lockfile.c: make hold_lock_file_for_append preserve meaningful errno
 - refs.c: add a function to append a reflog entry to a fd
 - refs.c: add a new update_type field to ref_update
 - refs.c: rename the transaction functions
 - refs.c: make