Re: Harmful LESS flags

Junio C Hamano gits...@pobox.com writes: I am not opposed to changing the default in the longer term, as long as we have a solid transition plan to ensure that it won't disrupt and/or upset existing users too much. I am personally in favor of changing the default to drop the S. Silently

Re: What is missing from Git v2.0

ty...@mit.edu writes: On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote: I don't even think we need to query the user to fill out all of the fields. We can prepopulate a lot of the fields (name, e-mail address, etc.) from OS specific defaults that are available on most systems

Re: What is missing from Git v2.0

Javier Domingo Cansino javier...@gmail.com writes: Felipe's === = 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

Re: What is missing from Git v2.0

I don't even think we need to query the user to fill out all of the fields. We can prepopulate a lot of the fields (name, e-mail address, etc.) from OS specific defaults that are available on most systems --- specifically, the default values we would use the name and e-mail address are

Re: What is missing from Git v2.0

I think you are on the right track but the solution is not to shrug shoulders. We should acknowledge there are serious problems with the interface, list them, and try to fix them. One example is `git add $tracked_file` being wrong, it should be `git stage $tracked_file`. I agree. The stage

Re: What is missing from Git v2.0

Philippe Vaucher wrote: I think you are on the right track but the solution is not to shrug shoulders. We should acknowledge there are serious problems with the interface, list them, and try to fix them. One example is `git add $tracked_file` being wrong, it should be `git stage

Re: What is missing from Git v2.0

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 than the current --all flag. One

Re: What is missing from Git v2.0

On Fri, Apr 25, 2014 at 04:23:43PM +0200, Philippe Vaucher wrote: I agree, but I think it's better than index tho. That one is heavily overloaded and easily confused with other meaning in other softwares. There is a big difference between being used in a difference sense than other software

Re: What's cooking in git.git (Apr 2014, #07; Tue, 22)

On Tue, Apr 22, 2014 at 04:12:42PM -0700, Junio C Hamano wrote: * bc/blame-crlf-test (2014-02-18) 1 commit - blame: add a failing test for a CRLF issue. I have a feeling that a fix for this should be fairly isolated and trivial (it should be just the matter of paying attention to the

Re: Harmful LESS flags

Hi, Matthieu Moy wrote: I am personally in favor of changing the default to drop the S. Silently hiding stuff from the user's eyes is really bad. With good coding standard and reasonable terminal size, it actually doesn't matter. Just for clarity: no, when we are talking about well formatted

Re: Harmful LESS flags

Jonathan Nieder jrnie...@gmail.com writes: Matthieu Moy wrote: I am personally in favor of changing the default to drop the S. Silently hiding stuff from the user's eyes is really bad. With good coding standard and reasonable terminal size, it actually doesn't matter. Just for clarity: no,

Re: What is missing from Git v2.0

Hi, David Kastrup wrote: Javier Domingo Cansino javier...@gmail.com 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

Re: Harmful LESS flags

David Kastrup wrote: Jonathan Nieder jrnie...@gmail.com 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

Re: What is missing from Git v2.0

Jonathan Nieder jrnie...@gmail.com writes: Hi, David Kastrup wrote: Javier Domingo Cansino javier...@gmail.com 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

Re: What is missing from Git v2.0

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 documentation, both

[PATCH v3 11/19] tag.c: use ref transactions when doing updates

Change tag.c to use ref transactions for all ref updates. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- 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 +++

[PATCH v3 07/19] refs.c: remove the onerr argument to ref_transaction_commit

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

[PATCH v3 02/19] refs.c: allow passing NULL to ref_transaction_free

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

[PATCH v3 12/19] replace.c: use the ref transaction functions for updates

Update replace.c to use ref transactions for updates. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- 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 ---

[PATCH v3 19/19] refs.c: pass **transaction to commit and have it clear the pointer

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

[PATCH v3 06/19] refs.c: make update_ref_write to return error string on failure

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 sahlb...@google.com --- refs.c | 10 +++--- 1 file

[PATCH v3 00/19] Use ref transactions from most callers

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

[PATCH v3 17/19] refs.c: change update_ref to use a transaction

Change the update_ref helper function to use a ref transaction internally. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- 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 +++

[PATCH v3 18/19] refs.c: free the transaction before returning when number of updates is 0

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

[PATCH v3 04/19] refs.c: return error string from ref_update_reject_duplicates on failure

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- 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) }

[PATCH v3 10/19] refs.c: ref_transaction_delete to check for error and return status

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 sahlb...@google.com --- builtin/update-ref.c | 5 +++-- refs.c | 15 ++- refs.h

[PATCH v3 15/19] fast-import.c: change update_branch to use ref transactions

Change update_branch() to use ref transactions for updates. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- 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 ---

[PATCH v3 13/19] commit.c: use ref transactions for updates

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 sahlb...@google.com --- builtin/commit.c | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-)

[PATCH v3 14/19] sequencer.c: use ref transactions for all ref updates

Change to use ref transactions for all updates to refs. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- 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 +++

[PATCH v3 01/19] refs.c: constify the sha arguments for ref_transaction_create|delete|update

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

[PATCH v3 16/19] branch.c: use ref transaction for all ref updates

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

[PATCH v3 05/19] update-ref.c: use the error string from _commit to print better message

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

[PATCH v3 09/19] refs.c: change ref_transaction_create to do error checking and return status

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 sahlb...@google.com --- builtin/update-ref.c | 4 +++- refs.c | 17 +++-- refs.h

Re: What is missing from Git v2.0

David Kastrup wrote: Jonathan Nieder jrnie...@gmail.com 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

[PATCH v3 03/19] refs.c: make ref_transaction_commit return an error string

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

[PATCH v3 08/19] refs.c: change ref_transaction_update() to do error checking and return status

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 sahlb...@google.com --- builtin/update-ref.c | 10 ++ refs.c | 9 +++-- refs.h

Re: [SECURITY PATCH] git-prompt.sh: don't put unsanitized branch names in $PS1

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

Re: What is missing from Git v2.0

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

Re: What is missing from Git v2.0

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 in use in large

[PATCH v2 try2 01/14] Add proper 'stage' command

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/git-stage.txt| 46 + Makefile | 2 +- builtin.h | 1 + builtin/stage.c| 53

[PATCH v2 try2 03/14] diff: document --staged

Synonym for --cached. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- 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 ---

[PATCH v2 try2 00/14] Officially start moving to the term 'staging area'

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 best

[PATCH v2 try2 13/14] reset: allow --keep with --stage

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- 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

[PATCH v2 try2 12/14] reset: add --stage and --work options

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- 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

[PATCH v2 try2 14/14] completion: update 'git reset' new stage options

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- 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 ---

[PATCH v2 try2 07/14] stash: add --stage to pop and apply

Synonym of --index. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- 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

[PATCH v2 try2 09/14] apply: add --stage option

Synonym for --index. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- 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

[PATCH v2 try2 11/14] completion: update --staged options

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- 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 ---

[PATCH v2 try2 10/14] apply: add --work, --no-work options

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

[PATCH v2 try2 06/14] stash: add --stage option to save

--no-stage is synonym for --keep-index. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/git-stash.txt | 6 +++--- git-stash.sh| 8 +++- 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/git-stash.txt

[PATCH v2 try2 08/14] submodule: add --staged options

Synonym for --cached. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/git-submodule.txt | 8 ++-- git-submodule.sh| 10 +- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/Documentation/git-submodule.txt

[PATCH v2 try2 05/14] rm: add --staged option

Synonym for --cached. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- 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

[PATCH v2 try2 04/14] grep: add --staged option

Synonym for --cached. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- 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

[PATCH v2 try2 02/14] stage: add edit command

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/git-stage.txt| 5 +++ builtin/stage.c| 74 ++ contrib/completion/git-completion.bash | 4 +- 3 files changed, 82 insertions(+), 1 deletion(-) diff

Re: What is missing from Git v2.0

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

Re: [PATCH] Revert Stop starting pager recursively

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 would

[GSoC 2014] Accepted GSoC student introduction

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

Re: What is missing from Git v2.0

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.git/233469

Re: [PATCH] Revert Stop starting pager recursively

Jörn Engel jo...@logfs.org 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

Re: What is missing from Git v2.0

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

[PATCH v11 02/11] trailer: process trailers from input message and arguments

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

[PATCH v11 04/11] trailer: process command line trailer arguments

Parse the trailer command line arguments and put the result into an arg_tok doubly linked list. Signed-off-by: Christian Couder chrisc...@tuxfamily.org Signed-off-by: Junio C Hamano gits...@pobox.com --- trailer.c | 118 ++ 1 file

[PATCH v11 03/11] trailer: read and process config information

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 chrisc...@tuxfamily.org

Re: What is missing from Git v2.0

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

[PATCH v11 05/11] trailer: parse trailers from file or stdin

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 chrisc...@tuxfamily.org Signed-off-by: Junio C Hamano gits...@pobox.com --- trailer.c | 116

[PATCH v11 11/11] Documentation: add documentation for 'git interpret-trailers'

While at it add git-interpret-trailers to command-list.txt. Signed-off-by: Christian Couder chrisc...@tuxfamily.org Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git-interpret-trailers.txt | 143 +++ command-list.txt | 1 +

[PATCH v11 00/11] Add interpret-trailers builtin

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.

Re: What is missing from Git v2.0

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 better name,

[PATCH v11 08/11] trailer: add tests for git interpret-trailers

Signed-off-by: Christian Couder chrisc...@tuxfamily.org Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t7513-interpret-trailers.sh | 418 ++ 1 file changed, 418 insertions(+) create mode 100755 t/t7513-interpret-trailers.sh diff --git

[PATCH v11 07/11] trailer: add interpret-trailers command

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 chrisc...@tuxfamily.org Signed-off-by: Junio C Hamano gits...@pobox.com --- .gitignore | 1 + Makefile

[PATCH v11 10/11] trailer: add tests for commands in config file

And add a few other tests for some special cases. Signed-off-by: Christian Couder chrisc...@tuxfamily.org Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t7513-interpret-trailers.sh | 124 ++ 1 file changed, 124 insertions(+) diff --git

[PATCH v11 01/11] trailer: add data structures and basic functions

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 chrisc...@tuxfamily.org Signed-off-by: Junio C

[PATCH v11 06/11] trailer: put all the processing together and print

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 chrisc...@tuxfamily.org Signed-off-by: Junio C Hamano gits...@pobox.com --- trailer.c | 58

[PATCH v11 09/11] trailer: execute command from 'trailer.name.command'

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 chrisc...@tuxfamily.org Signed-off-by: Junio C Hamano gits...@pobox.com --- trailer.c | 65

Re: What is missing from Git v2.0

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

Re: [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers'

From: Junio C Hamano gits...@pobox.com Christian Couder chrisc...@tuxfamily.org 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'

Re: [PATCH] Revert Stop starting pager recursively

On Fri, 25 April 2014 20:49:52 +0200, Matthieu Moy wrote: Jörn Engel jo...@logfs.org 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.

[PATCH] l10n: de.po: improve hint for autocorrected command execution

Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- 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 @@

Re: [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers'

From: Michael Haggerty mhag...@alum.mit.edu 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, -

Re: [PATCH] l10n: de.po: translate 45 new messages

Ralf Thielow ralf.thie...@gmail.com 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

Re: [PATCH 02/11] refs.c: change ref_transaction_update() to do error checking and return status

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

Re: [PATCH v3 00/19] Use ref transactions from most callers

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

Re: [PATCH v3 00/19] Use ref transactions from most callers

On Fri, Apr 25, 2014 at 2:53 PM, Jonathan Nieder jrnie...@gmail.com 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

Re: [PATCH v3 03/19] refs.c: make ref_transaction_commit return an error string

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

Re: [PATCH v3 04/19] refs.c: return error string from ref_update_reject_duplicates on failure

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,

Re: [PATCH v3 05/19] update-ref.c: use the error string from _commit to print better message

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

Re: [PATCH v2 2/3] remote-helpers: move out of contrib

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

Re: [PATCH v3 06/19] refs.c: make update_ref_write to return error string on failure

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 after

Re: [PATCH v3 07/19] refs.c: remove the onerr argument to ref_transaction_commit

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

What's cooking in git.git (Apr 2014, #08; Fri, 25)

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

[ANNOUNCE] Git v2.0.0-rc1

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:

Re: [PATCH 04/14] appp.sh: use the $( ... ) construct for command substitution

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}` -DIFF=`sed -e

Re: [PATCH v3 11/19] tag.c: use ref transactions when doing updates

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 sahlb...@google.com --- builtin/tag.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/builtin/tag.c b/builtin/tag.c

Re: [PATCH v3 12/19] replace.c: use the ref transaction functions for updates

On 04/25/2014 06:14 PM, Ronnie Sahlberg wrote: Update replace.c to use ref transactions for updates. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- builtin/replace.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/builtin/replace.c

Re: gitignore vs. exclude vs assume-unchanged?

Andrew Ardill andrew.ard...@gmail.com 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

[PATCH] commit: do not complain of empty messages from -C

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 would

Re: [PATCH v3 16/19] branch.c: use ref transaction for all ref updates

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

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

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 +

[PATCH] Updated C# userdiff patterns.

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

Re: [PATCH v3 17/19] refs.c: change update_ref to use a transaction

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 sahlb...@google.com --- refs.c | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/refs.c

  1   2   >