Alex Davidson wrote:
> On Fri, 2014-04-25 at 20:36 -0500, Felipe Contreras wrote:
> > Jeff King wrote:
> > > If you are waiting on me, I do not have much else to say on this topic.
> > > @{publish} as specified by Felipe is not useful to me, and I would
> > > continue to pursue @{push} separately a
On 24 Apr 2014 11:52, wrote:
>
> From: James Denholm
>
> contrib/subtree/Makefile is a shambles in regards to it's consistency
> with other makefiles, which makes subtree overly painful to include in
> build scripts.
>
> Two major issues are present:
>
> Firstly, calls to git itself (for $(gitd
On Fri, Apr 25, 2014 at 08:36:55PM -0500, Felipe Contreras wrote:
> > As for the patches themselves, I have not reviewed them carefully, and
> > would prefer not to. As I mentioned before, though, I would prefer the
> > short "@{p}" not be taken for @{publish} until it has proven itself.
>
> Pres
On Fri, 2014-04-25 at 20:36 -0500, Felipe Contreras wrote:
> Jeff King wrote:
> > If you are waiting on me, I do not have much else to say on this topic.
> > @{publish} as specified by Felipe is not useful to me, and I would
> > continue to pursue @{push} separately as "the remote-tracking branch o
Jeff King wrote:
> On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
> > * fc/publish-vs-upstream (2014-04-21) 8 commits
> > - sha1_name: add support for @{publish} marks
> > - sha1_name: simplify track finding
> > - sha1_name: cleanup interpret_branch_name()
> > - branch: displa
Max Horn wrote:
> I am going to step away from this painful discussion and also this mailing
> list, but I owed it to send one last reply with two of the problems I am
> still seeing, simply in the hope that this will benefit some future
> git-remote-hg users, but also to dispel any claims I was "h
On 25 April 2014 11:12, Felipe Contreras wrote:
> It has been discussed many times in the past that 'index' is not an
> appropriate description for what the high-level user does with it, and
> it has been agreed that 'staging area' is the best term.
>
> The term 'staging area' is more intuitive fo
On 04/25/2014 06:14 PM, Ronnie Sahlberg wrote:
> Change ref_transaction_commit to take a pointer to a pointer for the
> transaction. This allows us to clear the transaction pointer from within
> ref_transaction_commit so that it becomes NULL in the caller.
>
> This makes transaction handling in th
On Fri, Apr 25, 2014 at 4:56 PM, David Kastrup wrote:
> The previous implementation used a single sorted linear list of blame
> entries for organizing all partial or completed work. Every subtask had
> to scan the whole list, with most entries not being relevant to the
> task. The resulting run-
The previous implementation used a single sorted linear list of blame
entries for organizing all partial or completed work. Every subtask had
to scan the whole list, with most entries not being relevant to the
task. The resulting run-time was quadratic to the number of separate
chunks.
This chan
Includes reasonably tasteful begging.
Signed-off-by: David Kastrup
---
Documentation/RelNotes/2.0.0.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/RelNotes/2.0.0.txt b/Documentation/RelNotes/2.0.0.txt
index ffd4899..27b23c3 100644
--- a/Documentation/RelNotes/2.0.0.t
On 04/25/2014 06:14 PM, Ronnie Sahlberg wrote:
> Change the update_ref helper function to use a ref transaction internally.
>
> Signed-off-by: Ronnie Sahlberg
> ---
> refs.c | 23 +++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index
New keywords: foreach, break, in, try, finally, as, is, typeof, var,
default, fixed, checked, unchecked, this, lock, readonly, unsafe,
ref, out, base, null, delegate, continue.
Removed keywords: instanceof. It's only in Java.
Moved keywords to happen before modifier parsing, as matching a keyword
On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
> * jk/external-diff-use-argv-array (2014-04-21) 6 commits
> (merged to 'next' on 2014-04-22 at e6d92d7)
> + run_external_diff: refactor cmdline setup logic
> + run_external_diff: hoist common bits out of conditional
> + run_exte
On 04/25/2014 06:14 PM, Ronnie Sahlberg wrote:
> Change create_branch to use a ref transaction when creating the new branch.
> ref_transaction_create will check that the ref does not already exist and fail
> otherwise meaning that we no longer need to keep a lock on the ref during the
> setup_track
When we pick another commit's message, we die() immediately
if we find that it's empty and we are not going to run an
editor (i.e., when running "-C" instead of "-c"). However,
this check is redundant and harmful.
It's redundant because we will already notice the empty
message later, after we wou
Andrew Ardill writes:
As a data point, I have seen people add ".gitignore" to their
.gitignore file, as they don't want to share the file.
Right, I've seen that too. It confused the heck out of me. It only lends
credence to my point about the docs. Those users want the functionality
of a pat
On 04/25/2014 06:14 PM, Ronnie Sahlberg wrote:
> Update replace.c to use ref transactions for updates.
>
> Signed-off-by: Ronnie Sahlberg
> ---
> builtin/replace.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/replace.c b/builtin/replace.c
> ind
On 04/25/2014 06:14 PM, Ronnie Sahlberg wrote:
> Change tag.c to use ref transactions for all ref updates.
>
> Signed-off-by: Ronnie Sahlberg
> ---
> builtin/tag.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/tag.c b/builtin/tag.c
> index 40356
On Wed, Apr 23, 2014 at 06:43:56AM -0700, Elia Pinto wrote:
> @@ -25,11 +25,11 @@ fi
>
> cd - > /dev/null
>
> -SUBJECT=`sed -n -e '/^Subject: /p' "${PATCH}"`
> -HEADERS=`sed -e '/^'"${SEP}"'$/,$d' $1`
> -BODY=`sed -e "1,/${SEP}/d" $1`
> -CMT_MSG=`sed -e '1,/^$/d' -e '/^---$/,$d' "${PATCH}"`
>
A release candidate Git v2.0.0-rc1 is now available for testing
at the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the 'v2.0.0-rc1'
tag and the 'master' branch that the tag points at:
ur
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of the 'master' branch is at v2.0.0-rc1. Last minute fixes
to newly added code keep flowing in, which is good.
You can find the change
Ronnie Sahlberg wrote:
> Since we now pass meaningful error messages back from ref_transaction_commit
> on failures, we no longer need to provide a onerr argument.
Yay! More precisely, now that all callers use
UPDATE_REFS_QUIET_ON_ERR there's no need to support any other
behavior.
Thanks for cl
Ronnie Sahlberg wrote:
> Change update_ref_write to also return an error string on failure.
> This makes the error avaialbel to ref_transaction_commit callers if the
> transaction failed dur to update_ref_sha1/write_ref_sha1 failures.
Nits:
* available
* during
Probably should come right afte
Hi,
I am going to step away from this painful discussion and also this mailing
list, but I owed it to send one last reply with two of the problems I am
still seeing, simply in the hope that this will benefit some future
git-remote-hg users, but also to dispel any claims I was "hoarding" bugs to
so
Ronnie Sahlberg wrote:
> Call ref_transaction_commit with QUIET_ON_ERR and use the error string
> that is returned to print a better log message if/after the transaction
> fails.
Ah, so that's how the transition to a better API happens. Makes sense.
(A mention of QUIET_ON_ERR in the patch that
Ronnie Sahlberg wrote:
> --- a/refs.c
> +++ b/refs.c
> @@ -3393,6 +3393,7 @@ static int ref_update_compare(const void *r1, const
> void *r2)
> }
>
> static int ref_update_reject_duplicates(struct ref_update **updates, int n,
> + char **err,
>
Ronnie Sahlberg wrote:
> Let ref_transaction_commit return an optional error string that describes
> the transaction failure. Start by returning the same error as update_ref_lock
> returns, modulo the initial error:/fatal: preamble.
s/returns/prints/?
> This will make it easier for callers to c
On Fri, Apr 25, 2014 at 2:53 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> This patch series changes most of the places where the ref functions for
>> locking and writing refs to instead use the new ref transaction API.
>
> Thanks. Is this series based against mh/ref-transaction from "
Ronnie Sahlberg wrote:
> This patch series changes most of the places where the ref functions for
> locking and writing refs to instead use the new ref transaction API.
Thanks. Is this series based against mh/ref-transaction from "next"?
[...]
> I think I have covered all issues raised on the p
Hi,
Ronnie Sahlberg wrote:
> Update ref_transaction_update() do some basic error checking and return
> true on error. Update all callers to check ref_transaction_update() for error.
Micronit: nonzero, not true. (true tends to mean '1' while here we
have the usual error return of -1. It's kind
Ralf Thielow writes:
> Translate 45 new messages came from git.pot update in 5e078fc
> (l10n: git.pot: v2.0.0 round 1 (45 new, 28 removed)).
Thanks for sending this with extra context, it really helps reviewing!
With the small changes below,
Acked-by: Thomas Rast
> #: diffcore-rename.c:517
From: Michael Haggerty
>
> On 04/08/2014 01:35 PM, Christian Couder wrote:
>>
>> The trailers are recognized in the input commit message using the
>> following rules:
>> - only lines that contains a ':' are considered trailers,
>> - the trailer lines must all be next to each other,
>> - after
Signed-off-by: Ralf Thielow
---
I'll queue this as part of the German l10n changes for
the next release.
po/de.po | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/po/de.po b/po/de.po
index b777ef4..d143572 100644
--- a/po/de.po
+++ b/po/de.po
@@ -555,12 +555,12 @@ msgid ""
On Fri, 25 April 2014 20:49:52 +0200, Matthieu Moy wrote:
> Jörn Engel writes:
> > On Mon, 21 April 2014 16:46:22 -0400, Jörn Engel wrote:
> >>
> >> This reverts commit 88e8f908f2b0c56f9ccf8134d8ff9f689af9cc84.
> >>
> >> Caused a usability regression for me and foul language for my coworkers.
>
From: Junio C Hamano
>
> Christian Couder writes:
>
>> +Help add RFC 822-like headers, called 'trailers', at the end of the
>> +otherwise free-form part of a commit message.
>
> I think it is somewhat misleading to use the word "headers" like
> that. 'trailers' look similar to RFC-822-headers
Jeff King wrote:
> On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote:
>
> > > Maybe I was not clear in my response, so let me try again. I do _not_
> > > necessarily agree that we need to move away from the name index.
> >
> > So you agree that "the index" is a bad name, and you ag
Let the user specify a command that will give on its standard output
the value to use for the specified trailer.
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
trailer.c | 65 +++
1 file changed, 65 insertions(+)
di
We will use a doubly linked list to store all information
about trailers and their configuration.
This way we can easily remove or add trailers to or from
trailer lists while traversing the lists in either direction.
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
Makefile |
This patch adds the process_trailers() function that
calls all the previously added processing functions
and then prints the results on the standard output.
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
trailer.c | 58 +
And add a few other tests for some special cases.
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
t/t7513-interpret-trailers.sh | 124 ++
1 file changed, 124 insertions(+)
diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-t
This patch adds the "git interpret-trailers" command.
This command uses the previously added process_trailers()
function in trailer.c.
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
.gitignore | 1 +
Makefile | 1 +
builtin.h
On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote:
> > Maybe I was not clear in my response, so let me try again. I do _not_
> > necessarily agree that we need to move away from the name index.
>
> So you agree that "the index" is a bad name, and you agree "staging area" is a
> bet
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
t/t7513-interpret-trailers.sh | 418 ++
1 file changed, 418 insertions(+)
create mode 100755 t/t7513-interpret-trailers.sh
diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-tr
While at it add git-interpret-trailers to "command-list.txt".
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
Documentation/git-interpret-trailers.txt | 143 +++
command-list.txt | 1 +
2 files changed, 144 insertions(+)
c
This patch series implements a new command:
git interpret-trailers
and an infrastructure to process trailers that can be reused,
for example in "commit.c".
1) Rationale:
This command should help with RFC 822 style headers, called
"trailers", that are found at the end of commit messages.
Read trailers from a file or from stdin, parse the trailers and then
put the result into a doubly linked list.
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
trailer.c | 116 ++
1 file changed, 116 insertions(+)
dif
Jeff King wrote:
> On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote:
>
> > I specifically said everybody agreed to "move away from the name 'index'", I
> > didn't say everybody agreed on the "staged area" although the vast majority
> > did, and I didn't say anybody agreed on my pat
Parse the trailer command line arguments and put
the result into an arg_tok doubly linked list.
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
trailer.c | 118 ++
1 file changed, 118 insertions(+)
diff --git a/trail
Read the configuration to get trailer information, and then process
it and store it in a doubly linked list.
The config information is stored in the list whose first item is
pointed to by:
static struct trailer_item *first_conf_item;
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
Implement the logic to process trailers from the input message
and from arguments.
At the beginning trailers from the input message are in their
own "in_tok" doubly linked list, and trailers from arguments
are in their own "arg_tok" doubly linked list.
The lists are traversed and when an "arg_tok
On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote:
> I specifically said everybody agreed to "move away from the name 'index'", I
> didn't say everybody agreed on the "staged area" although the vast majority
> did, and I didn't say anybody agreed on my patches, although some did.
>
Jörn Engel writes:
> On Mon, 21 April 2014 16:46:22 -0400, Jörn Engel wrote:
>>
>> This reverts commit 88e8f908f2b0c56f9ccf8134d8ff9f689af9cc84.
>>
>> Caused a usability regression for me and foul language for my coworkers.
>
> Ping.
How do you solve the problem that the commit you revert was
Jeff King wrote:
> On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote:
>
> > When I say literally everbody agreed to move away from the name "index"
> > (except
> > Junio and another guy) I mean it. I even composed a list:
> >
> > http://article.gmane.org/gmane.comp.version-control
Hi,
I am one of the three selected GSoC(Google summer of Code) students by
Git this year.
I am a third year computer science student from India. First, I want to thank
you all for guiding me through the patch review process and being
patient with me. I learned a lot from you all
and this helped me
On Mon, 21 April 2014 16:46:22 -0400, Jörn Engel wrote:
>
> This reverts commit 88e8f908f2b0c56f9ccf8134d8ff9f689af9cc84.
>
> Caused a usability regression for me and foul language for my coworkers.
Ping.
Jörn
--
People really ought to be forced to read their code aloud over the phone.
That wo
On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote:
> When I say literally everbody agreed to move away from the name "index"
> (except
> Junio and another guy) I mean it. I even composed a list:
>
> http://article.gmane.org/gmane.comp.version-control.git/233469
>
> Jeff King, Jon
Signed-off-by: Felipe Contreras
---
Documentation/git-stage.txt| 5 +++
builtin/stage.c| 74 ++
contrib/completion/git-completion.bash | 4 +-
3 files changed, 82 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-sta
Synonym for --cached.
Signed-off-by: Felipe Contreras
---
Documentation/git-submodule.txt | 8 ++--
git-submodule.sh| 10 +-
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index bfef8a
Synonym of --index.
Signed-off-by: Felipe Contreras
---
Documentation/git-stash.txt | 8
git-stash.sh| 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 21a01c2..5fdaa35 100644
--- a/Doc
Synonym for --index.
Signed-off-by: Felipe Contreras
---
Documentation/git-apply.txt | 5 -
builtin/apply.c | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index f605327..8c047ef 100644
--- a/Document
Signed-off-by: Felipe Contreras
---
contrib/completion/git-completion.bash | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 2ec7b1a..52d83f2 100644
--- a/contrib/completion/git-com
'git apply', 'git apply --index', 'git apply --cached' do different
things, but what they do is not precisely clear, specially since no
other commands has similar distinctions.
With --no-work (--work being the default), it's clear what the option
would do; modify, or not, the working directory.
S
--no-stage is synonym for --keep-index.
Signed-off-by: Felipe Contreras
---
Documentation/git-stash.txt | 6 +++---
git-stash.sh| 8 +++-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index db7e803..2
Synonym for --cached.
Signed-off-by: Felipe Contreras
---
Documentation/git-rm.txt | 5 -
builtin/rm.c | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index f1efc11..458880b 100644
--- a/Documentation/git-rm
Synonym for --cached.
Signed-off-by: Felipe Contreras
---
Documentation/git-grep.txt | 5 -
builtin/grep.c | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index f837334..6ed84d7 100644
--- a/Documentati
Signed-off-by: Felipe Contreras
---
Documentation/git-reset.txt | 2 +-
builtin/reset.c | 13 ++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 5cd75a8..a1419c9 100644
--- a/Documentation/git-
Signed-off-by: Felipe Contreras
---
Documentation/git-reset.txt | 8
builtin/reset.c | 20
2 files changed, 28 insertions(+)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index f445cb3..5cd75a8 100644
--- a/Documentation/git-res
Signed-off-by: Felipe Contreras
---
contrib/completion/git-completion.bash | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 52d83f2..e9b793b 100644
--- a/contrib/completion/git-completion.b
tl;dr: everyone except Junio C Hamano and Drew Northup agrees; we should move
away from the name "the index".
It has been discussed many times in the past that 'index' is not an
appropriate description for what the high-level user does with it, and
it has been agreed that 'staging area' is the bes
Signed-off-by: Felipe Contreras
---
Documentation/git-stage.txt| 46 +
Makefile | 2 +-
builtin.h | 1 +
builtin/stage.c| 53 ++
contrib/com
Synonym for --cached.
Signed-off-by: Felipe Contreras
---
Documentation/git-diff.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 56fb7e5..ca2a0ed 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/
Philippe Vaucher wrote:
> >> Yes, of course there should be a list of both positive and negative
> >> tradeoffs. But I think the "overloaded" argument can be easily solved
> >> by renaming one of the overloads.
> >
> > And renaming one of a term also has costs, especially if it is one
> > that is i
Theodore Ts'o wrote:
> On Fri, Apr 25, 2014 at 09:48:53AM +0200, Philippe Vaucher wrote:
> >
> > I agree. The "stage area" is a very important concept in git, why not
> > talk git commands that refers to it? Then we could add flags like
> > --new-files or --deleted-files for better granularity tha
On 2014-04-25 03:37, Simon Oosthoek wrote:
> (though tbh, I think you'd have to be in an automated situation
> to check out a branch that is basically a command to hack your
> system, a human would probably figure it too cumbersome, or too
> fishy)
You can get in trouble by cloning a malicious rep
Update ref_transaction_update() do some basic error checking and return
true on error. Update all callers to check ref_transaction_update() for error.
Signed-off-by: Ronnie Sahlberg
---
builtin/update-ref.c | 10 ++
refs.c | 9 +++--
refs.h | 10 +
David Kastrup wrote:
> Jonathan Nieder writes:
>> I probably missed a subtlety, but the above comment reminded me of
>> some netiquette I think this list is starting to forget. If I have
>> misread it, please let me know and skip the rest of this message.
[...]
>> On the git list, the rule is si
Let ref_transaction_commit return an optional error string that describes
the transaction failure. Start by returning the same error as update_ref_lock
returns, modulo the initial error:/fatal: preamble.
This will make it easier for callers to craft better error messages when
a transaction call fa
Call ref_transaction_commit with QUIET_ON_ERR and use the error string
that is returned to print a better log message if/after the transaction
fails.
Update the tests to reflect that the log message is now slightly different
fatal: update_ref failed: Cannot lock the ref 'some ref'
versus from th
Do basic error checking in ref_transaction_create() and make it return
status. Update all callers to check the result of ref_transaction_create()
Signed-off-by: Ronnie Sahlberg
---
builtin/update-ref.c | 4 +++-
refs.c | 17 +++--
refs.h | 8
3
Change create_branch to use a ref transaction when creating the new branch.
ref_transaction_create will check that the ref does not already exist and fail
otherwise meaning that we no longer need to keep a lock on the ref during the
setup_tracking. This simplifies the code since we can now do the t
ref_transaction_create|delete|update has no need to modify the sha1
arguments passed to it so it should use const unsigned char* instead
of unsigned char*.
Some functions, such as fast_forward_to(), already have its old/new
sha1 arguments as consts. This function will at some point need to
use ref
Change update_branch() to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg
---
fast-import.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index fb4738d..a2b05fa 100644
--- a/fast-import.c
+++ b/fast-import.
Change commit.c to use ref transactions for all ref updates.
Make sure we pass a NULL pointer to ref_transaction_update if have_old
is false.
Signed-off-by: Ronnie Sahlberg
---
builtin/commit.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/builtin/
Change to use ref transactions for all updates to refs.
Signed-off-by: Ronnie Sahlberg
---
sequencer.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index bde5f04..7d59f58 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -272,1
Change ref_transaction_delete() to do basic error checking and return
status. Update all callers to check the return for ref_transaction_delete()
Signed-off-by: Ronnie Sahlberg
---
builtin/update-ref.c | 5 +++--
refs.c | 15 ++-
refs.h | 8
3 f
Change the update_ref helper function to use a ref transaction internally.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 1557c3c..95df4a9 100644
--- a/refs.c
+++ b/refs.c
@@ -3397,11 +3
We have to free the transaction before returning in the early check for
'return early if number of updates == 0' or else the following code would
create a memory leak with the transaction never being freed :
t = ref_transaction_begin()
ref_transaction_commit(t)
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Ronnie Sahlberg
---
refs.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 0712912..9d9eab8 100644
--- a/refs.c
+++ b/refs.c
@@ -3393,6 +3393,7 @@ static int ref_update_compare(const void *r1, const void
*r2)
}
static int ref_up
Change update_ref_write to also return an error string on failure.
This makes the error avaialbel to ref_transaction_commit callers if the
transaction failed dur to update_ref_sha1/write_ref_sha1 failures.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 10 +++---
1 file changed, 7 insertions(+)
This patch series changes most of the places where the ref functions for
locking and writing refs to instead use the new ref transaction API. There
are still three more places where write_ref_sha1() is called from outside
of refs.c but those all will require more complex work and review so those
ch
Update replace.c to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg
---
builtin/replace.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index b62420a..cf0f56d 100644
--- a/builtin/replace.c
+++ b/builtin/
Change ref_transaction_commit to take a pointer to a pointer for the
transaction. This allows us to clear the transaction pointer from within
ref_transaction_commit so that it becomes NULL in the caller.
This makes transaction handling in the callers much nicer since instead of
having to write hor
Change tag.c to use ref transactions for all ref updates.
Signed-off-by: Ronnie Sahlberg
---
builtin/tag.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 40356e3..dd53fb4 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -48
Since we now pass meaningful error messages back from ref_transaction_commit
on failures, we no longer need to provide a onerr argument. The callers can now
on commit failures die() with a meaningful, and in most cases even better than
before, error message.
Signed-off-by: Ronnie Sahlberg
---
bu
Allow ref_transaction_free to be called with NULL and in extension allow
ref_transaction_rollback to be called for a NULL transaction.
This allows us to write code that will
if ( (!transaction ||
ref_transaction_update(...)) ||
(ref_transaction_commit(...) && !(transaction = NULL)
>> Yes, of course there should be a list of both positive and negative
>> tradeoffs. But I think the "overloaded" argument can be easily solved
>> by renaming one of the overloads.
>
> And renaming one of a term also has costs, especially if it is one
> that is in use in large amounts of documentat
Jonathan Nieder writes:
> Hi,
>
> David Kastrup wrote:
>> Javier Domingo Cansino writes:
>
>>> = Reject non-fast-forward pulls by default =
>>> Not having this introduced yet allows newbie people to use git with
>>> just 4 commands, without bothering around with fetch and merge and so.
>>
>> If
David Kastrup wrote:
> Jonathan Nieder writes:
>> Just for clarity: no, when we are talking about well formatted code,
>> -S is actually a way better interface.
>
> When we are talking about well-formatted code, -S does not matter either
> which way.
Sorry for the lack of clarity. I believe wel
Hi,
David Kastrup wrote:
> Javier Domingo Cansino writes:
>> = Reject non-fast-forward pulls by default =
>> Not having this introduced yet allows newbie people to use git with
>> just 4 commands, without bothering around with fetch and merge and so.
>
> If you have a gun lying around your house
1 - 100 of 112 matches
Mail list logo
