[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/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 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 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 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 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

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: 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 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: [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:

[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: 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

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: 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

[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: [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

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

[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 10/10] pack-revindex: radix-sort the revindex

2013-07-10 Thread Ramkumar Ramachandra
Jeff King wrote: That does O(n log n) offset comparisons, and profiling shows that we spend most of our time in cmp_offset. However, since we are sorting on a simple off_t, we can use numeric sorts that perform better. A radix sort can run in O(k*n), where k is the number of digits in our

Re: [PATCH 06/10] cat-file: add --batch-check=format

2013-07-10 Thread Ramkumar Ramachandra
Jeff King wrote: +If `--batch` or `--batch-check` is given, `cat-file` will read objects +from stdin, one per line, and print information about them. + +You can specify the information shown for each object by using a custom +`format`. The `format` is copied literally to stdout for each

Re: [PATCH 08/10] cat-file: split --batch input lines on whitespace

2013-07-10 Thread Ramkumar Ramachandra
Jeff King wrote: git rev-list --objects HEAD | git cat-file --batch-check='%(objectsize) %(text)' If anything, I would have expected %(rest), not %(text). This atom is specific to commands that accept input via stdin (i.e. not log, f-e-r, branch, or anything else I can think of). Also,

Re: [PATCH v2 1/2] send-email: squelch warning from Net::SMTP::SSL

2013-07-14 Thread Ramkumar Ramachandra
Torsten Bögershausen wrote: /usr/bin/perl -MIO::Socket::SSL -e 'print $IO::Socket::SSL::VERSION\n;' 1.22 This is ancient! (I have 1.84). Is it not possible to do an ssl-verify-peer in older versions (is it exported as something else)? The older versions don't display the warning anyway, and

Re: [PATCH v2 1/2] send-email: squelch warning from Net::SMTP::SSL

2013-07-14 Thread Ramkumar Ramachandra
brian m. carlson wrote: I didn't stick the require in the eval because git-send-email will fail in this case anyway if you don't have it, since Net::SMTP::SSL requires it. Let me know if you want a patch for this on top of the existing two in this series and I'll provide one. Yeah, that'd be

Re: Re* [PATCH] send-email: improve SSL certificate verification

2013-07-18 Thread Ramkumar Ramachandra
Junio C Hamano wrote: Ramkumar, as you will still be the primary author of the resulting commit, I tentatively added a line for your sign-off even though you haven't signed off _this_ version yet, so that I would not forget. If this version looks good, please tell us you would. Yeah, it seems

Re: Git Clone Parameter

2013-07-19 Thread Ramkumar Ramachandra
Allan Acheampong wrote: I could write a script with for each in but thats way too much hassle $ git for-each-ref --format=%(refname) refs/remotes/origin/ | sed 's/refs\/remotes\/origin\///;/HEAD\|master/d' | xargs git checkout -b (completely untested ofcourse) Do you see what the problem is

[RFC] checkout --rebase

2013-07-19 Thread Ramkumar Ramachandra
Hi, I'm often work on small topic branches, and find myself doing this quite often: # on branch master $ git checkout um-build $ git rebase master This is horribly inefficient; the first operation takes a _really_ long time to complete, since master updates itself very often and I have to

[RFC] Delete current branch

2013-07-19 Thread Ramkumar Ramachandra
Hi, Many of my ideas turn out to be really stupid, and I need to throw away my feature branch. So, I find myself doing this often: # on branch menuconfig-jk $ git checkout master $ git branch -DBACKSAPCE # er, what was the branch name again? $ git checkout - # Ah $ git checkout

Re: [RFC] checkout --rebase

2013-07-19 Thread Ramkumar Ramachandra
Sebastian Staudt wrote: Isn't this what you want? $ git rebase master um-build Ha, yes. Sorry about the stupidity. -- 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: [RFC] checkout --rebase

2013-07-19 Thread Ramkumar Ramachandra
Ramkumar Ramachandra wrote: Sebastian Staudt wrote: Isn't this what you want? $ git rebase master um-build Ha, yes. Sorry about the stupidity. Hm, I'm not entirely sure how to optimize the codepath to eliminate the checkout. It seems to be absolutely necessary atleast in the -i codepath

Re: [RFC] checkout --rebase

2013-07-19 Thread Ramkumar Ramachandra
Ramkumar Ramachandra wrote: diff --git a/git-rebase.sh b/git-rebase.sh index 0039ecf..7405d9a 100755 --- a/git-rebase.sh +++ b/git-rebase.sh Er, sorry. I think it suffices to check that $branch_name equals HEAD, for this optimization. -- To unsubscribe from this list: send the line

Re: [RFC] checkout --rebase

2013-07-19 Thread Ramkumar Ramachandra
Damn it: checkout doesn't get executed at all because the $mb = $onto condition fails; I was looking in the wrong place. It's format-patch and am that are slowing things down terribly. Has anyone looked into stripping out the dependency? Why is cherry-pick deficient? My current workaround is

Re: [RFC] Delete current branch

2013-07-19 Thread Ramkumar Ramachandra
Andreas Schwab wrote: Ramkumar Ramachandra artag...@gmail.com writes: # er, what was the branch name again? $ git checkout - You could take a look in the reflog. Yeah, or use the @{-N} revision to do that for me. My scripted version is essentially: test true = $(git rev-parse

Re: [RFC] Delete current branch

2013-07-19 Thread Ramkumar Ramachandra
Junio C Hamano wrote: Did you know that the general way to spell the branch previously you were on is @{-1} and checkout - is an ugly special case that is possible only because checkout does not happen to take a - as a valid argument that means something else (like the more usual read from

Re: Git Clone Parameter

2013-07-19 Thread Ramkumar Ramachandra
Junio C Hamano wrote: git branch -t $branchname origin/$branchname A couple of notes here: 1. I use git branch -u personally. Why the -t variant? 2. Don't we auto-track? (or is that only on checkout) -- To unsubscribe from this list: send the line unsubscribe git in the body of a

Re: Git Clone Parameter

2013-07-19 Thread Ramkumar Ramachandra
Junio C Hamano wrote: You would at least need xargs -n 1 for the produced command line to make any sense, and it is wasteful to actually check out each and every branch to the working tree only to create it. Right. xargs -n 1, git branch, and refname:short. -- To unsubscribe from this list:

Re: [RFC] Delete current branch

2013-07-19 Thread Ramkumar Ramachandra
Junio C Hamano wrote: That limits the context we could use - and we cannot consistently use it everywhere. I find _that_ ugly from the design cleanliness point of view. Right, noted. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to

Re: [PATCH] Fix compilation on OS X.

2013-07-20 Thread Ramkumar Ramachandra
Benoit Sigoure wrote: diff --git a/compat/unsetenv.c b/compat/unsetenv.c index 4ea1856..addf3dc 100644 --- a/compat/unsetenv.c +++ b/compat/unsetenv.c @@ -1,5 +1,10 @@ #include ../git-compat-util.h +#ifdef __APPLE__ +// On OS X libc headers don't define this symbol. +extern char

Re: Dead link

2013-07-20 Thread Ramkumar Ramachandra
Ondřej Bílka wrote: http://marc.theaimsgroup.com/?l=gitm=112927316408690w=2 Just run a sed 's|http://marc.theaimsgroup.com|http://marc.info|', and submit the resulting patch. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org

Re: What's cooking in git.git (Jul 2013, #03; Tue, 9)

2013-07-23 Thread Ramkumar Ramachandra
Junio C Hamano wrote: * mv/merge-ff-tristate (2013-07-02) 1 commit (merged to 'next' on 2013-07-09 at c32b95d) + merge: handle --ff/--no-ff/--ff-only as a tri-state option Sorry I didn't notice sooner, but I was confused by the second test title this added: test_expect_success 'option

[PATCH] commit: correct advice about aborting a cherry-pick

2013-07-26 Thread Ramkumar Ramachandra
of a ranged pick, as a 'git reset' will fail to remove $GIT_DIR/sequencer, failing a subsequent cherry-pick or revert. Change the advice to: git cherry-pick --abort Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Another candidate for maint? I'd also really like to squelch

Re: [PATCH] commit: correct advice about aborting a cherry-pick

2013-07-26 Thread Ramkumar Ramachandra
Jeff King wrote: Hmm. I don't think I've run across this message myself, so perhaps I do not understand the situation. It's very simple. # on branch master $ git checkout -b test $ git cherry-pick master $ ls .git/sequencer # missing In the pseudo multi-pick case (I say pseudo

Re: [PATCH] commit: correct advice about aborting a cherry-pick

2013-07-26 Thread Ramkumar Ramachandra
Jeff King wrote: Ah. I don't mind improving the message in the meantime, but it sounds like this is a deficiency in sequenced cherry-pick that needs addressed eventually. I'm especially irked by how slow rebase--am is, and want to replace it. -- To unsubscribe from this list: send the line

Re: [PATCH] commit: correct advice about aborting a cherry-pick

2013-07-27 Thread Ramkumar Ramachandra
Jeff King wrote: builtin/commit.c | 25 ++--- 1 file changed, 22 insertions(+), 3 deletions(-) Overall, highly inelegant. The single-commit pick has been special cased only because we needed to preserve backward compatibility: I would hate for the detail to be

Re: [PATCH] commit: correct advice about aborting a cherry-pick

2013-07-27 Thread Ramkumar Ramachandra
Jonathan Nieder wrote: Your patch is just swapping out git reset for cherry-pick --abort, so I think that is a good improvement in the meantime. Um, wasn't the idea of the original message that you can run git reset and then git cherry-pick --continue? No, and I don't know where you got that

[BUG] git_path() returns relative paths

2013-07-27 Thread Ramkumar Ramachandra
Hi, I noticed a regression in the latest master, and I've been trying to debug it for 30 minutes now. I'm still clueless about the root cause, but I'll list whatever I found so far: I suddenly noticed that I wasn't able to commit to a certain repository with submodules anymore. This was

Re: [BUG] git_path() returns relative paths

2013-07-27 Thread Ramkumar Ramachandra
Ramkumar Ramachandra wrote: *scratches head* Just took a much-needed shower and came back. It was trivial to find. $ git log v1.8.3.4.. -- path.c e02ca72 (path.c: refactor relative_path(), not only strip prefix, 2013-06-25) is the offender. -- To unsubscribe from this list: send the line

Re: [BUG] git_path() returns relative paths

2013-07-27 Thread Ramkumar Ramachandra
Ramkumar Ramachandra wrote: e02ca72 (path.c: refactor relative_path(), not only strip prefix, 2013-06-25) is the offender. The problem is the callsite in setup.c:setup_work_tree(). When relative_path() is called with /home/artagnon/dotfiles/.git/modules/.elisp/flx and /home/artagnon/dotfiles

Re: [BUG] git_path() returns relative paths

2013-07-27 Thread Ramkumar Ramachandra
Fredrik Gustafsson wrote: When I hear submodules The only reason this bug has something to do with submodules is because of the relative path in the gitfile (although I'm yet to corner the exact issue). Otherwise, it doesn't exercise any new code in submodule.c/ git-submodule.sh. -- To

Re: [BUG] git_path() returns relative paths

2013-07-27 Thread Ramkumar Ramachandra
Duy Nguyen wrote: 044bbbc (Make git_dir a path relative to work_tree in setup_work_tree() - 2008-06-19) Okay, so it does seem to be a significant optimization. Frankly, e02ca72 only improves the relative_path() algorithm, and it's not really doing anything Wrong: it's has just uncovered a

Re: [BUG] git_path() returns relative paths

2013-07-27 Thread Ramkumar Ramachandra
Duy Nguyen wrote: I was involved with this code (the gitdir setup code, not submodule) and am interested to know what's going on too. Could you produce a small script to reproduce it? Here's your reduced testcase. Just point mygit to a HEAD build. #!/bin/sh mygit=~/src/git/git cd /tmp

Re: [BUG] git_path() returns relative paths

2013-07-27 Thread Ramkumar Ramachandra
Jiang Xin wrote: I change the EDITOR(GIT_EDITOR) environment in your test script as follows: GIT_EDITOR=echo PWD: $(pwd); echo REALPATH: $(pwd -P); echo \ git commit --amend See, what stumps be about this is the no-submodule case: #!/bin/sh mygit=~/src/git/git cd /tmp rm

Re: [BUG] git_path() returns relative paths

2013-07-28 Thread Ramkumar Ramachandra
Duy Nguyen wrote: I think instead of letting the kernel walk the path, emacs does it by itself. If this were true, shouldn't we be able to reproduce the behavior with my no-submodules symlink testcase? How can it resolve symlinks in one case, and not in the other case? -- To unsubscribe from

  1   2   3   4   5   6   7   8   9   10   >