Re: [PATCH] t7406: submodule..update command must not be run from .gitmodules

Stefan Beller <sbel...@google.com> writes: > submodule..update can be assigned an arbitrary command via setting > it to "!command". When this command is found in the regular config, Git > ought to just run that command instead of other update mechanisms. > > Howeve

[PATCH] t7406: submodule..update command must not be run from .gitmodules

submodule..update can be assigned an arbitrary command via setting it to "!command". When this command is found in the regular config, Git ought to just run that command instead of other update mechanisms. However if that command is just found in the .gitmodules file, it is potentially

Re: [PATCH] t7406: submodule..update command must not be run from .gitmodules

Am 26.09.2017 um 20:54 schrieb Stefan Beller: +test_expect_success 'submodule update - command in .gitmodules is ignored' ' + test_when_finished "git -C super reset --hard HEAD^" && + + git -C super config -f .gitmodules submodule.submodule.update "!false&qu

[PATCH] t7406: submodule..update command must not be run from .gitmodules

submodule..update can be assigned an arbitrary command via setting it to "!command". When this command is found in the regular config, Git ought to just run that command instead of other update mechanisms. However if that command is just found in the .gitmodules file, it is potentially

Re: [PATCH] t7406: submodule..update command must not be run from .gitmodules

Johannes Sixt writes: >> +test_when_finished "git -C super reset --hard HEAD^" && >> + >> +write_script must_not_run.sh <<-EOF && >> +>$TEST_DIRECTORY/bad >> +EOF > > I am pretty confident that this does not test what you intend to > test. Notice that

Re: [PATCH] t7406: submodule..update command must not be run from .gitmodules

Am 26.09.2017 um 00:50 schrieb Stefan Beller: submodule..update can be assigned an arbitrary command via setting it to "!command". When this command is found in the regular config, Git ought to just run that command instead of other update mechanisms. However if that command is

Re: [PATCH] Documentation: consolidate submodule..update

Brandon Williams <bmw...@google.com> writes: >> +The method by which a submodule is updated by 'git submodule update', >> +which is the only affected command, others such as >> +'git checkout --recurse-submodules' are unaffected. It exists for >> +

Re: [PATCH] t7406: submodule..update command must not be run from .gitmodules

Stefan Beller wrote: > submodule..update can be assigned an arbitrary command via setting > it to "!command". When this command is found in the regular config, Git > ought to just run that command instead of other update mechanisms. > > However if that command is just

Re: [PATCH] Documentation: consolidate submodule..update

e. > >> all wrong, > > Care to spell out this bold claim? In the state of "master", "man git-config" tells me that [submodule ""] update = ... sets the "default update procedure for a submodule". It suggests that I r

[PATCH] t7406: submodule..update command must not be run from .gitmodules

submodule..update can be assigned an arbitrary command via setting it to "!command". When this command is found in the regular config, Git ought to just run that command instead of other update mechanisms. However if that command is just found in the .gitmodules file, it is potentially

Re: [PATCH] Documentation: consolidate submodule..update

On Mon, Sep 25, 2017 at 3:22 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: > Stefan Beller wrote: >> On Mon, Sep 25, 2017 at 12:17 PM, Brandon Williams <bmw...@google.com> wrote: >>> On 09/25, Stefan Beller wrote: > >>>> Have one place to exp

Re: [PATCH] Documentation: consolidate submodule..update

Stefan Beller wrote: > On Mon, Sep 25, 2017 at 12:17 PM, Brandon Williams <bmw...@google.com> wrote: >> On 09/25, Stefan Beller wrote: >>> Have one place to explain the effects of setting submodule..update >>> instead of two. >>> >>&g

Re: [PATCH] Documentation: consolidate submodule..update

On Mon, Sep 25, 2017 at 12:17 PM, Brandon Williams <bmw...@google.com> wrote: > On 09/25, Stefan Beller wrote: >> Have one place to explain the effects of setting submodule..update >> instead of two. >> >> Signed-off-by: Stefan Beller <sbel...@google.com>

Re: [PATCH] t7406: submodule..update command must not be run from .gitmodules

Stefan Beller wrote: > submodule..update can be assigned an arbitrary command via setting > it to "!command". When this command is found in the regular config, Git > ought to just run that command instead of other update mechanisms. > > However if that command is just

[PATCH] t7406: submodule..update command must not be run from .gitmodules

submodule..update can be assigned an arbitrary command via setting it to "!command". When this command is found in the regular config, Git ought to just run that command instead of other update mechanisms. However if that command is just found in the .gitmodules file, it is potentially

Re: [PATCH] Documentation: consolidate submodule..update

On 09/25, Stefan Beller wrote: > Have one place to explain the effects of setting submodule..update > instead of two. > > Signed-off-by: Stefan Beller <sbel...@google.com> > --- > >> I disagree. Actually, I think the git-config(1) blurb could just > >> p

[PATCH] Documentation: consolidate submodule..update

Have one place to explain the effects of setting submodule..update instead of two. Signed-off-by: Stefan Beller <sbel...@google.com> --- >> I disagree. Actually, I think the git-config(1) blurb could just >> point here, and that the text here ought to be clear about what >

[RFC PATCH 2/8] commit: move code to update HEAD to libgit

From: Phillip Wood Signed-off-by: Phillip Wood --- builtin/commit.c | 31 +++ sequencer.c | 39 ++- sequencer.h | 2 ++ 3 files changed, 47 insertions(+), 25

[PATCH v3 21/21] packed-backend.c: rename a bunch of things and update comments

()` → `sort_snapshot()` * `read_packed_refs()` → `create_snapshot()` * `validate_packed_ref_cache()` → `validate_snapshot()` * `get_packed_ref_cache()` → `get_snapshot()` * Renamed local variables and struct members accordingly. Also update a bunch of comments to reflect the renaming and the accumulated

Re: [PATCHv2] Documentation/config: clarify the meaning of submodule..update

>> 1 file changed, 8 insertions(+), 4 deletions(-) >> >> Jonathan writes: > >>> You'll want to update Documentation/gitmodules.txt, too. >> >> No. /grumpycat >> >> It should already be fine, as I read it as if it is only relevant to >> &qu

[PATCH v2 6/9] perf/run: update get_var_from_env_or_config() for subsections

As we will set some config options in subsections, let's teach get_var_from_env_or_config() to get the config options from the subsections if they are set there. Signed-off-by: Christian Couder --- t/perf/run | 32 1 file changed, 20

Re: [PATCHv2] Documentation/config: clarify the meaning of submodule..update

Stefan Beller wrote: > Reported-by: Lars Schneider <larsxschnei...@gmail.com> > Signed-off-by: Stefan Beller <sbel...@google.com> > --- > Documentation/config.txt | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) > > Jonathan writes: >&

[PATCHv2] Documentation/config: clarify the meaning of submodule..update

With more commands (that potentially change a submodule) paying attention to submodules as well as the recent discussion[1] on submodule..update, let's spell out that submodule..update is strictly to be used for configuring the "submodule update" command and not to be obeyed by othe

Re: [PATCH] Documentation/config: clarify the meaning of submodule..update

Hi, Stefan Beller wrote: > With more commands (that potentially change a submodule) paying attention > to submodules as well as the recent discussion[1] on submodule..update, > let's spell out that submodule..update is strictly to be used > for configuring the "submodul

[PATCH] Documentation/config: clarify the meaning of submodule..update

With more commands (that potentially change a submodule) paying attention to submodules as well as the recent discussion[1] on submodule..update, let's spell out that submodule..update is strictly to be used for configuring the "submodule update" command and not to be obeyed by othe

[PATCH v8 07/12] update-index: add fsmonitor support to update-index

Add support in update-index to manually add/remove the fsmonitor extension via --[no-]fsmonitor flags. Add support in update-index to manually set/clear the fsmonitor valid bit via --[no-]fsmonitor-valid flags. Signed-off-by: Ben Peart <benpe...@microsoft.com> --- builtin/update-index.

[PATCH v8 03/12] update-index: add a new --force-write-index option

-index) to update-index that will ensure the index is written out even if the cache_changed flag is not set. Signed-off-by: Ben Peart <benpe...@microsoft.com> --- builtin/update-index.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/builtin/update-index.c b/builtin/

Re: [PATCH v3 0/4] filter-branch: support for incremental update + fix for ancient tag format

Ian Campbell writes: > Travis is happy and the dt reconvert looks sensible (only took 60 hours > ;-)). Good. > Don't know if this is useful to your workflow but: > > The following changes since commit 4384e3cde2ce8ecd194202e171ae16333d241326: > >   Git 2.14 (2017-08-04

Re: [PATCH v3 0/4] filter-branch: support for incremental update + fix for ancient tag format

On Fri, 2017-09-22 at 13:42 +0900, Junio C Hamano wrote: > Ian Campbell writes: > > > This is the third version of my patches to add incremental support to > > git-filter-branch. Since the last time I have replaced `git mktag -- > > allow-missing-tagger` with `git

Re: [PATCH v3 0/4] filter-branch: support for incremental update + fix for ancient tag format

Ian Campbell writes: > This is the third version of my patches to add incremental support to > git-filter-branch. Since the last time I have replaced `git mktag -- > allow-missing-tagger` with `git hash-object -t tag -w --stdin`. > > I've force pushed to [1] (Travis is still

[PATCH v3 0/4] filter-branch: support for incremental update + fix for ancient tag format

This is the third version of my patches to add incremental support to git-filter-branch. Since the last time I have replaced `git mktag -- allow-missing-tagger` with `git hash-object -t tag -w --stdin`. I've force pushed to [1] (Travis is still running) and have set off the process of

Re: [PATCH v7 03/12] update-index: add a new --force-write-index option

2nd bit (and then add the logic to set >> that bit every time a fsmonitor change was made) but I don't see that >> it really buys us anything useful. The force write flag in >> update-index is off by default and the only scenario we have that >> someone would set it is for test

Re: [PATCH v7 03/12] update-index: add a new --force-write-index option

r reading a few paragraphs, at which point I rewound and started reading from the beginning, and it was crystal clear." > Yes, I suppose we _could_ add a 2nd bit (and then add the logic to set > that bit every time a fsmonitor change was made) but I don't see that > it really buys

Re: [PATCH v7 03/12] update-index: add a new --force-write-index option

't see that it really buys us anything useful. The force write flag in update-index is off by default and the only scenario we have that someone would set it is for test cases where the perf of writing out the index when it is not needed just doesn't matter. The challenge came when it wa

Re: [PATCH v7 03/12] update-index: add a new --force-write-index option

Ben Peart writes: > Lets see how my ascii art skills do at describing this: Your ascii art is fine. If you said upfront that the capital letters signify points in time, lower letters are file-touching events, and time flows from left to right, it would have been perfect ;-)

Re: [PATCH v7 03/12] update-index: add a new --force-write-index option

On 9/20/2017 1:47 AM, Junio C Hamano wrote: Ben Peart writes: + OPT_SET_INT(0, "force-write-index", _write, + N_("write out the index even if is not flagged as changed"), 1), Hmph. The only time this makes difference is when

Re: [PATCH v7 03/12] update-index: add a new --force-write-index option

Ben Peart writes: > + OPT_SET_INT(0, "force-write-index", _write, > + N_("write out the index even if is not flagged as > changed"), 1), Hmph. The only time this makes difference is when the code forgets to mark active_cache_changed even

[PATCH v7 03/12] update-index: add a new --force-write-index option

-index) to update-index that will ensure the index is written out even if the cache_changed flag is not set. Signed-off-by: Ben Peart <benpe...@microsoft.com> --- builtin/update-index.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/builtin/update-index.c b/builtin/

[PATCH v7 07/12] update-index: add fsmonitor support to update-index

Add support in update-index to manually add/remove the fsmonitor extension via --[no-]fsmonitor flags. Add support in update-index to manually set/clear the fsmonitor valid bit via --[no-]fsmonitor-valid flags. Signed-off-by: Ben Peart <benpe...@microsoft.com> --- builtin/update-index.

Re: [PATCH] doc: update information about windows build

On Monday 18 September 2017 12:32 AM, Phillip Wood wrote: May be the Windows build exit with failure on other repos rather than saying it passes? I'm not quite sure what you're asking. If the tests aren't run it needs to look like a pass or everyone's branches would be marked as failing on

[RFC PATCH 4/5] branch: introduce dont_fail parameter for update validation

This parameter allows the branch update validation function to optionally return a flag specifying the reason for failure, when requested. This allows the caller to know why it was about to die. This allows more useful error messages to be given to the user when trying to rename a branch

[PATCH v2 21/21] packed-backend.c: rename a bunch of things and update comments

()` → `sort_snapshot()` * `read_packed_refs()` → `create_snapshot()` * `validate_packed_ref_cache()` → `validate_snapshot()` * `get_packed_ref_cache()` → `get_snapshot()` * Renamed local variables and struct members accordingly. Also update a bunch of comments to reflect the renaming and the accumulated

Re: [PATCH] doc: update information about windows build

On 17/09/17 14:42, Kaartic Sivaraam wrote: On Sun, 2017-09-17 at 14:24 +0100, Phillip Wood wrote: From that commit: diff --git a/ci/run-windows-build.sh b/ci/run-windows-build.sh new file mode 100755 index 0..4e3a50b60 --- /dev/null +++ b/ci/run-windows-build.sh @@ -0,0 +1,74 @@

Re: [PATCH] doc: update information about windows build

On Sun, 2017-09-17 at 14:24 +0100, Phillip Wood wrote: > > From that commit: > diff --git a/ci/run-windows-build.sh b/ci/run-windows-build.sh > new file mode 100755 > index 0..4e3a50b60 > --- /dev/null > +++ b/ci/run-windows-build.sh > @@ -0,0 +1,74 @@ > +#!/usr/bin/env bash > +# > +#

Re: [PATCH] doc: update information about windows build

On 17/09/17 06:28, Kaartic Sivaraam wrote: 029aeeed5 (travis-ci: build and test Git on Windows, 2017-03-24) added support for testing the git build for Windows. So, update the documentation and the example used in it. From that commit: diff --git a/ci/run-windows-build.sh b/ci/run-windows

[PATCH v2 0/4] filter-branch: support for incremental update + fix for ancient tag format

This is the second version of my patches to add incremental support to git-filter-branch. Since the last time I have: * addressed the review feedback (see changelog embedded in final patch) * switched to using the (newly introduced) `--allow-missing-tagger` option to `git mktag` to allow

[PATCH] doc: update information about windows build

029aeeed5 (travis-ci: build and test Git on Windows, 2017-03-24) added support for testing the git build for Windows. So, update the documentation and the example used in it. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> --- Documentation/SubmittingPatches | 5 +++--

[PATCH v6 03/12] update-index: add a new --force-write-index option

-index) to update-index that will ensure the index is written out even if the cache_changed flag is not set. Signed-off-by: Ben Peart <benpe...@microsoft.com> --- builtin/update-index.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/builtin/update-index.c b/builtin/

[PATCH v6 07/12] update-index: add fsmonitor support to update-index

Add support in update-index to manually add/remove the fsmonitor extension via --fsmonitor/--no-fsmonitor flags Signed-off-by: Ben Peart <benpe...@microsoft.com> --- builtin/update-index.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/builtin/update-index.c b/b

Re: [PATCH 20/20] packed-backend.c: rename a bunch of things and update comments

e()` → `get_snapshot()` > * Renamed local variables and struct members accordingly. > > Also update a bunch of comments to reflect the renaming and the > accumulated changes that the code has undergone. > > Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu> I have skimmed this series and it looks good. Thanks, Stefan

[PATCH 20/20] packed-backend.c: rename a bunch of things and update comments

()` → `sort_snapshot()` * `read_packed_refs()` → `create_snapshot()` * `validate_packed_ref_cache()` → `validate_snapshot()` * `get_packed_ref_cache()` → `get_snapshot()` * Renamed local variables and struct members accordingly. Also update a bunch of comments to reflect the renaming and the accumulated

Re: [PATCH v4 0/4] Rerolling ma/split-symref-update-fix

On Sat, Sep 09, 2017 at 08:57:14AM +0200, Martin Ågren wrote: > > I'll take Peff's hint, tweak/add comments for correctness and symmetry > > with the previous patch and add an if-BUG for symmetry. > > Here's a reroll of ma/split-symref-update-fix. The first three patches >

[PATCH v4 0/4] Rerolling ma/split-symref-update-fix

> I'll take Peff's hint, tweak/add comments for correctness and symmetry > with the previous patch and add an if-BUG for symmetry. Here's a reroll of ma/split-symref-update-fix. The first three patches are v3 plus Michael's Reviewed-By. The fourth is the conceptual fix of adding `r

[PATCH v2 09/11] files_ref_store: use a transaction to update packed refs

aggerty <mhag...@alum.mit.edu> --- refs/files-backend.c | 132 +-- t/t1404-update-ref-errors.sh | 4 +- 2 files changed, 103 insertions(+), 33 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index 2700e3b5d5..29eb5e826f 100644 --- a/refs/f

Re: [PATCH 08/10] files_ref_store: use a transaction to update packed refs

On Fri, Sep 08, 2017 at 02:44:57PM +0200, Michael Haggerty wrote: > > That means we're holding the packed-refs lock for a slightly longer > > period. I think this could mean worse lock contention between otherwise > > unrelated transactions over the packed-refs file. I wonder if the > >

Re: [PATCH 08/10] files_ref_store: use a transaction to update packed refs

rue. `files_pack_refs()` does the following: 1. Lock the `packed-refs` file. 2. Start a packed ref-store transaction. 3. Iterate over the loose ref cache. For each reference that should be packed: * add it to the packed-refs transaction as an update to set it to the loose value (without speci

MICROSOFT VERIFICATION UPDATE

MICROSOFT VERIFICATION UPDATE Geachte klant, Lees en volg de instructies om uw Microsoft Privacy te beschermen. Als onderdeel van onze inspanningen om uw ervaring te verbeteren in onze consumentendiensten, updaten we de Microsoft Services Agreement en de Microsoft Privacy Statement. We

Re: [PATCH 08/10] files_ref_store: use a transaction to update packed refs

On Tue, Aug 29, 2017 at 10:20:32AM +0200, Michael Haggerty wrote: > First, the old code didn't obtain the `packed-refs` lock until > `files_transaction_finish()`. This means that a failure to acquire the > `packed-refs` lock (e.g., due to contention with another process) > wasn't detected until

[PATCH 04/10] update-index: fix cache entry leak in add_one_file()

When we fail to add the cache entry to the index, we end up just leaking the struct. We should follow the pattern of the early-return above and free it. Signed-off-by: Jeff King <p...@peff.net> --- builtin/update-index.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff

[PATCH 18/20] lockfile: update lifetime requirements in documentation

Now that the tempfile system we rely on has loosened the lifetime requirements for storage, we can adjust our documentation to match. Signed-off-by: Jeff King --- lockfile.h | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/lockfile.h

[PATCH 08/10] files_ref_store: use a transaction to update packed refs

aggerty <mhag...@alum.mit.edu> --- refs/files-backend.c | 132 +-- t/t1404-update-ref-errors.sh | 4 +- 2 files changed, 103 insertions(+), 33 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index 29c7c78602..4f4c47b9db 100644 --- a/refs/f

Re: Should rerere auto-update a merge resolution?

; > Having said that, I suspect that it may be a bug if this procedure > kept the original preimage. It should either remove it, or update > it to record the state before the ealier resolution was applied > (i.e. make the updated preimage identical to thisimage, so that a > corrected

Re: Should rerere auto-update a merge resolution?

Johannes Schindelin writes: > In my hands, I need to tell rerere to forget, *and then recreate the merge > conflict* before I can resolve it again and let rerere learn the new > resolution. I can believe that---that is how I originally desiged "forget" to behave.

Re: Should rerere auto-update a merge resolution?

t I did: > ... > After git rerere forget, I observe (check subdirectories in > .git/rr-cache/ whose timestamps are recent) that postimage gets > removed but preimage and thisimage stay. Having said that, I suspect that it may be a bug if this procedure kept the original preimage. It sh

Re: Should rerere auto-update a merge resolution?

Martin Langhoff writes: > - when I tell it to forget, won't it forget the pre-resolution state? I do not recall the details of what I did ;-) so I played around a bit. Here is what I did: git checkout master^0 git merge --no-ff --no-edit

Re: Should rerere auto-update a merge resolution?

Hi Martin, On Wed, 23 Aug 2017, Martin Langhoff wrote: > On Wed, Aug 23, 2017 at 4:34 PM, Junio C Hamano wrote: > > Between these two steps: > > > >> - I reset hard, retry the merge, using --no-commit, rerere applies what > >> it knows > >> - I fix things up, then commit >

Re: Should rerere auto-update a merge resolution?

On Wed, Aug 23, 2017 at 4:34 PM, Junio C Hamano wrote: > Between these two steps: > >> - I reset hard, retry the merge, using --no-commit, rerere applies what it >> knows >> - I fix things up, then commit > > You'd tell rerere to forget what it knows because it is wrong. Hi

Re: Should rerere auto-update a merge resolution?

Martin Langhoff writes: > Hi List! > > Let's say... > - git v2.9.4 > - rerere is enabled. > - I merge maint into master, resolve erroneously, commit > - I publish my merge in a temp branch, a reviewer points out my mistake > - I reset hard, retry the merge, using

Should rerere auto-update a merge resolution?

Hi List! Let's say... - git v2.9.4 - rerere is enabled. - I merge maint into master, resolve erroneously, commit - I publish my merge in a temp branch, a reviewer points out my mistake - I reset hard, retry the merge, using --no-commit, rerere applies what it knows - I fix things up, then

Re: [PATCH 1/2] Documentation/user-manual: update outdated example output

Martin Ågren writes: > Since commit f7673490 ("more terse push output", 2007-11-05), git push > has a completely different output format than the one shown in the user > manual for a non-fast-forward push. > > Signed-off-by: Martin Ågren > --- >

[PATCH 1/2] Documentation/user-manual: update outdated example output

Since commit f7673490 ("more terse push output", 2007-11-05), git push has a completely different output format than the one shown in the user manual for a non-fast-forward push. Signed-off-by: Martin Ågren --- I'd say it's "not very many read this and immediately tried

Re: [PATCH] pull: respect submodule update configuration

On 08/22, Stefan Beller wrote: > On Tue, Aug 22, 2017 at 7:50 AM, Lars Schneider > wrote: > > > > OK. I change my scripts to use ".active" and it seems to work nicely. > > > > I noticed one oddity, though: > > > > If I clone a repo using `git clone --recursive ` then the

Re: [PATCH] pull: respect submodule update configuration

On Tue, Aug 22, 2017 at 7:50 AM, Lars Schneider wrote: > > OK. I change my scripts to use ".active" and it seems to work nicely. > > I noticed one oddity, though: > > If I clone a repo using `git clone --recursive ` then the local > Git config of the repo gets the

Re: [PATCH] pull: respect submodule update configuration

y. >>>>> >>>>> I am also curious. Isn't this the same strategy we are using in other >>>>> places? >>>>> >>>> >>>> I dislike it because the UX feels crude. When reading the documentation, >>>> it see

Re: [PATCH] pull: respect submodule update configuration

well. >> >> (B) That may hint at another (UX) bug. >> >> The test case there uses "git submodule update --init". >> The init flag will set all submodules to active. >> >> Maybe you want >> >> git config submodule.active ":(e

[GSoC] Update: Week 14

tests which the patch is currently failing at. The current status of the patch can be viewed at [2]. * update: porting this subcommand is already underway, and porting of the functions is_tip_reachable() and fetch_in_submodule() as completed. * patches: a smaller patch series is floated on

Re: [PATCH] pull: respect submodule update configuration

laces? > >>> > >> > >> I dislike it because the UX feels crude. When reading the documentation, > >> it seems to me as if submodule. can be one of the following > >> > >>(none, checkout, rebase, merge, !) > >> > >> This is

Re: [PATCH] pull: respect submodule update configuration

ng the documentation, >> it seems to me as if submodule. can be one of the following >> >>(none, checkout, rebase, merge, !) >> >> This is perfect for "submodule-update", whose primary goal is >> to update submodules *somehow*. However other commands &

Re: [PATCH] pull: respect submodule update configuration

gt; I am also curious. Isn't this the same strategy we are using in other >> places? >> > > I dislike it because the UX feels crude. When reading the documentation, > it seems to me as if submodule. can be one of the following > >(none, checkout, rebase, merge,

Re: [PATCH] pull: respect submodule update configuration

UX feels crude. When reading the documentation, it seems to me as if submodule. can be one of the following (none, checkout, rebase, merge, !) This is perfect for "submodule-update", whose primary goal is to update submodules *somehow*. However other commands git rebase -

Re: [PATCH] pull: respect submodule update configuration

On Fri, Aug 18, 2017 at 11:24:47PM -0700, Junio C Hamano wrote: > Stefan Beller <sbel...@google.com> writes: > > > From: Lars Schneider <larsxschnei...@gmail.com> > > > > Do not override the submodule configuration in the call to update > >

Re: [PATCH] pull: respect submodule update configuration

Stefan Beller <sbel...@google.com> writes: > From: Lars Schneider <larsxschnei...@gmail.com> > > Do not override the submodule configuration in the call to update > the submodules, but give a weaker default. > > Reported-by: Lars Schneider <larsxschnei...@gmail.co

Re: [PATCH] pull: respect submodule update configuration

Stefan Beller writes: > On Fri, Aug 18, 2017 at 3:04 PM, Stefan Beller wrote: >> From: Lars Schneider > > eh, that is what I get for amending to Lars patch. Sorry, I do not understand this remark. If you started from a patch

Re: [PATCH] pull: respect submodule update configuration

On Fri, Aug 18, 2017 at 3:04 PM, Stefan Beller wrote: > From: Lars Schneider eh, that is what I get for amending to Lars patch.

[PATCH] pull: respect submodule update configuration

From: Lars Schneider <larsxschnei...@gmail.com> Do not override the submodule configuration in the call to update the submodules, but give a weaker default. Reported-by: Lars Schneider <larsxschnei...@gmail.com> Signed-off-by: Stefan Beller <sbel...@google.com> --- Pe

Re: [PATCH v2] update revisions doc for quoting in ':/' notation

ryenus writes: > To make sure the `` in `:/` is seen as one search string, > one should quote/escape `` properly. > > Especially, the example given in the manual `:/fix nasty bug` does not > work because of missing quotes when used in shell. A note about > quoting/escaping is

[PATCH v2] update revisions doc for quoting in ':/' notation

To make sure the `` in `:/` is seen as one search string, one should quote/escape `` properly. Especially, the example given in the manual `:/fix nasty bug` does not work because of missing quotes when used in shell. A note about quoting/escaping is added along with a working example, however,

[GSoC] Update: Week-13

rs as well. The current status of the patch is pushed on github as well, and can be viewed at:[2] Since the rest of the patches were almost the same as that in the previous update(except for the 'summary' patch, which was last updated after Christian's review), the haven't been uploaded again to avoid

[PATCH 0/2] filter-branch: support for incremental update + fix for ancient tag format

Hi, I've long (since 2013, urk!) been carrying these two changes to git- filter-branch in the split out devicetree source tree[0] which extracts all the device tree sources from the Linux kernel source tree. I think it's about time I sent them here, sorry for the rather extreme delay! I've

[GSoC][PATCH 00/13] Update: Week-12

SUMMARY OF MY PROJECT: Git submodule subcommands are currently implemented by using shell script 'git-submodule.sh'. There are several reasons why we'll prefer not to use the shell script. My project intends to convert the subcommands into C code, thus making them builtins. This will increase

[PATCH v2 05/15] submodule--helper: don't overlay config in update-clone

Don't rely on overlaying the repository's config on top of the submodule-config, instead query the repository's config directly for the url and the update strategy configuration. Signed-off-by: Brandon Williams <bmw...@google.com> --- builtin/submodule--helper.

[GSoC][PATCH 00/13] Update: Week-11

his, I'll try to resolve the issues regarding it. In the patches following the update, I have addressed this issue as well. * add: Porting of this subcommand is still underway and will be working on to completely port this subcommand. A complete build report of these series of patches is

Re: [GSoC][PATCH v2 00/13] Update: Week 10

On 07/30, Prathamesh Chavan wrote: > Thank you Brandon Williams for reviewing the previous > patch series. > Also, I'm sorry for repling late to your reviews. The main reason was > to give sufficient time to prepare the next version of each patch as > suggested. No worries,

Re: [PATCH/RFC] setup: update error message to be more meaningful

On Sun, 2017-07-30 at 16:17 +0530, Kaartic Sivaraam wrote: > On Sat, 2017-07-29 at 09:10 -0700, Junio C Hamano wrote: > > We perhaps need to somehow make sure new users won't be led to the > > misunderstanding. Improving our documentation is a good first step. > > That's something I could help

Re: [PATCH/RFC] setup: update error message to be more meaningful

On Sat, 2017-07-29 at 09:10 -0700, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > > That's interesting. In that case, I'll go with the suggested statement, > > happily! > > It is not interesting at all. It actually is disturbing that you > had the notion

[GSoC][PATCH v2 00/13] Update: Week 10

Thank you Brandon Williams for reviewing the previous patch series. Also, I'm sorry for repling late to your reviews. The main reason was to give sufficient time to prepare the next version of each patch as suggested. The changes made in each patch are enlisted in the patch

Re: [PATCH/RFC] setup: update error message to be more meaningful

Kaartic Sivaraam writes: > On Fri, 2017-07-28 at 20:53 -0700, Junio C Hamano wrote: >> Kaartic Sivaraam writes: >> >> > Though the message seems to be most fitting one, I'm a little reluctant >> > to use it as it "might" create a

[PATCH] setup: update error message to be more meaningful

The error message shown when a flag is found when expecting a filename wasn't clear as it didn't communicate what was wrong using the 'suitable' words in *all* cases. $ git ls-files README.md test-file Correct case, $ git rev-parse README.md --flags

Re: [PATCH/RFC] setup: update error message to be more meaningful

On Fri, 2017-07-28 at 20:53 -0700, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > Though the message seems to be most fitting one, I'm a little reluctant > > to use it as it "might" create a wrong picture on the minds of the user > > making them think this

Re: [PATCH/RFC] setup: update error message to be more meaningful

Kaartic Sivaraam writes: > Though the message seems to be most fitting one, I'm a little reluctant > to use it as it "might" create a wrong picture on the minds of the user > making them think this would be the case in other cases too, which we > know is not true.

<    1   2   3   4   5   6   7   8   9   10   >