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
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 f
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.
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 thou
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 r
Ramkumar Ramachandra wrote:
> Signed-off-by: Ramkumar Ramachandra
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.
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 "u
f arr is declared separately.
Helped-by: René Scharfe
Signed-off-by: Ramkumar Ramachandra
---
.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
--- /de
Instead of manually eyeballing style in reviews, just ask all
contributors to run their patches through [git-]clang-format.
Signed-off-by: Ramkumar Ramachandra
---
The idea is to introduce the community to this new toy I found called
clang-format. Whether or not it's actually going to be
Signed-off-by: Ramkumar Ramachandra
---
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 dbe2abf..5dde920
Signed-off-by: Ramkumar Ramachandra
---
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/git-contacts
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
/Library/Developer/CommandLin
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 f
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 http:
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
ugline
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
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.
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
It's a simple matter of opening the directory specified in the gitfile.
Signed-off-by: Ramkumar Ramachandra
---
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
@@ -337,6 +3
$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
---
perl/Git/SVN.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
ind
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
---
I was worried because of the long wait, so I wrote this to convince
myself that git-svn
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 u
, 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
Signed-off-by: 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" &&
> pick_one_pre
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.
work for cherry-pick.
--
To unsubscribe from this list: send the line "unsubscribe git
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 majord.
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 ma
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"),
> - find_unique_abbrev(co
Felipe Contreras wrote:
> Signed-off-by: Felipe Contreras
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
remote.pushdefault is configured?
--
To u
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, i
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 majord...@v
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 m
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
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 fi
Fix a few minor things.
Signed-off-by: Ramkumar Ramachandra
---
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 are there.
Document
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
---
Documentation/merge-strategies.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/
Jeff King wrote:
> Thus, config like:
>
> [branch "master"]
> pushremote = foo
> [remote]
> pushdefault = bar
>
> erroneously ends up pushing to "bar" from the master branch.
Oh, ouch. Thanks for fixing this.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
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_
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 form
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 sp
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 sta
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 http:/
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:
>
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
will make it much
simpler to add more constructs in future patches.
While we're at it, let's also break apart the refactored
code into a few helper functions. These will be useful when
we implement similar @{upstream}-like constructs.
Signed-off-by: Jeff King
Signed-off-by: Ramku
to
"remote" and "remote_name"; "pushremote" and "pushremote_name".
Helped-by: Jeff King
Signed-off-by: Ramkumar Ramachandra
---
remote.c | 15 ---
remote.h | 3 +++
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/remote.c b/remo
me subtle
differences.
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
Signed-off-by: Ramkumar Ramachandra
---
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/t1507-rev-parse
Kevin wrote:
> Either the documentation is wrong, and should be changed to "th
> 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"
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 le
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 maj
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
> sp
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 o
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.*
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
>
[Fixed typo in Junio's address]
On Wed, Jan 8, 2014 at 1:59 AM, Ramkumar Ramachandra 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
>
uild
functionality around this new configuration variable.
Cc: Jeff King
Cc: Junio C Hamano
Signed-off-by: Ramkumar Ramachandra
---
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 and
rebase.
Bu
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 = upstr
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 majo
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.
>
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.pushdefault"set to 'publish', you can expect
>
>
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 fo
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
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 ""] inste
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 sta
Junio C Hamano wrote:
> - why is a single branch name sufficient?
It does accept a , 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 simply d
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;
I'm
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
Signed-off-by: Ramkumar Ramachandra
---
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-completion.bash
+++ b
ter' explicitly 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
---
Documentation/config.txt | 4
builtin/log.c |
Hi,
This is inspired by merge.defaultToUpstream. Disclaimer: I have an
"fpm" alias for doing this (separate from "fp" for when I need to
generate patches against some other branch), which I'd like to get rid
of.
Thanks.
Ramkumar Ramachandra (2):
completion: co
quot;. To facilitate 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
---
contrib/completion/git-completion.bash | 22 ++
contrib/completion/git-completion.z
directory than in those system default places.
Signed-off-by: Ramkumar Ramachandra
---
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 fac5e71..6fca145
When attempting to complete
$ git config remote.push
'pushdefault' doesn't come up. This is because "$cur" is matched with
"remote.*" and a list of remotes are completed. Add 'pushdefault' as a
candidate for completion too, using __gitcomp_nl_ap
Hi Junio et al,
Most significantly, [2/4] no longer duplicates __gitcompadd () in
__gitcomp_nl_append (). Other than that, the commit messages for the
other patches are improved.
Thanks.
Ramkumar Ramachandra (4):
zsh completion: find matching custom bash completion
completion: introduce
#x27; as candidates for
completion too, using __gitcomp_nl_append ().
Signed-off-by: Ramkumar Ramachandra
---
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 20febff..
brian m. carlson wrote:
> I'm not clear on this change. It looks like this loads
> git-completion.bash from the same directory as git-completion.zsh. Is
> this correct?
Yes, and that's what I meant to convey with the "./". Junio's message
is clearer though, so I'll use that.
Thanks.
--
To unsub
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
l
When attempting to complete
$ git config remote.push
'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 ().
Sign
tuprebase' to the list of
branches using __gitcomp_nl_append ().
Signed-off-by: Ramkumar Ramachandra
---
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
quot;. To facilitate 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
---
contrib/completion/git-completion.bash | 13 +
contrib/completion/git-completion.zsh | 8 +
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: intr
To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion
Junio C Hamano wrote:
> I am not sure what you are worried about $pfx; what does it do when
> you have strings with different prefix in COMPREPLY? If it breaks,
> then the answer is "don't do it then".
>
> Doesn't an array know its own length and give you a way to ask?
Right. I was just throwing c
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 providin
cilitate completions of this kind, create a
variation of __gitcomp_nl () that accepts two sets of arguments and two
independent suffixes.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 30 ++
contrib/completion/git-completion.zsh | 10
Hi,
In this iteration, I've removed hunks to prevent completing:
$ git config remote.pushdefault.
$ git config branch.autosetupmerge.
$ git config branch.autosetuprebase.
Since they're perfectly valid remote/ branch names.
Thanks.
Ramkumar Ramachandra (4):
completion: priori
To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion
e list of branches using
__gitcomp_2 ().
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 64b20b8..cbb4eca 100644
---
When attempting to complete
$ git config remote.push
'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_2 ().
Sign
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 bo
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.autosetupmer
hit backspace to delete the trailing space, inserted a dot, and hit again.
> If you are working
Signed-off-by: Ramkumar Ramachandra
---
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 +92,7 @@ static
lso take care to not complete
$ git config remote.pushdefault.
with the usual remote.. candidates.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib
cilitate completions of this kind, create a
variation of __gitcomp_nl () that accepts two sets of arguments and two
independent suffixes.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 30 ++
contrib/completion/git-completion.zsh | 10
f branches using
__gitcomp_2 ().
Also take care to not complete
$ git config branch.autosetupmerge.
$ git config branch.autosetuprebase.
with the usual branch.. candidates.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 8 +++-
1 file changed, 7 insert
h 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
To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion
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
t
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 socke
1 - 100 of 1623 matches
Mail list logo
