Re: [RFE] Add minimal universal release management capabilities to GIT

Heads up, I'm gonna play the devil's advocate a little, here. On Sat, 2017-10-21 at 15:56 +0200, nicolas.mail...@laposte.net wrote: > No that is not up to the hash function. First because hashes are too > long to be manipulated by humans, and second no hash will ever > capture human intent. You

Re: Re* Is t5601 flaky for anybody else?

On Tue, 2017-10-17 at 17:08 -0400, Jeff King wrote: > On Wed, Oct 18, 2017 at 06:02:59AM +0900, Junio C Hamano wrote: > > FWIW, I can't replicate the problem on either "master" or "pu". I wonder > why. > Neither can I. I tried running t5601 on "master" and on "pu" after reverting the patch

Re: [PATCH 3/3] branch: forbid refs/heads/HEAD

On Sat, 2017-10-21 at 17:57 +0900, Junio C Hamano wrote: > ... The code may already > handle it, or there may need even more code to support the rename; I > didn't check. > As far as I could see there the code does seem to already handle the rename. This part of builtin/branch.c is what seems to

Re: [PATCH 0/3] a small branch API clean-up

On Sat, 2017-10-21 at 17:52 +0900, Junio C Hamano wrote: > > Sorry, but I am not sure what you are asking. > > I was looking at the code, noticed NEEDSWORK comment and worked on > cleaning things up---you seem to feel that I need a reason, or > perhaps even your permission, when I try

Re: [PATCH 2/3] branch: split validate_new_branchname() into two

On Fri, 2017-10-13 at 14:11 +0900, Junio C Hamano wrote: > > diff --git a/branch.c b/branch.c > index 7404597678..2c3a364a0b 100644 > --- a/branch.c > +++ b/branch.c > @@ -178,19 +178,31 @@ int read_branch_desc(struct strbuf *buf, const char > *branch_name) > return 0; > } > > -int

Re: [PATCH 3/3] branch: forbid refs/heads/HEAD

Junio C Hamano writes: > > > Perhaps. Also we may want to make sure that "git branch -D HEAD" > > still works as a way to recover from historical mistakes. > > The only difference is improved tests where we use show-ref to make > sure refs/heads/HEAD does not exist when it

Re: [PATCH 0/3] a small branch API clean-up

On Fri, 2017-10-13 at 14:11 +0900, Junio C Hamano wrote: > This started as a little clean-up for a NEEDSWORK comment in > branch.h, but it ended up adding a rather useful safety feature. > Part of this series seems to duplicate the work done in part of my series that tries to give more useful

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

On Fri, 2017-10-20 at 14:50 -0700, Stefan Beller wrote: > On Mon, Sep 25, 2017 at 1:20 AM, Kaartic Sivaraam > <kaartic.sivar...@gmail.com> wrote: > > The ad-hoc patches to add new arguments to a function when needed > > resulted in the related arguments not b

Re: [RFC PATCH v2 1/5] branch: improve documentation and naming of certain parameters

On Fri, 2017-10-20 at 17:51 -0400, Eric Sunshine wrote: > On Mon, Sep 25, 2017 at 1:20 AM, Kaartic Sivaraam > <kaartic.sivar...@gmail.com> wrote: > > Documentation for a certain function was incomplete as it didn't say > > what certain parameters were used for. Further

Re: [RFC PATCH v2 1/5] branch: improve documentation and naming of certain parameters

On Fri, 2017-10-20 at 14:33 -0700, Stefan Beller wrote: > Up to here ( including the subject line), I have no idea you're talking about > 'create_branch'. Maybe > That's because I didn't want to be explicit. > branch: improve documentation and naming of parameters for create_branch > >

Re: [RFC PATCH v2 0/5] Give more useful error messages when renaming a branch

What happened to the v2 of the patch? Has this not received attention or is there anything that's not done correctly? -- Kaartic

Re: git send-email does not work with Google anymore?!

On Thu, 2017-10-05 at 12:52 +0200, Lars Schneider wrote: > Apparently that stopped working today. I get this error: > > (mbox) Adding cc: Lars Schneider from line > 'From: Lars Schneider ' > Password for

Re: is there a truly compelling rationale for .git/info/exclude?

On Fri, 2017-10-06 at 06:14 -0400, rpj...@crashcourse.ca wrote: >and in this funny grey area in between, we have .git/info/exclude, > to be used for ... what, exactly? the one argument i've come up with > is the situation where you discover that a repo you've cloned has an > incomplete set of

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

On Thu, 2017-10-05 at 10:13 +0900, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > > Moreover, as a consequence of my assumption that the tests don't check > > for the error messages themselves; I haven't even thought of checki

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

On Tue, 2017-10-03 at 09:32 +0900, Junio C Hamano wrote: > > As an aside, I wonder if we want to _() the message. It's outside > the scope of this fix, obviously. > I'm surprised it isn't already! I think it should. As an aside, I wanted to know whether we should add 'test_expect_failure's

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

On Wed, 2017-10-04 at 13:11 +0900, Junio C Hamano wrote: > > It is a bit dissapointing that we do not need to touch tests, as it > indicates that the logic to diagnose extra arguments as an error has > no coverage. Even if there were tests I don't think they would have needed any updation as

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

On Tue, 2017-10-03 at 09:21 +0900, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > I do not even recall what the patches did and if I thought what they > wanted to do made sense, I thought you did or may be I misinterpreted the f

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

From: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> 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. $ git ls-files README.md test-file Correc

Re: [PATCH v2/RFC] commit: change the meaning of an empty commit message

On Thu, 2017-08-31 at 19:06 +0530, Kaartic Sivaraam wrote: > On Thu, 2017-08-24 at 13:19 -0700, Junio C Hamano wrote: > > > > The latter is easier for me as we do not have to worry about > > breaking people's scripts and tools used in > > their e

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

On Mon, 2017-08-21 at 19:06 +0530, Kaartic Sivaraam wrote: > The error messages shown when the branch command is misused > by supplying it wrong number of parameters wasn't meaningful. > That's because it used the the phrase "too many branches" > assuming all parameters to b

Re: [PATCH] git: add --no-optional-locks option

On Wed, 2017-09-27 at 02:40 -0400, Jeff King wrote: > On Sun, Sep 24, 2017 at 01:08:41PM +0530, Kaartic Sivaraam wrote: > > > > > So, if I get that correctly "git status --no-optional-locks" is a way to get > > the "current" status without updating the

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

-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> --- Changes in v3: - Used the commit message as suggested by Junio Documentation/git-branch.txt | 4 ++-- Documentation/git-tag.txt| 2 +- 2 files changed, 3 inse

[RFC PATCH v2 4/5] branch: introduce dont_fail parameter for create validation

-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- branch.c | 32 ++-- branch.h | 23 +-- builtin/branch.c | 2 +- builtin/checkout.c | 2 +- 4 files changed, 45 insertions(+), 14 deletions(-) diff --git a/bran

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

, and branch 'master' already exists Note: Thanks to the strbuf API that made it possible to easily construct the composite error message strings! Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- builtin/branch.c | 41 +++-- 1 file chang

[RFC PATCH v2 3/5] branch: cleanup branch name validation

ith the 'force' switch. So, it's no more possible to do, $ git branch -m master master (which doesn't seem that useful). This strongly enforces the following statement of the 'git branch' documentation, "If exists, -M must be used to force the rename to happen."

[RFC PATCH v2 0/5] Give more useful error messages when renaming a branch

interaction sent for v1 still holds. This series applies on top of 'master' and can be found in my fork[1]. In case you were wondering, the Travis-CI tests did pass. [1]: https://github.com/sivaraam/git/tree/work/branch-move-revamp [2]: https://travis-ci.org/sivaraam/git/builds/279199977 Kaartic Sivaraam

[RFC PATCH v2 1/5] branch: improve documentation and naming of certain parameters

more communicative. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- branch.c | 4 ++-- branch.h | 7 ++- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/branch.c b/branch.c index 703ded69c..8d4360aa5 100644 --- a/branch.c +++ b/branch.c @@ -229,7 +229,7

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

to keep the related arguments close to each other. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- branch.c | 2 +- branch.h | 4 ++-- builtin/branch.c | 2 +- builtin/checkout.c | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/bran

Re: [PATCH] git: add --no-optional-locks option

On Thursday 21 September 2017 10:02 AM, Jeff King wrote: > Some tools like IDEs or fancy editors may periodically run > commands like "git status" in the background to keep track > of the state of the repository. I might be missing something, shouldn't the IDEs be encouraged to use libgit2

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

On Sun, 2017-09-24 at 09:28 +0900, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > > A few configuration variable names of Git are composite words. References > > to such variables in manpages are hard to read because they use >

Re: [RFC PATCH 3/5] branch: cleanup branch name validation

On Thursday 21 September 2017 07:07 AM, Junio C Hamano wrote: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: Thanks for giving a better alternative. Sounds catchy. How about `validate_branch_creation`? I do not know what you meant by "catchy",

Re: [RFC PATCH 1/5] builtin/checkout: avoid usage of '!!'

On Thursday 21 September 2017 07:01 AM, Junio C Hamano wrote: What does "with arithmetic constructs" mean? Would it refer to things like !!i != !!(j + 3) that unnecessarily obfuscates what is going on? Thanks that clears the confusion because I haven't seen constructs like this

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

On Thursday 21 September 2017 02:27 AM, Stefan Beller wrote: It's conventional to report that 'tset' doesn't exist rather than reporting that 'master' exists, the same way the 'mv' command does. $ git branch -m tset master This is not the 'mv' command as promised? So this is just to

Re: Behaviour of 'git stash show' when a stash has untracked files

On Wed, 2017-09-20 at 23:31 -0400, Jeff King wrote: > But I have always been bothered how the saved state > is a bit hidden from the user. It seems like a recipe for user confusion > when they save something with "git stash" but then "stash show" doesn't > even mention it. > Yeah, I feel the

Re: Behaviour of 'git stash show' when a stash has untracked files

On Wed, 2017-09-20 at 15:36 -0400, Jeff King wrote: > > Or sometimes people are just really behind in reading the mailing list. ;) > > This seemed familiar, and indeed there was some discussion a few months > ago: > > >

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

-insensitively so this does not affect functionality. This also ensures consistency with other parts of the docs that use camelCase fo refer to configuration variable names. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [RFC PATCH 3/5] branch: cleanup branch name validation

On Wednesday 20 September 2017 09:50 AM, Junio C Hamano wrote: Also I'd avoid "could", which can be taken as an optimization hint (i.e. "you usually do not have to worry about this thing to already exist, but I am telling you that for this one call that is not the case and you need to be a bit

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

-insensitively so this does not affect functionality. This also ensures consistency with other parts of the docs that use camelCase fo refer to configuration variable names. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> Reviewed-by: Jonathan Nieder <jrnie...@

Re: [RFC PATCH 3/5] branch: cleanup branch name validation

On Wednesday 20 September 2017 09:50 AM, Junio C Hamano wrote: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: -int validate_new_branchname(const char *name, struct strbuf *ref, - int force, int attr_only) +int validate_branch_update(const char *name,

Re: [RFC PATCH 1/5] builtin/checkout: avoid usage of '!!'

Wait, I missed a contradiction here. On Wednesday 20 September 2017 09:30 AM, Junio C Hamano wrote:   And !!ptr is a shorter and more established way than ptr != NULL to turn non-NULL ness into an int boolean, Documentation/SubmittingPatches says:  - Some clever tricks, like using the

Re: [RFC PATCH 2/5] branch: document the usage of certain parameters

On Wednesday 20 September 2017 09:42 AM, Junio C Hamano wrote: @@ -15,6 +15,11 @@ * * - reflog creates a reflog for the branch * + * - if 'force' is true, clobber_head indicates whether the branch could be + * the current branch; else it has no effect Everybody else in this

Re: [RFC PATCH 1/5] builtin/checkout: avoid usage of '!!'

On Wednesday 20 September 2017 09:30 AM, Junio C Hamano wrote: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: There was a usage for which there's no compelling reason.So, replace such a usage as with something else that expresses the intent more clearly. I actually

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

On Wednesday 20 September 2017 01:52 AM, Jonathan Nieder wrote: nit: Git's commit messages describe the current behavior of Git in the present tense. Something like: Thanks for the clarification. I was once searching Documentation/SubmittingPatches to see if there is any guideline about the

Re: [PATCH v2] for_each_string_list_item: avoid undefined behavior for empty list

On Wednesday 20 September 2017 10:57 AM, Jonathan Nieder wrote: Guard the loop with a NULL check to make the intent crystal clear to even the most pedantic compiler. A suitably clever compiler could let the NULL check only run in the first iteration, Noted this just now. So, the overhead

Re: [PATCH] for_each_string_list_item(): behave correctly for empty list

Hi, Though this thread seems to have reached a conclusion, I just wanted to know what I was missing about the optimisation. On Wednesday 20 September 2017 08:00 AM, Jonathan Nieder wrote: From that link: for ( ;valid_int && *valid_int < 10; (*valid_int)++) { printf("Valid

Re: [PATCH] for_each_string_list_item(): behave correctly for empty list

On Saturday 16 September 2017 09:36 AM, Michael Haggerty wrote: Does the following alternate fix work? I think I prefer it because it doesn't require introducing a new global. [...] #define for_each_string_list_item(item,list) \ - for (item = (list)->items; item < (list)->items +

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

The 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] t4014: strengthen search patterns

-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- t/t4014-format-patch.sh | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh index 482112ca339f0..7dff7996c9e1f 100755 --- a/t/t4014-format-patch.sh +++ b/t/t4014-

Re: [RFC SAMPLE] builtin/branch: give more useful error messages when renaming

Sorry, the email client seems to have crapped up the formatting. In case it looks difficult to follow, let me know so that I could send a better version. --- Kaartic

Re: [PATCH] doc: update information about windows build

On Monday 18 September 2017 12:32 AM, Phillip Wood wrote: May be the Windows build exit with failure on other repos rather than saying it passes? I'm not quite sure what you're asking. If the tests aren't run it needs to look like a pass or everyone's branches would be marked as failing on

[RFC SAMPLE] builtin/branch: give more useful error messages when renaming

The patch series results in a change in output as specified below. Only few cases have been shown here to keep it short. The output for other cases are similar. $ git branch * master foo bar Before patch, $ # Trying to rename non-existent branch $ git branch -m hypothet no_such_branch

[RFC PATCH 4/5] branch: introduce dont_fail parameter for update validation

-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- branch.c | 34 +++--- branch.h | 23 +-- builtin/branch.c | 2 +- builtin/checkout.c | 2 +- 4 files changed, 46 insertions(+), 15 deletions(-) diff --git a/bran

[RFC PATCH 2/5] branch: document the usage of certain parameters

Documentation for a certain function was incomplete as it didn't say what certain parameters were used for. So, document them for the sake of completeness and easy reference. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- branch.h | 5 + 1 file changed, 5 inse

[RFC PATCH 0/5] branch: improve error messages of branch renaming

did succeed but I don't think we can rely on that a lot because the test aren't exhaustive (I guess). https://travis-ci.org/sivaraam/git/builds/277146416 [2]: https://github.com/sivaraam/git/tree/work/branch-move-revamp Kaartic Sivaraam (5): builtin/checkout: avoid usage of '!!' for expressions

[RFC PATCH 3/5] branch: cleanup branch name validation

s no more possible to do, $ git branch -m master master (which doesn't seem that useful). This strongly enforces the following statement of the 'git branch' documentation, "If exists, -M must be used to force the rename to happen." Signed-off-by: Kaartic Sivar

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

: Thanks to the strbuf API that made it possible to easily construct the composite error message strings! Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- builtin/branch.c | 48 ++-- 1 file changed, 42 insertions(+), 6 deletions(-)

[RFC PATCH 1/5] builtin/checkout: avoid usage of '!!'

o, replace such a usage as with something else that expresses the intent more clearly. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- I think the expression, !!opts.new_branch_force is equivalent to, opts.new_branch_force != NULL in all cases. If it's

Re: [PATCH] t2018: remove unwanted empty line

On Monday 18 September 2017 12:52 AM, Kevin Daudt wrote: Why is this empty line unwanted? This kind of whitespace can help separate logical sections, just like paragraphs would. You're right. I seem to have sent a fix precariously because I haven't such separation before (forgetting the fact

Re: [PATCH] doc: update information about windows build

On Sun, 2017-09-17 at 14:24 +0100, Phillip Wood wrote: > > From that commit: > diff --git a/ci/run-windows-build.sh b/ci/run-windows-build.sh > new file mode 100755 > index 0..4e3a50b60 > --- /dev/null > +++ b/ci/run-windows-build.sh > @@ -0,0 +1,74 @@ > +#!/usr/bin/env bash > +# > +#

[PATCH] t2018: remove unwanted empty line

Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- t/t2018-checkout-branch.sh | 1 - 1 file changed, 1 deletion(-) diff --git a/t/t2018-checkout-branch.sh b/t/t2018-checkout-branch.sh index 2131fb2a5682c..e0a52334a22dd 100755 --- a/t/t2018-checkout-branch.sh +++ b/t

[PATCH] t/README: fix typo and grammatically improve a sentence

Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- t/README | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/README b/t/README index 2f95860369751..4b079e4494d93 100644 --- a/t/README +++ b/t/README @@ -265,12 +265,12 @@ or: $ sh ./t92

[PATCH] doc: update information about windows build

029aeeed5 (travis-ci: build and test Git on Windows, 2017-03-24) added support for testing the git build for Windows. So, update the documentation and the example used in it. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Documentation/SubmittingPatches | 5 +++--

Behaviour of 'git stash show' when a stash has untracked files

Some time ago, I stashed a few changes along with untracked files. I almost forgot it until recently. Then I wanted to see what I change I had in the stash. So I did a 'git stash show '. It worked fine but didn't say anything about the untracked files in that stash. That made me wonder where the

Behaviour of 'git stash show' when a stash has untracked files

Some time ago, I stashed a few changes along with untracked files. I almost forgot it until recently. Then I wanted to see what I change I had in the stash. So I did a 'git stash show '. It worked fine but didn't say anything about the untracked files in that stash. That made me wonder where the

Re: Are the 'How to' documents present as man pages?

On Sat, 2017-09-16 at 10:54 +0200, Simon Ruderich wrote: > On Sat, Sep 16, 2017 at 10:30:43AM +0530, Kaartic Sivaraam wrote: > > I was reading the 'git revert' documentation and found the following > > line in it, > > > > -m parent-number >

Re: [PATCHv3] builtin/merge: honor commit-msg hook for merges

Seems 'Documentation/githooks.txt' needs an update related to this change. Previously it said(note the **s) that 'commit-msg' is invoked only by 'git commit', commit-msg This hook is invoked by git commit**, and can be bypassed with the --no-verify option. It takes a

Are the 'How to' documents present as man pages?

I was reading the 'git revert' documentation and found the following line in it, -m parent-number --mainline parent-number ... See the revert-a-faulty-merge How-To[1] for more details. It says that the 'How-To' is present in the first section of the man page. I tried

Re: [PATCH v3] commit-template: change a message to be more intuitive

On Fri, 2017-09-15 at 12:00 +0200, Michael J Gruber wrote: > Kaartic Sivaraam venit, vidit, dixit 15.09.2017 06:50: > > > > I didn't expect the least that this would go upto v3. In case anyboy finds That's should have been 'anybody'. > > something wrong with this change t

[PATCH v3] commit-template: change a message to be more intuitive

, so change the terms in that too. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Changes in v3: - changed the wordings of the second sentence as there seemed to be a magical 'or else' connecting the two lines. I didn't expect the least that this would go u

Re: [PATCH v2] commit-template: change a message to be more intuitive

On Thu, 2017-09-14 at 09:36 +0200, Michael J Gruber wrote: > > Also, given all the translations that we have, it seems somewhat strange > to try and foresee and workaround possible misunderstandings of commonly > used English phrases. In case you're trying to say that "Translators have

Re: commit-msg hook does not run on merge with --no-ff option

On Tue, 2017-09-12 at 13:24 -0500, Joseph Dunne wrote: > Sorry I don't understand your question. The commit-msg hook runs > properly in all cases except when I perform a merge with the --no-ff > option enabled. > It's working just as the documentation says it does (emphasis mine), This

Re: [PATCH v2] commit-template: change a message to be more intuitive

On Thursday 14 September 2017 01:06 PM, Michael J Gruber wrote: Kaartic Sivaraam venit, vidit, dixit 13.09.2017 15:05: void wt_status_add_cut_line(FILE *fp) { - const char *explanation = _("Do not touch the line above.\nEverything below will be removed."); +

[PATCH v2] commit-template: change a message to be more intuitive

difficult as it might not have the intended meaning in a few languages when translated as such. So, use more intuitive terms in the sentence. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- wt-status.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --gi

[PATCH v2] commit-template: change a message to be more intuitive

Changes in v2: - Changed the message as suggested by Jeff - Made the commit message to be even more clear --- Kaartic

Re: [PATCH] commit-template: change a message to be more intuitive

On Wednesday 13 September 2017 04:50 PM, Jeff King wrote: I agree with both of your points. It is very clear to me as a native speaker, but I can see how it might not be for everyone. Interestingly, the change here: - const char *explanation = _("Do not touch the line above.\nEverything

Re: [PATCH] commit-template: change a message to be more intuitive

On Wednesday 13 September 2017 03:59 PM, Kevin Daudt wrote: Touching something can also mean to disturb or change something, which is the meaning being used here, so it is not an incorrect use of the word. I do get your point but I should have been clearer in my commit message about the fact

Re: Buffered value should be shown when requesting username for remote authentication

On Tuesday 12 September 2017 09:03 PM, Jeff King wrote: If I understand right, you typed "sivaraam" once, then the network lagged, then you typed "sivaraam" again. Almost there but I should have been more clearer. What I actually did was I run `git push` and knowing it would ask for a username

Re: [PATCH 10/10] add UNLEAK annotation for reducing leak false positives

On Tuesday 12 September 2017 08:35 PM, Jeff King wrote: But theta-well isn't a pun. :P :) It is true that prepending to a linked list is also Θ(1), but I'm not sure if it's carelessness that causes many programmers to use big-O. It's that what we care about is worst-case performance. So

Re: [PATCH 10/10] add UNLEAK annotation for reducing leak false positives

On Tuesday 12 September 2017 08:59 PM, Jeff King wrote: Like all good writing rules, I think it's important to know when to break them. :) That's right. "Have guidelines but 'Be bold' enough to break them when they seem to be inducing counter productivity." Writing in the imperative is

Re: [PATCH 10/10] add UNLEAK annotation for reducing leak false positives

> On Tue, 2017-09-05 at 15:05 -0700, Stefan Beller wrote: > > After having a sneak peak at the implementation > it is O(1) in runtime for each added element, and the > space complexity is O(well). > Incidentally I was reading about "complexity of algorithms" and there was the following

Re: [PATCH 10/10] add UNLEAK annotation for reducing leak false positives

On Tue, 2017-09-05 at 09:05 -0400, Jeff King wrote: > This patch introduces an UNLEAK() macro that lets us do so. > To understand its design, let's first look at some of the > alternatives. > > This patch adds the UNLEAK() macro and enables it > automatically when Git is compiled with

Buffered value should be shown when requesting username for remote authentication

Hello all, I noted a little issue with the interaction to a remote git repository. The issue occurs when the network used for remote communication is a bit sluggish. The main issue is illustrated by the following shell interaction, $ git push -u fork sivaraamUsername for '

[PATCH] help: change a message to be more precise

in which the user has used an alias like 'tgit'. $ tgit co --help `git co' is aliased to `checkout' So, make the message more precise. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- builtin/help.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH] commit-template: change a message to be more intuitive

It's not possible to 'touch' the cut-line that is shown when the user requests a patch in his commit template. So, make the sentence more intuitive. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Just a small tweak. May or may not be worth the patch. wt-status

[PATCH/RFC] branch: strictly don't allow a branch with name 'HEAD'

$ git checkout -b HEAD Avoid such loop holes by 'strictly' checking for a branch with name HEAD. The check is referred to as strict because it's done in a place which is supposed to be called to ensure that a new branch name is a valid one. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91

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

On Tue, 2017-09-12 at 15:49 +0900, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: > > > Thanks. Now I get it. What about doing that check in > > branch.c::create_branch or branch.c::validate_new_branchname? I guess > > crea

Re: [PATCH v2/RFC] commit: change the meaning of an empty commit message

On Thu, 2017-08-24 at 13:19 -0700, Junio C Hamano wrote: > > The latter is easier for me as we do not have to worry about > breaking people's scripts and tools used in > their established workflows at all. > In that case, how about doing something similar to what was done to 'set-upstream'

[PATCH v2/RFC] commit: change the meaning of an empty commit message

will be ignored, and an empty message aborts the commit. # ... END : COMMIT MESSAGE With the default cleanup, the above message would produce a commit with the 'Signed-off-by:' line as it's subject. Eg, [master 4a34e74] Signed-off-by: Random J Developer

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

Sorry, wrong thread :( Please ignore this. --- Kaartic

[PATCH v2] 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 v2] 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

What does 'git blame --before -- ' supposed to mean?

Hello all, I tried to do a 'git blame' on a file and wanted to see the blame before a particular revision of that file. I initially didn't know that you could achieve that with, $ git blame I thought I need to pass the revision as a parameter so I tried (before looking into the

Re: Please fix the useless email prompts

On Sun, 2017-08-20 at 05:18 -0400, Jeff King wrote: > Ironically, Git used to behave as you requested in 2005. After being > bombarded with complaints about how Git was too lax in creating commits > with bogus ident information, we changed it in 2012. So I don't think > "it's 2017" carries any

Re: Git *accepts* a branch name, it can't identity in the future?

Thanks, but Johannes has already found the issue and given a solution. Regardless, replying to the questions just for the note. On Sun, 2017-08-20 at 04:33 -0400, Jeff King wrote: > What does "git for-each-ref" say about which branches you _do_ have? > > Also, what platform are you on? > I use

Re: Git *accepts* a branch name, it can't identity in the future?

On Sun, 2017-08-20 at 10:20 +0200, Johannes Sixt wrote: > It is not Git's fault that your terminal converts an invalid UTF-8 > sequence (that your script produces) to �. Nor is it when you paste that > character onto the command line, that it is passed as a (correct) UTF-8 > character. >

Git *accepts* a branch name, it can't identity in the future?

Hello all, First of all, I would like to tell that this happened completely by accident and it's partly my mistake. Here's what happened. I recently started creating 'feature branches' a lot for the few patches that I sent to this mailing list. To identify the status of the patch corresponding

Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option

On Friday 18 August 2017 01:25 AM, Junio C Hamano wrote: Martin Ågren <martin.ag...@gmail.com> writes: On 17 August 2017 at 04:54, Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> wrote: Helped-by: Martin Ågren <martin.ag...@gmail.com>, Junio C Hamano <gits...@

Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option

On Friday 18 August 2017 01:28 AM, Junio C Hamano wrote: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index 81bd0a7b7..948d9c9ef 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-bran

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

On Thursday 17 August 2017 12:58 AM, Junio C Hamano wrote: Nothing has. Neither thread seems to have any comment from anybody but you, and I took it as an indication that people do not think it is a good change. I do not find the s/branch/parameter/ too bad (although I would have said

[PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option

aster Helped-by: Martin Ågren <martin.ag...@gmail.com>, Junio C Hamano <gits...@pobox.com> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Changes in v4: - made a few changes suggested by Martin - hid the '--set-upstream' option from 'git branch

<    1   2   3   4   5   >