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

On Wed, 2017-07-05 at 10:00 -0700, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > > So, we're searching for scripts that > > could both be  helpful to users and could serve as a good sample to > > prove what could be done usi

Re: Help needed for solving a few issues with building git

On Wed, 2017-07-05 at 01:30 +0530, Kaartic Sivaraam wrote: > I tried pointing it to the installed location, it doesn't seem to be > working. To elaborate a little on what I did, > > * I installed the "libcurl4-openssl-dev" package b > * I found tha

[PATCH] comment: fix a typo in the comment

--- Though very trivial, I wanted to correct this as I didn't want to ignore it after seeing it. builtin/commit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/commit.c b/builtin/commit.c index 8d1cac0..aff6bf7 100644 --- a/builtin/commit.c +++ b/builtin/commit.c

[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> --- Removed the GNUism in sed command. In case no other changes are required this one's

[PATCH] 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> --- This one's the final proposed patch for this simple hook. I have requested

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

Hello all, There's an attempt in progress to replace the part of the sample "prepare-commit-msg" hook that comments the "Conflicts" part of a merge commit message. This is being done as the "Conflicts" portion is commented by default for quite some time (since 2014) and thus the script in the

Re: Why doesn't merge fail if message has only sign-off?

On Mon, 2017-07-03 at 10:21 -0700, Junio C Hamano wrote: > I think that it is not by design that it doesn't fail.  It's not > like we decided to allow s-o-b only merge because we found a reason > why it is a good idea to do so. > > So I do not think anybody minds too deeply if somebody came up a

Re: Help needed for solving a few issues with building git

On Mon, 2017-07-03 at 11:13 -0700, Junio C Hamano wrote: > Adding HTTPS support > > >  > > > I tried to add HTTP/HTTPS support to the custom built version > > > for which > > > AFAIK 'git' depends on 'curl'. I tried providing the location > > > of the > > > 

Re: "git intepret-trailers" vs. "sed script" to add the signature

On Mon, 2017-07-03 at 09:58 -0700, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > > So, it seems that excepting for 'commit' it has quite a nice > > spacing. I > > guess we could add something like the following to fix that, >

Help needed for solving a few issues with building git

Hello all, Building without localization support I tried to build git from source without localization support by adding the following line to the Makefile, NO_GETTEXT=1 It doesn't seem to be working for reasons I'm unable to find. I used the following

Why doesn't merge fail if message has only sign-off?

While trying to merge a branch using "git merge" if a merge message consists only of a "Sign-off" line it doesn't fail. To be consistent with the behaviour of "git commit" shouldn't the merge fail? -- Kaartic

[PATCH] hooks: add script to HOOKS that allows adding notes from commit message

This script is a little different from others in that it uses THREE hooks to acheive it's goal, which is to allow users to add notes for a commit while writing the commit message. It's working isn't guaranteed even if one of the hooks aren't executed. It currently works in the following

[PATCH/RFC] hooks: replace irrelevant hook sample

example that replaces it to ensure there's atleast one example that could be used just by enabling the hook. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- This patch assumes that a previous patch that touched the commit template [1] has been appled. Else it could remov

Re: [PATCH] hooks: add signature to the top of the commit message

On Sat, 2017-07-01 at 13:31 -0700, Junio C Hamano wrote: > That sounds like a sample that is there not because it would be > useful, but because we couldn't think of any useful example. > > IOW, I view it just as useful as a sample that does > > #!/bin/sh > echo "# useless cruft"

Re: [PATCH] hooks: add signature to the top of the commit message

On Sat, 2017-07-01 at 10:36 -0700, Junio C Hamano wrote: > Actually I was wondering if it is a good idea to remove it, as it > seems to have outlived its usefulness. It does seem to be a good idea but it would leave the 'prepare-commit- msg' hook with no scripts that could be used by just

[PATCH/RFC] 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> --- I've tried the various commands that I could think of and it seems to work well. I guess i

"git intepret-trailers" vs. "sed script" to add the signature

On Sat, 2017-07-01 at 19:45 +0530, Kaartic Sivaraam wrote: > On Fri, 2017-06-30 at 09:44 -0700, Junio C Hamano wrote: > > It does look like a hack.  I was wondering if "interpret-trailers" > > is mature enough and can be used for this by now. > > It does

Re: [PATCH] hooks: add signature to the top of the commit message

On Fri, 2017-06-30 at 09:44 -0700, Junio C Hamano wrote: > It does look like a hack.  I was wondering if "interpret-trailers" > is mature enough and can be used for this by now. It does look promising except for a few differences from the hook which I'll explain in the following mail. >  Also the

Re: [PATCH 2/2] commit-template: distinguish status information unconditionally

Will try to follow that in future. :) -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: [PATCH 2/2] commit-template: distinguish status information unconditionally

On Fri, 2017-06-30 at 07:52 -0700, Junio C Hamano wrote: > Thanks, both looks good.  Will queue. You're welcome :)

[PATCH] hooks: add signature to the top of the commit message

. Add the signature to the top of the commit message as it's more appropriate and consistent with the "-s" option of git commit. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- The change might seem to be bit of an hack, but it seems worth it (at least to me).

[PATCH 2/2] commit-template: distinguish status information unconditionally

the other parts of the commit-template to make it more readable. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- In trying to make the test independent of the previous test, it got a bit long. Hope it's not doing anything that shouldn't be done. In case you would wonder, th

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

was changed to align with other people's "$scm commit ", the text was added to help them transition their expectations. Remove the message that now has outlived its usefulness. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Only commit message has been chang

Re: [PATCH 2/2] commit-template: add new line before status information

On Thu, 2017-06-29 at 11:17 -0700, Junio C Hamano wrote: > The rationale of this has changed in this final version, hasn't it, > especially with the removal of the "include/only warning" bit? > > We used to add a blank line to separate the "we are committing for > somebody else", which is an

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

On Thu, 2017-06-29 at 10:56 -0700, Junio C Hamano wrote: > When I said "I would have ... if I were doing this", I merely meant > exactly that---as I weren't doing it, I left it up to you.  But you > did it the way anyways, which is very nice of you ;-). > It made a *lot* of sense, that's why. :)

[PATCH 2/2] commit-template: add new line before status information

The commit template adds the optional parts without a new line to distinguish them. This results in difficulty in interpreting it's content, specifically for inexperienced users. Add new lines to separate the distinct parts of the template. --- I tried writing tests to ensure that the new line

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

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 doing "git commit --include ", and after we changed the behaviour of the command to align with other people's

Re: [PATCH/RFC] commit-template: improve readability of commit template

I might have been ignorant about something about git in my reply in the previous email (found below). In that case, please enlighten me. On Wed, 2017-06-28 at 18:34 +0530, Kaartic Sivaraam wrote: > On Tue, 2017-06-27 at 10:56 -0700, Junio C Hamano wrote: > > Kaartic Sivaraam <kaart

Re: [PATCH] commit-template: improve readability of commit template

I forgot to add the RFC in the subject in a hurry. Please consider it's presence. -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

[PATCH] commit-template: improve readability of commit template

it's purpose of warning users about the usage '--only' as default rather than '--include'. Remove it. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- builtin/commit.c | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/builtin/commit.c b/builtin/co

Re: [PATCH/RFC] commit-template: improve readability of commit template

On Tue, 2017-06-27 at 10:56 -0700, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > I thought it's not good to trade-off readability for vertical space > > as > > the ultimate aim of the commit template (at least to me) is to

Re: [PATCH/RFC] commit-template: improve readability of commit template

y do "git commit foo", so perhaps it may be a > better > change to _remove_ the message altogether. > > And with that done, I wouldn't have reservations on this change > (i.e. "is it worth wasting extra screen real estate, especially in > the vertical direction?"), as instead of wasting 2 lines to give a > message that is no longer useful in today's world, it will be > removing one line ;-) > You're right! It is worth saving lines if it's not useful these days. I have sent another mail to the mailing list to get any other possible improvements to the status. http://public-inbox.org/git/1498583779.2737.4.ca...@gmail.com/ -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: Requesting improvements to "status" in commit template

On Tue, 2017-06-27 at 22:46 +0530, Kaartic Sivaraam wrote: > Hello all, > > There's an attempt to improve the readability of the "status" shown > in > the commit template[1]. It's been quite congested (at least to me) > Sorry, here's the link to the thread. [1] :

Requesting improvements to "status" in commit template

send them in, likely in that thread (to keep conversations intact). Thank you. -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

[PATCH/RFC] commit-template: improve readability of commit template

. Make it more clear so user gets what it's trying to say. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- I've tried to improve the message specified in the commit. Hope it works correctly. Local test passed. builtin/commit.c | 9 + 1 file changed, 5 inse

Re: Ambiguity warning printed twice ?

ugh to deserve a fix except if there are other things that I'm missing that could spoil my calculation. Anyways, hoping some "big" would happen, that avoids these kind of issues (inherently). :) -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Ambiguity warning printed twice ?

seems suspicious. $ git branch   HEAD   master * test $ git status warning: refname 'HEAD' is ambiguous. warning: refname 'HEAD' is ambiguous. On branch test Any reasons behind this behaviour or is this a bug? -- Regards, Kaartic Sivaraam

Re: Small issue with "add untracked" option of 'git add -i'

On Mon, 2017-06-12 at 10:59 -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > After prompting to get the list of desired files, if the user chose > > nothing, the message is shown.  "No untracked files chosen." is > > probably what the code wants to say, I would

Re: [PATCH/FINAL] status: contextually notify user about an initial commit

o, from this I conclude the following, "Never user e-mail clients to send patches. They seem to be bringing in all sorts of surprising changes." This is just a consequence of not following the advice in Documentation/SubmittingPatches. This won't repeat in future. (expecting, I could hold to that statement :)) -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

[PATCH/FINAL] Documentation/git-submodule: cleanup

"humanish" by "canonical" as that conveys better what we do to guess the path. While at it, quote all occurrences of '.gitmodules' as that is an important file in the submodule context, also link to it on its first mention. Helped-by: Stefan Beller <sbel...@google.com> Signed-off-by:

Re: Using '--help' for aliases

ays, I was actually considering it to be another way of getting to the man page of a command. Have to play with it a little to see in what other ways '--help' could help me! In case there's anything that's so useful about it that I'm missing, let me know. > or to show them the > referred command's manp

Re: Does 'git config' accept the '--remove' option?

On Wed, 2017-06-21 at 11:34 -0700, Junio C Hamano wrote: > Neither, I would say.  I think that you would get exactly the same > behaviour from  > > $ git config --remo test > $ git config --remove-sec test > > These are merely "unique prefix can be abbreviated in option names" > kicking

Using '--help' for aliases

at 'co' is aliased to 'checkout' but isn't it possible for it to take one step more to display help ? Just wondering if there were any reason for not doing it. -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: [PATCH] status tests: fix a minor indenting issue

weak to make it apply, so no need to resend but please > make sure you can send your patches cleanly before sending a more > substantial patch. > > Thanks. > Sorry about that. As specified in another thread, will be careful about sending patches through email-clients in fu

[PATCH/FINAL] status: contextually notify user about an initial commit

mit The most succint one among the alternatives was chosen. Helped-by: Junio C Hamano <gits...@pobox.com> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com> --- Change(s):  * Added the corresponding change to

Does 'git config' accept the '--remove' option?

output, > $ git config --remove test > fatal: No such section! > $ git config --remove-section test > fatal: No such section! Is this a bug (or) is the documentation stale ? --  Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: [PATCH/FINAL] status: contextually notify user about an initial commit

_must_fail test_i18ngrep ... > > Instead of the correct form: > > test_i18ngrep ! ... > Yeah, I did it after reading info about 'test_must_fail' in 't/README'. I thought it should be used for tests that fail which seemed to be a misinterpretation. Thanks for pointing it out. F

Re: [PATCH/FINALRFC] Documentation/git-submodule: cleanup

On Wed, 2017-06-21 at 09:11 -0700, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > > Helped-by: Stefan Beller <sbel...@google.com> > > Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> > > ---

Re: [PATCH/FINAL] status: contextually notify user about an initial commit

On Wed, 2017-06-21 at 08:07 +0530, Kaartic Sivaraam wrote: > The existing message, "Initial commit", makes sense for the commit > template > notifying users that it's their initial commit, but is confusing when > merely checking the status of a fresh repository (or orphan br

[PATCH] status tests: fix a minor indenting issue

Change the indentation from "\t " to "\t". This indenting issue was introduced when the test was added in commit 1d2f393ac9 ("status/commit: show staged submodules regardless of ignore config", 2014-04-05). Helped-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com

Re: Small issue with "add untracked" option of 'git add -i'

On Wed, 2017-06-21 at 06:52 +0200, Kevin Daudt wrote: > Did you make sure you used the git you built, and also the relevant > subcommands? > You got it. I apologise for any confusion caused here. I seemed to have accidentally given a build location in my custom build script, different from the

[PATCH/FINALRFC] Documentation/git-submodule: cleanup

"humanish" by "canonical" as that conveys better what we do to guess the path. While at it, quote all occurrences of '.gitmodules' as that is an important file in the submodule context, also link to it on its first mention. Helped-by: Stefan Beller <sbel...@google.com> Signed-off-by:

Re: Small issue with "add untracked" option of 'git add -i'

ot;No untracked files.\n"); > + print __("No untracked file chosen.\n"); >   } > - print "\n"; >  } >   >  sub run_git_apply { I tried applying the patch and building it locally. For some reason I couldn't see the change in effect. What could I be missing? -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

[PATCH/FINAL] status: contextually notify user about an initial commit

re, * Waiting for initial commit * Your current branch does not have any commits * Current branch waiting for initial commit The most succint one among the alternatives was chosen. Helped-by: Junio C Hamano <gits...@pobox.com> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam9

Re: [PATCH 1/3] Contextually notify user about an initial commit

"status: ". > That's a good one. I initially thought it was optional. -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: [PATCHv2] Tweak help auto-correct phrasing.

   assumed); > + else { > + fprintf_ln(stderr, > +    _("Continuing in %0.1f seconds, " > +  "assuming that you meant > '%s'."), > +    (float)autocorrect/10.0, > assumed); >   sleep_millisec(autocorrect * 100); >   } >   return assumed; Excuse me bringing this up after a long time. Was this patch applied? What's it's status? -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: [PATCH/RFC] Cleanup Documentation

on its first > > mention. > > (This paragraph is not exactly what happens in the commit, but > I > > wrote it > > as a way how I would write commit messages. It shows the reader > > how > > you addressed the given problem, with the quantifiers "all" > "the > > first" showing > > what you think is important, and that you deliberately omitted > > others) > Made this change too. -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: [PATCHv2] Tweak help auto-correct phrasing.

ntinuing under the assumption that you meant 'log'. > > Signed-off-by: Marc Branchaud <marcn...@xiplink.com> > --- > Excuse me for bringing this up after a long time. What's the status of this patch? Was it applied? -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: [PATCH 1/3] Contextually notify user about an initial commit

this. Both the commit messages are found below for comparison. Old one --- > On Tue, Jun 20 2017, Kaartic Sivaraam jotted: > > "git status" indicated "Initial commit" when HEAD points at > an unborn branch.  This message is shared with the commit > l

[PATCH/RFC] Cleanup Documentation

Make following changes to the git-submodule documentation: * Remove redundancy * Remove unclear back reference * Use more appropriate word * Quote important word Suggestions-by: Stefan Beller <sbel...@google.com> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --

[PATCH 3/3] Add tests for the contextual initial status message

Also, fixed minor spacing issue Helped-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com> Helped-by: Junio C Hamano <gits...@pobox.com> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- t/t7508-status.sh | 32 +++- 1 file changed, 3

[PATCH 2/3] Update test(s) that used old status message

The tests that checked for old status message have been updated to check for the new status message Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- t/t7501-commit.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t7501-commit.sh b/t/t7501-com

[PATCH 1/3] Contextually notify user about an initial commit

nt branch does not have any commits * Current branch waiting for initial commit The most succint one, "No commits yet", among the alternatives was chosen. Helped-by: Junio C Hamano <gits...@pobox.com> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- builtin/c

Re: [PATCH 2/2] Add test for the new status message

On Mon, 2017-06-19 at 14:04 -0400, Jeff King wrote: > On Mon, Jun 19, 2017 at 11:29:49PM +0530, Kaartic Sivaraam wrote: > > > Is there a way to test for the "Initial commit" message in the > > commit > > template? > > You can do "git commit --dry-

Re: [PATCH 2/2] Add test for the new status message

On Sun, 2017-06-18 at 21:32 -0700, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > > +test_expect_success 'No commits yet should be noted in status > > output' ' > > +   git init initial && > > +   

Re: [PATCH/RFC] Cleanup Documentation

1) redundancy seems fine to me. > Sorry about that. The commit message should have been, ... 2. Removed unclear back reference ... by which I intend to denote the following removal, > -In either case, the given URL is recorded into .gitmodules for > -use by subsequent users cloning the superproject. Note: Will follow up with a patch, soon. -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: [PATCH/ALMOST FINAL] Contextually notify user about an initial commit

as fine". I am unopinionated, too. I'll stay with "No commits yet" for now until someone suggests to change it due to confusion about whether it's a "No commits yet on the branch" or it's a "No commits yet on this repository". -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

[PATCH/RFC] Cleanup Documentation

1. Remove redundancy from documentation 2. Remove unclear reference to alternative Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- The following line seemes unclear and hence was removed for now. Suggest any changes that could make it clear. "This second form

[PATCH 2/2] Add test for the new status message

Patch-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Resending as a continuation of previous patch t/t7508-status.sh | 11 +++ 1 file changed, 11 insertions(+) diff --git a/t/t7508-status.sh b/t/t7508-sta

[PATCH 2/2] Add test for the new status message

Patch-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- t/t7508-status.sh | 11 +++ 1 file changed, 11 insertions(+) diff --git a/t/t7508-status.sh b/t/t7508-status.sh index fb00e6d9b..e9337c728 100755 -

[PATCH 1/2] Contextually notify user about an initial commit

nt branch does not have any commits * Current branch waiting for initial commit Patch-derived-from: Junio C Hamano <gits...@pobox.com> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Hope this would be final :) builtin/commit.c | 1 + wt-status.c | 5 +++

[PATCH/ALMOST FINAL] Contextually notify user about an initial commit

nt branch does not have any commits * Current branch waiting for initial commit Patch-by: Junio C Hamano <gits...@pobox.com> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- builtin/commit.c | 1 + wt-status.c | 5 - wt-status.h | 1 + 3 files changed,

Re: [PATCH/Almost final] wt-status.c: Modified status message shown for a parent-less branch

On Fri, 2017-06-16 at 06:50 -0400, Jeff King wrote: > Wouldn't you want this in cmd_commit(), not cmd_status()? > That's right. I made a little mistake while trying to replicate a change specified by Mr. Junio C. Hamano in a previous mail in this thread.  Seems there aren't any other changes

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

On Thu, 2017-06-15 at 09:12 -0400, Jeff King wrote: > On Thu, Jun 15, 2017 at 07:43:17AM -0400, Samuel Lijin wrote: > > > > Saying just "staged changes" is definitely accurate. I don't know > > > if > > > some users would find that too terse, too. The phrase "not staged > > > for > > > commit"

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

On Mon, 2017-06-12 at 17:37 -0400, Jeff King wrote: > On Mon, Jun 12, 2017 at 02:31:25PM -0700, Junio C Hamano wrote: > > > I think "staged for commit" still makes perfect sense even when > > > we are > > > just asking "what's the current status" and not "what would it > > > look like > > > if I

Re: Small issue with "add untracked" option of 'git add -i'

On Wed, 2017-06-14 at 18:34 +0530, Kaartic Sivaraam wrote: > That's right. Though I'm not sure of the implementation, I guess the > following patch would make `git add -i` do what I thought it should. > A possible, probably better, alternative would be to make the empty state ou

Re: Small issue with "add untracked" option of 'git add -i'

On Mon, 2017-06-12 at 10:59 -0700, Junio C Hamano wrote: > Together with your other wishes, perhaps something like this is what > you have in mind.  The original tried to throw in a blank line as a > separator to help interactive users to more easily tell the boundary > of blocks of text, but it

Re: Small issue with "add untracked" option of 'git add -i'

be a more apt message to be shown. It's unambiguous. -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Small issue with "add untracked" option of 'git add -i'

s in his working directory. > *** Commands *** >   1: status   2: update   3: revert   4: add > untracked >   5: patch  6: diff   7: quit   8: help > What now> 4 > No untracked files. > -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

area?", I would think. > > Thanks. > It seems that the current change has to be discarded altogether and further the change required doesn't look trivial. This seems to warrant some bit of research of the code base. As a first step I would like to know which part of the code base creates the commit template. I guess much can't be done without knowing how it's created. -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

On Sat, 2017-06-10 at 14:14 +0530, Kaartic Sivaraam wrote: > Looks odd. Just to be more clear by "Looks odd" I mean that the new status message looks odd in the commit template. --  Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # # Waiting for initial commit # # Changes to be committed: #   new file:   test-file # Looks odd. Not sure how to fix this. Maybe on of the alternatives have to be considered. "Your current branch does not have any commits" seems a good one. -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

to make their initial commit which the previous message didn't seem to do communicate well. A few alternatives were, * No commit yet * Your current branch does not have any commits * Current branch waiting for initial commit Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.

[PATCH] wt-status.c: Modified status message shown for a parent-less branch

to make their initial commit which the previous message didn't seem to do communicate well. A few alternatives were, * No commit yet * Your current branch does not have any commits * Current branch waiting for initial commit Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> -

Re: What does this output of git supposed to mean ?

urse would need to remain the same). BTW, could anyone provide a pointer to the implementation that prints this message ? -- Regards, Kaartic Sivaraam

Re: What does this output of git supposed to mean ?

t; on the branch, and the branch is waiting for the initial commit. > Looks descriptive to me too. Just for the note, I wouldn't have asked this question if `git status` showed a message like this. -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

What does this output of git supposed to mean ?

itial commit" supposed to mean? -- Regards, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>

Re: Missing: Consistency of clean state output of "git add -i"

On Sun, 2017-05-28 at 11:39 +0100, Philip Oakley wrote: > I wouldn't let that stop you. We were all ignorant once. > I know little of tcl (gitk/git-gui), but I've still managed to fix a > couple  > of issues, with the help of others on the list (and the search > engines and  > their results;-) >

Re: Missing: Consistency of clean state output of "git add -i"

I guess I'll take back my note in the previous email that says, I could help. I saw the implementation and found that I couldn't help as I don't have experience with PERL. My bad.

Missing: Consistency of clean state output of "git add -i"

Hello all, When the "git add -i" command is triggered with a clean working directory and index, the outputs of the various options don't seem to be giving consistent results. A few of the distinct outputs are, 1. No output, the options are displayed 2. A single blank line and the options are

Re: [Suggestion] Alternative way for displaying help menu of patch flow

On Friday 28 April 2017 12:07 PM, Jeff King wrote: If the hunk is big, that message scrolls off the screen. We could probably put it after the hunk, but I'd worry that the ordering would be confusing (because it comes between the hunk and the "this hunk" prompt. Probably it could be better to

[Suggestion] Alternative way for displaying help menu of patch flow

Hello community, I would like to state about a small issue I face when I use the `git add -i` command. I guess it's expressed easily with an example. Start Imagine a situation in which you accidentally made a reasonable amount of change to your code from your last commit. You

Re: Suggestion for the "Did you mean this?" feature

Hello all, On Sun, 18 December 2016 at 20:59, Alexei Lozovsky wrote, > It's definitely a good thing for human users. For example, I am > annoyed > from time to time when I type in some long spell, mistype one minor > thing, > and the whole command fails. Then I need to press , correct the >

Re: Suggestion for the "Did you mean this?" feature

On Sun, 2016-12-18 at 14:16 +0100, Stephan Beyer wrote: > I cannot tell if this is a good idea (or why it would be a bad idea) > but > why do you restrict your suggestion to the case when there is only > one > alternative? > > Why not also something like: > > --- > $ git sta > git: 'sta' is not

Suggestion for the "Did you mean this?" feature

Hello all, I have found the "Did you mean this?" feature of git as a very good feature. I thought it would be even better if it took a step toward by asking for a prompt when there was only one alternative to the command that was entered.  E.g. > unique@unique-pc:~$ git hepl > git: 'hepl' is

<    1   2   3   4   5