Re: Hash algorithm analysis

On Mon, 23 Jul 2018 at 14:48, Sitaram Chamarty wrote: > On 07/23/2018 06:10 PM, demerphq wrote: > > On Sun, 22 Jul 2018 at 01:59, brian m. carlson > > wrote: > >> I will admit that I don't love making this decision by myself, because > >> right now, w

Re: Hash algorithm analysis

On Sun, 22 Jul 2018 at 01:59, brian m. carlson wrote: > I will admit that I don't love making this decision by myself, because > right now, whatever I pick, somebody is going to be unhappy. I want to > state, unambiguously, that I'm trying to make a decision that is in the > interests of the Git

Re: could `git merge --no-ff origin/master` be made more useful?

On 15 May 2018 at 00:58, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > > On Mon, May 14 2018, demerphq wrote: > >> The first time I tried to use --no-ff I tried to do something like this: >> >> git checkout master >> git commit -a -m'whatever' &g

could `git merge --no-ff origin/master` be made more useful?

The first time I tried to use --no-ff I tried to do something like this: git checkout master git commit -a -m'whatever' git commit -a -m'whatever2' git merge --no-ff origin/master and was disappointed when "it didn't work" and git told me there was nothing to do as the branch was up to

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On 1 March 2018 at 16:08, Jeff King wrote: > On Thu, Mar 01, 2018 at 09:28:31AM -0500, Randall S. Becker wrote: > >> > It's not clear to me though if we just want to tweak the programs run in >> > the >> > test scripts in order to get test_must_fail to stop complaining, or if we

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On 1 March 2018 at 08:36, Jeff King <p...@peff.net> wrote: > On Wed, Feb 28, 2018 at 05:51:14PM +0100, demerphq wrote: > >> I would look into putting it into a module and then using the PERL5OPT >> environment var to have it loaded automagically in any of your perl >&g

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On 28 February 2018 at 18:19, demerphq <demer...@gmail.com> wrote: > On 28 February 2018 at 18:10, Randall S. Becker <rsbec...@nexbridge.com> > wrote: >> On February 28, 2018 11:46 AM, demerphq wrote: >>> On 28 February 2018 at 08:49, Jeff King <p...@peff.ne

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On 28 February 2018 at 18:10, Randall S. Becker <rsbec...@nexbridge.com> wrote: > On February 28, 2018 11:46 AM, demerphq wrote: >> On 28 February 2018 at 08:49, Jeff King <p...@peff.net> wrote: >> > On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote: >>

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On 28 February 2018 at 15:55, Randall S. Becker wrote: > On February 28, 2018 2:49 AM, Peff wrote: >> On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote: >> >> > > > > a) We could override the meaning of die() in Git.pm. This feels >> > > > > ugly but if it

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On 28 February 2018 at 08:49, Jeff King wrote: > On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote: > >> > > > a) We could override the meaning of die() in Git.pm. This feels >> > > > ugly but if it works, it would be a very small patch. >> > > >> > > Unlikely to work

Re: RFC v3: Another proposed hash function transition plan

On 14 September 2017 at 17:23, Johannes Schindelin wrote: > Hi Junio, > > On Thu, 14 Sep 2017, Junio C Hamano wrote: > >> Jonathan Nieder writes: >> >> > In other words, a long lifetime for the hash absolutely is a design >> > goal. Coping well

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

On 13 September 2017 at 17:22, Jeff King <p...@peff.net> wrote: > On Wed, Sep 13, 2017 at 05:18:56PM +0200, demerphq wrote: > >> > Hmph. That is very disturbing. But with that information I should be >> > able to track down the culprit. Thanks

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

On 13 September 2017 at 16:51, Jeff King <p...@peff.net> wrote: > On Wed, Sep 13, 2017 at 04:49:45PM +0200, demerphq wrote: > >> On 13 September 2017 at 16:17, Jeff King <p...@peff.net> wrote: >> > You're welcome to read over the function to double-chec

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

On 13 September 2017 at 16:17, Jeff King wrote: > You're welcome to read over the function to double-check, but I just > looked it over and couldn't find any unchecked writes. I can look, but I doubt I would notice something you did not. On the other hand the strace output does

Re: RFC v3: Another proposed hash function transition plan

On 13 September 2017 at 14:05, Johannes Schindelin wrote: > For example, I am still in favor of SHA-256 over SHA3-256, after learning > some background details from in-house cryptographers: it provides > essentially the same level of security, according to my sources,

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

On 13 September 2017 at 14:34, Jeff King <p...@peff.net> wrote: > On Wed, Sep 13, 2017 at 01:59:17PM +0200, demerphq wrote: > >> After being away for a while I saw the following message in one of my git >> repos: >> >> $ git status >> On branch yves/xxx &

Bug: git branch --unset-upstream command can nuke config when disk is full.

After being away for a while I saw the following message in one of my git repos: $ git status On branch yves/xxx Your branch is based on 'origin/yves/xxx', but the upstream is gone. (use "git branch --unset-upstream" to fixup) nothing to commit, working tree clean $ git branch --unset-upstream

Re: your mail

On 22 June 2017 at 23:58, Ævar Arnfjörð Bjarmason wrote: > +You don't need to be subscribed to the list to send mail to it, and > +others on-list will generally CC you when replying (although some > +forget this). It's adviced to subscribe to the list if you want to be FWIW:

Re: Unaligned accesses in sha1dc

On 2 June 2017 at 22:14, Ævar Arnfjörð Bjarmason wrote: > On Fri, Jun 2, 2017 at 10:11 PM, Martin Ågren wrote: >> On 2 June 2017 at 21:32, Ævar Arnfjörð Bjarmason wrote: >>> On Fri, Jun 2, 2017 at 11:49 AM, Martin Ågren

Re: Unaligned accesses in sha1dc

On 2 June 2017 at 21:32, Ævar Arnfjörð Bjarmason wrote: > On Fri, Jun 2, 2017 at 11:49 AM, Martin Ågren wrote: >> On 2 June 2017 at 10:51, Ævar Arnfjörð Bjarmason wrote: >>> On Fri, Jun 2, 2017 at 2:15 AM, Junio C Hamano

Re: Git 2.13.0 segfaults on Solaris SPARC due to DC_SHA1=YesPlease being on by default

On 16 May 2017 at 00:09, Jeff King wrote: > On Mon, May 15, 2017 at 04:13:58PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> On Mon, May 15, 2017 at 3:58 PM, Marc Stevens wrote: >> > Hi Aevar, >> > >> > Thank you for notifying us of this issue. >> > Big

Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #01; Mon, 1)

On 9 May 2017 at 13:12, Ævar Arnfjörð Bjarmason wrote: > On Tue, May 9, 2017 at 2:37 AM, brian m. carlson > wrote: >> On Tue, May 09, 2017 at 02:00:18AM +0200, Ævar Arnfjörð Bjarmason wrote: > * gitweb is vulnerable to CPU DoS now in its default

Re: Feature request: --format=json

On 18 April 2017 at 10:44, Fred .Flintstone wrote: > Well the easiest way to work with that would be JSON. > So the best would be if Git could output the data I want in JSON format. > Then it would be easy for me to work with data. > > With git rev-list and git-cat file, its

Re: Will OpenSSL's license change impact us?

On 25 March 2017 at 17:35, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > On Sat, Mar 25, 2017 at 10:43 AM, demerphq <demer...@gmail.com> wrote: >> >> >> On 25 Mar 2017 10:18 a.m., "Ævar Arnfjörð Bjarmason" <ava...@gmail.com> >> wrote:

Re: Will OpenSSL's license change impact us?

On 25 March 2017 at 00:51, Ævar Arnfjörð Bjarmason wrote: > They're changing their license[1] to Apache 2 which unlike the current > fuzzy compatibility with the current license[2] is explicitly > incompatible with GPLv2[3]. Are you sure there is an issue? From the Apache page

Re: send-email garbled header with trailing doublequote in email

On 3 November 2016 at 15:18, Jeff King wrote: > On Wed, Nov 02, 2016 at 11:29:01PM +0100, Andrea Arcangeli wrote: > >> So this must be postfix then that out of the blue decided to garble it >> in a strange way while parsing the input... The removal of all >> whitespaces s/what

Re: git add without whitespace

On 30 May 2016 at 21:06, Junio C Hamano wrote: > Robert Dailey writes: > >> $ git diff -U0 -w --no-color | git apply --cached --ignore-whitespace >> --unidiff-zero >> >> This command explicitly leaves out context because it can sometimes >> cause the

Re: t6044 broken on pu

On 8 May 2016 at 20:20, Junio C Hamano wrote: > Torsten Bögershausen writes: > >> May a simple >> printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n" >> >> be an option ? > > If you were to do that, at least have the decency to make it more > readable by doing something

Re: best practices against long git rebase times?

On 4 December 2015 at 18:28, John Keeping <j...@keeping.me.uk> wrote: > On Fri, Dec 04, 2015 at 06:09:33PM +0100, demerphq wrote: >> On 4 December 2015 at 16:05, Andreas Krey <a.k...@gmx.de> wrote: >> > Hi all, >> > >> > our workflow is pretty re

Re: best practices against long git rebase times?

On 4 December 2015 at 16:05, Andreas Krey wrote: > Hi all, > > our workflow is pretty rebase-free for diverse reasons yet. > > One obstacle now appearing is that rebases simply take > very long - once you might want to do a rebase there are > several hundred commits on the remote

Re: XDL_FAST_HASH can be very slow

(sorry for the repost, I use gmail and it send html mails by default). On 22 December 2014 at 11:48, Thomas Rast t...@thomasrast.ch wrote: 1. hash function throughput 2. quality of the hash values 3. avoiding collision attacks XDL_FAST_HASH was strictly an attempt to improve throughput, and

Re: [GSoC14][RFC] Is there any interest in adding a port of checkpatch.pl to contrib/?

On 18 March 2014 02:38, Jacopo Notarstefano jacopo.notarstef...@gmail.com wrote: 3. As far as I can tell, checkpatch needs to be run from the root folder of a linux repository clone. Cloning several hundred MBs for a single perl script looks a little foolish to me. If that is your worry maybe

Re: question about: Facebook makes Mercurial faster than Git

On 10 March 2014 11:07, Dennis Luehring dl.so...@gmx.net wrote: according to these blog posts http://www.infoq.com/news/2014/01/facebook-scaling-hg https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ mercurial can be faster then git but i don't found any reply

Re: Confusing git log --- First time bug submission please advise on best practices

On 7 February 2014 18:26, Duy Nguyen pclo...@gmail.com wrote: On Fri, Feb 07, 2014 at 09:43:46AM +, Francis Stephens wrote: Thanks for your clear response. I can see where I went wrong now. Maybe something like this would help avoid confusion a bit in the future? This toy patch puts a

Rebase triggers git diff header lacks filename information on very large patch with binary files

Hi, I just did a rebase, and it throws an error like this: Applying: comment1 Applying: comment2 Applying: comment3 Applying: comment4 Applying: patch_with_binary_files fatal: git diff header lacks filename information when removing 1 leading pathname component (line 7330213) Repository lacks

Re: Rebase triggers git diff header lacks filename information on very large patch with binary files

On 14 January 2014 12:48, demerphq demer...@gmail.com wrote: Hi, I just did a rebase, and it throws an error like this: Applying: comment1 Applying: comment2 Applying: comment3 Applying: comment4 Applying: patch_with_binary_files fatal: git diff header lacks filename information when

Re: [Administrivia] On ruby and contrib/

On 5 June 2013 16:45, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano gits...@pobox.com wrote: That might make sense for the shorter term, but in longer term I see Perl as declining in favor of other languages. It's only a matter of time before

Re: inotify to minimize stat() calls

On 10 February 2013 12:17, Duy Nguyen pclo...@gmail.com wrote: Bear in mind though this is Linux, where lstat is fast. On systems with slow lstat, these timings could look very different due to the large number of lstat calls compared to open+getdents. I really like to see similar numbers on

Re: CodingGuidelines Perl amendment

On 6 February 2013 17:29, Junio C Hamano gits...@pobox.com wrote: Ted Zlatanov t...@lifelogs.com writes: - As in C (see above), we avoid using braces unnecessarily (but Perl forces braces around if/unless/else/foreach blocks, so this is not always possible). Is it ever (as opposed to

Re: CodingGuidelines Perl amendment

On 6 February 2013 19:14, Junio C Hamano gits...@pobox.com wrote: demerphq demer...@gmail.com writes: As you mention below statement modifiers have their place. For instance next if $whatever; Is considered preferable to if ($whatever) { next; } Similarly open my $fh

Re: CodingGuidelines Perl amendment

On 6 February 2013 19:35, Ted Zlatanov t...@lifelogs.com wrote: On Wed, 6 Feb 2013 19:25:43 +0100 demerphq demer...@gmail.com wrote: d On 6 February 2013 19:05, Ted Zlatanov t...@lifelogs.com wrote: On Wed, 06 Feb 2013 08:29:30 -0800 Junio C Hamano gits...@pobox.com wrote: JCH Is it ever

Re: push race

On 15 October 2012 16:09, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: On Mon, Oct 15, 2012 at 11:14 AM, Angelo Borsotti angelo.borso...@gmail.com wrote: Hello, FWIW we have a lot of lemmings pushing to the same ref all the time at $work, and while I've seen cases where: 1. Two clients

Re: Ignore on commit

On 5 October 2012 03:00, Andrew Ardill andrew.ard...@gmail.com wrote: On 5 October 2012 07:20, Marco Craveiro marco.crave...@gmail.com wrote: ... Similar but not quite; the idea is that you know that there is some code (I'm just talking about files here, so lets ignore hunks for the moment)

Re: Should GIT_AUTHOR_{NAME,EMAIL} set the tagger name/email?

On 11 September 2012 18:53, Junio C Hamano gits...@pobox.com wrote: Ævar Arnfjörð Bjarmason ava...@gmail.com writes: On Sat, Sep 1, 2012 at 6:12 PM, Andreas Schwab sch...@linux-m68k.org wrote: Ævar Arnfjörð Bjarmason ava...@gmail.com writes: I don't get what you mean, what committer info?

Re: Sync production with Git

On 8 August 2012 15:11, kiranpyati kiran.py...@infobeans.com wrote: I am new to github, Earlier we used to manually upload files on the production through FTP although git was present on the production. Due to this now git status shows many modified and untrack files. To sync that with git

Re: Sync production with Git

On 9 August 2012 06:21, demerphq demer...@gmail.com wrote: On 8 August 2012 15:11, kiranpyati kiran.py...@infobeans.com wrote: I am new to github, Earlier we used to manually upload files on the production through FTP although git was present on the production. Due to this now git status