I have a large and active SVN repository. More than 36,000 revisions,
thousands of branches - new ones created daily - and a non-standard
layout. Also, a secondary git repository that serves as a faithful
"git" copy of the work accumulating in SVN (git version 2.9.5). I seek
an efficient way to
I have a large and active SVN repository. More than 36,000 revisions,
thousands of branches - new ones created daily - and a non-standard
layout. Also, a secondary git repository that serves as a faithful
"git" copy of the work accumulating in SVN (git version 2.9.5). I seek
an efficient way to
How about something like this? It ignores attributes that should have no
bearing on whether the kernel is considered dirty. Copied trees with no other
changes would no longer be marked with -dirty. Plus it works on read-only
media since no index updating is required.
Would this also be considered
On 01/18/2018 11:27 AM, Christoph Hellwig wrote:
[adding Chris to the Cc list - this is about the awful ext3 data=ordered
behavior of syncing the whole file system data and metadata on each
fsync]
On Wed, Jan 17, 2018 at 03:57:53PM -0800, Linus Torvalds wrote:
On Wed, Jan 17, 2018 at 3:52 PM, T
On 05/10/2017 11:43, Junio C Hamano wrote:
> On Thu, Oct 5, 2017 at 6:30 PM, Jeff King wrote:
>
>> Mason wrote:
>>
>>> The patch header contains:
>>>
>>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>> Content-Transfer-Encod
Hello everyone,
Recently, the SMTP server we use at work started mangling outgoing
messages, by converting them to quoted-printable, whatever their
original encoding (even 7-bit clean, pure ASCII).
This breaks patches I send to Linux mailing lists, because it changes
TAB to =09, EQUAL to =3D, TRA
Mason wrote:
I was planning to write 'git diff -q commit^ commit'
to test for empty commits. Looks like I'll be needing
'git diff commit^ commit | wc -l' instead?
I wrote a script to generate the list of empty commits.
git log --format="%h" --reverse 413cb0
Junio C Hamano wrote:
> Mason wrote:
>
>> I was planning to write 'git diff -q commit^ commit'
>> to test for empty commits.
>
> s/-q/--quiet/ and all is well, no?
Doh! I've no idea how I missed these...
--exit-code
Make the program exit with codes
Junio C Hamano wrote:
> Mason wrote:
>
>> I fetched linux-stable.git inside our repo.
>> I created ~300 patches using git format-patch -1 in a loop.
>> I can now run 'git am --3way $IGNORE *.patch'
>>
>> IGNORE is used to --exclude the directori
Junio C Hamano wrote:
But I personally think "git am -3" may be easier to handle.
Thanks! At least now, I see the light at the end of the tunnel.
I fetched linux-stable.git inside our repo.
I created ~300 patches using git format-patch -1 in a loop.
I can now run 'git am --3way $IGNORE *.patc
Hello everyone,
Here's the situation:
Back in 2012, we cloned a MIPS repo, which was itself a clone of
a 3.4.2 kernel with ~40 MIPS-specific patches applied.
Then the devs started pushing patches; and once in a while, the
maintainer would "sync" with the mainline kernel. I don't know
what tool
On Friday 22 April 2005 16:32, Chris Mason wrote:
> If I pack every 64k (uncompressed), the checkout-tree time goes down to
> 3m14s. That's a very big difference considering how stupid my code is .git
> was only 20% smaller with 64k chunks. I should be able to do better...I'l
On Thursday 21 April 2005 18:47, Linus Torvalds wrote:
> On Thu, 21 Apr 2005, Chris Mason wrote:
> > Shrug, we shouldn't need help from the kernel for something like this.
> > git as a database hits worst case scenarios for almost every FS.
[ ... ]
We somewhat agree on mos
On Thursday 21 April 2005 15:28, Krzysztof Halasa wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
> > Wrong. You most definitely _can_ lose: you end up having to optimize for
> > one particular filesystem blocking size, and you'll lose on any other
> > filesystem. And you'll lose on the special
On Thursday 21 April 2005 11:41, Linus Torvalds wrote:
> On Thu, 21 Apr 2005, Chris Mason wrote:
> > There have been a few threads on making git more space efficient, and
> > eventually someone mentions tiny files and space fragmentation. Now that
> > git object names are
Hello,
There have been a few threads on making git more space efficient, and
eventually someone mentions tiny files and space fragmentation. Now that git
object names are decoupled from their compression, it's easier to consider a
a variety of compression algorithms. I whipped up a really sil
On Wednesday 20 April 2005 13:52, Linus Torvalds wrote:
> On Wed, 20 Apr 2005, Chris Mason wrote:
> > The patch below with your current tree brings my 100 patch test down to
> > 22 seconds again.
>
> If you ever have a cache_entry bigger than 16384, your code will write
>
On Wednesday 20 April 2005 13:06, Linus Torvalds wrote:
> On Wed, 20 Apr 2005, Chris Mason wrote:
> > At any rate, the time for a single write-tree is pretty consistent.
> > Before it was around .5 seconds, and with this change it goes down to
> > .128s.
>
> O
On Wednesday 20 April 2005 11:40, Linus Torvalds wrote:
> On Wed, 20 Apr 2005, Chris Mason wrote:
> > Thanks for looking at this. Your new tree is faster, it gets the commit
> > 100 patches time down from 1m5s to 50s.
>
> It really _shouldn't_ be faster. It still does t
On Wednesday 20 April 2005 02:43, Linus Torvalds wrote:
> On Tue, 19 Apr 2005, Chris Mason wrote:
> > I'll finish off the patch once you ok the basics below. My current code
> > works like this:
>
> Chris, before you do anything further, let me re-consider.
>
>
On Tuesday 19 April 2005 17:23, Linus Torvalds wrote:
> On Tue, 19 Apr 2005, Chris Mason wrote:
> > Regardless, putting it into the index somehow should be fastest, I'll see
> > what I can do.
>
> Start by putting it in at "read-tree" time, and adding the code
On Tuesday 19 April 2005 15:03, Linus Torvalds wrote:
> On Tue, 19 Apr 2005, Chris Mason wrote:
> > Very true, you can't replace quilt with git without ruining both of them.
> > But it would be nice to take a quilt tree and turn it into a git tree
> > for merging p
On Tuesday 19 April 2005 13:36, Linus Torvalds wrote:
> On Tue, 19 Apr 2005, Chris Mason wrote:
> > I did a quick experiment with applying/commit 100 patches from the suse
> > kernel into a kernel git tree, which quilt can do in 2 seconds. git
> > needs 1m5s.
>
> Note
Hello everyone,
I did a quick experiment with applying/commit 100 patches from the suse kernel
into a kernel git tree, which quilt can do in 2 seconds. git needs 1m5s.
The primary performance problem during each commit is write-tree recalculating
the hash of each directory, even though the con
24 matches
Mail list logo
