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, wh
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
On 15 May 2018 at 00:58, Ævar Arnfjörð Bjarmason 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'
>> git comm
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 da
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
>> > consider the
On 1 March 2018 at 08:36, Jeff King 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
>> scripts.
>>
&
On 28 February 2018 at 18:19, demerphq wrote:
> On 28 February 2018 at 18:10, Randall S. Becker
> wrote:
>> On February 28, 2018 11:46 AM, demerphq wrote:
>>> On 28 February 2018 at 08:49, Jeff King wrote:
>>> > On Wed, Feb 28, 2018 at 07:42:51AM +, Eric
On 28 February 2018 at 18:10, Randall S. Becker wrote:
> On February 28, 2018 11:46 AM, demerphq wrote:
>> On 28 February 2018 at 08:49, Jeff King wrote:
>> > On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote:
>> >
>> >> > > > a) We coul
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 works, it would be a very s
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 since I think w
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 with an unexpectedly short lifetime for the hash is
On 13 September 2017 at 17:22, Jeff King 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 for digging
On 13 September 2017 at 16:51, Jeff King wrote:
> On Wed, Sep 13, 2017 at 04:49:45PM +0200, demerphq wrote:
>
>> 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
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 show that this is
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, while
> hardware support seem
On 13 September 2017 at 14:34, Jeff King 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
>> Your bra
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
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: "adviced" is misspel
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
>>> wrote:
On 2 June 2017 at 10:51, Ævar Arnfjörð Bjarmason wrote:
>
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 wrote:
Martin Ågren writes:
> I looked into this some more.
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 endianness is a tricky issue, also since I don
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 configuration.
> It's easy to provide an ERE that e
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 not so easy to reliabl
On 25 March 2017 at 17:35, Ævar Arnfjörð Bjarmason wrote:
> On Sat, Mar 25, 2017 at 10:43 AM, demerphq wrote:
>>
>>
>> On 25 Mar 2017 10:18 a.m., "Ævar Arnfjörð Bjarmason"
>> wrote:
>>
>> On Sat, Mar 25, 2017 at 9:40 AM, demerphq wrote:
>&
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 on this:
Apache 2
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 ever/whatever/ espec
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 patch to fail to apply, I think due to whitesp
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 like:
>
> printf "%s\n" 1 2
On 4 December 2015 at 18:28, John Keeping wrote:
> On Fri, Dec 04, 2015 at 06:09:33PM +0100, demerphq wrote:
>> On 4 December 2015 at 16:05, Andreas Krey wrote:
>> > Hi all,
>> >
>> > our workflow is pretty rebase-free for diverse reasons yet.
>> >
&g
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 branch, and our t
(sorry for the repost, I use gmail and it send html mails by default).
On 22 December 2014 at 11:48, Thomas Rast 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 fairly
> succ
On 18 March 2014 02:38, Jacopo Notarstefano
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 you should upload the scrip
On 10 March 2014 11:07, Dennis Luehring 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 from the
On 7 February 2014 18:26, Duy Nguyen 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 horizontal line
On 14 January 2014 12:48, demerphq 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 filena
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 nec
On 5 June 2013 16:45, Felipe Contreras wrote:
> On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano 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 Ruby surpasses Perl in popularity, and
On 26 March 2013 18:48, Jeff King wrote:
> On Tue, Mar 26, 2013 at 06:20:09PM +0100, demerphq wrote:
>
>> Seconded. At $work lots of people started asking anxious questions
>> about this. It was suggested it is a potential security hole, although
>> I am not sure I agr
On 26 March 2013 18:06, Richard Weinberger wrote:
> P.s: I've told this story to some friends and co-workers which use git like
> me very day.
> All of them were shocked about the behavior of git-clean and GIT_DIR.
Seconded. At $work lots of people started asking anxious questions
about this. It
On 10 February 2013 12:17, Duy Nguyen 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 Windows.
Is wi
On 6 February 2013 19:35, Ted Zlatanov wrote:
> On Wed, 6 Feb 2013 19:25:43 +0100 demerphq wrote:
>
> d> On 6 February 2013 19:05, Ted Zlatanov wrote:
>>> On Wed, 06 Feb 2013 08:29:30 -0800 Junio C Hamano wrote:
>>>
> JCH> Is it ever (as opposed to &
On 6 February 2013 19:05, Ted Zlatanov wrote:
> On Wed, 06 Feb 2013 08:29:30 -0800 Junio C Hamano wrote:
>
> JCH> Is it ever (as opposed to "not always") possible to omit braces?
>
> Oh yes! Not that I recommend it, and I'm not even going to touch on
> Perl Golf :)
I think you are wrong. Can yo
On 6 February 2013 19:14, Junio C Hamano wrote:
> demerphq writes:
>
>> As you mention below statement modifiers have their place. For instance
>>
>> next if $whatever;
>>
>> Is considered preferable to
>>
>> if ($whatever) {
>> next;
On 6 February 2013 17:29, Junio C Hamano wrote:
> Ted Zlatanov 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 "not always") possible t
On 15 October 2012 16:09, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Oct 15, 2012 at 11:14 AM, Angelo Borsotti
> 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 try to push
> 2. They both get
On 5 October 2012 03:00, Andrew Ardill wrote:
> On 5 October 2012 07:20, Marco Craveiro 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) which is normally checked in but for a p
On 11 September 2012 18:53, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> On Sat, Sep 1, 2012 at 6:12 PM, Andreas Schwab wrote:
>>> Ævar Arnfjörð Bjarmason writes:
>>>
I don't get what you mean, what committer info?
>>>
>>> GIT_COMMITTER_{NAME,EMAIL}. A tagger isn't really
On 9 August 2012 06:21, demerphq wrote:
> On 8 August 2012 15:11, kiranpyati 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
&
On 8 August 2012 15:11, kiranpyati 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 we have downloaded
49 matches
Mail list logo
