Re: [PATCH] send-email: new option to walkaround email server limits

2017-05-03 Thread Ramkumar Ramachandra
For the list, in plain text: IIUC, they use the date received to sort. I think this might stem from a historical cruft: emails sometimes took non-trivial amounts of time to transit, back in the old days. MUAs (especially web-based ones) probably did not want to violate user expectation by placing

Re: [PATCHv4] Documentation: triangular workflow

2016-06-11 Thread Ramkumar Ramachandra
Junio C Hamano wrote: > Jordan DE GEA wrote: > > > +* Allows contributors to work with Git even though they do not have > > +write access to **UPSTREAM**. > > > > +* Allows maintainers to receive code from contributors they may not > > +trust. Triangular workflow is the ability to accept changes

Re: [PATCH] completion: suggest sequencer commands for revert

2015-05-29 Thread Ramkumar Ramachandra
Junio C Hamano wrote: contrib/completion/git-completion.bash | 5 + 1 file changed, 5 insertions(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index bfc74e9..3c00acd 100644 --- a/contrib/completion/git-completion.bash +++

Re: [PULL] git-svn updates from Ramkumar

2015-01-21 Thread Ramkumar Ramachandra
Eric Wong wrote: Adding it to GITPERLLIB should work... I tried everything including replicating the commands in the brew formula that does the Right thing: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/git.rb I'm clearly missing something. Can someone on Darwin tell us the

Re: [PATCH] .clang-format: introduce the use of clang-format

2015-01-21 Thread Ramkumar Ramachandra
René Scharfe wrote: However, even then struct declarations that are combined with variable declaration and initialization get mangled: I'm pretty sure this is a bug in clang-format. It might be semi-trivial to fix too. Thanks for your inputs. -- To unsubscribe from this list: send the line

[PATCH v2] .clang-format: introduce the use of clang-format

2015-01-21 Thread Ramkumar Ramachandra
Scharfe l@web.de Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- .clang-format | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 .clang-format diff --git a/.clang-format b/.clang-format new file mode 100644 index 000..a336438 --- /dev/null +++ b/.clang-format

Re: [PATCH v2] contacts: introduce --since and --min-percent

2015-01-21 Thread Ramkumar Ramachandra
Ramkumar Ramachandra wrote: Signed-off-by: Ramkumar Ramachandra artag...@gmail.com Junio: this isn't in the latest rebuild of pu; I wonder if you've forgotten to pick it up. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More

Re: [PATCH v2] .clang-format: introduce the use of clang-format

2015-01-21 Thread Ramkumar Ramachandra
Jeff King wrote: On Wed, Jan 21, 2015 at 12:01:27PM -0500, Ramkumar Ramachandra wrote: +BreakBeforeBraces: Linux [...] +BreakBeforeBraces: Stroustrup Oh, oops. - It really wants to break function declarations that go over the column limit, even though we often do not do so. I think

[PATCH] .clang-format: introduce the use of clang-format

2015-01-17 Thread Ramkumar Ramachandra
Instead of manually eyeballing style in reviews, just ask all contributors to run their patches through [git-]clang-format. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- The idea is to introduce the community to this new toy I found called clang-format. Whether or not it's actually

[PATCH] contacts: introduce --since and --min-percent

2015-01-16 Thread Ramkumar Ramachandra
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/contacts/git-contacts | 4 1 file changed, 4 insertions(+) diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts index dbe2abf..b06f2e1 100755 --- a/contrib/contacts/git-contacts +++ b/contrib/contacts

[PATCH v2] contacts: introduce --since and --min-percent

2015-01-16 Thread Ramkumar Ramachandra
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/contacts/git-contacts | 4 contrib/contacts/git-contacts.txt | 16 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts index

Re: [PULL] git-svn updates from Ramkumar

2015-01-15 Thread Ramkumar Ramachandra
Junio C Hamano wrote: To which a natural reaction was Can the existing breakage demonstrated by a test?. There's a lot to do, if we really want to dig deeper. The second git-svn-basic test onwards doesn't pass for me, so I really can't do much in the way of contributing tests until that's

Re: [PULL] git-svn updates from Ramkumar

2015-01-15 Thread Ramkumar Ramachandra
Eric Wong wrote: I haven't seen this before. Which SVN Perl binding version are you using? Perhaps your svnadmin tool is from a different SVN version or installation of SVN than your Perl bindings? I have two installations of Subversion: the system one is at

Re: [PATCH] git-svn: show progress in working_head_info()

2015-01-14 Thread Ramkumar Ramachandra
Eric, I'm sorry, but this change isn't important enough for me to follow up. Please merge the other two patches, if you think they're good. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at

[PATCH] git-svn: make it play nicely with submodules

2015-01-10 Thread Ramkumar Ramachandra
It's a simple matter of opening the directory specified in the gitfile. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- git-svn.perl | 4 1 file changed, 4 insertions(+) diff --git a/git-svn.perl b/git-svn.perl index 6aa156c..8642783 100755 --- a/git-svn.perl +++ b/git-svn.perl

Re: [PATCH] Git::SVN: handle missing ref_id case correctly

2015-01-10 Thread Ramkumar Ramachandra
Ramkumar Ramachandra wrote: -our $default_ref_id = $ENV{GIT_SVN_ID} || 'git-svn'; +our $default_ref_id = defined $ENV{GIT_SVN_ID} ? $ENV{GIT_SVN_ID} : 'git-svn'; This is probably not a functional change; please look at the second hunk. -- To unsubscribe from this list: send the line

[PATCH] git-svn: show progress in working_head_info()

2015-01-10 Thread Ramkumar Ramachandra
The working_head_info routine takes a very long time to execute on large repositories. The least we can do is to comfort users that some progress is being made. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- I was worried because of the long wait, so I wrote this to convince myself

[PATCH] Git::SVN: handle missing ref_id case correctly

2015-01-10 Thread Ramkumar Ramachandra
$ENV{GIT_SVN_ID} will return a string, so check it with defined. Also, ref_id should not match refs/remotes/. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- perl/Git/SVN.pm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm index

Re: [PATCH] git-svn: make it play nicely with submodules

2015-01-10 Thread Ramkumar Ramachandra
Eric Wong wrote: How portable is open on a directory? Perhaps it'd be better to check if it's a file, first: Sure, that works; feel free to fix it up locally before committing. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org

Re: [PATCH] Git::SVN: handle missing ref_id case correctly

2015-01-10 Thread Ramkumar Ramachandra
Ramkumar Ramachandra wrote: It is functional, maybe someone will use GIT_SVN_ID=0 ? Right. Kindly drop the first hunk. Amendment: there are actually many other places where variables are checked without defined, so I doubt we want to put up with the extra ugliness to allow 0. -- To unsubscribe

Re: [PATCH] Git::SVN: handle missing ref_id case correctly

2015-01-10 Thread Ramkumar Ramachandra
Eric Wong wrote: It is functional, maybe someone will use GIT_SVN_ID=0 ? Right. Kindly drop the first hunk. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/2] test-config: Add tests for the config_set API

2014-07-06 Thread Ramkumar Ramachandra
A couple of quick nits. Tanay Abhra wrote: +test_expect_success 'clear default config' ' + rm -f .git/config +' Unnecessary; a fresh temporary directory is created for each test run. +test_expect_success 'initialize default config' ' You might want to mark this as setup. -- To

[PATCH] rebase -i: handle Nothing to do case with autostash

2014-05-19 Thread Ramkumar Ramachandra
, it missed this case in git-rebase--interactive.sh. Since this case is unlike the other cases which return control for housekeeping, assign it a special return status and handle that return value explicitly in git-rebase.sh. Reported-by: Karen Etheridge et...@cpan.org Signed-off-by: Ramkumar

Re: [PATCH v7 03/12] revert/cherry-pick: add --quiet option

2014-04-24 Thread Ramkumar Ramachandra
Felipe Contreras wrote: @@ -635,9 +637,10 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts) } if (opts-skip_empty is_index_unchanged() == 1) { - warning(_(skipping %s... %s), -

Re: [PATCH v7 04/12] revert/cherry-pick: add --skip option

2014-04-24 Thread Ramkumar Ramachandra
Felipe Contreras wrote: Akin to 'am --skip' and 'rebase --skip'. I don't recall why my original sequencer series didn't include this option. Perhaps Jonathan remembers? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More

Re: [PATCH v7 06/12] builtin: add rewrite helper

2014-04-24 Thread Ramkumar Ramachandra
Felipe Contreras wrote: So that we can load and store rewrites, as well as other operations on a list of rewritten commits. Please elaborate. Explain why this code shouldn't go in sequencer.c. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to

Re: [PATCH v7 12/12] cherry-pick: copy notes and run hooks

2014-04-24 Thread Ramkumar Ramachandra
Felipe Contreras wrote: If no action-name is specified, nothing is done. Why? Is it because git-rebase implements its own notes-copy-on-rewrite logic? Otherwise, I agree with the goal of making notes.rewrite.command work for cherry-pick. -- To unsubscribe from this list: send the line

Re: [PATCH v7 12/12] cherry-pick: copy notes and run hooks

2014-04-24 Thread Ramkumar Ramachandra
Felipe Contreras wrote: diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 43631b4..fd085e1 100644 --- a/git-rebase--interactive.sh +++ b/git-rebase--interactive.sh @@ -248,7 +248,7 @@ pick_one () { test -d $rewritten

Re: [PATCH v2 9/9] sha1_name: add support for @{publish} marks

2014-04-10 Thread Ramkumar Ramachandra
Felipe Contreras wrote: @@ -1068,23 +1069,35 @@ static const char *get_upstream_branch(const char *name_buf, int len) */ if (!branch) die(_(HEAD does not point to a branch)); - if (!branch-merge || !branch-merge[0]-dst) { - if

Re: [PATCH v2 8/9] sha1_name: simplify track finding

2014-04-10 Thread Ramkumar Ramachandra
Felipe Contreras wrote: It's more efficient to check for the braces first. Why is it more efficient? So you can error out quickly in the case of a malformed string? I'm personally not thrilled about this change. -- To unsubscribe from this list: send the line unsubscribe git in the body of a

Re: [PATCH v2 7/9] sha1_name: cleanup interpret_branch_name()

2014-04-10 Thread Ramkumar Ramachandra
Felipe Contreras wrote: sha1_name.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) I like this variable rename. This instance has annoyed me in the past. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to

Re: [PATCH v2 9/9] sha1_name: add support for @{publish} marks

2014-04-10 Thread Ramkumar Ramachandra
Felipe Contreras wrote: diff --git a/sha1_name.c b/sha1_name.c index aa3f3e0..a36852d 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -415,9 +415,9 @@ static int ambiguous_path(const char *path, int len) return slash; } -static inline int upstream_mark(const char *string, int len)

Re: [PATCH v2 6/9] branch: display publish branch

2014-04-10 Thread Ramkumar Ramachandra
Felipe Contreras wrote: Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Please write a commit message, preferably showing the new git-branch output. I noticed that this only picks up a publish-branch if branch.*.pushremote is configured. What happened to the case when

[PATCH] Documentation/merge-strategies: avoid hyphenated commands

2014-03-16 Thread Ramkumar Ramachandra
Replace git-pull and git-merge with the corresponding un-hyphenated versions. While at it, use ` to mark it up instead of '. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/merge-strategies.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH pu] Documentation/giteveryday: fix some obvious problems

2014-03-16 Thread Ramkumar Ramachandra
Fix a few minor things. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Philip, I spotted a few obvious issues with your giteveryday patch in pu. Maybe Junio can squash this into your patch? Contents are still a bit stale, but I'm not sure what other markup problems

Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)

2014-03-16 Thread Ramkumar Ramachandra
Philip Oakley wrote: * po/everyday-doc (2014-01-27) 1 commit - Make 'git help everyday' work This may make the said command to emit something, but the source is not meant to be formatted into a manual pages to begin with, and also its contents are a bit stale. It may be a good first step in

Re: What's cooking in git.git (Feb 2014, #06; Wed, 19)

2014-02-21 Thread Ramkumar Ramachandra
Junio C Hamano wrote: * jk/branch-at-publish-rebased (2014-01-17) 5 commits - t1507 (rev-parse-upstream): fix typo in test title - implement @{publish} shorthand - branch_get: provide per-branch pushremote pointers - branch_get: return early on error - sha1_name: refactor upstream_mark

Re: Git GSoC 2014

2014-02-14 Thread Ramkumar Ramachandra
Jeff King wrote: 1. Speed up git-rebase--am.sh Isn't the merge backend faster? I thought that was the point of it. I suppose, but I thought git-rebase--am.sh (the default flavor) could be improved by leveraging relatively new cherry-pick features; I assumed that the reason it was using

Re: Git GSoC 2014

2014-02-13 Thread Ramkumar Ramachandra
Jeff King wrote: - ideas ideas ideas I'll throw in a few ideas from half-finished work. 1. Speed up git-rebase--am.sh Currently, git-rebase--am.sh is really slow because it dumps each patch to a file using git-format-patch, and picks it up to apply subsequently using git-am. Find a way to

[TEST EMAIL] Testing rk/send-email-ssl-cert in pu

2014-01-26 Thread Ramkumar Ramachandra
Hi, This email tests that 01645b7 (send-email: /etc/ssl/certs/ directory may not be usable as ca_path, 2014-01-15) doesn't cause a regression. Ram -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH] send-email: If the ca path is not specified, use the defaults

2014-01-26 Thread Ramkumar Ramachandra
Junio C Hamano wrote: This change could introduce a regression for people on a platform whose certificate directory is /etc/ssl/certs but its IO::Socket:SSL somehow fails to use it as SSL_ca_path without being told. I can confirm that my git-send-email doesn't regress to the pre-35035bbf

Re: [PATCH 5/5] implement @{publish} shorthand

2014-01-24 Thread Ramkumar Ramachandra
Jeff King wrote: As far as merging it to 'next', I had not really intended it to go that far. :) It was more for Ram to use as a base. Sorry about not having posted a follow-up yet; I'm adjusting to a new timezone and environment. I find some of the refactoring questionable, including:

Re: [PATCH 3/3] remote: introduce and fill branch-pushremote

2014-01-13 Thread Ramkumar Ramachandra
Jeff King wrote: 2. If the current branch has a branch.*.pushremote set, but we want to know where a _different_ branch would be pushed, we have no way to access remote.pushdefault (it gets overwritten in the hunk above). @{upstream} does not have this problem, because it is

Re: Error in documentation for @{-n} in gitrevisions

2014-01-12 Thread Ramkumar Ramachandra
Kevin wrote: Either the documentation is wrong, and should be changed to nth branch/commit checkout out before the current one, or the behavior of @{-1} is wrong. Yeah, the documentation needs to be updated. Patches welcome. -- To unsubscribe from this list: send the line unsubscribe git in

[PATCH 1/3] t1507 (rev-parse-upstream): fix typo in test title

2014-01-12 Thread Ramkumar Ramachandra
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t1507-rev-parse-upstream.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t1507-rev-parse-upstream.sh b/t/t1507-rev-parse-upstream.sh index 2a19e79..15f2e7e 100755 --- a/t/t1507-rev-parse-upstream.sh +++ b/t

[PATCH 0/3] Minor preparation for @{publish}

2014-01-12 Thread Ramkumar Ramachandra
. Thanks. Jeff King (1): interpret_branch_name: factor out upstream handling Ramkumar Ramachandra (2): t1507 (rev-parse-upstream): fix typo in test title remote: introduce and fill branch-pushremote remote.c | 15 ++-- remote.h | 3

[PATCH 2/3] interpret_branch_name: factor out upstream handling

2014-01-12 Thread Ramkumar Ramachandra
-by: Ramkumar Ramachandra artag...@gmail.com --- sha1_name.c | 83 ++--- 1 file changed, 52 insertions(+), 31 deletions(-) diff --git a/sha1_name.c b/sha1_name.c index b1873d8..7ebb8ee 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -1046,6 +1046,54

[PATCH 3/3] remote: introduce and fill branch-pushremote

2014-01-12 Thread Ramkumar Ramachandra
and remote_name; pushremote and pushremote_name. Helped-by: Jeff King p...@peff.net Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- remote.c | 15 --- remote.h | 3 +++ 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/remote.c b/remote.c index a89efab..286cdce 100644

Re: [PATCH 2/5] interpret_branch_name: factor out upstream handling

2014-01-08 Thread Ramkumar Ramachandra
Jeff King wrote: sha1_name.c | 83 ++--- 1 file changed, 52 insertions(+), 31 deletions(-) Thanks. I applied this to my series as-it-is. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to

Re: [RFC/PATCH 0/5] branch@{publish} shorthand

2014-01-08 Thread Ramkumar Ramachandra
Jeff King wrote: There's a fair bit of refactoring involved. I took a stab at it and came up with the series below. No docs or tests, and some of the refactoring in remote.c feels a little weird. I can't help but feel more of the logic from git push should be shared here. But it at least

Re: [PATCH 1/2] completion: complete format.coverLetter

2014-01-07 Thread Ramkumar Ramachandra
Ramkumar Ramachandra wrote: contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) Junio: Please push this part via 'maint' independently. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-07 Thread Ramkumar Ramachandra
John Szakmeister wrote: I guess it's not a good idea to set 'push.default' to 'upstream' in this triangle workflow then, otherwise the branch name being pushed to will be 'branch.*.merge'. Is that correct? I just want to make sure I understand what's happening here. push.default = upstream

[RFC/PATCH] format-patch: introduce branch.*.forkedFrom

2014-01-07 Thread Ramkumar Ramachandra
this new configuration variable. Cc: Jeff King p...@peff.net Cc: Junio C Hamano gis...@pobox.com Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Since -M, -C, -D are left in the argc, checking argc 2 isn't sufficient. I wanted to get an early reaction before wiring up checkout

Re: [RFC/PATCH] format-patch: introduce branch.*.forkedFrom

2014-01-07 Thread Ramkumar Ramachandra
[Fixed typo in Junio's address] On Wed, Jan 8, 2014 at 1:59 AM, Ramkumar Ramachandra artag...@gmail.com wrote: A very common workflow for preparing patches involves working off a topic branch and generating patches against 'master' to send off to the maintainer. However, a plain $ git

Re: [RFC/PATCH] format-patch: introduce branch.*.forkedFrom

2014-01-07 Thread Ramkumar Ramachandra
Junio C Hamano wrote: I do not mind allowing laziness by defaulting to something, but I am not enthused by an approach that adds the new variable whose value is questionable. The description does not justify at all why @{upstream} is not a good default (unless the workflow is screwed up and

Re: [RFC/PATCH] format-patch: introduce branch.*.forkedFrom

2014-01-07 Thread Ramkumar Ramachandra
Jeff King wrote: I have not carefully read some of the later bits of the discussion from last night / this morning, so maybe I am missing something, but this seems backwards to me from what Junio and I were discussing earlier. The point was that the meaning of @{upstream} (and branch.*.merge)

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-07 Thread Ramkumar Ramachandra
Jeff King wrote: My daily procedure is something like: all_topics | while read topic; do echo $topic $(git rev-parse $topic@{u}); done | topo_sort | while read topic upstream; do git rebase $upstream $topic || exit 1 done Ah, I was perhaps over-specializing for my own

Re: [RFC/PATCH] format-patch: introduce branch.*.forkedFrom

2014-01-07 Thread Ramkumar Ramachandra
Jeff King wrote: I definitely respect the desire to reuse the existing tooling we have for @{u}. At the same time, I think you are warping the meaning of @{u} somewhat. It is _not_ your upstream here, but rather another version of the branch that has useful changes in it. That might be

[PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
everytime. Save the user the extra keystrokes by introducing format.defaultTo which can contain the name of a branch against which to base patches. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/config.txt | 4 builtin/log.c | 7

[PATCH 1/2] completion: complete format.coverLetter

2014-01-06 Thread Ramkumar Ramachandra
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 51c2dd4..39b81f7 100644 --- a/contrib/completion/git

Re: [PATCH 0/2] Minor convinience feature: format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
Ramkumar Ramachandra wrote: Ramkumar Ramachandra (2): completion: complete format.coverLetter format-patch: introduce format.defaultTo Any thoughts on checkout.defaultTo? I have a com alias to checkout 'master'. -- To unsubscribe from this list: send the line unsubscribe git in the body

[BUG] rebase --onto doesn't abort properly

2014-01-06 Thread Ramkumar Ramachandra
Hi, On the latest git, I noticed that a rebase --onto doesn't abort properly. Steps to reproduce: # on some topic branch $ git rebase --onto master @~10 ^C # quickly! $ git rebase --abort # HEAD is still detached I tried going back a few revisions, and the bug seems to be very old;

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
Junio C Hamano wrote: - why is a single branch name sufficient? It does accept a revision, so any form is allowed; but why would anyone want that in a format.defaultTo? I'm not sure we want to impose an artificial restriction on the configuration variable though. - is it a better option to

Re: [BUG] rebase --onto doesn't abort properly

2014-01-06 Thread Ramkumar Ramachandra
Junio C Hamano wrote: I do not think --abort was designed to abort an uncontrolled stop like ^C in the first place. Why not? All it requires is a reset --hard to .git/rebase-apply/head-name, as usual, no? To allow that kind of recovery, you need to teach rebase to first record the state you

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
Jonathan Nieder wrote: 1. Most config settings are in noun form: e.g., [remote] pushDefault = foo. That makes their names easy to guess and makes them easy to talk about: I set the default remote for pushing by changing the remote.pushdefault setting. '[url foo] insteadOf'

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
Junio C Hamano wrote: I meant a single branch as opposed to depending on what branch you are sending out, you may have to use a different upstream starting point, and a single format.defaultTo that does not read what your HEAD currently points at may not be enough. Unless you set @{u} to

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
Jeff King wrote: Yeah, I had similar thoughts. I personally use branch.*.merge as forkedFrom, and it seems like we are going that way anyway with things like git rebase and git merge defaulting to upstream. My issue with that is that I no idea where my branch is with respect to my forked

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
Junio C Hamano wrote:. As I said in the different subthread, I am not convinced that you would need the complexity of branch.*.forkedFrom. If you set your upstream to the true upstream (not your publishing point), and have remote.pushdefaultset to 'publish', you can expect git push

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
John Szakmeister wrote: Then where does it get pushed? Do you always specify where to save your work? FWIW, I think the idea of treating @{u} as the eventual recipient of your changes is good, but then it seems like Git is lacking the publish my changes to this other branch concept. Am I

Re: [PATCH v3 2/4] completion: introduce __gitcomp_nl_append ()

2014-01-05 Thread Ramkumar Ramachandra
Junio C Hamano wrote: Is it because going this route and doing it at such a low level would make zsh completion (which I have no clue about ;-) unnecessarily complex? The zsh completion only cares to override __gitcomp_nl () and __gitcomp_nl_append (), without bothering to re-implement the

[PATCH v4 1/4] zsh completion: find matching custom bash completion

2014-01-05 Thread Ramkumar Ramachandra
directory than in those system default places. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/completion/git-completion.zsh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh index

[PATCH v2 1/4] completion: prioritize ./git-completion.bash

2014-01-03 Thread Ramkumar Ramachandra
To ease development, prioritize ./git-completion.bash over other standard system paths. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/completion/git-completion.zsh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.zsh b

[PATCH v2 2/4] completion: introduce __gitcomp_2 ()

2014-01-03 Thread Ramkumar Ramachandra
of this kind, create a variation of __gitcomp_nl () that accepts two sets of arguments and two independent suffixes. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/completion/git-completion.bash | 30 ++ contrib/completion/git-completion.zsh | 10

[PATCH v2 0/4] Fix branch.autosetup(merge|rebase) completion

2014-01-03 Thread Ramkumar Ramachandra
Hi, In this iteration, I've removed hunks to prevent completing: $ git config remote.pushdefault.TAB $ git config branch.autosetupmerge.TAB $ git config branch.autosetuprebase.TAB Since they're perfectly valid remote/ branch names. Thanks. Ramkumar Ramachandra (4): completion

Re: [PATCH 3/4] completion: fix branch.autosetup(merge|rebase)

2014-01-03 Thread Ramkumar Ramachandra
Junio C Hamano wrote: You seem to be calling it incorrect to give the same degree of completion for a branch the user named autosetupmerge as another branch topic, but I think it is incorrect not to, so I cannot tell if we are agreeing or disagreeing. No, what's incorrect is providing

[PATCH v3 0/4] Fix branch.autosetup(merge|rebase) completion

2014-01-03 Thread Ramkumar Ramachandra
Hi Junio et al, In v3, I've implemented __gitcomp_nl_append (), like you suggested. After implementing it, I feel foolish about having gone around my head to do __gitcomp_2 (). Thanks. Ramkumar Ramachandra (4): completion: prioritize ./git-completion.bash completion: introduce

[PATCH v3 1/4] completion: prioritize ./git-completion.bash

2014-01-03 Thread Ramkumar Ramachandra
To ease development, prioritize ./git-completion.bash over other standard system paths. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/completion/git-completion.zsh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.zsh b

[PATCH v3 2/4] completion: introduce __gitcomp_nl_append ()

2014-01-03 Thread Ramkumar Ramachandra
completions of this kind, create a variation of __gitcomp_nl () that appends to the existing list of completion candidates, COMPREPLY. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/completion/git-completion.bash | 13 + contrib/completion/git-completion.zsh | 8

[PATCH v3 4/4] completion: fix remote.pushdefault

2014-01-03 Thread Ramkumar Ramachandra
When attempting to complete $ git config remote.pushTAB 'pushdefault' doesn't come up. This is because $cur is matched with remote.* and a list of remotes are completed. Add 'pushdefault' to the list of remotes using __gitcomp_nl_append (). Signed-off-by: Ramkumar Ramachandra artag

[PATCH v3 3/4] completion: fix branch.autosetup(merge|rebase)

2014-01-03 Thread Ramkumar Ramachandra
(). Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index bf358d6..75c7302 100644 --- a/contrib/completion/git

Re: [PATCH 3/4] completion: fix branch.autosetup(merge|rebase)

2014-01-02 Thread Ramkumar Ramachandra
Junio C Hamano wrote: If we are looking at branch.autosetupmerge. followed by something, who typed that final dot? I admit that it's a very unlikely case. The user did: $ branch.autosetupmerTAB hit backspace to delete the trailing space, inserted a dot, and hit TAB again. If you are

Re: [PATCH 2/4] completion: introduce __gitcomp_2 ()

2014-01-02 Thread Ramkumar Ramachandra
Junio C Hamano wrote: __gitcomp_nl $(__git_heads) $pfx $cur_ . __gitcomp_nl_append $autosetupmerge\nautosetuprebase\n $pfx $cur_ This is not a bad idea at all. I'm just afraid that we might be leaving open ends: What happens if the $pfx isn't the same in both cases? Who

[PATCH 1/4] completion: prioritize ./git-completion.bash

2013-12-30 Thread Ramkumar Ramachandra
To ease development, prioritize ./git-completion.bash over other standard system paths. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/completion/git-completion.zsh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.zsh b

[PATCH 0/4] Fix branch.autosetup(merge|rebase) completion

2013-12-30 Thread Ramkumar Ramachandra
with the solution. I hope it's an enjoyable read. Ramkumar Ramachandra (4): completion: prioritize ./git-completion.bash completion: introduce __gitcomp_2 () completion: fix branch.autosetup(merge|rebase) completion: fix remote.pushdefault contrib/completion/git-completion.bash | 43

[PATCH 2/4] completion: introduce __gitcomp_2 ()

2013-12-30 Thread Ramkumar Ramachandra
of this kind, create a variation of __gitcomp_nl () that accepts two sets of arguments and two independent suffixes. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/completion/git-completion.bash | 30 ++ contrib/completion/git-completion.zsh | 10

[PATCH 3/4] completion: fix branch.autosetup(merge|rebase)

2013-12-30 Thread Ramkumar Ramachandra
to not complete $ git config branch.autosetupmerge.TAB $ git config branch.autosetuprebase.TAB with the usual branch.name. candidates. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/completion/git-completion.bash | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff

[PATCH 4/4] completion: fix remote.pushdefault

2013-12-30 Thread Ramkumar Ramachandra
remote.pushdefault.TAB with the usual remote.name. candidates. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/completion/git-completion.bash | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git

[PATCH] for-each-ref: remove unused variable

2013-12-30 Thread Ramkumar Ramachandra
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- builtin/for-each-ref.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c index 6551e7b..51798b4 100644 --- a/builtin/for-each-ref.c +++ b/builtin/for-each-ref.c @@ -92,7

Re: [PATCH 3/3] send-email: set SSL options through IO::Socket::SSL::set_client_defaults

2013-12-02 Thread Ramkumar Ramachandra
Thomas Rast wrote: When --smtp-encryption=ssl, we use a Net::SMTP::SSL connection, passing its -new all the options that would otherwise go to Net::SMTP-new (most options) and IO::Socket::SSL-start_SSL (for the SSL options). However, while Net::SMTP::SSL replaces the underlying socket class

Re: git-svn troubles with calendarserver SVN repo

2013-12-02 Thread Ramkumar Ramachandra
Matěj Cepl wrote: I am trying to git-svn clone https://svn.calendarserver.org/repository/calendarserver/CalendarServer/ and I cannot say I am much succesful. Consider using (the somewhat experimental) git-remote-testsvn and the underlying contrib/svn-fe/. For starters, try: $ git clone

Re: branch annotations?

2013-11-25 Thread Ramkumar Ramachandra
Jeff King wrote: I think it makes sense to be able to show it as part of git branch, but the verbose branch listing there is a bit of a mess. Doing it cleanly would probably involve refactoring the branch-display code to allow users to specify more flexible formats. Certainly. I'm quite

Re: Git issues with submodules

2013-11-22 Thread Ramkumar Ramachandra
[+CC: Jens, the goto-guy for submodules] Sergey Sharybin wrote: Namely, `git ls-files -m` will show addons as modified, regardless ignore=all configuration. In the same time `git diff-index --name-only HEAD --` will show no changes at all. This happens because diff-index handles submodules

Re: Git issues with submodules

2013-11-22 Thread Ramkumar Ramachandra
Sergey Sharybin wrote: On Fri, Nov 22, 2013 at 5:16 PM, Ramkumar Ramachandra artag...@gmail.com wrote: [+CC: Jens, the goto-guy for submodules] Sergey Sharybin wrote: Namely, `git ls-files -m` will show addons as modified, regardless ignore=all configuration. In the same time `git diff

Re: Git issues with submodules

2013-11-22 Thread Ramkumar Ramachandra
Jeff King wrote: I just checked it out: it uses `git ls-files -m` to get the list of unstaged changes; `git diff --name-only HEAD --` will list staged changes as well. That diff command compares the working tree and HEAD; if you are trying to match `ls-files -m`, you probably wanted just

Re: Git issues with submodules

2013-11-22 Thread Ramkumar Ramachandra
Sergey Sharybin wrote: Ramkumar, not actually sure what you mean? For me `git diff --name-only HEAD --` ignores changes to submodules hash changes. `git diff --name-only HEAD --` compares the worktree to HEAD (listing both staged and unstaged changes); we want `git diff --name-only --` to

Re: Git issues with submodules

2013-11-22 Thread Ramkumar Ramachandra
Sergey Sharybin wrote: To reproduce the issue: - Run git submodule update --recursive to make sure their SHA is changed. Then `git add /path/to/changed submodule` or just `git add .` - Modify any file from the parent repository - Neither of `git status`, `git diff` and `git diff-files

Re: Git issues with submodules

2013-11-22 Thread Ramkumar Ramachandra
Jens Lehmann wrote: But the question is if that is the right thing to do: should diff.ignoreSubmodules and submodule.name.ignore only affect the diff family or also git log friends? That would make users blind for submodule history (which they already are when using diff friends, so that

Re: Re: Git issues with submodules

2013-11-22 Thread Ramkumar Ramachandra
Heiko Voigt wrote: What I think needs fixing here first is that the ignore setting should not apply to any diffs between HEAD and index. IMO, it should only apply to the diff between worktree and index. When we have that the user does not see the submodule changed when normally working. But

Re: [PATCH v4 6/6] for-each-ref: avoid color leakage

2013-11-19 Thread Ramkumar Ramachandra
Junio C Hamano wrote: My knee-jerk adding it to struct refinfo is not correct, either, because what we want to know, i.e. do we need an extra reset? is not a property for each ref. It is similar to what is the set of atoms the format string is using? and do we need to peel tags in order to

Re: [PATCH v2 3/3] for-each-ref: introduce %(color:...) for color

2013-11-18 Thread Ramkumar Ramachandra
Junio C Hamano wrote: If you are saying, by after each token, that --format='%(color:blue)%(A)literal string%(B)' should result in color blue value for A color reset literal string value for B then I would disagree. Hm, I didn't think it was a bad idea to reset after

  1   2   3   4   5   6   7   8   9   10   >