[PATCH v4 3/3] branch: quote branch/ref names to improve readability

Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- No changes in this one. Sending this just because of the change in the total number of commits. branch.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/branch.c b/branch.c

[PATCH v4 1/3] test: cleanup cruft of a test

for the changes that are to be introduced to be independent of it. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- This was part of [PATCH v3 1/2] and has been separated as it seemed to be a "logically separate" change. t/t3200-branch.sh | 1 + 1 file changed, 1 in

[PATCH v2/RFC] hook: use correct logical variable

ottom line: Being consistent prevents all sorts of weird issues. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Changes in v2: - updated the commit message Suggestions regarding ways to improve the message are most welcome. templates/hooks--prepare-commit

Re: [PATCH] hook: use correct logical variable

On Tue, 2017-08-15 at 10:28 -0700, Junio C Hamano wrote: > I did shoot for conciseness, but what is a lot more important is to > record what is at the core of the issue. "I found it by doing A" > can hint to careful readers why doing A leads to an undesirable > behaviour, but when there are other

Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

On Wed, 2017-08-16 at 12:09 -0700, Junio C Hamano wrote: > You said that "checkout" does not do a necessary check that is done > in "branch", so presumably "branch" already has a code to do so that > is not called by the current "checkout", right? Then you would add > a new caller in "checkout"

Re: What's cooking in git.git (Aug 2017, #03; Mon, 14)

It's been around 4 or 5 issues of 'What's cooking in git.git' and I haven't heard about the patches found at, http://public-inbox.org/git/<20170730111705.12444-1-kaarticsivaraam91...@gmail.com> and https://public-inbox.org/git/<20170730115908.13841-1-kaarticsivaraam91...@gmail.com> What has

Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

On Wednesday 16 August 2017 12:28 AM, Junio C Hamano wrote: Some refactoring to make it easier to reuse it from the new caller would be necessary. Sorry but I think I don't get that correctly. What's the "new caller" being referred to here? What should be refactored? --- Kaartic

Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

On Tuesday 15 August 2017 01:49 AM, Junio C Hamano wrote: I wonder if these two lines add any value here. Those who know the reason would not be helped, and those who don't know have to view "git show b347d06bf" anyway. That's right. I somehow think the above wastes bits a bit too much.

Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

On Tuesday 15 August 2017 12:44 AM, Martin Ågren wrote: --set-upstream:: - If specified branch does not exist yet or if `--force` has been - given, acts exactly like `--track`. Otherwise sets up configuration - like `--track` would when creating the branch, except that where

Re: [PATCH] hook: use correct logical variable

On Monday 14 August 2017 11:49 PM, Junio C Hamano wrote: I tend to agree with "Anyways" above ;-) simply because I found the long paragraph more confusing than enlightening, leaving me wonder "why is the user using different settings for author and committer name" at the end, which _is_ an

Re: [PATCH] hook: use correct logical variable

On Monday 14 August 2017 11:24 PM, Stefan Beller wrote: On Mon, Aug 14, 2017 at 1:46 AM, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> wrote: Sign-off added should be that of the "committer" not that of the "commit's author". Use the correct logical variable tha

[PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

$ git branch * master $ git branch --set-upstream origin/master fatal: the '--set-upstream' flag is no longer supported and will be removed. Consider using '--track' or '--set-upstream-to' $ echo $? 128 $ git branch * master Signed-off-by: Kaartic Sivaraam &

Re: [PATCH v2 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

On Wednesday 09 August 2017 12:03 AM, Martin Ågren wrote: (Also, is this really a refactoring?) Not quite. --set-upstream:: - If specified branch does not exist yet or if `--force` has been - given, acts exactly like `--track`. Otherwise sets up configuration - like

[PATCH] hook: use correct logical variable

Sign-off added should be that of the "committer" not that of the "commit's author". Use the correct logical variable that identifies the committer. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- This fixes a small issue when trying to do the

[PATCH v2 2/2 / RFC] branch: quote branch/ref names to improve readability

Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- branch.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/branch.c b/branch.c index ad5a2299b..a40721f3c 100644 --- a/branch.c +++ b/branch.c @@ -90,24 +90,24 @@ int install_branch_conf

[PATCH v2 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

h --set-upstream origin/master fatal: the '--set-upstream' flag is no longer supported and will be removed. Consider using '--track' or '--set-upstream-to' $ echo $? 128 $ git branch * master Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Changes in

Re: Can the '--set-upstream' option of branch be removed ?

On Mon, 2017-08-07 at 13:59 -0700, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > > I refactored builtin/branch.c to remove the '--set-upstream' > > option,successfully. The corresponding patch follows. > > > > The

Re: Change in output as a result of patch

On Mon, 2017-07-24 at 14:25 -0700, Junio C Hamano wrote: > I suspect that with a moderately-sized refactoring around > validate_new_branchname() function, this should be doable. Instead > of passing two "int" parameters force and attr_only, make them into > a single "unsigned flag" I guess it's

[PATCH 2/2 / RFC] branch: quote branch/ref names to improve readability

Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- branch.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/branch.c b/branch.c index ad5a2299b..a40721f3c 100644 --- a/branch.c +++ b/branch.c @@ -90,24 +90,24 @@ int install_branch_conf

[PATCH 1/2 / RFC] builtin/branch: remove the deprecated '--set-upstream' option

the after sequence is still '--set-upstream' though the behaviour is that of '--set-upstream-to'. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Documentation/git-branch.txt | 10 ++--- builtin/branch.c | 24 - t/t3200-branch.sh

Can the '--set-upstream' option of branch be removed ?

I refactored builtin/branch.c to remove the '--set-upstream' option,successfully. The corresponding patch follows. There's just one issue with the version of git that doesn't have the '--set-upstream' option. It's described in the commit log message of the following patch. I guess it would be

Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged

On Wed, 2017-08-02 at 10:58 -0700, Stefan Beller wrote: > That may be either a contributors problem (lacking time or > motivation to go through a long document) or a problem with > the community. > I'm trying to avoid the former. > I would not want to explain the same thing over and

Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged

On Wed, 2017-08-02 at 09:01 -0700, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > > On Tue, 2017-08-01 at 10:46 -0700, Stefan Beller wrote: > > > So maybe we want to cut a lot of workflow related commendatory from

Re: [RFC] The correct and consistent alternative to quote a command ?

On Wed, 2017-08-02 at 10:32 -0700, Stefan Beller wrote: > Thanks for checking. You're welcome. :) -- Kaartic

Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged

On Tue, 2017-08-01 at 10:46 -0700, Stefan Beller wrote: > Actually I am slightly negative on this one, because of > occurrences like [1]. > > Our SubmittingPatches is already considered *too long* for most people > who just want to drop a drive-by patch. > > Adding more knowledge (which btw is

Re: [RFC] The correct and consistent alternative to quote a command ?

On Tue, 2017-08-01 at 10:38 -0700, Stefan Beller wrote: > On Tue, Aug 1, 2017 at 8:59 AM, Kaartic Sivaraam wrote: > > I assume you mean the consistency in quoting i.e., you're expecting the > > patch to use (") instead of (') for quoting. Correct me, if I'm wrong. > > Ac

[PATCH 2/2] doc: add another way to identify if a patch has been merged

Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Documentation/SubmittingPatches | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 886fe3650..7197709ee 100644 --- a/Documentation/SubmittingP

[PATCH 1/2] doc: fix small issues in SubmittingPatches

Replace the dashed version of a command with undashed version and quote it. Use double quotes to quote a git command for consistency. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Documentation/SubmittingPatches | 4 ++-- 1 file changed, 2 insertions(+), 2 del

Re: [PATCH 1/2] doc: fix small issues in SubmittingPatches

On Mon, 2017-07-31 at 13:23 -0700, Stefan Beller wrote: > On Sun, Jul 30, 2017 at 9:18 AM, Kaartic Sivaraam > <kaarticsivaraam91...@gmail.com> wrote: > > Replace the dashed version of a command with undashed > > version and quote it. > > I like it, but sim

[PATCH 1/2] doc: fix small issues in SubmittingPatches

Replace the dashed version of a command with undashed version and quote it. Further, remove duplicated space character. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Documentation/SubmittingPatches | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

Re: [PATCH 1/2] doc: fix small issues in SubmittingPatches

On Sun, 2017-07-30 at 15:49 +0100, Philip Oakley wrote: > From: "Kaartic Sivaraam" <kaarticsivaraam91...@gmail.com> > > minor nit: It's nice, for these single character changes, to give a clue in > the commit message as to what to look for. > > E.g. > >

[PATCH] branch: change the error messages to be more meaningful

elow, $ git branch foo * master $ git branch -m foo foo old fatal: too many branches for a rename operation Change the messages to be more general thus making no assumptions about the "parameters". Signed-off-by: Kaartic Sivaraam <kaarticsiva

Wrong thread

Sorry, sent it to the wrong thread. Please, ignore this patch. -- Kaartic

[PATCH] remote: split and simplify messages

Splitting a single sentence across multiple lines could degrade readability. Further, long messages are likely to be ignored by users. Split the sentences and simplify it to improve their readability. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- re

[PATCH] branch: change the error messages to be more meaningful

elow, $ git branch foo * master $ git branch -m foo foo old fatal: too many branches for a rename operation Change the messages to be more general thus making no assumptions about the "parameters". Signed-off-by: Kaartic Sivaraam <kaarticsiva

[PATCH 1/2] doc: fix small issues in SubmittingPatches

Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Documentation/SubmittingPatches | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 558d465b6..9d0dab08d 100644 --- a/Documen

[PATCH 2/2] doc: add another way to identify if a patch has been merged

Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- I'm not sure if the first one (pull --rebase) is still required and hence leaving it as such. Let me know if it could be removed. Documentation/SubmittingPatches | 4 1 file changed, 4 insertions(+) diff

Re: [PATCH/RFC] setup: update error message to be more meaningful

On Sun, 2017-07-30 at 16:17 +0530, Kaartic Sivaraam wrote: > On Sat, 2017-07-29 at 09:10 -0700, Junio C Hamano wrote: > > We perhaps need to somehow make sure new users won't be led to the > > misunderstanding. Improving our documentation is a good first step. > > That's s

Re: [PATCH/RFC] setup: update error message to be more meaningful

On Sat, 2017-07-29 at 09:10 -0700, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > > > That's interesting. In that case, I'll go with the suggested statement, > > happily! > > It is not interesting at all. It actually is dis

[PATCH] setup: update error message to be more meaningful

: option '-n' must come before non-option arguments Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/setup.c b/setup.c index 860507e1fdb2d..09c79328247dd 100644 --- a/setup.c +++ b/setup.c @@ -230,7

Re: [PATCH/RFC] setup: update error message to be more meaningful

On Fri, 2017-07-28 at 20:53 -0700, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > > Though the message seems to be most fitting one, I'm a little reluctant > > to use it as it "might" create a wrong picture on the minds

Guidlines for error messages

Hello all, On reading the CodingGuidelines, I saw a section that specifies rules about the structure and formatting of error messages. I have reproduced it below, Error Messages  - Do not end error messages with a full stop.  - Do not capitalize ("unable to open %s", not "Unable

Re: [PATCH/RFC] setup: update error message to be more meaningful

On Wed, 2017-07-26 at 13:09 -0700, Junio C Hamano wrote: > Jonathan Nieder writes: > > > For an initial guess: in the example > > > > git grep test -n > > > > ... > > 2. Focus on "argument" instead of "filename" so that the message > > could still apply: something

[PATCH] remote: split and simplify messages

Splitting a single sentence across multiple lines could degrade readability. Further, long messages are likely to be ignored by users. Split the sentences and simplify it to improve their readability. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- re

Re: [PATCH/RFC] setup: update error message to be more meaningful

Hello Jonathan Nieder, Thanks for the reply! Jonathan Nieder wrote: > > > The error message shown when a flag is found when expecting a > > filename wasn't clear as it didn't communicate what was wrong > > using the 'suitable' words in *all* cases. > > > > Correct case, > > > > $ git

Re: Change in output as a result of patch

Let me see if I got everything correctly. Correct me if any of the below observations are wrong. On Mon, 2017-07-24 at 14:25 -0700, Junio C Hamano wrote: > Imagine this scenario instead, which I think is more realistic > example of making a typo. The set of existing branches are like > this: >

Re: [PATCH] branch: change the error messages to be more meaningful

The second patch differs from the first one only in the commit message. -- Kaartic

[PATCH] branch: change the error messages to be more meaningful

elow, $ git branch foo * master $ git branch -m foo foo old fatal: too many branches for a rename operation Change the messages to be more general thus making no assumptions about the "parameters". Signed-off-by: Kaartic Sivaraam <kaarticsiva

Re: [PATCH/RFC] setup: update error message to be more meaningful

I've added RFC to this patch's subject as I'm not sure if the new message is suitable. Suggestions for messages that are more suitable are welcome. It seems that the function "verify_filename" is invoked by plumbing commands like 'rev-parse', let me know if I've missed something about them. I

[PATCH/RFC] setup: update error message to be more meaningful

fatal: found flag '--flags' in place of a filename $ git grep "test" -n fatal: found flag '-n' in place of a filename Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] branch: change the error messages to be more meaningful

s". Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- builtin/branch.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/builtin/branch.c b/builtin/branch.c index a3bd2262b3367..59fedf085d3db 100644 --- a/builtin/branch.c +++ b/builtin/branch.c

Change in output as a result of patch

The patch in the previous mail results in a change in output as specified below. $ git branch * master   foo   bar Before patch, $ git branch -m hypothet master fatal: A branch named 'master' already exists. $ git branch -m hypothet real error: refname

[PATCH/RFC] branch: warn user about non-existent branch

-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- I'm sending this patch as I didn't want to leave this thread open ended. I'm not yet sure if this is a good thing to do. This patch is open to comments, as the prvious ones I've sent have been. builtin/branch.c | 4

Re: [L10N] Kickoff of translation for Git 2.14.0 round 1

On Sat, 2017-07-15 at 21:30 +0200, Jean-Noël Avila wrote: > * commit 4ddb1354e8 ("status: contextually notify user about an initial > commit") plays sentence lego while introducing colorization which again > does not play well with i18n. > What, if anything, should be done about this? --

[PATCH] doc: reformat the paragraph containing the 'cut-line'

. Reformat the pragraph to make the 'cut-line' stand on a line of it's own thus distinguishing it from the rest of the paragraph. This further prevents it from getting wrapped to some extent. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Documentation/git-commit.tx

Re: [PATCH] doc: reformat the paragraph containing the 'cut-line'

On Mon, 2017-07-17 at 15:16 -0700, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > + Same as `whitespace` except that everything from (and including) > > +the line found below is truncated, if the message is to be edited. > > +

Re: [L10N] Kickoff of translation for Git 2.14.0 round 1

Hello, As a heads up (and because I have been pulled into this thread :)), I wanted to bring to the notice of translators that the commit, b884244c8 commit-template: remove outdated notice about explicit paths *removes* a message ("Explicit paths specified without -i or -o; assuming --only

[PATCH] doc: camelCase the i18n config variables to improve readability

The i18n config variable used weren't readable as they were in the crude form of how git stores/uses it's config variables. Improve it's readability by replacing them with camelCased versions of config variables as it doesn't have any impact on it's usage. Signed-off-by: Kaartic Sivaraam

[PATCH] doc: reformat the paragraph containing the 'cut-line'

. Reformat the pragraph to make the 'cut-line' stand on a line of it's own thus distinguishing it from the rest of the paragraph. This further prevents it from getting wrapped to some extent. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Documentation/git-commit.tx

[PATCH] commit: check for empty message before the check for untouched template

uched" error which is wrong. He should be shown the "empty message" error. Do the empty message check before checking for an untouched template thus fixing this issue. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- builtin/commit.c | 12 ++-- 1

Re: [PATCH] commit & merge: modularize the empty message validator

On Fri, 2017-07-14 at 23:19 +0530, Kaartic Sivaraam wrote: > * Imagine a hypothetical version of git that aborts when the > is empty though a  is present. This would > quite possibly instigate controversies as the "hypothetical git" > red

Re: [PATCH] commit & merge: modularize the empty message validator

On Thu, 2017-07-13 at 12:23 -0700, Junio C Hamano wrote: > All good points; if it bothers you that "commit" and "merge" define > "emptyness" of the buffer differently too much, I think you could > persuade me to unify them to "the buffer _must_ contain no bytes", > i.e. not special-casing sign-off

Re: [PATCH] commit & merge: modularize the empty message validator

On Thu, 2017-07-13 at 10:58 -0700, Junio C Hamano wrote: > I think many people know about and do use the "delete all lines" > (i.e. ":1,$d" in vi, or \M-< \C-SPC \M-> \C-w in Emacs) to abort out > of a commit or a merge.  I just do not think it is likely for them > to leave Sign-off lines and

Re: [PATCH] commit & merge: modularize the empty message validator

On Tue, 2017-07-11 at 13:22 -0700, Junio C Hamano wrote: > I think the "validation" done with the rest_is_empty() is somewhat > bogus.  Why should we reject a commit without a message and a > trailer block with only signed-off-by lines, while accepting a > commit without a message and a trailer

Re: [PATCH] commit & merge: modularize the empty message validator

On Tue, 2017-07-11 at 13:22 -0700, Junio C Hamano wrote: > Having said all that, I am not sure "Prevent such surprises" is a > problem that is realistic to begin with.  When a user sees the > editor buffer in "git merge", it is pre-populated with at least a > single line of message "Merge branch

Re: [PATCH 4/4] hook: add a simple first example

On Tue, 2017-07-11 at 09:03 -0700, Junio C Hamano wrote: > But does it even be useful to enable it? Just for the note, I thought it was considered useful (at least to someone) due to it's presence in the sample script.

Re: [PATCH 4/4] hook: add a simple first example

On Tue, 2017-07-11 at 09:03 -0700, Junio C Hamano wrote: > But does it even be useful to enable it?  The commented out "git > status" output already lists the modified paths, so I do not think > anything is gained by adding 'diff --cached --name-status' there. The script *doesn't* add the output

Re: [PATCH/RFC] commit & merge: modularize the empty message validator

Sorry, forgot to add the RFC suffix to [PATCH]. Please consider it's presence. -- Kaartic

[PATCH 4/4] hook: add a simple first example

Add a simple example that replaces an outdated example that was removed. This ensures that there's at the least a simple example that illustrates what could be done using the hook just by enabling it. Also, update the documentation. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.

[PATCH] commit & merge: modularize the empty message validator

se surprises to users who are accustomed to the meaning of an "empty message" of "git commit". Prevent such surprises by ensuring the meaning of an empty 'merge message' to be in line with that of an empty 'commit message'. This is done by separating the empty message validator from 'commit'

[PATCH 3/4] hook: add sign-off using "interpret-trailers"

istent with the output of "-s" option. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- templates/hooks--prepare-commit-msg.sample | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/templates/hooks--prepare-commit-msg.sample b/templates/

[PATCH 4/4] hook: add a simple first example

Add a simple example that replaces an outdated example that was removed. This ensures that there's at the least a simple example that illustrates what could be done using the hook just by enabling it. Also, update the documentation. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.

[PATCH 2/4] hook: name the positional variables

It's always nice to have named variables instead of positional variables as they communicate their purpose well. Appropriately name the positional variables of the hook to make it easier to see what's going on. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- templates

[PATCH 1/4] hook: cleanup script

e 261f315b ("merge & sequencer: turn "Conflicts:" hint into a comment", 2014-08-28). Further update the relevant comments from the sample script and update the documentation. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Documentation/githooks.txt

Re: [PATCH 4/4] hook: add a simple first example

On Mon, 2017-07-10 at 13:02 -0700, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > >  I made an attempt to make the second example work with amending  > >  with the aim of making it suitable for usage out of the box. It > >  se

Re: [PATCH 3/4] hook: add signature using "interpret-trailers"

Note: Re-attempting to send mail due to rejection On Mon, 2017-07-10 at 16:13 +0100, Ramsay Jones wrote: > > Again, s/signature/sign-off/g, or similar (including subject line). > Thanks! Forgot that in the course of splitting the patches and modifying them. -- Kaartic

Re: [PATCH 3/4] hook: add signature using "interpret-trailers"

On Mon, 2017-07-10 at 16:13 +0100, Ramsay Jones wrote: > > Again, s/signature/sign-off/g, or similar (including subject line). > Thanks! Forgot that in the course of splitting the patches and modifying them.

[PATCH] doc: correct a mistake in an illustration

The first illustration of the "RECOVERING FROM UPSTREAM REBASE" section in the 'git-rebase' documentation wasn't in line with the rest of the illustrations of that section. Correct it. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Documentation/git-reba

[PATCH 3/4] hook: add signature using "interpret-trailers"

consistent with the output of "-s" option. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- templates/hooks--prepare-commit-msg.sample | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/templates/hooks--prepare-commit-msg.sample b/tem

[PATCH 4/4] hook: add a simple first example

Add a simple example that replaces an outdated example that was removed. This ensures that there's at the least a simple example that illustrates what could be done using the hook just by enabling it. Also, update the documentation. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.

[PATCH 2/4] hook: name the positional variables

It's always nice to have named variables instead of positional variables as they communicate their purpose well. Appropriately name the positional variables of the hook to make it easier to see what's going on. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- templates

[PATCH 1/4] hook: cleanup script

e 261f315b ("merge & sequencer: turn "Conflicts:" hint into a comment", 2014-08-28). Further remove the relevant comments from the sample script and update the documentation. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Documentation/githooks.txt

Re: "Branch exists" error while trying to rename a non-existing branch to an existing one

On Sun, 2017-07-09 at 11:57 -0700, Junio C Hamano wrote: > This is borderline "meh" at least to me.  An argument against a > hypothetical version of Git that "fixes" your issue would be that no > matter what the source of renaming is, as long as 'master' exists, > "branch -m" shouldn't overwrite

"Branch exists" error while trying to rename a non-existing branch to an existing one

Hello all, I recently got the following error message by change as a result of the command, $ git branch -m no-branch master fatal: A branch named 'master' already exists. Note: no-branch is an hypothetical branch that doesn't exist. Shouldn't I get a 'no-branch' doesn't exist before

Re: [PATCH 1/2] commit-template: remove outdated notice about explicit paths

On Fri, 2017-06-30 at 17:42 +0530, Kaartic Sivaraam wrote: > The notice that "git commit " default to "git commit > --only " was there since 756e3ee0 ("Merge branch > 'jc/commit'", 2006-02-14).  Back then, existing users of Git > expected the command

Re: What's cooking in git.git (Jul 2017, #02; Fri, 7)

On Sat, 2017-07-08 at 15:33 -0700, Junio C Hamano wrote: > That is how a message that is BCC'ed to you is supposed to look > like, isn't it? May be not. rfc5322 (Internet Message Format) seems to clear the confusion, There are three ways in which the "Bcc:" field is used. In the first case,

Re: What's cooking in git.git (Jul 2017, #02; Fri, 7)

Just wanted to know something out of curiosity. How am I actually receiving these "What's cooking" emails though I'm not a subscriber to the mailing list to which this is being addressed ? Further, my email address isn't list in the To, Cc or Bcc fields. I wanted to know this as, this has been

[PATCH 2/2] hooks: add signature using "interpret-trailers"

consistent with the output of "-s" option. While at it, name the input parameters to improve readability of script. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- templates/hooks--prepare-commit-msg.sample | 18 -- 1 file changed, 16 insertion

[PATCH 1/2] hooks: replace irrelevant hook sample

alternative example that replaces it. This ensures there's at the least a simple example that illustrates what could be done using the hook just by enabling it. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- I have made the second patch depend on the first one to avoid conflicts th

[PATCH] commit: fix a typo in the comment

Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- builtin/commit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/commit.c b/builtin/commit.c index 8d1cac062..aff6bf7aa 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -984,7 +984,7 @@

Re: [PATCH] hooks: replace irrelevant hook sample

On Fri, 2017-07-07 at 08:05 -0700, Junio C Hamano wrote: > That is because I wear multiple hats, because I try to help in > different ways, and because open source is not a battle to see whose > idea is more right, but is a cooperative process to find a better > solution together. > Thanks for

Re: [PATCH] hooks: replace irrelevant hook sample

On Wed, 2017-07-05 at 12:50 -0700, Junio C Hamano wrote: > Three things that caught my eyes: > >  - Between "git commit --cleanup=strip" and "git commit -- > cleanup=verbatim", >    lines that make up this initial instruction section are different. > >  - "git grep 'Please enter the '" finds

Re: [PATCH] hooks: add signature using "interpret-trailers"

On Wed, 2017-07-05 at 21:14 +0100, Ramsay Jones wrote: > > On 05/07/17 18:35, Kaartic Sivaraam wrote: > > The sample hook to prepare the commit message before > > a commit allows users to opt-in to add the signature > > to the commit message. The signature is added a

Re: [PATCH] merge-message: change meaning of "empty merge message"

On Thu, 2017-07-06 at 06:46 +0200, Kevin Daudt wrote: > > The function is called "rest_is_empty". > Thanks for correcting that! > But isn't it better that commit and merge use the same code, instead > of > duplicating it again? Otherwise one may be updated, and the other > forgotten, getting

[PATCH] merge-message: change meaning of "empty merge message"

se surprises to users who are accustomed to the meaning of an "empty message" of "git commit". Prevent such surprises by changing the meaning of an empty 'merge message' to be in line with that of an empty 'commit message'. Signed-off-by: Kaartic Sivaraa

Re: Requesting suggestions for a good sample "prepare-commit-msg" hook

On Wed, 2017-07-05 at 12:19 -0700, Junio C Hamano wrote: > I honestly do not see your point.  Yes, I said that the change > indicates that there is no useful example found (so far).  That does > not necessarily mean that we must find a useful example so that we > can keep this sample script, which

[PATCH] comment: fix a typo in the comment

Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- builtin/commit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/commit.c b/builtin/commit.c index 8d1cac062..aff6bf7aa 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -984,7 +984,7 @@

Re: [PATCH] comment: fix a typo in the comment

On Wed, 2017-07-05 at 11:18 -0700, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > > --- > >  Though very trivial, I wanted to correct this as I didn't > >  want to ignore it after seeing it. > > Thanks for sharp eyes

Re: Requesting suggestions for a good sample "prepare-commit-msg" hook

> On Wed, 2017-07-05 at 10:00 -0700, Junio C Hamano wrote: > > I am not so sure that we are searching for them, to be honest (who > > are we in this context anyway?) > Imagining HTML could be used in plain-text, I think I misinterpreted your sentence in one of the other mails (found below),

[PATCH] hooks: add signature using "interpret-trailers"

consistent with the output of "-s" option. While at it, name the input parameters to improve readability of script. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Added a close quote that got missed in the previous patch. templates/hooks--prepare-commit-

<    1   2   3   4   5   >