* 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
* Re: gitk: avoid obscene memory consumption
From: Jacob Keller @ 2016-11-06 20:33 UTC (permalink / raw)
To: Markus Hitter; +Cc: Paul Mackerras, Stefan Beller, git@vger.kernel.org
In-Reply-To: <ff5bb36b-e30c-3998-100d-789b4b5e7249@jump-ing.de>
On Sun, Nov 6, 2016 at 2:28 AM, Markus Hitter <mah@jump-ing.de> wrote:
> - 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.
>
This seems like the right solution. Store only what we need to view as
we need to view it. (IE: lazily generate the diff and don't keep it
long term, possibly by generating each file separately when that file
is viewed)?
> - View the diff sparsely. Like rendering only the actually visible portion.
>
This also would be valuable, as part of the solution above.
> - 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.
>
I think all three suggestions here are a better solution that what
you've outlined already as you explain the problems caused by cutting
off the diff.
Thanks,
Jake
^ permalink raw reply
* Re: Regarding "git log" on "git series" metadata
From: Jacob Keller @ 2016-11-06 20:17 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: <20161106173311.lqoxxgcklx4jlrg7@x>
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?
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11
From: Lars Schneider @ 2016-11-06 19:35 UTC (permalink / raw)
To: Jeff King; +Cc: git, tboegi, gitster
In-Reply-To: <20161017095002.bbqyp2hkbuyau66t@sigill.intra.peff.net>
> On 17 Oct 2016, at 11:50, Jeff King <peff@peff.net> wrote:
>
> On Sun, Oct 16, 2016 at 05:25:49PM -0700, larsxschneider@gmail.com wrote:
>
>> From: Lars Schneider <larsxschneider@gmail.com>
>>
>> Apple removed the OpenSSL header files in macOS 10.11 and above. OpenSSL
>> was deprecated since macOS 10.7.
>>
>> Set `NO_OPENSSL` and `APPLE_COMMON_CRYPTO` to `YesPlease` as default for
>> macOS. Make it possible to override this and use OpenSSL by defining
>> `DARWIN_OPENSSL`.
>
> I like that you gave an override, but I don't think it works in all
> cases:
>
>> diff --git a/config.mak.uname b/config.mak.uname
>> index b232908..f0c94a9 100644
>> --- a/config.mak.uname
>> +++ b/config.mak.uname
>> @@ -108,6 +108,12 @@ ifeq ($(uname_S),Darwin)
>> ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 11 && echo 1),1)
>> HAVE_GETDELIM = YesPlease
>> endif
>> + ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 15 && echo 1),1)
>> + ifndef DARWIN_OPENSSL
>> + NO_OPENSSL = YesPlease
>> + APPLE_COMMON_CRYPTO=YesPlease
>> + endif
>> + endif
>
> This is in config.mak.uname, which gets sourced before config.mak (and
> ifndef is evaluated at the time of parsing). So it would work to do:
>
> make DARWIN_OPENSSL=Yep
>
> but not:
>
> echo DARWIN_OPENSSL=Yep >>config.mak
> make
>
> I think you'd have to set a flag in config.mak.uname, and then resolve
> it in the Makefile proper like:
>
> ifdef DARWIN_OPENSSL
> # Overrides AUTO_AVOID_OPENSSL, do nothing.
> else ifdef AUTO_AVOID_OPENSSL
> NO_OPENSSL = YesPlease
> APPLE_COMMON_CRYPTO = YesPlease
> endif
>
> but that's totally untested.
Good point. I think I found an even easier way to achieve the same.
What do you think about the patch below?
Thanks,
Lars
-- >8 --
Subject: Makefile: set NO_OPENSSL on macOS by default
Apple removed the OpenSSL header files in macOS 10.11 and above. OpenSSL
was deprecated since macOS 10.7.
Set `NO_OPENSSL` and `APPLE_COMMON_CRYPTO` to `YesPlease` as default for
macOS. It is possible to override this and use OpenSSL by defining
`NO_APPLE_COMMON_CRYPTO`.
Original-patch-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
---
Makefile | 1 +
1 file changed, 1 insertion(+)
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
--
^ permalink raw reply related
* Re: [PATCH (optional)] t0021: use arithmetic expansion to trim whitespace from wc -c output
From: Johannes Sixt @ 2016-11-06 19:31 UTC (permalink / raw)
To: Lars Schneider; +Cc: git, gitster, jnareb, peff, ramsay, tboegi
In-Reply-To: <C61D1F80-7B7A-4111-9418-75D178AF4353@gmail.com>
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
^ permalink raw reply related
* Re: Regarding "git log" on "git series" metadata
From: Josh Triplett @ 2016-11-06 17:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jacob Keller, Christian Couder, git, Shawn O. Pierce, Jeff King,
Nguyen Thai Ngoc Duy, Mike Hommey
In-Reply-To: <xmqqshr4cyy7.fsf@gitster.mtv.corp.google.com>
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
^ permalink raw reply
* Re: [PATCH v1 12/19] Documentation/config: add splitIndex.maxPercentChange
From: Junio C Hamano @ 2016-11-06 17:16 UTC (permalink / raw)
To: Christian Couder
Cc: git, Nguyen Thai Ngoc Duy, Ævar Arnfjörð Bjarmason,
Christian Couder
In-Reply-To: <CAP8UFD2H6rZNQqg1VGNkes65KAk-4P160rjQSjFY3NjgZydZmA@mail.gmail.com>
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).
^ permalink raw reply
* Re: Regarding "git log" on "git series" metadata
From: Junio C Hamano @ 2016-11-06 17:14 UTC (permalink / raw)
To: Josh Triplett
Cc: Jacob Keller, Christian Couder, git, Shawn O. Pierce, Jeff King,
Nguyen Thai Ngoc Duy, Mike Hommey
In-Reply-To: <20161106163410.ilysej5r6qd3744e@x>
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.
^ permalink raw reply
* Re: Regarding "git log" on "git series" metadata
From: Josh Triplett @ 2016-11-06 16:34 UTC (permalink / raw)
To: Jacob Keller
Cc: Christian Couder, Junio C Hamano, git, Shawn O. Pierce, Jeff King,
Nguyen Thai Ngoc Duy, Mike Hommey
In-Reply-To: <CA+P7+xoG3ag8dj7s_NRoqz-EwjVENSJSzE_qj6gnW-SmWt0bgA@mail.gmail.com>
On Sat, Nov 05, 2016 at 09:50:07PM -0700, Jacob Keller wrote:
> On Sat, Nov 5, 2016 at 1:25 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> > On Sat, Nov 05, 2016 at 09:21:58PM +0100, Christian Couder wrote:
> >> On Sat, Nov 5, 2016 at 4:18 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> >> > On Sat, Nov 05, 2016 at 01:45:27PM +0100, Christian Couder wrote:
> >> >> And with what Peff says above it looks like we will need ways
> >> >> configure and tweak commit reachability with gitlink/gitref anyway. So
> >> >> the point of gitref compared to gitlink would be that they just have a
> >> >> different reachability by default. But couldn't that be replaced by a
> >> >> default rule saying that when a gitlink is reached "this way or that
> >> >> way" then the commit reachability should be enforced, and otherwise it
> >> >> should not be?
> >> >
> >> > Any version of git unaware of that rule, though, would consider objects
> >> > only reachable by gitlink as unreachable and delete them, causing data
> >> > loss. Likewise for a server not aware of that rule. And a server
> >> > unaware of that rule would not supply those objects to a client pulling
> >> > such a branch.
> >>
> >> Yeah, so you would really need an up-to-date server and client to
> >> store the git-series data.
> >> But anyway if we create a gitref object, you would also need
> >> up-to-date servers and clients to make it work.
> >
> > Agreed, but gitrefs have the advantage of failing safe, rather than
> > failing with dataloss.
> >
> > - Josh Triplett
>
> Isn't the "failing safe" only true if the client disconnects when a
> server doesn't advertise "i understand gitrefs"? So couldn't we, as
> part of the rules for reachability advertise a capability that does a
> similar thing and fails safe as well?
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.
^ 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