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
---
contrib/completion/git-completion.bash | 52 --
1 f
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
it gerrit-diff
Signed-off-by: Peter Wu
---
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 482ca84..bd9ef4c 10064
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
---
On Thursday 22 January 2015 11:59:54 Stefan Beller wrote:
> cc Johannes Schindelin who is working in
> the fsck at the moment
> cc Peter Wu who worked on builtin/remote.c a few weeks
> ago
>
> I just compiled origin/pu to test and also found a problem (doesn't
&g
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
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
> >
'--direction=...' is too long and
'--dir=' is ambiguous ("directory"?). Thus, for brevity three new
options were introduced.
The documentation has also been updated and a missing '--push' option
is added to the 'git remote -h' command.
Tests a
On Saturday 29 November 2014 13:31:18 Philip Oakley wrote:
> From: "Peter Wu"
> > 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
On Tuesday 25 November 2014 17:09:04 Eric Sunshine wrote:
> On Tue, Nov 25, 2014 at 6:48 AM, 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
>
27;--push' option
is added to the 'git remote -h' command.
Tests are also added to verify the documented behavior.
Signed-off-by: Peter Wu
---
v2: fixed test case
v3: added --both option, changed --fetch --push behavior, added more tests for
--add/--delete cases, refact
On Monday 24 November 2014 21:19:16 Junio C Hamano wrote:
> On Mon, Nov 24, 2014 at 9:01 PM, Jeff King 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
think that t
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"? Expla
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 o
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
>
On Monday 24 November 2014 14:04:07 Junio C Hamano wrote:
> Peter Wu 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
mand now allows you to change just the
fetch URL without modifying the push URL 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:
On Wednesday 19 November 2014 13:18:56 Junio C Hamano wrote:
> Junio C Hamano writes:
> > Jeff King 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 like this, instead?
> >
On Wednesday 19 November 2014 12:29:47 Junio C Hamano wrote:
> Jeff King 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 about wh
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
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
the 'git remote -h' command.
Tests are also added to verify the documented behavior.
Signed-off-by: Peter Wu
---
(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 tou
gt; they are actually needed. There is a theoretical bug in this
> implementation: we can't write empty trees/directories that match that
> pathspec.
>
> Noticed-by: Peter Wu
> Signed-off-by: Nguyễn Thái Ngọc Duy
Ah, ignore my last mail, I just noticed this one. This patch works
On Wednesday 03 September 2014 13:21:06 Duy Nguyen wrote:
> On Wed, Sep 3, 2014 at 5:17 AM, Peter Wu wrote:
> > Hi,
> >
> > The `git archive` seems to accept a pathspec judging from the error message
> > (git
> > version 2.1.0):
> >
> > git archi
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' did not match any files
When I try to use deeper glob specs however, it throws an error (this also
happens if I use `:(glob)**/Makefile`, tested
e where
> `--list` is given alongside `-d` and flag an error. With
> this patch, we will also catch the use of `--contains` and
> other filter options alongside `-d`.
>
> Signed-off-by: Jeff King
Tested-by: Peter Wu
I have tested this patch on top of 1.8.1.2 and it seems to wo
Hi,
I was trying to check whether a certain branch contained a commit and ran:
git branch --contains ddc150f7a33ae0c9cb16eaac3641abc00f56316f master
This resulted in:
fatal: A branch named 'master' already exists.
When "name" does not exist, this command creates a branch. I expect this
racters not to be escaped are taken from the
subversion/libsvn_subr/path.c file to fully account for all characters. Tested
with a filename containing all characters in the range 0x20 to 0x78 (inclusive).
Signed-off-by: Peter Wu
---
perl/Git/SVN/Editor.pm | 3 ++-
1 file changed, 2 insertions(+), 1
28 matches
Mail list logo
