e2_cmd_set_config(const char *key, const char *value)`::
- Emits a "def_param" message for a specific configuration
- setting IFF it matches the `GIT_TR2_CONFIG_PARAMS` pattern.
+ Emits a "def_param" message for a new or updated key/value
+
On Fri, Apr 05, 2019 at 02:03:06PM -0400, Jeff King wrote:
> Other than that, it's substantially the same as v1. I did move the
> public declaration of pack_basename() to the patch where it is added,
> rather than doing it later, which shows up in the range diff below.
Sorry, two things I noticed
On Thu, Apr 04, 2019 at 07:21:04PM -0400, Jeff King wrote:
> This patch series started with patch 12: I just wanted to drop the
> unused "force" parameter from update_info_refs().
> [...]
> And here we are. I present them here in reverse rabbit-hole order (which
> is also roughly important fixes f
Jeff King writes:
> This patch series started with patch 12: I just wanted to drop the
> unused "force" parameter from update_info_refs().
>
> But that made me look at its sibling update_info_packs(), and whether it
> ...
> And here we are. I present them here in reverse rabbit-hole order (which
characters is not quite enough: when both
the total and the throughput happen to change units from KiB to MiB in
the same update, then the progress bar's length is shortened by four
characters (or maybe even more!):
Receiving objects: 25% (2901/11603), 772.01 KiB | 733.00 KiB/s
Receiving objects
This patch series started with patch 12: I just wanted to drop the
unused "force" parameter from update_info_refs().
But that made me look at its sibling update_info_packs(), and whether it
needs its force parameter. It _does_ in fact do something (though I am
slightly doubtful that anybody actual
On Mon, Apr 01, 2019 at 04:15:42PM +0200, SZEDER Gábor wrote:
> > I don't think it could matter here, as these are meant to be smallish
> > strings, but I think we should get into the habit of using size_t
> > consistently to hold string lengths.
> >
> > It makes auditing for integer overflow pro
On Mon, Apr 01, 2019 at 09:30:00AM -0400, Jeff King wrote:
> On Mon, Apr 01, 2019 at 01:52:16PM +0200, SZEDER Gábor wrote:
>
> > diff --git a/progress.c b/progress.c
> > index 842db14b72..3149ecd460 100644
> > --- a/progress.c
> > +++ b/progress.c
> > @@ -84,6 +84,7 @@ static void display(struct p
On Mon, Apr 01, 2019 at 01:52:16PM +0200, SZEDER Gábor wrote:
> diff --git a/progress.c b/progress.c
> index 842db14b72..3149ecd460 100644
> --- a/progress.c
> +++ b/progress.c
> @@ -84,6 +84,7 @@ static void display(struct progress *progress, uint64_t n,
> const char *done)
> const char *t
characters is not quite enough: when both
the total and the throughput happen to change units from KiB to MiB in
the same update, then the progress bar's length is shortened by four
characters (or maybe even more!):
Receiving objects: 25% (2901/11603), 772.01 KiB | 733.00 KiB/s
Receiving objects
In protocol v0, when sending "shallow" lines, the server distinguishes
between lines caused by the remote repo being shallow and lines caused
by client-specified depth settings. Unless "--update-shallow" is
specified, there is a difference in behavior: refs that reach the fo
On Tue, Mar 26, 2019 at 10:53:26AM -0700, Jonathan Tan wrote:
> @@ -1625,6 +1649,7 @@ struct ref *fetch_pack(struct fetch_pack_args *args,
> {
> struct ref *ref_cpy;
> struct shallow_info si;
> + struct oid_array shallows_scratch = OID_ARRAY_INIT;
>
> fetch_pack_setup();
>
On Tue, Mar 26, 2019 at 10:37:06AM -0700, Jonathan Tan wrote:
> > Perhaps it's worth passing down the shallows array we get from the
> > caller of fetch_pack(). Something like the patch below (I think it is
> > never NULL, which means in your patch 1 you can simplify the conditional
> > for the BU
In protocol v0, when sending "shallow" lines, the server distinguishes
between lines caused by the remote repo being shallow and lines caused
by client-specified depth settings. Unless "--update-shallow" is
specified, there is a difference in behavior: refs that reach the fo
> On Mon, Mar 25, 2019 at 01:43:23PM -0700, Jonathan Tan wrote:
>
> > In protocol v0, when sending "shallow" lines, the server distinguishes
> > between lines caused by the remote repo being shallow and lines caused
> > by client-specified depth sett
On Tue, Mar 26, 2019 at 10:18 PM Jeff King wrote:
>
> On Tue, Mar 26, 2019 at 05:14:11PM +0700, Duy Nguyen wrote:
>
> > > That seems like the best we can do without the protocol change. And even
> > > if we adjust the protocol, we need some fallback behavior for existing
> > > v2 servers, so this
On Tue, Mar 26, 2019 at 05:14:11PM +0700, Duy Nguyen wrote:
> > That seems like the best we can do without the protocol change. And even
> > if we adjust the protocol, we need some fallback behavior for existing
> > v2 servers, so this is worth doing.
>
> Are people actually doing this (i.e. clon
d
> > by client-specified depth settings. Unless "--update-shallow" is
> > specified, there is a difference in behavior: refs that reach the former
> > "shallow" lines, but not the latter, are rejected. But in v2, the server
> > does not, and the client
On Mon, Mar 25, 2019 at 01:43:23PM -0700, Jonathan Tan wrote:
> In protocol v0, when sending "shallow" lines, the server distinguishes
> between lines caused by the remote repo being shallow and lines caused
> by client-specified depth settings. Unless "--update-shallow&q
In protocol v0, when sending "shallow" lines, the server distinguishes
between lines caused by the remote repo being shallow and lines caused
by client-specified depth settings. Unless "--update-shallow" is
specified, there is a difference in behavior: refs that reach the fo
characters is not quite enough: when both
the total and the throughput happen to change units from KiB to MiB in
the same update, then the progress bar's length is shortened by four
characters:
Receiving objects: 25% (2901/11603), 772.01 KiB | 733.00 KiB/s
Receiving objects: 27% (3133/11603), 1.4
Now that Unicode 12 has been announced[0], update the character
width tables to the new version.
[0] http://blog.unicode.org/2019/03/announcing-unicode-standard-version-120.html
Signed-off-by: Beat Bolli
---
unicode-width.h | 38 +-
1 file changed, 25
The prefix is always a NUL-terminated string, and we just end up passing
it along to parse_pathspec() anyway (which does not even take a length).
Signed-off-by: Jeff King
---
builtin/update-index.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/builtin/update-index.c b
Paul Mackerras writes:
> On Wed, Mar 13, 2019 at 01:06:32PM +0100, Alexander Shopov wrote:
>>
>>
>> Hello all,
>> I am resending the update of Bulgarina translation of Gitk that I last sent
>> here:
>> on 4 of March: https://marc.info/?l=git&m=15
From: Nickolai Belakovski
The output of git branch is modified to mark branches checked out in a
linked worktree with a "+" and color them in cyan (in contrast to the
current branch, which will still be denoted with a "*" and colored in green)
This is meant to communicate to the user that the br
On Wed, Mar 13, 2019 at 01:28:33PM +0100, Alexander Shopov wrote:
> Signed-off-by: Alexander Shopov
Thanks, applied.
Paul.
On Wed, Mar 13, 2019 at 01:06:32PM +0100, Alexander Shopov wrote:
>
>
> Hello all,
> I am resending the update of Bulgarina translation of Gitk that I last sent
> here:
> on 4 of March: https://marc.info/?l=git&m=155169580131311&w=2
> Any idea why it is not get
On Thu, Feb 21, 2019 at 4:44 AM Jeff King wrote:
>
> On Tue, Feb 19, 2019 at 05:31:22PM +0900, nbelakov...@gmail.com wrote:
>
> > From: Nickolai Belakovski
> >
> > The output of git branch is modified to mark branches checkout out in a
>
> s/checkout out/checked out/ ?
>
Yes, thanks
>
> > - s
не може да се анализира:"
-#: gitk:1740
+#: gitk:1744
msgid "No commit information available"
msgstr "Липсва информация за подавания"
-#: gitk:1903 gitk:1932 gitk:4334 gitk:9702 gitk:11274 gitk:11554
+#: gitk:1907 gitk:1936 gitk:4339 gitk:9789 gitk:11388 gitk:11668
Hello all,
I am resending the update of Bulgarina translation of Gitk that I last sent
here:
on 4 of March: https://marc.info/?l=git&m=155169580131311&w=2
Any idea why it is not getting merged? Perhaps I missed something or Paul
Mackerras,
maintaining gitk, is busy?
Anything that
Robert reported that core.excludesFile was not mentioned in the
git-clean docs[1]. This cleans that up by mentioning that in the docs.
[1]:
https://public-inbox.org/git/alpine.LFD.2.21.1902231328560.@localhost.localdomain/
Denton Liu (1):
git-clean.txt: specify core.excludesFile variable i
uot;Изходът от „git log“ не може да се анализира:"
-#: gitk:1740
+#: gitk:1744
msgid "No commit information available"
msgstr "Липсва информация за подавания"
-#: gitk:1903 gitk:1932 gitk:4334 gitk:9702 gitk:11274 gitk:11554
+#: gitk:1907 gitk:1936 gitk:4339 g
Update the docs for cat-file command. Some new formatting atoms added
because of reusing ref-filter code.
Actually, %(rest) is supported for all ref-filter commands, but it
has the meaning only for cat-file, that's why I decided to leave it here.
Signed-off-by: Olga Telez
On Tue, Feb 19, 2019 at 05:31:22PM +0900, nbelakov...@gmail.com wrote:
> From: Nickolai Belakovski
>
> The output of git branch is modified to mark branches checkout out in a
s/checkout out/checked out/ ?
> linked worktree with a "+" and color them in cyan (in contrast to the
> current branch,
From: Nickolai Belakovski
The output of git branch is modified to mark branches checkout out in a
linked worktree with a "+" and color them in cyan (in contrast to the
current branch, which will still be denoted with a "*" and colored in green)
This is meant to communicate to the user that the b
-update.sh
index 5b56b23166..1dd17fc03e 100755
--- a/t/lib-submodule-update.sh
+++ b/t/lib-submodule-update.sh
@@ -139,7 +139,7 @@ create_lib_submodule_repo () {
git revert HEAD &&
git checkout -b invalid_sub1 add_sub1 &&
- git update-i
Hi Elijah,
On Thu, 14 Feb 2019, Elijah Newren wrote:
> Since commit 8fe9c3f21dff (Merge branch 'en/rebase-merge-on-sequencer',
> 2019-02-06), --merge now uses the interactive backend (and matches its
> behavior) so there is no separate merge backend anymore. Fix an
> oversight in the docs that s
Since commit 8fe9c3f21dff (Merge branch 'en/rebase-merge-on-sequencer',
2019-02-06), --merge now uses the interactive backend (and matches its
behavior) so there is no separate merge backend anymore. Fix an
oversight in the docs that should have been updated with the previous
change.
Signed-off-b
-update.sh
index 5b56b23166..1dd17fc03e 100755
--- a/t/lib-submodule-update.sh
+++ b/t/lib-submodule-update.sh
@@ -139,7 +139,7 @@ create_lib_submodule_repo () {
git revert HEAD &&
git checkout -b invalid_sub1 add_sub1 &&
- git update-i
Hi Junio,
On Tue, 5 Feb 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Mon, 4 Feb 2019, SZEDER Gábor wrote:
> >
> >> Under Dscho's bugreport it looks like they already merged a one-liner
> >> fix, but how long will it take to tickle down to Travis CI, I have no
> >> idea.
>
Commit 0f086e6dca [1] counts the number of files updated by "git
checkout -- " command and prints it. Later on 536ec1839d [2]
adds the ability to remove files in "git checkout -- ". This is
still an update on worktree and should be reported to the user.
To prepare for such
Johannes Schindelin writes:
> On Mon, 4 Feb 2019, SZEDER Gábor wrote:
>
>> Under Dscho's bugreport it looks like they already merged a one-liner
>> fix, but how long will it take to tickle down to Travis CI, I have no
>> idea.
>
> Since the fix affected a Homebrew package, it was not so much abou
Hi Gábor,
On Mon, 4 Feb 2019, SZEDER Gábor wrote:
> Under Dscho's bugreport it looks like they already merged a one-liner
> fix, but how long will it take to tickle down to Travis CI, I have no
> idea.
Since the fix affected a Homebrew package, it was not so much about
trickling down to Travis,
patch thicket are waiting
(for the most part) to be upstreamed.
> > is to help Homebrew get `brew update --quiet` to work again. I just
> > opened a ticket to that end:
> >
> > https://github.com/Homebrew/brew/issues/5666
And this ticket has been closed with a fix! Yay!
On Mon, Feb 04, 2019 at 10:49:05AM +0100, Johannes Schindelin wrote:
> Hi Gábor,
>
> On Sat, 2 Feb 2019, SZEDER Gábor wrote:
>
> > Before installing the necessary dependencies, our OSX build jobs run
> > 'brew update --quiet'. This is problematic for two r
On Mon, Feb 04, 2019 at 10:26:29AM -0800, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > - This '--quiet' flag apparently broke overnight, resulting in
> > errored builds:
> > ...
> > I belive that this breakage will be noticed and fixed soon-ish, so
> > we could probably just w
SZEDER Gábor writes:
> Before installing the necessary dependencies, our OSX build jobs run
> 'brew update --quiet'. This is problematic for two reasons:
>
> - This '--quiet' flag apparently broke overnight, resulting in
> errored builds:
> ...
>
Hi Gábor,
On Sat, 2 Feb 2019, SZEDER Gábor wrote:
> Before installing the necessary dependencies, our OSX build jobs run
> 'brew update --quiet'. This is problematic for two reasons:
>
> - This '--quiet' flag apparently broke overnight, resulting in
>
Before installing the necessary dependencies, our OSX build jobs run
'brew update --quiet'. This is problematic for two reasons:
- This '--quiet' flag apparently broke overnight, resulting in
errored builds:
+brew update --quiet
==> Downloading
https
In addition to old %(trailers:only) it is now allowed to write
%(trailers:only=yes)
By itself this only gives (the not quite so useful) possibility to have
users change their mind in the middle of a formatting
string (%(trailers:only=true,only=false)). However, it gives users the
opportunity to
Nguyễn Thái Ngọc Duy writes:
> This was noticed by Ramsay [1] and I almost forgot.
>
> [1]
> http://public-inbox.org/git/419519f9-1b48-93bb-eead-eacf6b383...@ramsayjones.plus.com
Not forgetting is good ;-)
> diff --git a/repository.c b/repository.c
> --- a/repository.c
> +++
This was noticed by Ramsay [1] and I almost forgot.
[1]
http://public-inbox.org/git/419519f9-1b48-93bb-eead-eacf6b383...@ramsayjones.plus.com
Range-diff:
1: 4478671442 ! 1: 971d2839ab cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS
switch
@@ -2,12 +2,11 @@
cache.h: flip NO_
> This updates the patchset to support copy, as suggested by Andrey.
>
> Luke Diamand (2):
> git-p4: add failing test for shelved CL update involving move/copy
> git-p4: handle update of moved/copied files when updating a shelve
>
> git-p4.py| 2
From: Stefan Xenos
Implement the git change update command, which
are sufficient for constructing change graphs.
For example, to create a new change (a stable name) that refers to HEAD:
git change update -c HEAD
To record a rebase or amend in the change graph:
git change update -c -r
To
On Fri, Jan 18, 2019 at 10:16:33AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I just had to cc Brandon and manually look up his email address, which
> > made me wonder what ever happened to this patch. :)
>
> d076ad13 ("Merge branch 'bw/mailmap'", 2019-01-14)
Oh, heh. False alarm:
Jeff King writes:
> I just had to cc Brandon and manually look up his email address, which
> made me wonder what ever happened to this patch. :)
d076ad13 ("Merge branch 'bw/mailmap'", 2019-01-14)
Luke Diamand writes:
> This updates the patchset to support copy, as suggested by Andrey.
>
> Luke Diamand (2):
> git-p4: add failing test for shelved CL update involving move/copy
> git-p4: handle update of moved/copied files when updating a shelve
>
> git-p4.py
On Fri, Dec 07, 2018 at 02:22:25PM -0800, Jonathan Nieder wrote:
> Stefan Beller wrote:
>
> > What would be more of interest is why we'd be interested in this patch
> > as there is no commit/patch sent by Brandon with this email in gits history.
>
> I think there's an implicit assumption in this
edit(src)# src must be open before move
p4_move(src, dest) # opens for (move/delete, move/add)
diff --git a/t/t9807-git-p4-submit.sh b/t/t9807-git-p4-submit.sh
index 2ad3d801cc..099e5e079d 100755
--- a/t/t9807-git-p4-submit.sh
+++ b/t/t9807-
e() {
+ p4 -G changes -s shelved -m 1 //depot/... | marshal_dump change
+}
+
make_shelved_cl() {
test_commit "$1" >/dev/null &&
git p4 submit --origin HEAD^ --shelve >/dev/null &&
@@ -533,12 +537,59 @@ test_expect_success 'submit
This updates the patchset to support copy, as suggested by Andrey.
Luke Diamand (2):
git-p4: add failing test for shelved CL update involving move/copy
git-p4: handle update of moved/copied files when updating a shelve
git-p4.py| 2 ++
t/t9807-git-p4-submit.sh | 57
>
> Updating a shelved P4 changelist where one or more files have
> been moved does not work. Add a test for this.
>
> The problem is that P4 requires a complete list of the files being
> changed, and move/rename only includes the _source_ in the case of
> updating a shelved changelist. This resu
There are no changes needed for 'submodule update'. The clones will be
per-worktree and all the support is already in place. Add a test to
make sure it actually works.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t2405-worktree-submodules.sh | 11 +++
1 file changed, 11 insertion
-p4-submit.sh b/t/t9807-git-p4-submit.sh
index c390af56ad..c4ddd28f41 100755
--- a/t/t9807-git-p4-submit.sh
+++ b/t/t9807-git-p4-submit.sh
@@ -546,7 +546,7 @@ test_expect_success 'submit --update-shelve' '
)
'
-test_expect_failure 'update a shelve involving a moved fi
hanges -s shelved -m 1 //depot/... | marshal_dump change
+}
+
make_shelved_cl() {
test_commit "$1" >/dev/null &&
git p4 submit --origin HEAD^ --shelve >/dev/null &&
@@ -533,12 +537,53 @@ test_expect_success 'submit --update-shelve' '
) &&
Eric Sunshine writes:
> On Sun, Jan 13, 2019 at 8:58 AM Luke Diamand wrote:
>> Updating a shelved P4 changelist where one or more of the files have
>> been moved does not work. Add a test for this.
>
> Perhaps this message could give more detail about the actual problem
> than the generic "does
with:
change=$(last_shelve) &&
> @@ -533,12 +539,53 @@ test_expect_success 'submit --update-shelve' '
> ) &&
> (
> cd "$cli" &&
> - change=$(p4 -G changes -s shelved -m 1 //depot/
-p4-submit.sh b/t/t9807-git-p4-submit.sh
index 08dc8d2caf..4d5ea9e64c 100755
--- a/t/t9807-git-p4-submit.sh
+++ b/t/t9807-git-p4-submit.sh
@@ -548,7 +548,7 @@ test_expect_success 'submit --update-shelve' '
)
'
-test_expect_failure 'update a shelve involving a moved fi
shelved -m 1 //depot/... | \
+ marshal_dump change)
+ echo $change
+}
+
make_shelved_cl() {
test_commit "$1" >/dev/null &&
git p4 submit --origin HEAD^ --shelve >/dev/null &&
@@ -533,12 +539,53 @@ test_expect_success 'submit --update-
Changes are described in CHANGES.
Contributions-by: Matthieu Moy
Contributions-by: William Stewart
Contributions-by: Ville Skyttä
Contributions-by: Dirk Olmes
Contributions-by: Björn Kautler
Contributions-by: Konstantin Ryabitsev
Contributions-by: Gareth Pye
Contributions-by: David Lazar
S
Commit abef9020e3 (sha1_file: convert sha1_object_info* to object_id,
2018-03-12) renamed the function to oid_object_info(), but missed some
comments which mention it.
Signed-off-by: Jeff King
---
builtin/cat-file.c | 6 +++---
builtin/pack-objects.c | 4 ++--
cache.h| 2 +-
> - git status --ignore-submodules=none
> + git status --ignore-submodules=none &&
> +
> + # also make sure this old setup does not regress
> + git submodule update --init --recursive >out 2>err &&
> + test_must_be_empty out &&
> + test_must_be_empty err
> '
>
> test_expect_success 'absorb the git dir in a nested submodule' '
Philip Oakley writes:
> On 14/12/2018 21:25, Anthony Sottile wrote:
>> Signed-off-by: Anthony Sottile
>> ---
>> Documentation/git-update-index.txt | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/git-update-i
x27;t.
It turns out that update_shallow() doesn't write pre-"want" shallow
information unless --update-shallow is set. But post-"want" shallow
information is always written regardless of --update-shallow. (So maybe
--update-shallow is not the best name for it, but that is an
On Sat, Dec 15, 2018 at 9:18 AM Philip Oakley wrote:
>
> On 14/12/2018 21:25, Anthony Sottile wrote:
> > Signed-off-by: Anthony Sottile
> > ---
> > Documentation/git-update-index.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
On 14/12/2018 21:25, Anthony Sottile wrote:
Signed-off-by: Anthony Sottile
---
Documentation/git-update-index.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-update-index.txt
b/Documentation/git-update-index.txt
index 1c4d146a4..9c03ca167 100644
As f178c13fda (Revert "Merge branch 'sb/submodule-core-worktree'",
2018-09-07) was produced shortly before a release, nobody asked for
a regression test to be included. Add a regression test that makes sure
that the invocation of `git submodule update` on old setups doesn
Signed-off-by: Anthony Sottile
---
Documentation/git-update-index.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-update-index.txt
b/Documentation/git-update-index.txt
index 1c4d146a4..9c03ca167 100644
--- a/Documentation/git-update-index.txt
+++ b
Stefan Beller writes:
> From: Junio C Hamano
>
> In a028a1930c (fetching submodules: respect `submodule.fetchJobs`
> config option, 2016-02-29), we made sure to keep the default behavior
> of a fetching at most one submodule at once when not setting the
> newly introduced `submodule.fetchJobs` c
On Thu, Dec 13, 2018 at 2:03 PM Stefan Beller wrote:
> In a028a1930c (fetching submodules: respect `submodule.fetchJobs`
> config option, 2016-02-29), we made sure to keep the default behavior
> of a fetching at most one submodule at once when not setting the
s/of a/of/
> newly introduced `submo
From: Junio C Hamano
In a028a1930c (fetching submodules: respect `submodule.fetchJobs`
config option, 2016-02-29), we made sure to keep the default behavior
of a fetching at most one submodule at once when not setting the
newly introduced `submodule.fetchJobs` config.
This regressed in 90efe595c
On Thu, Dec 13, 2018 at 6:17 AM Junio C Hamano wrote:
>
> Sjon Hortensius writes:
>
> > When switching to 2.20 our `git submodule update' (which clones
> > through ssh) broke because our ssh-server rejected the ~20
> > simultaneous connections the git-client makes
Sjon Hortensius writes:
> When switching to 2.20 our `git submodule update' (which clones
> through ssh) broke because our ssh-server rejected the ~20
> simultaneous connections the git-client makes. This seems to be caused
> by a (possibly unintended) change in
> https:
On Thu, Dec 13 2018, Sjon Hortensius wrote:
> When switching to 2.20 our `git submodule update' (which clones
> through ssh) broke because our ssh-server rejected the ~20
> simultaneous connections the git-client makes. This seems to be caused
> by a (possibly unintended)
When switching to 2.20 our `git submodule update' (which clones
through ssh) broke because our ssh-server rejected the ~20
simultaneous connections the git-client makes. This seems to be caused
by a (possibly unintended) change in
https://github.com/git/git/c
it" copy of the work accumulating in SVN (git version 2.9.5). I seek
> an efficient way to routinely (nightly?) update the git repo with new
> changes accumulating in SVN.
SubGit [1]
I've been using it to translate SVN repository with ~40K revisions,
producing ~25GB Git bare repo.
SubGit
icient way to routinely (nightly?) update the git repo with new
changes accumulating in SVN.
Most of what I have found on the web suggests that, when properly
configured, incremental update will be correctly accomplished by "git
svn fetch". My experience so far is that - while that will
icient way to routinely (nightly?) update the git repo with new
changes accumulating in SVN.
Most of what I have found on the web suggests that, when properly
configured, incremental update will be correctly accomplished by "git
svn fetch". My experience so far is that - while that will
This patch adds a --reset-hard option for the update command to hard
reset submodule(s) to the gitlink for the corresponding submodule in
the superproject. This feature is desired e.g. to be able to discard
recent changes in the entire hierarchy of the submodules after running
git reset
>
>> Took me some time to figure out
>> why I was getting
>>
>> fatal: bad value for update parameter
>>
>> after all my changes to the git-submodule.sh script after looking at
>an
>> example commit 42b491786260eb17d97ea9fb1c4b70075bc
On Fri, Dec 7, 2018 at 8:21 PM Yaroslav Halchenko wrote:
>
>
> On Fri, 07 Dec 2018, Yaroslav Halchenko wrote:
>
>
> > On Fri, 07 Dec 2018, Stefan Beller wrote:
> > > > the initial "git submodule update --reset-hard" is pretty much a
> > > &g
Hi,
On Fri, 7 Dec 2018, Brandon Williams wrote:
> On Fri, Dec 7, 2018 at 10:08 PM Junio C Hamano
> wrote:
> >
> > Stefan Beller writes:
> >
> > > On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder
> > > wrote:
> > >>
> > >> Brandon Williams wrote:
> > >>
> > >> > Signed-off-by: Brandon Williams
>
executes
update-index. Truly disabling backup log must be done with something
like
git -c core.backupLog=false update-index ...
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-update-index.txt | 3 +++
builtin/update-index.c | 7 +++
t/t2080-backup-log.sh
t fd = open(path, O_CREAT | O_WRONLY | O_APPEND, 0666);
+ if (fd == -1)
+ return error_errno(_("unable to open %s"), path);
+ if (write_in_full(fd, new_log->buf, new_log->len) < 0) {
+ close(fd);
+ return error_errno(_("un
"Robert P. J. Day" writes:
> Current "man git-add" emphasizes single letter interactive
> shortcut commands with "[]".
Not for me. These prefixes are instead painted in colors.
gt;> probably should have also been updated to note the stronger
>> incompatibility between git-am and directory rename detection. Update
>> it now.
>>
>> Signed-off-by: Elijah Newren
>> Signed-off-by: Johannes Sixt
>> ---
>> Documentation/git-r
Stefan Beller writes:
> As f178c13fda (Revert "Merge branch 'sb/submodule-core-worktree'",
> 2018-09-07) was produced shortly before a release, nobody asked for
> a regression test to be included. Add a regression test that makes sure
> that the invocation of `git
entation/git-add.txt
@@ -239,8 +239,8 @@ and type return, like this:
*** Commands ***
- 1: status 2: update 3: revert 4: add untracked
- 5: patch6: diff 7: quit 8: help
+ 1: [s]tatus 2: [u]pdate 3: [r]evert
On Sat, Dec 08 2018, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder wrote:
>>>
>>> Brandon Williams wrote:
>>>
>>> > Signed-off-by: Brandon Williams
>>> > ---
>>> > .mailmap | 1 +
>>> > 1 file changed, 1 insertion(+)
>>>
>>> I can confirm t
On Sat, Dec 8, 2018 at 7:09 AM Junio C Hamano wrote:
> If this were "Jonathan asked Brandon if we want to record an address
> we can reach him in our .mailmap file and sent a patch to add one",
Not sure about Jonathan, but I did.
> then the story is different, and I tend to agree with you that s
201 - 300 of 3805 matches
Mail list logo
