001 fixes this).
Patch 2 makes the completions more aware of the --git-dir option.
Patch 3 builds on previous patches and makes completions aware of the -C option.
Kind regards,
Peter
Peter Wu (3):
completion: ignore git options for subcommand completion
completion: pass --git-dir to more
Avoid the "fatal: bad config file line 5 in config" message and properly
complete git commands having the "-C" option.
Besides the trivial command parsing, __gitdir is rewritten to apply any
directory changes requested via `git -C otherdir ...`.
Signed-off-by: Peter Wu
a variable and comments to __git_refs for clarity. (Note that
`--git-dir` needs to be kept there because it may not be the same as
the current repo, e.g. via `git fetch /tmp/repo `.)
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
contrib/completion/git-comp
/.git gerrit-diff
Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
---
contrib/completion/git-completion.bash | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 4
On Thursday 22 January 2015 11:59:54 Stefan Beller wrote:
cc Johannes Schindelin johannes.schinde...@gmx.de who is working in
the fsck at the moment
cc Peter Wu pe...@lekensteyn.nl who worked on builtin/remote.c a few weeks
ago
I just compiled origin/pu to test and also found a problem
options were introduced.
The documentation has also been updated and a missing '--push' option
is added to the 'git remote -h' command.
Tests are also added to verify the documented behavior.
Signed-off-by: Peter Wu pe...@lekensteyn.nl
---
Hi,
This is the fourth revision of the patch
On Wednesday 17 December 2014 11:08:07 Torsten Bögershausen wrote:
On 11/25/2014 12:48 PM, Peter Wu wrote:
git remote set-url knew about the '--push' option to update just the
pushurl, but it does not have a similar option for update fetch URL and
leave whatever was in place for the push
On Wednesday 17 December 2014 09:32:13 Jeff King wrote:
On Wed, Dec 17, 2014 at 03:18:56PM +0100, Peter Wu wrote:
This is the fourth revision of the patch that allows for just setting the
fetch
URL. Eric wondered why '--fetch --push' is not used to describe the state
'--both', so I
On Saturday 29 November 2014 13:31:18 Philip Oakley wrote:
From: Peter Wu pe...@lekensteyn.nl
Ok, I will make a clear note about the default (without --only)
behavior
having weird behavior for historical reasons. Are you really OK with
--only=both? It sounds a bit odd (mathematically
On Monday 24 November 2014 23:08:26 Jeff King wrote:
However, I think what removed the confusion for me in your --only=both
proposal was the presence of a both option, since it made it more
clear that is not what no-option means. So what about just --push,
--fetch, and --both? Explain the
On Monday 24 November 2014 21:19:16 Junio C Hamano wrote:
On Mon, Nov 24, 2014 at 9:01 PM, Jeff King p...@peff.net wrote:
We could also stop making push fall back to fetch. But I think people
would find that irritating.
The common case is probably having the same fetch and push URL, so I
' command.
Tests are also added to verify the documented behavior.
Signed-off-by: Peter Wu pe...@lekensteyn.nl
---
v2: fixed test case
v3: added --both option, changed --fetch --push behavior, added more tests for
--add/--delete cases, refactored to reduce duplication (not special-casing
On Tuesday 25 November 2014 17:09:04 Eric Sunshine wrote:
On Tue, Nov 25, 2014 at 6:48 AM, Peter Wu pe...@lekensteyn.nl wrote:
git remote set-url knew about the '--push' option to update just the
pushurl, but it does not have a similar option for update fetch URL and
leave whatever
using the new --fetch
option. For symmetry with the --push option.
(symmetry in the eyes of the user, not how it is implemented in the
git config.)
Opinions?
On Wednesday 19 November 2014 22:28:35 Peter Wu wrote:
On Wednesday 19 November 2014 13:18:56 Junio C Hamano wrote:
Junio C Hamano
On Monday 24 November 2014 14:04:07 Junio C Hamano wrote:
Peter Wu pe...@lekensteyn.nl writes:
I propose to add the option --fetch next to --push with the meaning set
the fetch/push URL of remote NAME to URL. Then --fetch --push means
set the fetch and push URL of remote NAME to URL
On Monday 24 November 2014 17:22:44 Jeff King wrote:
On Mon, Nov 24, 2014 at 11:16:03PM +0100, Peter Wu wrote:
A new option --fetch introducing a different behaviour is
perfectly fine; existing users who are not using it will not be
harmed by sudden behaviour change.
As stated
On Monday 24 November 2014 17:54:57 Jeff King wrote:
On Mon, Nov 24, 2014 at 11:47:30PM +0100, Peter Wu wrote:
I can understand that --fetch sounds a bit weird, what about this
natural translation:
git remote: set the URL (only the fetch one) for NAME to URL
git remote set-url
are also added to verify the documented behavior.
Signed-off-by: Peter Wu pe...@lekensteyn.nl
---
(please cc me, I am not subscribed)
Hi,
Now and then I hit this issue where I want to change the remote where
sources are fetched from without having to touch the push URL. Example:
git remote add gh g
On Wednesday 19 November 2014 14:08:00 Jeff King wrote:
On Wed, Nov 19, 2014 at 04:18:02PM +0100, Peter Wu wrote:
git remote set-url knew about the '--push' option to update just the
pushurl, but it does not have a similar option for update fetch URL and
leave whatever was in place
On Wednesday 19 November 2014 15:17:21 Jeff King wrote:
On Wed, Nov 19, 2014 at 08:42:19PM +0100, Peter Wu wrote:
git remote set-url --fetch new-fetch-url
This is less verbose and is much more intuitive.
I agree your suggestion is a nicer way to do this. I'm just not sure
On Wednesday 19 November 2014 12:29:47 Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I dunno. I guess that is more convenient, but it seems like a lot of
code for a very marginal use case. But more importantly, I'm a little
worried that the presence of --fetch creates confusion
On Wednesday 19 November 2014 13:18:56 Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
If you are fetching from somebody else and then pushing into your
own publishing repository (i.e. fork of that upstream), why isn't
the sequence of event
On Wednesday 03 September 2014 13:21:06 Duy Nguyen wrote:
On Wed, Sep 3, 2014 at 5:17 AM, Peter Wu pe...@lekensteyn.nl wrote:
Hi,
The `git archive` seems to accept a pathspec judging from the error message
(git
version 2.1.0):
git archive HEAD -- :x
fatal: pathspec 'x
that match that
pathspec.
Noticed-by: Peter Wu pe...@lekensteyn.nl
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Ah, ignore my last mail, I just noticed this one. This patch works fine. By the
way, the glob pattern is treated as a 'nullglob'. If you specify a glob pattern
that matches nothing
the use of `--contains` and
other filter options alongside `-d`.
Signed-off-by: Jeff King p...@peff.net
Tested-by: Peter Wu lekenst...@gmail.com
I have tested this patch on top of 1.8.1.2 and it seems to work.
One note, the following command spits out master without complaining about the
non
all characters in the range 0x20 to 0x78 (inclusive).
Signed-off-by: Peter Wu lekenst...@gmail.com
---
perl/Git/SVN/Editor.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/perl/Git/SVN/Editor.pm b/perl/Git/SVN/Editor.pm
index 3bbc20a..30f92cb 100644
--- a/perl/Git/SVN
26 matches
Mail list logo
