[PATCH v5 1/3] rebase: consistently use branch_name variable

are expecting either of them, and not limiting ourselves to a branch name. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> Signed-off-by: Junio C Hamano <gits...@pobox.com> Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- git-rebase.sh | 17 ++--

[PATCH v5 0/3] rebase: give precise error messages

p;& - !(git symbolic-ref -q HEAD) +! git symbolic-ref -q HEAD then say "$(eval_gettext "HEAD is up to date, rebase forced.")" else Kaartic Sivaraam (3): rebase: consiste

[PATCH v5 0/1] clarify about @{-N} syntax in check-ref-format documentation

s checkout operation'' might result -in a commit hash when the N-th last thing checked out was not a branch. +in a commit object name when the N-th last thing checked out was not +a branch. OPTIONS --- Kaartic Sivaraam (1): Doc/check-ref-format: clarify information about @{-N} syntax

[PATCH v5 1/1] Doc/check-ref-format: clarify information about @{-N} syntax

that the result of using @{-N} might also result in an commit object name. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- Documentation/git-check-ref-format.txt | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/Documentation/git-check

Re: What's cooking in git.git (Dec 2017, #03; Wed, 13)

On Friday 15 December 2017 02:38 AM, Junio C Hamano wrote: Junio C Hamano writes: I think you only sent 3/3 in newer rounds, which made it not to apply to my tree. If you meant to drop changes in 1/3 and 2/3, perhaps because they were needless churn, then 3/3 needs to be

Re: [PATCH v4 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

On Thursday 14 December 2017 11:32 PM, Junio C Hamano wrote: Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: Looks alright. It was made unnecessarily harder to review because it was marked as 2/2, even though this no longer applies on top of the copy of 1/2 that was merged some ti

Re: What's cooking in git.git (Dec 2017, #03; Wed, 13)

On Thursday 14 December 2017 10:50 PM, Junio C Hamano wrote: Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: It seems my series that fixes an error message in 'git-rebase'[1] (apart from a little cleanups) is missing. I guess I addressed the issue that was raised in 3/3 a

Re: What's cooking in git.git (Dec 2017, #03; Wed, 13)

It seems my series that fixes an error message in 'git-rebase'[1] (apart from a little cleanups) is missing. I guess I addressed the issue that was raised in 3/3 as a v3 for that patch[2]. Are any more changes needed? [1]: <20171127172104.5796-1-kaartic.sivar...@gmail.com> [2]:

[PATCH v4 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

that the result of using @{-N} might also result in an commit object name. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- Changes in v4: - updated the commit message - made changes suggested by Junio Documentation/git-check-ref-format.txt

Re: [PATCH v5 4/4] builtin/branch: strip refs/heads/ using skip_prefix

On Friday 08 December 2017 04:44 AM, Junio C Hamano wrote: Junio C Hamano writes: Somehow this fell underneath my radar horizon. I see v4 and v5 of 4/4 but do not seem to find 1-3/4. Is this meant to be a standalone patch, or am I expected to already have 1-3 that we

Re: [PATCH v5 2/2] launch_editor(): indicate that Git waits for user input

On Thursday 07 December 2017 10:00 PM, Junio C Hamano wrote: + + if (print_waiting_for_editor) { + /* +* A dumb terminal cannot erase the line later on. Add a +* newline to separate the hint from subsequent

Re: [PATCH v3 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

On Sunday 03 December 2017 07:38 AM, Junio C Hamano wrote: Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: NOTE: Though a commit-hash is a "syntactically" valid branch name, it is generally not considered as one for the use cases of "git check-ref-format --branch&qu

Re: [PATCH v2 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

On Tuesday 05 December 2017 12:14 AM, Junio C Hamano wrote: Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: Stepping back a bit, the mild suspicion above says $ git checkout HEAD^0 ... do things ... $ git checkout -b temp ... do more things ... $ git check

Re: [PATCH v2 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

On Sat, 2017-12-02 at 17:52 -0800, Junio C Hamano wrote: > Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: > > > > I have a mild suspicion that "git checkout -B @{-1}" would want to > > > error out instead of creating a valid new branch whose name is

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

On Sun, 2017-12-03 at 17:39 +0100, Lars Schneider wrote: > > On 02 Dec 2017, at 04:45, Kaartic Sivaraam <kaartic.sivar...@gmail.com> > > wrote: > > > > On Friday 01 December 2017 11:59 PM, Jeff King wrote: > > > On Fri, Dec 01, 2017 at

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

On Friday 01 December 2017 11:59 PM, Jeff King wrote: On Fri, Dec 01, 2017 at 01:52:14PM +0100, Lars Schneider wrote: Thanks for the review :-) Actually, I meant to bikeshed one part but forgot. ;) + fprintf(stderr, _("hint: Waiting for your editor input...")); I

[PATCH v3 3/3] rebase: rebasing can also be done when HEAD is detached

precise error message. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- Changes in v2: - avoided unnecesarily spawning a subshell in a conditional git-rebase.sh | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/git-rebase.sh

[PATCH v5 4/4] builtin/branch: strip refs/heads/ using skip_prefix

Instead of hard-coding the offset strlen("refs/heads/") to skip the prefix "refs/heads/" use the skip_prefix() function which is more communicative and verifies that the string actually starts with that prefix. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

On Friday 01 December 2017 02:21 AM, Jeff King wrote: These are obviously the result of devils-advocate poking at the feature. I doubt any editor would end its output with a CR. But the first case is probably going to be common, especially for actual graphical editors. We know that emacsclient

Re: [PATCH v4 0/2] launch_editor(): indicate that Git waits for user input

On Thu, 2017-11-30 at 16:13 +0100, Andreas Schwab wrote: > On Nov 30 2017, Thomas Adam wrote: > > > On Thu, Nov 30, 2017 at 02:55:35PM +0100, Lars Schneider wrote: > > > > > > > On 29 Nov 2017, at 19:35, Thomas Adam wrote: > > > > > > > > On Wed, Nov 29,

Re: [PATCH v4 1/2] refactor "dumb" terminal determination

On Wednesday 29 November 2017 08:07 PM, lars.schnei...@autodesk.com wrote: +int is_terminal_dumb(void) +{ + const char *terminal = getenv("TERM"); + return !terminal || !strcmp(terminal, "dumb"); So, IIUC, there terminal is considered to be 'dumb' when the TERM environment

[PATCH v4 4/4] builtin/branch: strip refs/heads/ using skip_prefix

Instead of hard-coding the offset strlen("refs/heads/") to skip the prefix "refs/heads/" use the skip_prefix() function which is more communicative and verifies that the string actually starts with that prefix. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gm

Re: [PATCH v2 0/3] rebase: give precise error message

On Wed, 2017-11-29 at 09:10 +0900, Junio C Hamano wrote: > Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: > > > If is the correct substitute , I could try to send a > > patch that fixes this. > > I do not think the above is a good change in the first pl

Re: Feature request: Reduce amount of diff in patch

On Tue, 2017-11-28 at 18:09 +0200, KES wrote: > Hi. > > I get often patches which can be minimized: > I guess the one below can't be (see below). > @@ -60,11 +64,8 @@ sub _get_filter { > address=> { -like => \[ '?', "%$search%" ] }, > company=> { -like => \[ '?',

Re: [PATCH v2 3/3] rebase: rebasing can also be done when HEAD is detached

On Tue, 2017-11-28 at 11:31 +0900, Junio C Hamano wrote: > Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: > > > + if test "$branch_or_commit" = "HEAD" && > > +!(git symbolic-ref -q HEAD) > > Did

Re: [RFC PATCH v2] builtin/worktree: enhance worktree removal

On Tuesday 28 November 2017 09:34 AM, Junio C Hamano wrote: Eric Sunshine writes: With this approach, validate_worktree() will print an error message saying that the worktree directory is missing before the control info is actually removed. Kaartic's original patch

[PATCH v3 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

;existing" branch name apart from it being syntactically valid. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- Documentation/git-check-ref-format.txt | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/Documentation/git-check-ref-

Re: [PATCH v2 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

On Tue, 2017-11-28 at 11:40 +0900, Junio C Hamano wrote: > Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: > > > When the N-th previous thing checked out sytax is used with > > '--branch' option of check-ref-format the results might not > > always be a valid br

Re: [PATCH v2 0/3] rebase: give precise error message

On Tue, 2017-11-28 at 11:25 +0900, Junio C Hamano wrote: > Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: > > > 1. "git rebase " does nothing > > Not limited to "rebase", you do not muck with remote-tracking branch > in your local reposi

[RFC PATCH v2] builtin/worktree: enhance worktree removal

of the worktree in such a case. Helped-by: Eric Sunshine <sunsh...@sunshineco.com> Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- Changes in v2: - incorporated the suggestion to avoid quieting `validate_worktree()` to detect inexistent directory (thanks, E

[PATCH v2 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

es a wrong thing by promoting it as the "previous branch syntax". So, correctly state @{-N} is the syntax for specifying "N-th last thing checked out" and also state that the result of using @{-N} might also result in a "commit hash". Signed-off-by: Kaar

[PATCH v2 1/2] Doc/checkout: checking out using @{-N} can lead to detached state

to a commit, 2014-01-19) which clearly specifies how @{-N} can be used to refer not only to a branch but also to a commit. Correct the misleading sentence which states that @{-N} doesn't detach HEAD. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- Documentation/git-checkout

[PATCH v2 2/3] rebase: distinguish user input by quoting it

Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- git-rebase.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-rebase.sh b/git-rebase.sh index a675cf691..3f8d99e99 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -477,7

[PATCH v2 3/3] rebase: rebasing can also be done when HEAD is detached

precise error message. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- git-rebase.sh | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/git-rebase.sh b/git-rebase.sh index 3f8d99e99..9cce1483a 100755 --- a/git-rebase.sh +++ b/git-reb

[PATCH v2 0/3] rebase: give precise error message

in/next f926f18f3dda0c52e794b2de0911f1b046c7dadf" Current branch f926f18f3dda0c52e794b2de0911f1b046c7dadf is up to date. As it's clear the commit is not a branch. What should be done to fix this? Kaartic Sivaraam (3): rebase: use a more appropriate variable name rebase: distinguish user inp

[PATCH v2 1/3] rebase: use a more appropriate variable name

The variable name "branch_name" used to indicate the parameter in "git rebase " is misleading as it seems to indicate that it holds only a "branch name" although at times it might actually hold any valid (branch/commit). So, use a more suitable name for that var

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

On Monday 27 November 2017 07:17 PM, lars.schnei...@autodesk.com wrote: Show a message in the original terminal and get rid of it when the editor returns. "... except in the case when an error occurs." could be included if needed. + static const char *close_notice = NULL; +

Re: [PATCH] git-status.txt: mention --no-optional-locks

On Monday 27 November 2017 11:37 AM, Junio C Hamano wrote: Jeff King writes: +using `git --no-optional-locks status` (see linkgit:git[1] for details). It strikes me just now that `--no-side-effects` might have been a better name for the option (of course, iff this avoid all

Re: [PATCH v2] launch_editor(): indicate that Git waits for user input

On Wednesday 22 November 2017 10:25 PM, Lars Schneider wrote: On 20 Nov 2017, at 01:11, Junio C Hamano <gits...@pobox.com> wrote: Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: It might be a good thing to keep the notice but I think it would be better to have that e

Re: [RFC PATCH] builtin/worktree: enhance worktree removal

Kaartic: Regarding the actual patch, rather than silencing validate_worktree() (which seems an unfortunate thing to do), isn't it possible simply to do a quick test to see if the worktree directory exists before calling validate_worktree()? If it doesn't exist, then just skip down to the part of

Re: [PATCH v2 4/4] builtin/branch: strip refs/heads/ using skip_prefix

On Wednesday 22 November 2017 07:39 AM, Junio C Hamano wrote: Eric Sunshine <sunsh...@sunshineco.com> writes: On Tue, Nov 21, 2017 at 2:12 PM, Kaartic Sivaraam <kaartic.sivar...@gmail.com> wrote: On Wednesday 22 November 2017 12:08 AM, Eric Sunshine wrote: The original code unc

Re: [RFC PATCH] builtin/worktree: enhance worktree removal

On Wednesday 22 November 2017 09:25 AM, Junio C Hamano wrote: Eric Sunshine writes: So, Kaatic's patch is intended to address that oversight (though I haven't examined the implementation closely; I was just trying to understand the reason for the patch). OK, so the

Re: [RFC PATCH] builtin/worktree: enhance worktree removal

On Wednesday 22 November 2017 03:07 AM, Eric Sunshine wrote: On Tue, Nov 21, 2017 at 10:09 AM, Kaartic Sivaraam <kaartic.sivar...@gmail.com> wrote: The new feature to 'remove' worktree was handy to remove specific worktrees. It didn't cover one particular case of removal. Specif

[PATCH v3 4/4] builtin/branch: strip refs/heads/ using skip_prefix

Instead of hard-coding the offset strlen("refs/heads/") to skip the prefix "refs/heads/" use the skip_prefix() function which is more communicative and verifies that the string actually starts with that prefix. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.

Re: [PATCH v2 4/4] builtin/branch: strip refs/heads/ using skip_prefix

On Wednesday 22 November 2017 12:08 AM, Eric Sunshine wrote: On Tue, Nov 21, 2017 at 9:18 AM, Kaartic Sivaraam <kaartic.sivar...@gmail.com> wrote: Though we don't check for the result of verification here as it's (almost) always the case that the string does start with "refs/heads&

[PATCH] rebase: rebasing can also be done when HEAD is detached

correctly to give a more precise error message. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- In this patch, I basically assumed that there would be no branch named "HEAD". To the cotrary if it did, it would make 'git' throw spurious ambiguity messages, in gener

[RFC PATCH] builtin/worktree: enhance worktree removal

the "entry" is stale and it could just be removed. So, in case there's a "worktree entry" but not "worktree direectory" then just remove the 'stale' entry. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- Hello Duy, I noticed that your remove command

[PATCH v2 4/4] builtin/branch: strip refs/heads/ using skip_prefix

it's (almost) always the case that the string does start with "refs/heads", it's just better to avoid hard-coding and be more communicative. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- Eric Sunshine <sunsh...@sunshineco.com> writes: > Perhaps call them

[PATCH] git-rebase: clean up dashed-usages in messages

Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- git-rebase.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-rebase.sh b/git-rebase.sh index 6344e8d5e..2f5d138a0 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -9,7 +9,7 @@ OPTIONS_STUCK

Re: [PATCH] docs: checking out using @{-N} can lead to detached state

On Monday 20 November 2017 07:39 AM, Junio C Hamano wrote: Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: After the first paragraph explains what happens during "checkout " and goes from the normal case where is really a branch name to an arbitrary commit (where &

Can @{-N} always be used where a branch name is expected?

I was recently digging to find if there is any special syntax accepted for in "git branch -m " other than the plain branch name. I discovered the @{-N} notation. I was trying to play around with it and found that it didn't work as guaranteed by the last sentence of the following paragraph

[PATCH] docs: checking out using @{-N} can lead to detached state

in some cases using `git checkout @{-$N}` does lead to a "detached HEAD" state. Correct the misleading sentence which states that @{-N} doesn't detach HEAD. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- Documentation/git-checkout.txt | 5 ++--- 1 file changed, 2

Re: [PATCH v2] launch_editor(): indicate that Git waits for user input

On Saturday 18 November 2017 07:10 AM, Junio C Hamano wrote: Eric Sunshine writes: @@ -40,6 +40,32 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en + static const char *close_notice = NULL; + + if

Re: [PATCH] git-rebase: clean up dashed-usages in messages

On Sunday 19 November 2017 07:42 AM, Junio C Hamano wrote: test -f "$apply_dir"/applying && - die "$(gettext "It looks like git-am is in progress. Cannot rebase.")" + die "$(gettext "It looks like you are in the middle of an am session. Cannot rebase.")" Probably not, as 'am'

Re: [PATCH 4/4] builtin/branch: strip refs/heads/ using skip_prefix

On Sunday 19 November 2017 06:34 AM, Eric Sunshine wrote: On Sat, Nov 18, 2017 at 12:26 PM, Kaartic Sivaraam <kaartic.sivar...@gmail.com> wrote: diff --git a/builtin/branch.c b/builtin/branch.c @@ -462,6 +462,8 @@ static void copy_or_rename_branch(const char *oldname, const char *newnam

Re: [PATCH] launch_editor(): indicate that Git waits for user input

On Thursday 16 November 2017 11:34 AM, Junio C Hamano wrote: * I tried this with "emacsclient" but it turns out that Emacs folks have already thought about this issue, and the program says "Waiting for Emacs..." while it does its thing, so from that point of view, perhaps as

[PATCH 1/4] branch: improve documentation and naming of create_branch() parameters

more communicative. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- branch.c | 4 ++-- branch.h | 7 ++- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/branch.c b/branch.c index 62f7b0d8c..3e8d2f93f 100644 --- a/branch.c +++ b/branch.c @@ -228,7 +228,7 @@

[PATCH 3/4] branch: update warning message shown when copying a misnamed branch

the misnamed branch. This is not correct and may confuse the user. So, update the warning message shown to be more precise that only a copy of the misnamed branch has been created. It's better to show the warning message than not showing it at all as it makes the user aware of the presence of a misnamed branch. Si

[PATCH 2/4] branch: group related arguments of create_branch()

turns out that 'clobber_head' is more related to 'force' than it is to 'track'. So, re-order the arguments to keep the related arguments close to each other. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- branch.c | 2 +- branch.h | 9 + builti

[PATCH 4/4] builtin/branch: strip refs/heads/ using skip_prefix

it's (almost) always the case that the string does start with "refs/heads", it's just better to avoid hard-coding and be more communicative. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- builtin/branch.c | 16 +++- 1 file changed, 11 insertions(+),

[PATCH 0/4] cleanups surrounding branch

conflicts with jc/branch-name-sanity Footnotes: [0]: cf. <20171102065407.25404-1-kaartic.sivar...@gmail.com> [1]: https://github.com/sivaraam/git/tree/work/branch-cleanups Kaartic Sivaraam (4): branch: improve documentation and naming of create_branch() parameters branch: group r

[PATCH] git-rebase: clean up dashed-usages in messages

Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- git-rebase.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-rebase.sh b/git-rebase.sh index 6344e8d5e..42a485aaa 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -9,7 +9,7 @@ OPTIONS_STUCK

Re: [PATCH 3/4] branch: correctly reject refs/heads/{-dash,HEAD}

On Thursday 16 November 2017 08:27 PM, Junio C Hamano wrote: Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: I guess this series is not yet ready for 'next'. When I tried to apply this patch it doesn't seem to be applying cleanly. I get some conflicts in 'sha1_name.c' po

Re: [PATCH 3/4] branch: correctly reject refs/heads/{-dash,HEAD}

On Thursday 16 November 2017 03:44 AM, Junio C Hamano wrote: Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: >> Are these two patches follow-up fixes (replacement of 3/3 plus an >> extra patch) to jc/branch-name-sanity topic? >

Re: [PATCH] branch doc: remove --set-upstream from synopsis

On Thursday 16 November 2017 04:19 PM, Martin Ågren wrote: On 16 November 2017 at 08:46, Todd Zullinger wrote: diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index d6587c5e96..159ca388f1 100644 --- a/Documentation/git-branch.txt +++

Re: [PATCH v2 1/2] branch: forbid refs/heads/HEAD

On Tuesday 14 November 2017 08:38 PM, Junio C Hamano wrote: Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: I should have been a little more clear with the numbering, sorry. The correct prefix should have been as follows, * [PATCH v2 1/2] --> [PATCH v2 3/3] * [PAT

Re: [PATCH v2 1/2] branch: forbid refs/heads/HEAD

I should have been a little more clear with the numbering, sorry. The correct prefix should have been as follows, * [PATCH v2 1/2] --> [PATCH v2 3/3] * [PATCH v2 1/2] --> [PATCH v2 4/3] Sorry for the inconvenience. --- Kaartic

[PATCH v2 2/2] builtin/branch: remove redundant check for HEAD

The lower level code has been made to handle this case for the sake of consistency. This has made this check redundant. So, remove the redundant check. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- builtin/branch.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/b

[PATCH v2 1/2] branch: forbid refs/heads/HEAD

lready use it to reject a branch whose name begins with a '-'. Use it to also reject "HEAD" as a branch name. Helped-by: Jeff King <p...@peff.net> Signed-off-by: Junio C Hamano <gits...@pobox.com> Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- C

Re: What's cooking in git.git (Nov 2017, #04; Tue, 14)

* jc/branch-name-sanity (2017-10-14) 3 commits - branch: forbid refs/heads/HEAD - branch: split validate_new_branchname() into two - branch: streamline "attr_only" handling in validate_new_branchname() "git branch" and "git checkout -b" are now forbidden from creating a branch whose name is

Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming

On Monday 13 November 2017 05:00 PM, Kevin Daudt wrote: On Mon, Nov 13, 2017 at 08:01:12AM +0530, Kaartic Sivaraam wrote: That was a little attribution I wanted make to the strbuf API as this was the first time I leveraged it to this extent and I was surprised by the way it made string

Re: [RFC PATCH v3 2/4] branch: re-order function arguments to group related arguments

On Mon, 2017-11-13 at 11:32 +0900, Junio C Hamano wrote: > Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: > > > I've tried to improve it, does the following paragraph sound clear > > enough? > > > > branch: group related arguments of create_branch(

Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming

On Sunday 12 November 2017 11:53 PM, Kevin Daudt wrote: On Thu, Nov 02, 2017 at 12:24:07PM +0530, Kaartic Sivaraam wrote: From: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> When trying to rename an inexistent branch to with a name of a branch This sentence does not read well. Prob

Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming

On Mon, 2017-11-06 at 11:30 +0900, Junio C Hamano wrote: > Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: > > No {} around a single statement block of "if", especially when there > is no "else" that has multi-statement block that needs {}. >

Re: [RFC PATCH v3 3/4] branch: introduce dont_fail parameter for branchname validation

On Mon, 2017-11-06 at 11:24 +0900, Junio C Hamano wrote: > Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: > > We usually use the word "gently" to when we enhance an operation > that used to always die on failure. When there are tons of callsite > to

Re: [RFC PATCH v3 2/4] branch: re-order function arguments to group related arguments

On Mon, 2017-11-06 at 11:06 +0900, Junio C Hamano wrote: > Kaartic Sivaraam <kaartic.sivar...@gmail.com> writes: > > > From: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> > > > > The ad-hoc patches to add new arguments to a function when needed > > r

Re: "git bisect" takes exactly one bad commit and one or more good?

On Sat, 2017-11-11 at 10:27 -0500, Robert P. J. Day wrote: > > i realize that one of each commit is the simplest use case, but the > scenario that occurred to me is a bunch of branches being merged and, > suddenly, you have a bug, and you're not sure where it came from so > you identify a

Re: "Cannot fetch git.git" ( iworktrees at fault? or origin/HEAD) ?

On Fri, 2017-11-03 at 12:11 -0700, Stefan Beller wrote: > On Fri, Nov 3, 2017 at 2:32 AM, Kaartic Sivaraam > <kaartic.sivar...@gmail.com> wrote: > > BTW, this is what I call _way way_ faster. Unfortunately due to the limited > > configuration of my system, the test su

Re: "Cannot fetch git.git" (worktrees at fault? or origin/HEAD) ?

On Monday 23 October 2017 11:07 PM, Stefan Beller wrote: Exactly. By memory I mean volatile RAM (as opposed to memory on a spinning disk). Using GIT_TEST_OPTS has had some issues (I remember vaguely there was an inconsistency between the output of `make test` and prove), so I put my entire

Re: [BUG] Incosistent repository state when trying to rename HEAD in the middle of a rebase

On Thursday 02 November 2017 01:21 PM, Junio C Hamano wrote: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: I was able to spare some time to dig into this and found a few things. First, it seems that the issue is more generic and the BUG kicks in whenever HEAD is not a symbol

[PATCH] mailmap: use Kaartic Sivaraam's new address

Map the old address to the new, hopefully more permanent one. Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index ab85e0d16..2634baef2 100644 --- a/.mailmap +++ b/.mailmap @@ -113,6

Re: [RFC PATCH v3 3/4] branch: introduce dont_fail parameter for branchname validation

On Friday 03 November 2017 12:12 AM, Stefan Beller wrote: On Thu, Nov 2, 2017 at 1:39 AM, Kaartic Sivaraam <kaartic.sivar...@gmail.com> wrote: On Thursday 02 November 2017 12:24 PM, Kaartic Sivaraam wrote: Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> Signed-off

Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming

On Thursday 02 November 2017 07:51 PM, Eric Sunshine wrote: Nicely explained; easily understood. Good to hear that. Translators can correct me, but this smells like "sentence lego"[1], which we'd like to avoid. Translators lack full context when presented with bits and pieces of a

Re: [RFC PATCH v3 3/4] branch: introduce dont_fail parameter for branchname validation

On Thursday 02 November 2017 12:24 PM, Kaartic Sivaraam wrote: Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> I just now saw this small glitch as a consequence of recently changing my email address. I

Re: [RFC PATCH v3 0/4] give more useful error messages while renaming branch

Sorry, ignore this mails. I actually have re-sent it to the correct thread. -- Kaartic

[RFC PATCH v3 1/4] branch: improve documentation and naming of 'create_branch()'

From: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> The documentation for 'create_branch()' was incomplete as it didn't say what certain parameters were used for. Further a parameter name wasn't very communicative. So, add missing documentation for the sake of completeness and easy ref

[RFC PATCH v3 2/4] branch: re-order function arguments to group related arguments

From: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> The ad-hoc patches to add new arguments to a function when needed resulted in the related arguments not being close to each other. This misleads the person reading the code to believe that there isn't much relation between those arg

[RFC PATCH v3 3/4] branch: introduce dont_fail parameter for branchname validation

-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- branch.c | 62 +++--- branch.h | 60 ++-- buil

[RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming

From: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> When trying to rename an inexistent branch to with a name of a branch that already exists the rename failed specifying the new branch name exists rather than specifying that the branch trying to be renamed doesn't exist. $ git bra

[RFC PATCH v3 0/4] give more useful error messages while renaming branch

missed something, let me know. The series could be found in my fork[2]. Any feedback welcome. Thanks, Kaartic [1] : https://public-inbox.org/git/20171013051132.3973-1-gits...@pobox.com [2] : https://github.com/sivaraam/git/tree/work/branch-revamp Kaartic Sivaraam (4): branch: improve

[RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming

From: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> When trying to rename an inexistent branch to with a name of a branch that already exists the rename failed specifying the new branch name exists rather than specifying that the branch trying to be renamed doesn't exist. $ git bra

[RFC PATCH v3 2/4] branch: re-order function arguments to group related arguments

From: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> The ad-hoc patches to add new arguments to a function when needed resulted in the related arguments not being close to each other. This misleads the person reading the code to believe that there isn't much relation between those arg

[RFC PATCH v3 1/4] branch: improve documentation and naming of 'create_branch()'

From: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> The documentation for 'create_branch()' was incomplete as it didn't say what certain parameters were used for. Further a parameter name wasn't very communicative. So, add missing documentation for the sake of completeness and easy ref

[RFC PATCH v3 0/4] give more useful error messages while renaming branch

missed something, let me know. The series could be found in my fork[2]. Any feedback welcome. Thanks, Kaartic [1] : https://public-inbox.org/git/20171013051132.3973-1-gits...@pobox.com [2] : https://github.com/sivaraam/git/tree/work/branch-revamp Kaartic Sivaraam (4): branch: improve

[RFC PATCH v3 3/4] branch: introduce dont_fail parameter for branchname validation

-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> Signed-off-by: Kaartic Sivaraam <kaartic.sivar...@gmail.com> --- branch.c | 62 +++--- branch.h | 60 ++-- buil

Re: [BUG] Incosistent repository state when trying to rename HEAD in the middle of a rebase

On Sat, 2017-10-28 at 22:28 +0530, Kaartic Sivaraam wrote: > git rebase-i HEAD~ > Small correction here. Now you could replace that with the simpler, git checkout HEAD^ diff --git a/sha1_name.c b/sha1_name.c index c7c5ab376..4345e14c9 100644 --- a/sha1_name.c +++ b/sha1_n

Re: What's cooking in git.git (Oct 2017, #06; Fri, 27)

On Fri, 2017-10-27 at 17:32 +0900, Junio C Hamano wrote: > * jc/branch-name-sanity (2017-10-14) 3 commits > (merged to 'next' on 2017-10-16 at 174646d1c3) > + branch: forbid refs/heads/HEAD > + branch: split validate_new_branchname() into two > + branch: streamline "attr_only" handling in

[BUG] Incosistent repository state when trying to rename HEAD in the middle of a rebase

I just noticed this recently while trying to see if a recent change [1] that disallowed the possibility of creating HEAD also allowed renaming branches named "HEAD" that were created using previous versions that allowed it. Unfortunately (or fortunately (?)), I was in the middle of an interactive

Re: [RFC PATCH v2 5/5] builtin/branch: give more useful error messages when renaming

On Mon, 2017-10-23 at 12:44 -0700, Stefan Beller wrote: > +static void get_error_msg(struct strbuf* error_msg, const char* oldname, > unsigned old_branch_exists, > > + const char* newname, int > > new_branch_validation_result) > > nit here and in the return of

Re: "Cannot fetch git.git" (worktrees at fault? or origin/HEAD) ?

On Fri, 2017-10-20 at 13:45 -0700, Stefan Beller wrote: > > The git-test from Michael sounds intriguing. Initially I put off using > it as I had my main working dir (or rather test dir) on a spinning > disk, still. Now I test in memory only, which is a lot faster, so I could > try if git-test can

<    1   2   3   4   5   >