Re: [PATCH 1/2] refs: show --exclude failure with --branches/tags/remotes=glob

Hi Junio, On Tue, 13 Nov 2018, Junio C Hamano wrote: > Rafael Ascensão writes: > > > The documentation of `--exclude=` option from rev-list and rev-parse > > explicitly states that exclude patterns *should not* start with 'refs/' > > when used with `--branches`

Re: [PATCH 1/2] refs: show --exclude failure with --branches/tags/remotes=glob

Rafael Ascensão writes: > The documentation of `--exclude=` option from rev-list and rev-parse > explicitly states that exclude patterns *should not* start with 'refs/' > when used with `--branches`, `--tags` or `--remotes`. > > However, following this advice results in refe

[PATCH 1/2] refs: show --exclude failure with --branches/tags/remotes=glob

The documentation of `--exclude=` option from rev-list and rev-parse explicitly states that exclude patterns *should not* start with 'refs/' when used with `--branches`, `--tags` or `--remotes`. However, following this advice results in refereces not being excluded if the next `--branches

Re: [PATCH v3 7/8] push: add DWYM support for "git push refs/remotes/...:"

Ævar Arnfjörð Bjarmason writes: > After all sometimes "other" is just the repo on my laptop or server. I > shouldn't need to jump through hoops to re-push stuff from my "other" > repo anymore than from the local repo. > > Yes refs/remotes/* isn't guar

Re: [PATCH v3 7/8] push: add DWYM support for "git push refs/remotes/...:"

do not think I mind all that much if a src that >>> is a tag object to automatically go to refs/tags/ (having a tag >>> object in refs/remotes/** is rare enough to matter in the first >>> place). >> >> Yeah maybe this is going too far. I don't think so, but ha

Re: [PATCH v3 7/8] push: add DWYM support for "git push refs/remotes/...:"

Ævar Arnfjörð Bjarmason writes: >> On the other hand, I do not think I mind all that much if a src that >> is a tag object to automatically go to refs/tags/ (having a tag >> object in refs/remotes/** is rare enough to matter in the first >> place). > > Yeah maybe

Re: [PATCH v3 7/8] push: add DWYM support for "git push refs/remotes/...:"

On Mon, Oct 29 2018, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Add DWYM support for pushing a ref in refs/remotes/* when the > > I think most people call it do-what-*I*-mean, not do-what-you-mean. FWIW I picked this up from the perl list where both

Re: [PATCH v3 7/8] push: add DWYM support for "git push refs/remotes/...:"

On Mon, Oct 29 2018, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> This is the first use of the %N$ style of printf format in >> the *.[ch] files in our codebase. It's supported by POSIX[2] and >> there's existing uses for it in po/*.po files,... > > For now, I'll eject this

Re: [PATCH v3 7/8] push: add DWYM support for "git push refs/remotes/...:"

Junio C Hamano writes: > Ævar Arnfjörð Bjarmason writes: > >> This is the first use of the %N$ style of printf format in >> the *.[ch] files in our codebase. It's supported by POSIX[2] and >> there's existing uses for it in po/*.po files,... > > For now, I'll eject this from 'pu', as I had

Re: [PATCH v3 7/8] push: add DWYM support for "git push refs/remotes/...:"

Ævar Arnfjörð Bjarmason writes: > This is the first use of the %N$ style of printf format in > the *.[ch] files in our codebase. It's supported by POSIX[2] and > there's existing uses for it in po/*.po files,... For now, I'll eject this from 'pu', as I had spent way too much time trying to

Re: [PATCH v3 7/8] push: add DWYM support for "git push refs/remotes/...:"

Ævar Arnfjörð Bjarmason writes: > Add DWYM support for pushing a ref in refs/remotes/* when the I think most people call it do-what-*I*-mean, not do-what-you-mean. > ref is unqualified. Now instead of erroring out we support e.g.: > > $ ./git-push avar refs/remotes/origin/mas

[PATCH 58/78] config.txt: move remotes.* to a separate file

index b7aafdbf17..9aa849ce8b 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -395,9 +395,7 @@ include::config/receive.txt[] include::config/remote.txt[] -remotes.:: - The list of remotes which are fetched by "git remote update - ". See linkgit:gi

[PATCH v3 7/8] push: add DWYM support for "git push refs/remotes/...:"

Add DWYM support for pushing a ref in refs/remotes/* when the ref is unqualified. Now instead of erroring out we support e.g.: $ ./git-push avar refs/remotes/origin/master:upstream-master -n To github.com:avar/git.git * [new branch]origin/master -> upstream-mas

[PATCH v2 7/7] push: add DWYM support for "git push refs/remotes/...:"

Add DWYM support for pushing a ref in refs/remotes/* when the ref is unqualified, e.g.: git push origin refs/remotes/origin/master:upstream-master Before this we wouldn't know what do do with refs/remotes/origin/master, now we'll look it up and discover that it's a commit (or tag) and add

[PATCH 44/59] config.txt: move remotes.* to a separate file

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/config.txt | 4 +--- Documentation/remotes-config.txt | 3 +++ 2 files changed, 4 insertions(+), 3 deletions(-) create mode 100644 Documentation/remotes-config.txt diff --git a/Documentation/config.txt b/Documentation/config.txt

[PATCHv2 2/3] git-p4: unshelve into refs/remotes/p4-unshelved, not refs/remotes/p4/unshelved

The branch detection code looks for branches under refs/remotes/p4/... and can end up getting confused if there are unshelved changes in there as well. This happens in the function p4BranchesInGit(). Instead, put the unshelved changes into refs/remotes/p4-unshelved/. Signed-off-by: Luke Diamand

Re: [PATCHv1 2/3] git-p4: unshelve into refs/remotes/p4-unshelved, not refs/remotes/p4/unshelved

On Fri, 12 Oct 2018 at 19:19, Luke Diamand wrote: > > On Fri, 12 Oct 2018 at 14:45, Junio C Hamano wrote: > > > > Luke Diamand writes: > > > > > The branch detection code looks for branches under refs/remotes/p4/... > > > and can end up getti

Re: [PATCHv1 2/3] git-p4: unshelve into refs/remotes/p4-unshelved, not refs/remotes/p4/unshelved

On Fri, 12 Oct 2018 at 14:45, Junio C Hamano wrote: > > Luke Diamand writes: > > > The branch detection code looks for branches under refs/remotes/p4/... > > and can end up getting confused if there are unshelved changes in > > there as well. This happens in t

Re: [PATCHv1 2/3] git-p4: unshelve into refs/remotes/p4-unshelved, not refs/remotes/p4/unshelved

Luke Diamand writes: > The branch detection code looks for branches under refs/remotes/p4/... > and can end up getting confused if there are unshelved changes in > there as well. This happens in the function p4BranchesInGit(). > > Instead, put the unshelved changes into refs/remot

[PATCHv1 2/3] git-p4: unshelve into refs/remotes/p4-unshelved, not refs/remotes/p4/unshelved

The branch detection code looks for branches under refs/remotes/p4/... and can end up getting confused if there are unshelved changes in there as well. This happens in the function p4BranchesInGit(). Instead, put the unshelved changes into refs/remotes/p4-unshelved/. Signed-off-by: Luke Diamand

Re: [PATCH v5 7/8] t0410: test fetching from many promisor remotes

On Fri, Sep 28, 2018 at 12:35 PM SZEDER Gábor wrote: > > On Tue, Sep 25, 2018 at 01:53:40PM +0200, Christian Couder wrote: > > + IDX=$(cat promisorlist | sed "s/promisor$/idx/") && > > You could drop the unnecessary 'cat', 'sed' is capable to open a file > on its own. > > > + git

Re: [PATCH v5 7/8] t0410: test fetching from many promisor remotes

On Tue, Sep 25, 2018 at 01:53:40PM +0200, Christian Couder wrote: > From: Christian Couder > > Signed-off-by: Christian Couder > Signed-off-by: Junio C Hamano > --- > t/t0410-partial-clone.sh | 24 +++- > 1 file changed, 23 insertions(+), 1 deletion(-) > > diff --git

[PATCH v5 7/8] t0410: test fetching from many promisor remotes

From: Christian Couder Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- t/t0410-partial-clone.sh | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh index 8b32be6417..3fbd8d919e

[PATCH v4 8/9] t0410: test fetching from many promisor remotes

From: Christian Couder Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- t/t0410-partial-clone.sh | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh index 71a9b9a3e8..9d513ebf57

Re: Proposed approaches to supporting HTTP remotes in "git archive"

Am 28.07.2018 um 00:32 schrieb Junio C Hamano: > Josh Steadmon writes: > >> # Supporting HTTP remotes in "git archive" >> >> We would like to allow remote archiving from HTTP servers. There are a >> few possible implementations to be discussed:

Re: Proposed approaches to supporting HTTP remotes in "git archive"

r will generate the > archive which is then delivered to the client. > > ### Benefits > > * Matches existing "git archive" behavior for other remotes. > > * Requires less bandwidth to send a compressed archive than a shallow > clone. > > * Res

Re: Proposed approaches to supporting HTTP remotes in "git archive"

Josh Steadmon writes: > # Supporting HTTP remotes in "git archive" > > We would like to allow remote archiving from HTTP servers. There are a > few possible implementations to be discussed: > > ## Shallow clone to temporary repo > > This approach bui

Re: Proposed approaches to supporting HTTP remotes in "git archive"

(just cc-ing René Scharfe, archive expert; Peff; Dscho; Franck Bui-Huu to see how his creation is evolving. Using the correct address for René this time. Sorry for the noise.) Josh Steadmon wrote: > # Supporting HTTP remotes in "git archive" > > We would like to allow remote

Re: Proposed approaches to supporting HTTP remotes in "git archive"

(just cc-ing René Scharfe, archive expert; Peff; Dscho; Franck Bui-Huu to see how his creation is evolving) Josh Steadmon wrote: > # Supporting HTTP remotes in "git archive" > > We would like to allow remote archiving from HTTP servers. There are a > few possible implement

Proposed approaches to supporting HTTP remotes in "git archive"

# Supporting HTTP remotes in "git archive" We would like to allow remote archiving from HTTP servers. There are a few possible implementations to be discussed: ## Shallow clone to temporary repo This approach builds on existing endpoints. Clients will connect to the remote server's

[PATCH v3 8/9] t0410: test fetching from many promisor remotes

From: Christian Couder Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- t/t0410-partial-clone.sh | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh index 71a9b9a3e8..9d513ebf57

[PATCH v2 8/9] t0410: test fetching from many promisor remotes

Signed-off-by: Christian Couder --- t/t0410-partial-clone.sh | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh index 71a9b9a3e8..9d513ebf57 100755 --- a/t/t0410-partial-clone.sh +++

[PATCH v1 08/11] t0410: test fetching from many promisor remotes

Signed-off-by: Christian Couder --- t/t0410-partial-clone.sh | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh index 6af4712da8..4a7a662512 100755 --- a/t/t0410-partial-clone.sh +++

[PATCH v1 8/8] t0410: test fetching from many promisor remotes

Signed-off-by: Christian Couder --- t/t0410-partial-clone.sh | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh index 6af4712da8..4a7a662512 100755 ---

Re: [PATCH v2 00/36] Promisor remotes and external ODB support

tion happens quite early in the patch series. > > This integration makes it possible to have many promisor and partial > clone remotes (instead of just one) with possibly different partial > clone filters, though that is not tested yet. > > I am not sure that the "external odb&q

[PATCH v2 00/36] Promisor remotes and external ODB support

. So the integration is much more complete now (though not fully complete), and this integration happens quite early in the patch series. This integration makes it possible to have many promisor and partial clone remotes (instead of just one) with possibly different partial clone filters, though

[PATCH 00/40] Promisor remotes and external ODB support

This is an early patch series that start to merge the jh/fsck-promisors patch series (which is currently in pu) with the external odb patch series. The merge is not complete and there is still work needed, but all the tests pass and in my opinion this shows that it is a good way forward to share

[PATCH v2] describe: teach --match to handle branches and remotes

acking references matching the + pattern, excluding respectively "refs/heads/" and "refs/remotes/" + prefix; references of other types are never considered. If given + multiple times, a list of patterns will be accumulated, and tags + matching any of the

Re: [PATCH] describe: teach --match to handle branches and remotes

On Tue, Sep 19, 2017 at 08:52:24AM +0900, Junio C Hamano wrote: > I think you can use skip_prefix() to avoid counting the length of > the prefix yourself, i.e. Thanks, will use it. > The hardcoded +10 for "is_tag" case assumes that anything other than > "refs/tags/something" would ever be used

Re: [PATCH] describe: teach --match to handle branches and remotes

terns. >> + excluding the "refs/tags/" prefix. If used with `--all`, it also >> + considers local branches and remote-tracking references matching the >> + pattern, excluding respectively "refs/heads/" and "refs/remotes/" >> + pref

Re: [PATCH] describe: teach --match to handle branches and remotes

ocal branches and remote-tracking references matching the > + pattern, excluding respectively "refs/heads/" and "refs/remotes/" > + prefix; references of other types are never considered. If given > + multiple times, a list of patterns will be accumulated,

[PATCH] describe: teach --match to handle branches and remotes

+ considers local branches and remote-tracking references matching the + pattern, excluding respectively "refs/heads/" and "refs/remotes/" + prefix; references of other types are never considered. If given + multiple times, a list of patterns will be accum

Re: Bug: `git remote show ` reports different HEAD branch than refs/remotes//HEAD

ybody wanting to get their feet wet in git development. The trickier half of showing both is getting the remote information, but we're already doing that. So I think any patch would want to: 1. Teach builtin/remote.c:show() to say "Remote HEAD branch" instead of just "HEAD branc

Re: Bug: `git remote show ` reports different HEAD branch than refs/remotes//HEAD

On Tue, Aug 15, 2017 at 1:09 PM, Igor Djordjevic <igor.d.djordje...@gmail.com> wrote: > Hi Jason, > > On 15/08/2017 16:26, Jason Karns wrote: >> I have a git repo that shows a different branch in >> `.git/refs/remotes/origin/HEAD` than is reported by `git remote show &

Re: Bug: `git remote show ` reports different HEAD branch than refs/remotes//HEAD

Hi Jason, On 15/08/2017 16:26, Jason Karns wrote: > I have a git repo that shows a different branch in > `.git/refs/remotes/origin/HEAD` than is reported by `git remote show > origin`. > > The branch is `github-rename` in refs/remotes/origin/HEAD, but shows > `master` in ou

Bug: `git remote show ` reports different HEAD branch than refs/remotes//HEAD

I have a git repo that shows a different branch in `.git/refs/remotes/origin/HEAD` than is reported by `git remote show origin`. The branch is `github-rename` in refs/remotes/origin/HEAD, but shows `master` in output of git-remote-show ``` $ cat .git/refs/remotes/origin/HEAD ref: refs/remotes

Re: Why 10k remotes? Was: Re: [RFC/PATCH 0/5] remote: eliminate remote->{fetch,push}_refspec and lazy parsing of refspecs

interesting use case. > > Now instead we > > pass the refspecs directly to fetch whenever move objects between the > > storage repos. They were the same for every remote anyway (and I'd guess > > that is true, too, of your 10k remotes). > > I do have different fetch ref

Why 10k remotes? Was: Re: [RFC/PATCH 0/5] remote: eliminate remote->{fetch,push}_refspec and lazy parsing of refspecs

On Sat, Jun 17, 2017 at 2:33 PM, Jeff King <p...@peff.net> wrote: > On Sat, Jun 17, 2017 at 02:25:39PM +0200, SZEDER Gábor wrote: >> Indeed. Even in my repos with close to 10k remotes the amount of >> memory wasted by the duplicated refspecs is not an problem, there are &g

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Ævar Arnfjörð Bjarmason writes: > It seems pretty haphazard to me, is it even documented somewhere? > > I'm talking about an establish process backed up by code, where for > example I can add an experimental feature in v2.14.0, it'll be subject > to change & warn unless you

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

On Tue, May 16, 2017 at 11:06 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> This and many other discussions on-list basically come down to: >> >> 1. Someone wants to change X. >> 2. This would have user impact Y. >> 3. We have no way to

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Ævar Arnfjörð Bjarmason writes: > This and many other discussions on-list basically come down to: > > 1. Someone wants to change X. > 2. This would have user impact Y. > 3. We have no way to quantify Y. > 4. X doesn't happen out of fear of unquantifiable Y. You forgot the step

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

t;> sources we treat as read-only? >> >> Well, you frequently complain about my patches, claiming that they place >> unnecessary maintenance burden on you. >> >> I would say that the .git/remotes/ and .git/branches/ code is a lot more >> maintenance burden than

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

that they place > unnecessary maintenance burden on you. > > I would say that the .git/remotes/ and .git/branches/ code is a lot more > maintenance burden than most of my patches. I wasn't going to respond to this thread anymore, because I didn't feel like the discussion was going anywh

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Hi Junio, On Sat, 13 May 2017, Junio C Hamano wrote: > Johannes Schindelin <johannes.schinde...@gmx.de> writes: > > > On Fri, 12 May 2017, Junio C Hamano wrote: > >> ... > >> FWIW, I do not think there is any reason for people to be using > >>

Re: checkout -b remotes/origin/ should not work

Jeff King <p...@peff.net> writes: > I think this problem extends beyond "remotes/". The worst is: > > git checkout -b HEAD > > but there are many confusing variants: > > git checkout -b refs/heads/foo > git checkout -b tags/v1.0 > > etc. T

Re: checkout -b remotes/origin/ should not work

On Sat, May 13, 2017 at 08:52:37PM -0700, Stefan Beller wrote: > NEEDSWORK: > > checkout -b remotes/origin/ should not work, unless force is > given (maybe?) > > (I just run into that, now I have a remote tracking branch that points > at my detached HEAD. Oh well.) To

checkout -b remotes/origin/ should not work

NEEDSWORK: checkout -b remotes/origin/ should not work, unless force is given (maybe?) (I just run into that, now I have a remote tracking branch that points at my detached HEAD. Oh well.)

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Jonathan Nieder <jrnie...@gmail.com> writes: > Johannes Schindelin wrote: >> On Fri, 12 May 2017, Junio C Hamano wrote: > >>> And this one is also important. I do not think we had to touch any >>> code that handles .git/remotes/ or .git/branches when w

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Johannes Schindelin <johannes.schinde...@gmx.de> writes: > On Fri, 12 May 2017, Junio C Hamano wrote: >> ... >> FWIW, I do not think there is any reason for people to be using >> .git/remotes/, but for .git/branches/, I do not think I can offer a >> more effici

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Johannes Schindelin wrote: > On Fri, 12 May 2017, Junio C Hamano wrote: >> And this one is also important. I do not think we had to touch any >> code that handles .git/remotes/ or .git/branches when we extended >> the .git/config based configuration for remotes, simply be

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Hi Junio, On Fri, 12 May 2017, Junio C Hamano wrote: > Junio C Hamano <gits...@pobox.com> writes: > > > Johannes Schindelin <johannes.schinde...@gmx.de> writes: > > > >> Git uses the config for remote/upstream information in favor of the > >>

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Junio C Hamano <gits...@pobox.com> writes: > Johannes Schindelin <johannes.schinde...@gmx.de> writes: > >> Git uses the config for remote/upstream information in favor of the >> previously-used .git/remotes/ and .git/branches/ for a decade now. > >

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Hi Peff, On Fri, 12 May 2017, Jeff King wrote: > On Thu, May 11, 2017 at 03:47:33PM +0200, Johannes Schindelin wrote: > > > Git uses the config for remote/upstream information in favor of the > > previously-used .git/remotes/ and .git/branches/ for a decade now. > > &

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Hi Junio, On Fri, 12 May 2017, Junio C Hamano wrote: > Johannes Schindelin <johannes.schinde...@gmx.de> writes: > > > Git uses the config for remote/upstream information in favor of the > > previously-used .git/remotes/ and .git/branches/ for a decade now. > >

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

On Thu, May 11, 2017 at 03:47:33PM +0200, Johannes Schindelin wrote: > Git uses the config for remote/upstream information in favor of the > previously-used .git/remotes/ and .git/branches/ for a decade now. > > Nothing in Git writes to these files any longer, and the most prom

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Git uses the config for remote/upstream information in favor of the > previously-used .git/remotes/ and .git/branches/ for a decade now. The last time I thought about trying this several years ago, I found that people who

Re: [PATCH 11/11] PREVIEW: remove support for .git/remotes/ and .git/branches/

Hi Stefan, On Thu, 11 May 2017, Stefan Beller wrote: > On Thu, May 11, 2017 at 6:48 AM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > > At long last, after a cycle or three of warning users who *still* use > > the ancient feature of .git/remotes/ and .g

Re: [PATCH 11/11] PREVIEW: remove support for .git/remotes/ and .git/branches/

On Thu, May 11, 2017 at 6:48 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > At long last, after a cycle or three of warning users who *still* use > the ancient feature of .git/remotes/ and .git/branches/, it is time to > retire the code. > > Signed-off-by

[PATCH 08/11] PREVIEW: remote: remove support for migrating ancient remotes

behave as if `--mirror` was passed. Rename the remote named to . All remote-tracking branches and configuration settings for the remote are updated. -+ -In case and are the same, and is a file under -`$GIT_DIR/remotes` or `$GIT_DIR/branches`, the remote is converted to -the configuration file

[PATCH 06/11] PREVIEW: t5510: convert .git/remotes/ test to use a regular remote

We are about to stop supporting the .git/remotes/ and .git/branches/ feature. In preparation, t5510-fetch is adjusted *not* to verify that .git/remotes/ works. As the tests are entangled, we do not simply remove the test repository with such a remote, but convert it to use a regular remote

[PATCH 11/11] PREVIEW: remove support for .git/remotes/ and .git/branches/

At long last, after a cycle or three of warning users who *still* use the ancient feature of .git/remotes/ and .git/branches/, it is time to retire the code. Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> --- path.c | 2 -- remote.

[PATCH 10/11] PREVIEW: t0060: stop testing support for .git/remotes/ and .git/branches/

eckout test_git_path GIT_COMMON_DIR=bar info//sparse-checkout .git/info//sparse-checkout -test_git_path GIT_COMMON_DIR=bar remotes/bar bar/remotes/bar -test_git_path GIT_COMMON_DIR=bar branches/bar bar/branches/bar test_git_path GIT_COMMON_DIR=bar logs/refs/heads/master ba

[PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Git uses the config for remote/upstream information in favor of the previously-used .git/remotes/ and .git/branches/ for a decade now. Nothing in Git writes to these files any longer, and the most prominent user of .git/branches/ (Cogito) is long abandoned. It is time to start not only

[PATCH 04/11] remote: warn loud and clear when .git/remotes/ is *still* used

Since at least 75c384efb52 (Do not create $GIT_DIR/remotes/ directory anymore., 2006-12-19), we strongly prefer remotes and upstream branches to be specified in the config rather than .git/remotes/ and .git/branches/. For some time, we still retained backwards-compatibility. At some stage

[PATCH 09/11] PREVIEW: t5515: remove .git/remotes/ and .git/branches/ tests

We are about to remove support for the long-obsolete .git/remotes/ and .git/branches/ directories. Let's stop testing them, in preparation for that move. The bulk of this patch simply removes support files that are no longer needed. Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx

[PATCH 02/11] Documentation: really deprecate .git/remotes/ and .git/branches/

'name' can be given to these commands in place of - 'repository' argument. See the REMOTES section in - linkgit:git-fetch[1] for details. This mechanism is legacy + 'repository' argument. This mechanism is legacy and not likely to be found in modern reposi

[PATCH v2] push: document & test --force-with-lease with multiple remotes

Document & test for cases where there are two remotes pointing to the same URL, and a background fetch & subsequent `git push --force-with-lease` shouldn't clobber un-updated references we haven't fetched. Some editors like Microsoft's VSC have a feature to auto-fetch in the ba

Re: [PATCH] push: document & test --force-with-lease with multiple remotes

Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > Document & test for cases where there are two remotes pointing to the > same URL, and a background fetch & subsequent `git push > --force-with-lease` shouldn't clobber un-updated references we haven't > fetc

Re: [PATCH] push: document & test --force-with-lease with multiple remotes

On Sun, Apr 9, 2017 at 11:55 AM, Simon Ruderich wrote: > Hello, > > I like the documentation update and test. > > On Sat, Apr 08, 2017 at 11:41:00AM +, Ævar Arnfjörð Bjarmason wrote: >> [snip] >> >> ++ >> +Now when the background process runs `git fetch origin` the

Re: [PATCH] push: document & test --force-with-lease with multiple remotes

Hello, I like the documentation update and test. On Sat, Apr 08, 2017 at 11:41:00AM +, Ævar Arnfjörð Bjarmason wrote: > [snip] > > ++ > +Now when the background process runs `git fetch origin` the references > +on `origin-push` won't be updated, and thus commands like: > ++ > + git push

[PATCH] push: document & test --force-with-lease with multiple remotes

Document & test for cases where there are two remotes pointing to the same URL, and a background fetch & subsequent `git push --force-with-lease` shouldn't clobber un-updated references we haven't fetched. Some editors like Microsoft's VSC have a feature to auto-fetch in the ba

[PATCH 6/6] Rename 'remotes/' to 'r../' in heads

r {$yt + $linespc - 1}] set xvals {} set wvals {} +set newTags {} + set i -1 foreach tag $marks { incr i + set newTag $tag + regsub {^remotes} $newTag "r.." newTag + if {$i >= $ntags && $i < $ntags + $nheads && $tag eq

Re: Git log exclude/remotes/branches options not working as expected

Robert Dailey <rcdailey.li...@gmail.com> writes: > I have 3 remotes registered in my clone: > > origin, fork, drive > > When I do: > > $ git log --oneline --decorate --graph > > I only want to see branches under: > > refs/heads/* > refs/remotes/origin/

Git log exclude/remotes/branches options not working as expected

I have 3 remotes registered in my clone: origin, fork, drive When I do: $ git log --oneline --decorate --graph I only want to see branches under: refs/heads/* refs/remotes/origin/* I tried the following: $ git log --oneline --decorate --graph --simplify-by-decoration --remote=origin topic1

Re: [PATCH v2] completion: complete --delete, --move, and --remotes for git branch

[c]}" > case "$i" in > - -d|-m) only_local_ref="y" ;; > - -r) has_r="y" ;; > + -d|--delete|-m|--move) only_local_ref="y" ;; > + -r|--remotes) has_r="y" ;; >

[PATCH v2] completion: complete --delete, --move, and --remotes for git branch

;; - -r) has_r="y" ;; + -d|--delete|-m|--move) only_local_ref="y" ;; + -r|--remotes) has_r="y" ;; esac ((c++)) done @@ -1023,7 +1023,7 @@ _git_branch ()

Re: git push doesn't update the status with multiple remotes

Thanks for the quick reply. On 12/07/16 06:26, Johannes Sixt wrote: Am 11.07.2016 um 18:54 schrieb Garoe: I have a repository on github, a clone on my desktop and bare repo on a private server, in my desktop the remotes looks like this allg...@github.com:user/repo.git (fetch) allg

git push doesn't update the status with multiple remotes

Hello, I'm using git 1.9.1 in Ubuntu 14.04. I have a repository on github, a clone on my desktop and bare repo on a private server, in my desktop the remotes looks like this all g...@github.com:user/repo.git (fetch) all g...@github.com:user/repo.git (push) all u

Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

> On 21 Jun 2016, at 08:20, Matthieu Moy wrote: > > Antoine Queru writes: > >> However, in the last version, if we want to deny an website, >> including all schemes, we can blacklist the url without the >> scheme. For

Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

Antoine Queru writes: > However, in the last version, if we want to deny an website, > including all schemes, we can blacklist the url without the > scheme. For example, "pushBlacklist = github.com". By doing so, this > remote is not an url anymore, and it

Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

> > >> ... > >> > > > > Hello Rémi, thanks you for your input ! I'll make the appropriate changes > > and send a new version as soon as i can ! > > Hi Antoine, > > do you have an updated version already or is this the one I should look at? >

Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

>> ... >> > > Hello Rémi, thanks you for your input ! I'll make the appropriate changes > and send a new version as soon as i can ! Hi Antoine, do you have an updated version already or is this the one I should look at? http://article.gmane.org/gmane.comp.version-control.git/296445 Thanks,

Re: [PATCH] push: deny policy to prevent pushes to unwanted remotes.

>> Currently, a user wanting to prevent accidental pushes to the wrong remote >>> has to create a pre-push hook. >>> The feature offers a configuration to allow users to prevent accidental >>> pushes >>> to the wrong remote. The user may define a list o

Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

Matthieu Moy writes: >> + *easier and avoid confusion with a distant repo like 'github.com' Forgotten nit in previous message: s/distant/remote/. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in

Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

acklisted by the user pushes to http://m...@github.com ? > ... >> +remote.pushBlacklist:: >> +The list of remotes the user is forbidden to push to. >> +See linkgit:git-push[1] > > This is only true when remote.pushDefaultPolicy is "allow". It makes &

Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

emote` for all branches, and is overridden by > `branch..pushRemote` for specific branches. > > +remote.pushBlacklist:: > + The list of remotes the user is forbidden to push to. > + See linkgit:git-push[1] This is only true when remote.pushDefaultPolicy is "allow&qu

Re: [PATCH] push: deny policy to prevent pushes to unwanted remotes.

ok. > > The feature offers a configuration to allow users to prevent accidental > > pushes > > to the wrong remote. The user may define a list of whitelisted remotes, a > > list > > of blacklisted remotes and a default policy ("allow" or "deny").

Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

- Mail original - > Hi Antoine, > > Antoine Queru writes: > > [...] > > +For example, if we set up the configuration variables like this: > > + > > +--- > > +git config --add remote.pushBlacklist repository.com > > +git config

Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

Hi Antoine, Antoine Queru writes: > [...] > +For example, if we set up the configuration variables like this: > + > +--- > +git config --add remote.pushBlacklist repository.com > +git config --add remote.pushWhitelist

[RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

Currently, a user wanting to prevent accidental pushes to the wrong remote has to create a pre-push hook. The feature offers a configuration to allow users to prevent accidental pushes to the wrong remote. The user may define a list of whitelisted remotes, a list of blacklisted remotes

  1   2   3   >