* [PATCH] submodules: allow empty working-tree dirs in merge/cherry-pick
From: David Turner @ 2016-11-07 18:31 UTC (permalink / raw)
To: git, sbeller; +Cc: David Turner
When a submodule is being merged or cherry-picked into a working
tree that already contains a corresponding empty directory, do not
record a conflict.
One situation where this bug appears is:
- Commit 1 adds a submodule
- Commit 2 removes that submodule and re-adds it into a subdirectory
(sub1 to sub1/sub1).
- Commit 3 adds an unrelated file.
Now the user checks out commit 1 (first deinitializing the submodule),
and attempts to cherry-pick commit 3. Previously, this would fail,
because the incoming submodule sub1/sub1 would falsely conflict with
the empty sub1 directory.
This patch ignores the empty sub1 directory, fixing the bug. We only
ignore the empty directory if the object being emplaced is a
submodule, which expects an empty directory.
Signed-off-by: David Turner <dturner@twosigma.com>
---
merge-recursive.c | 21 +++++++++++++++------
t/t3030-merge-recursive.sh | 4 ++--
t/t3426-rebase-submodule.sh | 3 ---
3 files changed, 17 insertions(+), 11 deletions(-)
Note that there are four calls to dir_in_way, and only two of them
have changed their semantics. This is because the merge code is quite
complicated, and I don't fully understand it. So I did not have time
to analyze the remaining calls to see whether they, too, should be
changed. For me, there are no test failures either way, indicating
that probably these cases are rare.
The reason behind the empty_ok parameter (as opposed to just always
allowing empy directories to be blown away) is found in t6022's 'pair
rename to parent of other (D/F conflicts) w/ untracked dir'. This
test would fail with an unconditional rename, because it wouldn't
generate the conflict file. It's not clear how important that
behavior is (I do not recall ever noticing the file~branch thing
before), but it seemed better to preserve it in case it was important.
diff --git a/merge-recursive.c b/merge-recursive.c
index 9041c2f..e64b48b 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -664,7 +664,13 @@ static char *unique_path(struct merge_options *o, const char *path, const char *
return strbuf_detach(&newpath, NULL);
}
-static int dir_in_way(const char *path, int check_working_copy)
+/**
+ * Check whether a directory in the index is in the way of an incoming
+ * file. Return 1 if so. If check_working_copy is non-zero, also
+ * check the working directory. If empty_ok is non-zero, also return
+ * 0 in the case where the working-tree dir exists but is empty.
+ */
+static int dir_in_way(const char *path, int check_working_copy, int empty_ok)
{
int pos;
struct strbuf dirpath = STRBUF_INIT;
@@ -684,7 +690,8 @@ static int dir_in_way(const char *path, int check_working_copy)
}
strbuf_release(&dirpath);
- return check_working_copy && !lstat(path, &st) && S_ISDIR(st.st_mode);
+ return check_working_copy && !lstat(path, &st) && S_ISDIR(st.st_mode) &&
+ !(empty_ok && is_empty_dir(path));
}
static int was_tracked(const char *path)
@@ -1062,7 +1069,7 @@ static int handle_change_delete(struct merge_options *o,
{
char *renamed = NULL;
int ret = 0;
- if (dir_in_way(path, !o->call_depth)) {
+ if (dir_in_way(path, !o->call_depth, 0)) {
renamed = unique_path(o, path, a_oid ? o->branch1 : o->branch2);
}
@@ -1195,7 +1202,7 @@ static int handle_file(struct merge_options *o,
remove_file(o, 0, rename->path, 0);
dst_name = unique_path(o, rename->path, cur_branch);
} else {
- if (dir_in_way(rename->path, !o->call_depth)) {
+ if (dir_in_way(rename->path, !o->call_depth, 0)) {
dst_name = unique_path(o, rename->path, cur_branch);
output(o, 1, _("%s is a directory in %s adding as %s instead"),
rename->path, other_branch, dst_name);
@@ -1704,7 +1711,8 @@ static int merge_content(struct merge_options *o,
o->branch2 == rename_conflict_info->branch1) ?
pair1->two->path : pair1->one->path;
- if (dir_in_way(path, !o->call_depth))
+ if (dir_in_way(path, !o->call_depth,
+ S_ISGITLINK(pair1->two->mode)))
df_conflict_remains = 1;
}
if (merge_file_special_markers(o, &one, &a, &b,
@@ -1862,7 +1870,8 @@ static int process_entry(struct merge_options *o,
oid = b_oid;
conf = _("directory/file");
}
- if (dir_in_way(path, !o->call_depth)) {
+ if (dir_in_way(path, !o->call_depth,
+ S_ISGITLINK(a_mode))) {
char *new_path = unique_path(o, path, add_branch);
clean_merge = 0;
output(o, 1, _("CONFLICT (%s): There is a directory with name %s in %s. "
diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh
index 470f334..be074a1 100755
--- a/t/t3030-merge-recursive.sh
+++ b/t/t3030-merge-recursive.sh
@@ -575,13 +575,13 @@ test_expect_success 'merge removes empty directories' '
test_must_fail test -d d
'
-test_expect_failure 'merge-recursive simple w/submodule' '
+test_expect_success 'merge-recursive simple w/submodule' '
git checkout submod &&
git merge remove
'
-test_expect_failure 'merge-recursive simple w/submodule result' '
+test_expect_sucess 'merge-recursive simple w/submodule result' '
git ls-files -s >actual &&
(
diff --git a/t/t3426-rebase-submodule.sh b/t/t3426-rebase-submodule.sh
index d5b896d..ebf4f5e 100755
--- a/t/t3426-rebase-submodule.sh
+++ b/t/t3426-rebase-submodule.sh
@@ -38,9 +38,6 @@ git_rebase_interactive () {
git rebase -i "$1"
}
-KNOWN_FAILURE_NOFF_MERGE_DOESNT_CREATE_EMPTY_SUBMODULE_DIR=1
-# The real reason "replace directory with submodule" fails is because a
-# directory "sub1" exists, but we reuse the suppression added for merge here
test_submodule_switch "git_rebase_interactive"
test_done
--
2.8.0.rc4.22.g8ae061a
^ permalink raw reply related
* Re: git submodule add broken (2.11.0-rc1): Cannot open git-sh-i18n
From: Stefan Beller @ 2016-11-07 17:56 UTC (permalink / raw)
To: Anthony Sottile; +Cc: git@vger.kernel.org
In-Reply-To: <CA+dzEBmP2aUit00ukJyQeg=iqUJJLVaovafo2gngf9MvEqZDPA@mail.gmail.com>
$ git --version
git version 1.8.5.6
$ if [ "$LATEST_GIT" = "1" ]; then
...
export PATH="/tmp/git:$PATH"
fi
....
make -j 8
...
$ git --version
git version 2.11.0-rc0
So you compile 2.11.0-rc0 yourself, but you do not install it, instead
the $PATH is pointed to /tmp/git instead, however the later calls fail with:
Can't open /home/travis/libexec/git-core/git-sh-i18n
which is where 1.8.5.6 is installed.
So you're running into an internationalization problem
between 2 very different versions of Git (1.8 seems to be ancient)
Not sure if i can offer advice except from
"Don't do that, instead install Git properly". ;)
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11
From: Paul Smith @ 2016-11-07 17:49 UTC (permalink / raw)
To: Jeff King; +Cc: Lars Schneider, git, tboegi, gitster
In-Reply-To: <20161107174559.t72vxxkckqdbxmbg@sigill.intra.peff.net>
On Mon, 2016-11-07 at 12:46 -0500, Jeff King wrote:
> Specifically I wanted to make sure that
>
> FOO = bar
> FOO =
> ifdef FOO
> ... something ...
> endif
>
> works as if FOO had never been set in the first place. Which it seems
> to, at least in GNU make (and that is the only one we support, for
> other reasons).
Yes, it will work. Confusingly, "ifdef" actually tests whether the
variable has a non-empty value, not whether it's defined:
> The 'ifdef' form takes the _name_ of a variable as its argument, not
> a reference to a variable. The value of that variable has a non-
> empty value, the TEXT-IF-TRUE is effective; otherwise, the TEXT-IF-
> FALSE, if any, is effective
*sigh* History...
^ permalink raw reply
* Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11
From: Jeff King @ 2016-11-07 17:46 UTC (permalink / raw)
To: Paul Smith; +Cc: Lars Schneider, git, tboegi, gitster
In-Reply-To: <1478540194.4171.19.camel@mad-scientist.net>
On Mon, Nov 07, 2016 at 12:36:34PM -0500, Paul Smith wrote:
> On Mon, 2016-11-07 at 12:26 -0500, Jeff King wrote:
> > I have in the back of my mind a fear that it is harder to unset a
> > make variable than it is to override it with a new value (which is
> > what you'd want to do here to turn openssl back on),
>
> It depends on what you mean by "unset".
>
> If you mean it as per the shell "unset" command, where the variable is
> completely forgotten as if it never was set at all, that's tricky. You
> have to use the "undefine" special command which was introduced in GNU
> make 3.82 (released in 2010).
>
> But if you just want to set the variable to the empty string, using
> "FOO=" works fine for that in all versions of make (GNU and otherwise)
> and using all the normal rules (command line override, etc.)
Specifically I wanted to make sure that
FOO = bar
FOO =
ifdef FOO
... something ...
endif
works as if FOO had never been set in the first place. Which it seems
to, at least in GNU make (and that is the only one we support, for other
reasons).
-Peff
^ permalink raw reply
* Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11
From: Paul Smith @ 2016-11-07 17:36 UTC (permalink / raw)
To: Jeff King, Lars Schneider; +Cc: git, tboegi, gitster
In-Reply-To: <20161107172617.tlcrpwbjy2w7aoyc@sigill.intra.peff.net>
On Mon, 2016-11-07 at 12:26 -0500, Jeff King wrote:
> I have in the back of my mind a fear that it is harder to unset a
> make variable than it is to override it with a new value (which is
> what you'd want to do here to turn openssl back on),
It depends on what you mean by "unset".
If you mean it as per the shell "unset" command, where the variable is
completely forgotten as if it never was set at all, that's tricky. You
have to use the "undefine" special command which was introduced in GNU
make 3.82 (released in 2010).
But if you just want to set the variable to the empty string, using
"FOO=" works fine for that in all versions of make (GNU and otherwise)
and using all the normal rules (command line override, etc.)
It's not easy to distinguish between a variable that is empty and one
that is actually not defined, in make, so it's a difference without a
distinction in almost all situations.
^ permalink raw reply
* git submodule add broken (2.11.0-rc1): Cannot open git-sh-i18n
From: Anthony Sottile @ 2016-11-07 17:27 UTC (permalink / raw)
To: git
Noticed as part of my automated tests here:
https://travis-ci.org/pre-commit/pre-commit/jobs/173957051
Minimal reproduction:
rm -rf /tmp/git /tmp/foo /tmp/bar
git clone git://github.com/git/git --depth 1 /tmp/git
pushd /tmp/git
make -j 8
popd
export PATH="/tmp/git:$PATH"
git init /tmp/foo
git init /tmp/bar
cd /tmp/foo
git submodule add /tmp/bar baz
Output:
$ rm -rf /tmp/git /tmp/foo /tmp/bar
$ git clone git://github.com/git/git --depth 1 /tmp/git
Cloning into '/tmp/git'...
remote: Counting objects: 3074, done.
remote: Compressing objects: 100% (2735/2735), done.
remote: Total 3074 (delta 249), reused 1871 (delta 215), pack-reused 0
Receiving objects: 100% (3074/3074), 6.38 MiB | 905.00 KiB/s, done.
Resolving deltas: 100% (249/249), done.
Checking connectivity... done.
$ pushd /tmp/git
/tmp/git /tmp
$ make -j 8
GIT_VERSION = 2.11.0-rc0
... lots of make output ...
$ popd
/tmp
$ export PATH="/tmp/git:$PATH"
$ git init /tmp/foo
warning: templates not found /home/asottile/share/git-core/templates
Initialized empty Git repository in /tmp/foo/.git/
$ git init /tmp/bar
warning: templates not found /home/asottile/share/git-core/templates
Initialized empty Git repository in /tmp/bar/.git/
$ cd /tmp/foo
$ git submodule add /tmp/bar baz
/tmp/git/git-submodule: 46: .: Can't open
/home/asottile/libexec/git-core/git-sh-i18n
$ echo $?
2
Thanks
Anthony
^ permalink raw reply
* Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11
From: Jeff King @ 2016-11-07 17:26 UTC (permalink / raw)
To: Lars Schneider; +Cc: git, tboegi, gitster
In-Reply-To: <8C67FF53-C26F-4993-908F-A5183C5E48D9@gmail.com>
On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote:
> Good point. I think I found an even easier way to achieve the same.
> What do you think about the patch below?
>
> [...]
>
> diff --git a/Makefile b/Makefile
> index 9d6c245..f53fcc9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1047,6 +1047,7 @@ ifeq ($(uname_S),Darwin)
> endif
> endif
> ifndef NO_APPLE_COMMON_CRYPTO
> + NO_OPENSSL = YesPlease
> APPLE_COMMON_CRYPTO = YesPlease
> COMPAT_CFLAGS += -DAPPLE_COMMON_CRYPTO
> endif
That is much simpler.
I have in the back of my mind a fear that it is harder to unset a make
variable than it is to override it with a new value (which is what you'd
want to do here to turn openssl back on), but I can't seem to come up
with a case that doesn't work. So I am probably misremembering, or just
thinking of something that used to be a problem long ago.
-Peff
^ permalink raw reply
* Re: git -C has unexpected behaviour
From: Johannes Schindelin @ 2016-11-07 16:54 UTC (permalink / raw)
To: Felix Nairz; +Cc: sbeller, git
In-Reply-To: <CADJspf+zqj2hHjD85dvt8Y4HKPViubvTzybbTq5mJDGCh2q1UQ@mail.gmail.com>
Hi Felix,
On Mon, 7 Nov 2016, Felix Nairz wrote:
> From what you are saying I can see that this expects as designed. It's
> confusing in the submodule case, but I get you don't want to add extra
> rules which slow down performance and mess with other people at the
> same time.
The "messing with other people" is the key point. There are most likely
other users than just me who use the fact that `git -C sub/directory/ ...`
works in a subdirectory of a checkout.
Ciao,
Johannes
^ permalink raw reply
* Re: Regarding "git log" on "git series" metadata
From: Josh Triplett @ 2016-11-07 16:11 UTC (permalink / raw)
To: Duy Nguyen
Cc: Jacob Keller, Junio C Hamano, Christian Couder, git,
Shawn O. Pierce, Jeff King, Mike Hommey
In-Reply-To: <CACsJy8BDySBWyp3iiLinRkBCew5FNXoQo7z9dMb6w6m9a5X=NA@mail.gmail.com>
On Mon, Nov 07, 2016 at 04:42:04PM +0700, Duy Nguyen wrote:
> On Mon, Nov 7, 2016 at 8:18 AM, Josh Triplett <josh@joshtriplett.org> wrote:
> > Once we have gitrefs, you have both alternatives: reachable (gitref) or
> > not reachable (gitlink).
> >
> > However, if you want some way to mark reachable objects as not
> > reachable, such as for a sparse checkout, external large-object storage,
> > or similar, then you can use a single unified mechanism for that whether
> > working with gitrefs, trees, or blobs.
>
> How? Whether an object reachable or not is baked in the definition (of
> either gitlink or gitref). I don't think you can have a "maybe
> reachable" type then rely on an external source to determine
> reachability,
You'd have various "reachable by default" entries in trees, including
trees, blobs, and gitrefs, and then have an external mechanism (likely
via .git/config) to say "ignore objects with these hashes/paths". For
instance, you might say "ignore all objects only reachable from the path
'assets/video/*' within a commit's tree". With the right set of client
and server extensions, you could then avoid downloading those objects.
^ permalink raw reply
* Re: [PATCH v4 08/14] i18n: add--interactive: mark edit_hunk_manually message for translation
From: Vasco Almeida @ 2016-11-07 16:04 UTC (permalink / raw)
To: git
Cc: Jiang Xin, Ævar Arnfjörð Bjarmason,
Jean-Noël AVILA, Jakub Narębski, David Aguilar,
Junio C Hamano
In-Reply-To: <20161010125449.7929-9-vascomalmeida@sapo.pt>
A Seg, 10-10-2016 às 12:54 +0000, Vasco Almeida escreveu:
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index 045b847..861f7b0 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -1058,6 +1058,30 @@ sub color_diff {
> } @_;
> }
>
> +my %edit_hunk_manually_modes = (
> + stage => N__(
> +"# If the patch applies cleanly, the edited hunk will immediately be
> +# marked for staging."),
> + stash => N__(
> +"# If the patch applies cleanly, the edited hunk will immediately be
> +# marked for stashing."),
> + reset_head => N__(
> +"# If the patch applies cleanly, the edited hunk will immediately be
> +# marked for unstaging."),
> + reset_nothead => N__(
> +"# If the patch applies cleanly, the edited hunk will immediately be
> +# marked for applying."),
> + checkout_index => N__(
> +"# If the patch applies cleanly, the edited hunk will immediately be
> +# marked for discarding"),
> + checkout_head => N__(
> +"# If the patch applies cleanly, the edited hunk will immediately be
> +# marked for discarding."),
> + checkout_nothead => N__(
> +"# If the patch applies cleanly, the edited hunk will immediately be
> +# marked for applying."),
> +);
> +
I think marking strings comment with '#' for translation is not the
best thing because there is a change that a translator will miss to
comment a line. I will change this to mark only the text and then, at
run time, prefix comment chars to that text.
> sub edit_hunk_manually {
> my ($oldtext) = @_;
>
> @@ -1065,22 +1089,21 @@ sub edit_hunk_manually {
> my $fh;
> open $fh, '>', $hunkfile
> or die sprintf(__("failed to open hunk edit file for
> writing: %s"), $!);
> - print $fh "# Manual hunk edit mode -- see bottom for a quick
> guide\n";
> + print $fh __("# Manual hunk edit mode -- see bottom for a
> quick guide\n");
Here too.
> print $fh @$oldtext;
> - my $participle = $patch_mode_flavour{PARTICIPLE};
> my $is_reverse = $patch_mode_flavour{IS_REVERSE};
> my ($remove_plus, $remove_minus) = $is_reverse ? ('-', '+') :
> ('+', '-');
> - print $fh <<EOF;
> -# ---
> -# To remove '$remove_minus' lines, make them ' ' lines (context).
> -# To remove '$remove_plus' lines, delete them.
> + print $fh sprintf(__(
> +"# ---
> +# To remove '%s' lines, make them ' ' lines (context).
> +# To remove '%s' lines, delete them.
> # Lines starting with # will be removed.
> -#
> -# If the patch applies cleanly, the edited hunk will immediately be
> -# marked for $participle. If it does not apply cleanly, you will be
> given
> +#\n"), $remove_minus, $remove_plus),
> +__($edit_hunk_manually_modes{$patch_mode}), __(
> +# TRANSLATORS: 'it' refers to the patch mentioned in the previous
> messages.
> +" If it does not apply cleanly, you will be given
> # an opportunity to edit again. If all lines of the hunk are
> removed,
> -# then the edit is aborted and the hunk is left unchanged.
> -EOF
> +# then the edit is aborted and the hunk is left unchanged.\n");
And here too.
Currently this joins the two sentences/parts in the same line like so
# If the patch applies cleanly, the edited hunk will immediately be
# marked for staging. If it does not apply cleanly, you will be given
# an opportunity to edit again. If all lines of the hunk are removed,
# then the edit is aborted and the hunk is left unchanged.
But since the translator translates each sentence separately, it is
hard to align them properly to not make lines too long. Hence I am
considering to break each sentence to start on its own line.
^ permalink raw reply
* git push remote syntax
From: Diggory Hardy @ 2016-11-07 13:49 UTC (permalink / raw)
To: git
Dear all,
One thing I find a little frustrating about git is that the syntax needed
differs by command. I wish the 'remote/branch' syntax was more universal:
> git pull myremote/somebranch
complains about the syntax; IMO it should either pull from that branch (and
merge if necessary) or complain instead that pulling from a different branch
is not supported (and suggest using merge).
> git push myremote/somebranch
should push there, i.e. be equivalent to
> git push myremote HEAD:somebranch
These are just some comments about how I think git could be made easier to
use. Apologies if the suggestions have already been discussed before.
Regards,
D Hardy
^ permalink raw reply
* Re: gitk: avoid obscene memory consumption
From: Markus Hitter @ 2016-11-07 13:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Stefan Beller, git@vger.kernel.org
In-Reply-To: <20161107041138.rnlzyuacoezsfwif@oak.ozlabs.ibm.com>
Am 07.11.2016 um 05:11 schrieb Paul Mackerras:
>> - Storing only the actually viewed diff. It's an interactive tool, so there's no advantage in displaying the diff in 0.001 seconds over viewing it in 0.1 seconds. As far as I can see, Gitk currently stores every diff it gets a hold of forever.
> It does? That would be a bug. :)
>
So far I've found three arrays being populated lazily (which is good) but never being released (which ignores changes to the underlying repo):
$commitinfo: one entry of about 500 bytes per line viewed in the list of commits. Maximum size of the array is the number of commits. As far as I can see, this array should be removed on a reload (Shift-F5).
$blobdifffd: one entry of about 45 bytes for every commit ever read. The underlying file descriptor gets closed, but the entry in this array remains. So far I didn't find the reason why this array exists at all. It's also not removed on a reload.
$treediffs: always the same number of entries as $blobdiffd, but > 1000 bytes/entry. Removed/refreshed on a reload (good!), different number of entries from that point on.
In case you want to play as well, here's the code I wrote for the investigation, it can be appended right at the bottom of the gitk script:
--------------8<---------------
proc variableSizes {} {
# Add variable here to get them shown.
global diffcontext diffids blobdifffd currdiffsubmod commitinfo
global diffnexthead diffnextnote difffilestart
global diffinhdr treediffs
puts "---------------------------------------------------"
foreach V [info vars] {
if { ! [info exists $V] } {
continue
}
set count 0
set bytes 0
if [array exists $V] {
set count [array size $V]
foreach I [array get $V] {
set bytes [expr $bytes + [string bytelength $I]]
}
} elseif [catch {llength [set $V]}] {
set count [llength [set $V]]
# set bytes [string bytelength [list {*}[set $V]]]
} else {
set bytes [string bytelength [set $V]]
}
puts [format "%20s: %5d items, %10d bytes" $V $count $bytes]
}
# catch {
# set output [memory info]
# puts $output
# }
after 3000 variableSizes
}
variableSizes
-------------->8---------------
[memory info] requires a Tcl with memory debug enabled.
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
^ permalink raw reply
* Forbid access to /gitweb but authorize the sub projets
From: Alexandre Duplaix @ 2016-11-07 13:07 UTC (permalink / raw)
To: git
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8"; format=flowed, Size: 1335 bytes --]
Hello,
I have several projects under https://myserver/gitweb and I would like
to forbid the access to the root, so that the users can't list the
differents projects.
However, I need to let the access to the sub projects (ex:
https://myserver/gitweb/?p=project1;a=summary
How can I do please ?
Thank you in advance :)
" Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caractère privé.
S'ils ne vous sont pas destinés nous vous signalons qu'il est strictement interdit de les
divulguer, de les reproduire ou d'en utiliser de quelque manière que ce
soit le contenu. Si ce message vous a été transmis par erreur, merci d'en
informer l'expéditeur et de supprimer immédiatement de votre système
informatique ce courriel ainsi que tous les documents qui y sont attachés"
******
" This e-mail and any attached documents may contain confidential or
proprietary information. If you are not the intended recipient, you are
notified that any dissemination, copying of this e-mail and any attachments
thereto or use of their contents by any means whatsoever is strictly
prohibited. If you have received this e-mail in error, please advise the
sender immediately and delete this e-mail and all attached documents
from your computer system."
#
^ permalink raw reply
* Re: [PATCH v1 03/19] split-index: add {add,remove}_split_index() functions
From: Duy Nguyen @ 2016-11-07 10:08 UTC (permalink / raw)
To: Christian Couder
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <CAP8UFD3hNEU_UeVizU6SVJTt4hqJPag9XWqZOM3FKCGJZXOthg@mail.gmail.com>
On Sun, Oct 30, 2016 at 5:06 AM, Christian Couder
<christian.couder@gmail.com> wrote:
> On Tue, Oct 25, 2016 at 11:58 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
>> <christian.couder@gmail.com> wrote:
>>> +void remove_split_index(struct index_state *istate)
>>> +{
>>> + if (istate->split_index) {
>>> + /*
>>> + * can't discard_split_index(&the_index); because that
>>> + * will destroy split_index->base->cache[], which may
>>> + * be shared with the_index.cache[]. So yeah we're
>>> + * leaking a bit here.
>>
>> In the context of update-index, this is a one-time thing and leaking
>> is tolerable. But because it becomes a library function now, this leak
>> can become more serious, I think.
>>
>> The only other (indirect) caller is read_index_from() so probably not
>> bad most of the time (we read at the beginning of a command only).
>> sequencer.c may discard and re-read the index many times though,
>> leaking could be visible there.
>
> So is it enough to check if split_index->base->cache[] is shared with
> the_index.cache[] and then decide if discard_split_index(&the_index)
> should be called?
It's likely shared though. We could un-share cache[] by duplicating
index entries in the_index.cache[] if they point back to
split_index->base (we know what entries are shared by examining the
"index" field). Once we do that, we can discard_split_index()
unconditionally. There's another place that has similar leak:
move_cache_to_base_index(), which could receive the same treatment.
--
Duy
^ permalink raw reply
* Re: [PATCH 4/5] attr: do not respect symlinks for in-tree .gitattributes
From: Duy Nguyen @ 2016-11-07 10:03 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20161102130848.qpigt4hxpoyfjf7x@sigill.intra.peff.net>
On Wed, Nov 2, 2016 at 8:08 PM, Jeff King <peff@peff.net> wrote:
> The attributes system may sometimes read in-tree files from
> the filesystem, and sometimes from the index. In the latter
> case, we do not resolve symbolic links (and are not likely
> to ever start doing so). Let's open filesystem links with
> O_NOFOLLOW so that the two cases behave consistently.
This sounds backward to me. The major use case is reading
.gitattributes on worktree, which follows symlinks so far. Only
git-archive has a special need to read index-only versions. The
worktree behavior should influence the in-index one, not the other way
around. If we could die("BUG" when git-archive is used on symlinks
(without --worktree-attributes). If people are annoyed by it, they can
implement symlink folllowing (to another version in index, not on
worktree).
The story is similar for .gitignore where in-index version is merely
an optimization. If it's symlinks and we can't follow, we should fall
back to worktree version.
--
Duy
^ permalink raw reply
* Re: Regarding "git log" on "git series" metadata
From: Duy Nguyen @ 2016-11-07 9:42 UTC (permalink / raw)
To: Josh Triplett
Cc: Jacob Keller, Junio C Hamano, Christian Couder, git,
Shawn O. Pierce, Jeff King, Mike Hommey
In-Reply-To: <20161107011841.vy2qfnbefidd2sjf@x>
On Mon, Nov 7, 2016 at 8:18 AM, Josh Triplett <josh@joshtriplett.org> wrote:
> Once we have gitrefs, you have both alternatives: reachable (gitref) or
> not reachable (gitlink).
>
> However, if you want some way to mark reachable objects as not
> reachable, such as for a sparse checkout, external large-object storage,
> or similar, then you can use a single unified mechanism for that whether
> working with gitrefs, trees, or blobs.
How? Whether an object reachable or not is baked in the definition (of
either gitlink or gitref). I don't think you can have a "maybe
reachable" type then rely on an external source to determine
reachability,
--
Duy
^ permalink raw reply
* Re: [PATCH v1 12/19] Documentation/config: add splitIndex.maxPercentChange
From: Duy Nguyen @ 2016-11-07 9:38 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason, git,
Christian Couder
In-Reply-To: <CAP8UFD1YL+RgdqbV0V1OnC=sJHJFc_an02Q9JeDNapW+u1CZcA@mail.gmail.com>
(sorry I got sick in the last few weeks and could not respond to this earlier)
On Mon, Nov 7, 2016 at 4:44 AM, Christian Couder
<christian.couder@gmail.com> wrote:
> Le 6 nov. 2016 09:16, "Junio C Hamano" <gitster@pobox.com> a écrit :
>>
>> Christian Couder <christian.couder@gmail.com> writes:
>>
>> > I think it is easier for user to be able to just set core.splitIndex
>> > to true to enable split-index.
>>
>> You can have that exact benefit by making core.splitIndex to
>> bool-or-more. If your default is 20%, take 'true' as if the user
>> specified 20% and take 'false' as if the user specified 100% (or is
>> it 0%? I do not care about the details but you get the point).
>
> Then if we ever add 'auto' and the user wants for example 10% instead of the
> default 20%, we will have to make it accept things like "auto,10".
In my opinion, "true" _is_ auto, which is a way to say "I trust you to
do the right thing, just re-split the index when it makes sense", "no"
is disabled of course. If the user wants to be specific, just write
"10" or some other percentage.(and either 0 or 100 would mean enable
split-index but do not re-split automatically, let _me_ do it when I
want it)
--
Duy
^ permalink raw reply
* Re: git -C has unexpected behaviour
From: Felix Nairz @ 2016-11-07 7:26 UTC (permalink / raw)
To: Johannes Schindelin, sbeller; +Cc: git
In-Reply-To: <alpine.DEB.2.20.1611041719140.3108@virtualbox>
Hi guys,
thanks for the answer and the clarification.
From what you are saying I can see that this expects as designed. It's
confusing in the submodule case, but I get you don't want to add extra
rules which slow down performance and mess with other people at the
same time.
I will look into the git-dir solution, this seems to be exactly what I need.
Thanks, Felix
On Fri, Nov 4, 2016 at 5:36 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Felix,
>
> On Fri, 4 Nov 2016, Felix Nairz wrote:
>
>> Now, to the unexpected part, which I think is a bug:
>>
>> If the TestData folder is there, but empty (I deleted all the files),
>> then running
>>
>> git -C .\TestData reset --hard
>>
>> will NOT throw me an error but run
>>
>> git reset --hard
>>
>> on the git repository (not the submodule in the sub-directory!),
>> without warning, or error.
>
> I *think* that this is actually intended. Please note that -C is *not* a
> synonym of --git-dir. It is more of a synonym of
>
> cd .\TestData
> git reset --hard
>
> In other words, you probably expected -C to specify the top-level
> directory of a worktree, and you expected Git to error out when it is not.
> Instead, Git will treat -C as a directory *from where to start*; It *can*
> be a subdirectory of the top-level directory of the worktree.
>
> Please note that
>
> git --git-dir=.\TestData\.git reset --hard
>
> will not work, though, as it mistakes the current directory for the
> top-level directory of the worktree. What you want to do is probably
>
> git -C .\TestData --git-dir=.git reset --hard
>
> This will tell Git to change the current working directory to the
> top-level of your intended worktree, *and* state that the repository needs
> to be in .git (which can be a file containing "gitdir: <real-git-dir>",
> which is the default in submodules).
>
> If the repository is *not* found, this command will exit with a failure.
>
> Ciao,
> Johannes
^ permalink raw reply
* Re: Regarding "git log" on "git series" metadata
From: Jacob Keller @ 2016-11-07 5:35 UTC (permalink / raw)
To: Josh Triplett
Cc: Junio C Hamano, Christian Couder, git, Shawn O. Pierce, Jeff King,
Nguyen Thai Ngoc Duy, Mike Hommey
In-Reply-To: <20161107011841.vy2qfnbefidd2sjf@x>
On Sun, Nov 6, 2016 at 5:18 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> Once we have gitrefs, you have both alternatives: reachable (gitref) or
> not reachable (gitlink).
>
> However, if you want some way to mark reachable objects as not
> reachable, such as for a sparse checkout, external large-object storage,
> or similar, then you can use a single unified mechanism for that whether
> working with gitrefs, trees, or blobs.
Fair enough.
Thanks,
Jake
^ permalink raw reply
* Re: gitk: avoid obscene memory consumption
From: Paul Mackerras @ 2016-11-07 4:11 UTC (permalink / raw)
To: Markus Hitter; +Cc: Stefan Beller, git@vger.kernel.org
In-Reply-To: <ff5bb36b-e30c-3998-100d-789b4b5e7249@jump-ing.de>
On Sun, Nov 06, 2016 at 11:28:37AM +0100, Markus Hitter wrote:
>
> Thanks for the positive comments.
>
> TBH, the more I think about the problem, the less I'm satisfied with the solution I provided. Including two reasons:
>
> - The list of files affected to the right is still complete and clicking a file name further down results in nothing ... as if the file wasn't part of the diff.
>
> - Local searches. Cutting off diffs makes them unreliable. Global searches still work, but actually viewing a search result in the skipped section is no longer possible.
>
> So I'm watching out for better solutions. So far I can think of these:
>
> - Storing only the actually viewed diff. It's an interactive tool, so there's no advantage in displaying the diff in 0.001 seconds over viewing it in 0.1 seconds. As far as I can see, Gitk currently stores every diff it gets a hold of forever.
It does? That would be a bug. :)
>
> - View the diff sparsely. Like rendering only the actually visible portion.
>
> - Enhancing ctext. This reference diff has 28 million characters, so there should be a way to store this with color information in, let's say, 29 MB of memory.
Tcl uses Unicode internally, I believe, so 57MB, but yes.
Paul.
^ permalink raw reply
* Re: [PATCH (optional)] t0021: use arithmetic expansion to trim whitespace from wc -c output
From: Lars Schneider @ 2016-11-06 19:43 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster, jnareb, peff, ramsay, tboegi
In-Reply-To: <b87ddffd-3de1-4481-b484-9f03a73b6ad1@kdbg.org>
> On 06 Nov 2016, at 20:31, Johannes Sixt <j6t@kdbg.org> wrote:
>
> Am 06.11.2016 um 16:45 schrieb Lars Schneider:
>>
>>> On 03 Nov 2016, at 21:22, Johannes Sixt <j6t@kdbg.org> wrote:
>>> This is a pure optimization that reduces the number of forks, which
>>> helps a bit on Windows.
>>>
>>> There would be a solution with perl that does not require trimming
>>> of whitespace, but perl startup times are unbearable on Windows.
>>> wc -c is better.
>
> I was wrong here. I had looked at the perl invocations due to
> git-sendemail, and they are awfully slow. A do-almost-nothing perl
> invocation is in the same ballpark as wc. Therefore I changed my mind
> and suggest the patch below instead.
>
>> Since the file size function became very simple with your patch,
>> shouldn't we get rid of it? If you agree, then we could squash the
>> patch below into your patch.
>
> In the new patch, the function is not that trivial (it uses perl), and
> the call sites can remain as they are (simple shell variables and
> substitutions).
>
> ---- 8< ----
> [PATCH] t0021: compute file size with a single process instead of a pipeline
>
> Avoid unwanted coding patterns (prodigal use of pipelines), and in
> particular a useless use of cat.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> t/t0021-conversion.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
> index db71acacb3..cb72fa49de 100755
> --- a/t/t0021-conversion.sh
> +++ b/t/t0021-conversion.sh
> @@ -22,7 +22,7 @@ generate_random_characters () {
> }
>
> file_size () {
> - cat "$1" | wc -c | sed "s/^[ ]*//"
> + perl -e 'print -s $ARGV[0]' "$1"
> }
>
> filter_git () {
> --
> 2.11.0.rc0.55.gd967357
>
I like this better, too. Looks good to me and works on macOS.
Thanks,
Lars
^ permalink raw reply
* 2.11.0-rc1 will not be tagged for a few days
From: Junio C Hamano @ 2016-11-07 2:32 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Lars Schneider, Jeff King
I regret to report that I won't be able to tag 2.11-rc1 as scheduled
in tinyurl.com/gitCal (I am feverish and my brain is not keeping
track of things correctly) any time soon. I'll report back an
updated schedule when able.
I'd appreciate that people keep discussing and exchanging patches
that will not be in 2.11 final to give a head-start to topics so
that people can agree on the designs and implementations in the
meantime, but one thing I'd like to see when I come back is somebody
tell me (when asked) what fix-up pathes that are "must to apply, or
there is no point tagging 2.11-rc1 while keeping it broken" are
found on the list. I am aware of only two right now ("cast enum to
int to work around compiler warning", in Dscho's prepare sequencer
series, and "wc -l may give leading whitespace" fix J6t pointed out
in Lars's filter process series), but it is more than likely that I
am missing a few more.
Thanks. Going back to bed...
^ permalink raw reply
* Re: Regarding "git log" on "git series" metadata
From: Josh Triplett @ 2016-11-07 1:18 UTC (permalink / raw)
To: Jacob Keller
Cc: Junio C Hamano, Christian Couder, git, Shawn O. Pierce, Jeff King,
Nguyen Thai Ngoc Duy, Mike Hommey
In-Reply-To: <CA+P7+xoxjwvjXrW0Pwh7ZK-OYBiYamPAxvf_=zqJOsQ8xWDPWw@mail.gmail.com>
On Sun, Nov 06, 2016 at 12:17:10PM -0800, Jacob Keller wrote:
> On Sun, Nov 6, 2016 at 9:33 AM, Josh Triplett <josh@joshtriplett.org> wrote:
> > On Sun, Nov 06, 2016 at 09:14:56AM -0800, Junio C Hamano wrote:
> >> Josh Triplett <josh@joshtriplett.org> writes:
> >> > We could, but if we (or one of the many third-party git implementations)
> >> > miss a case, gitlinks+reachability may appear to work in many cases with
> >> > dataloss afterward, while gitrefs will fail early and not appear
> >> > functional.
> >>
> >> I wonder what happens if we do not introduce the "gitref" but
> >> instead change the behaviour of "gitlink" to imply an optional
> >> reachability. That is, when enumerating what is reachable in your
> >> repository, if you see a gitlink and if you notice that you locally
> >> have the target of that gitlink, you follow, but if you know you
> >> lack it, you do not error out. This may be making things too
> >> complex to feasibily implement by simplify them ;-) and I see a few
> >> immediate fallout that needs to be thought through (i.e. downsides)
> >> and a few upsides, too. I am feeling feverish and not thinking
> >> straight, so I won't try to weigh pros-and-cons.
> >>
> >> This would definitely need protocol extension when transferring
> >> objects across repositories.
> >
> > It'd also need a repository format extension locally. Otherwise, if you
> > ever touched that repository with an older git (or a tool built on an
> > older libgit2 or JGit or other library), you could lose data.
> >
> > It does seem conceptually appealing, though. In an ideal world, the
> > original version of gitlink would have had opt-out reachability (and
> > .gitmodules with an external repository reference could count as opting
> > out).
> >
> > But I can't think of any case where it's OK for a git implementation to
> > not know about this reachability extension and still operate on the
> > gitlink. And given that, it might as well use a new object type that
> > the old version definitely won't think it understands.
> >
> > - Josh Triplett
>
> That's still only true if the receiving end runs fsck, isn't it? I
> suppose that's a large number of receivers, and at least there are
> ways post-push to determine that objects don't make sense to that
> version of git.
>
> I think using a new mode is the safest way, and it allows easily
> implementing RefTrees as well as other projects. Additionally, if we
> *wanted* additional "opt-in / opt-out" support we could add this by
> default to gitrefs,and they could (possibly) replace gitlinks in the
> future?
Once we have gitrefs, you have both alternatives: reachable (gitref) or
not reachable (gitlink).
However, if you want some way to mark reachable objects as not
reachable, such as for a sparse checkout, external large-object storage,
or similar, then you can use a single unified mechanism for that whether
working with gitrefs, trees, or blobs.
^ permalink raw reply
* Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS
From: Lars Schneider @ 2016-11-06 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Torsten Bögershausen, git
In-Reply-To: <20161017002550.88782-3-larsxschneider@gmail.com>
> On 17 Oct 2016, at 02:25, larsxschneider@gmail.com wrote:
>
> From: Lars Schneider <larsxschneider@gmail.com>
>
> TravisCI changed their default macOS image from 10.10 to 10.11 [1].
> Unfortunately the HTTPD tests do not run out of the box using the
> pre-installed Apache web server anymore. Therefore we enable these
> tests only for Linux and disable them for macOS.
>
> [1] https://blog.travis-ci.com/2016-10-04-osx-73-default-image-live/
>
> Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
> ---
> .travis.yml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 37a1e1f..d752447 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -32,7 +32,6 @@ env:
> - DEFAULT_TEST_TARGET=prove
> - GIT_PROVE_OPTS="--timer --jobs 3 --state=failed,slow,save"
> - GIT_TEST_OPTS="--verbose --tee"
> - - GIT_TEST_HTTPD=true
> - GIT_TEST_CLONE_2GB=YesPlease
> # t9810 occasionally fails on Travis CI OS X
> # t9816 occasionally fails with "TAP out of sequence errors" on Travis CI OS X
> @@ -57,6 +56,8 @@ before_install:
> - >
> case "${TRAVIS_OS_NAME:-linux}" in
> linux)
> + export GIT_TEST_HTTPD=YesPlease
> +
> mkdir --parents custom/p4
> pushd custom/p4
> wget --quiet http://filehost.perforce.com/perforce/r$LINUX_P4_VERSION/bin.linux26x86_64/p4d
> --
> 2.10.0
>
Hi Junio,
the patch above is one of two patches to make TravisCI pass, again.
Could you queue it?
The other patch is [1] which is still under discussion.
Thank you,
Lars
[1] http://public-inbox.org/git/8C67FF53-C26F-4993-908F-A5183C5E48D9@gmail.com/
^ permalink raw reply
* Re: [PATCH] t0021: expect more variations in the output of uniq -c
From: Johannes Sixt @ 2016-11-06 21:40 UTC (permalink / raw)
To: Lars Schneider; +Cc: git, gitster, jnareb, peff, ramsay, tboegi
In-Reply-To: <0B7DE8F1-34DF-4271-8936-B9B596EF5F9E@gmail.com>
Am 06.11.2016 um 16:31 schrieb Lars Schneider:
> This looks good to me. I wonder if I should post a patch
> to add the "|| return" trick to the following function
> "test_cmp_exclude_clean", too?!
The function does this:
for FILE in "$expect" "$actual"
do
grep -v "IN: clean" "$FILE" >"$FILE.tmp" &&
mv "$FILE.tmp" "$FILE"
done &&
It is an interesting case: If only matching lines are in the file,
nothing would be printed, and grep returns failure. But we shouldn't
care, because, strictly speaking, the function only wants to remove
lines with a certain pattern. Here, it actually hurts to &&-chain grep!
It wouldn't hurt to write 'mv ... || return', but at the same time, &&
after grep should be removed.
-- Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox