* Re: Switching from CVS to GIT
From: Daniel Barkalow @ 2007-10-16 17:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eli Zaretskii, raa.lkml, ae, tsuna, git
In-Reply-To: <Pine.LNX.4.64.0710161335260.25221@racer.site>
On Tue, 16 Oct 2007, Johannes Schindelin wrote:
> Hi,
>
> [culled make-w32, as per explicit request]
>
> On Tue, 16 Oct 2007, Eli Zaretskii wrote:
>
> > > Date: Tue, 16 Oct 2007 01:56:46 -0400 (EDT)
> > > From: Daniel Barkalow <barkalow@iabervon.org>
> > > cc: raa.lkml@gmail.com, Johannes.Schindelin@gmx.de, ae@op5.se,
> > > tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org
> > >
> > > Ah, that's helpful. We don't actually care too much about the
> > > particular info in stat; we just want to know quickly if the file has
> > > changed, so we can hash only the ones that have been touched and get
> > > the actual content changes.
> >
> > As I wrote in my other message, using native APIs improves performance
> > by at least a factor of two.
>
> Somehow this does not appeal to my "portability is good" side. You know,
> if we had to do such trickeries for every platform we support, we'd soon
> be as big as Subversion *cough*.
I think that it would be a worthwhile project, from the point of view of
making the code easier to follow and making the internal APIs clearer, to
organize git's source to abstract the object database to read_sha1_file(),
has_sha1_file(), hash_sha1_file(), and write_sha1_file() as the arbiters
of what is in the local database (with other functions public as support
for over-the-wire protocols, which may, by not-really-coincidence, by used
for local storage as well); then Windows could have an entirely different
storage mechanism that doesn't rely on filesystem metadata speed.
It would also be worthwhile to untangle the index's stat cache aspects and
its tree-object-related aspects, so that there can be a platform- and
repository-specific concept of how to handle the working area, and then
Windows could do different stuff for the default case of setting up a
directory on the local filesystem.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Andreas Ericsson @ 2007-10-16 16:59 UTC (permalink / raw)
To: Eli Zaretskii
Cc: barkalow, raa.lkml, Johannes.Schindelin, tsuna, git, make-w32
In-Reply-To: <E1Ihfrl-0007w1-3I@fencepost.gnu.org>
Eli Zaretskii wrote:
>> From: Andreas Ericsson <ae@op5.se>
>
>> I *think* (correct me if I'm wrong) that git is still faster
>> than a whole bunch of other scm's on windows, but to one who's used to
>> its performance on Linux that waiting several seconds to scan 10k files
>> just feels wrong.
>
> Unless that 10K is a typo and you really meant 100K, I don't think 10K
> files should take several seconds to scan on Windows. I just tried
> "find -print" on a directory with 32K files in 4K subdirectories, and
> it took 8 sec elapsed with a hot cache. So 10K files should take at
> most 2 seconds, even without optimizing file traversal code. Doing
> the same with native Windows system calls ("dir /s") brings that down
> to 4 seconds for 32K files.
>
It was a typo. Thanks for correcting me.
> On the other hand, what packages have 100K files? If there's only one
> -- the Linux kernel -- then I think this kind of performance is for
> all practical purposes unimportant on Windows
But it's most definitely not. The *huge* projects that have looked at
git have sometimes turned it down simply because they're either cross-
platform (Mozilla) or they have translators that use windows exclusively
(KDE and Mozilla, just to mention two).
Both Mozilla and KDE repos are *much* larger than the Linux repo.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 09/25] Port builtin-add.c to use the new option parser.
From: Pierre Habouzit @ 2007-10-16 16:55 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <2209D123-A245-43C4-8DD9-A83386852556@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
On mar, oct 16, 2007 at 08:55:41 +0000, Michael Witten wrote:
>
> On 16 Oct 2007, at 4:39:42 AM, Pierre Habouzit wrote:
>
> >+ OPT_BOOLEAN('u', NULL, &take_worktree_changes, "update only files that
> >git already knows about"),
>
> "update only files in the current directory that git already knows about"
As a general rule, as I'm not a native speaker, I'd be glad if someone
went through the diffs and made it better english. I'm not sure what the
more efficient way to merge those corrections is, as I'm not able to see
if it's any better or not. So the someone mergint it (Shawn ?) may have
to go through every OPTION_* and check the helps strings, and --amend
fixes on top of the patches if needed. It looks like the best way to me.
Alternatively, a native speaker could propose a 26th patch that fixes
all of the bad strings on top of this series. But again, I won't do
that, not because of lazyness, just because I can't decide :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: Speed up get_projects_list for large source trees
From: Andreas Ericsson @ 2007-10-16 16:55 UTC (permalink / raw)
To: Luke Lu; +Cc: git
In-Reply-To: <3A2DCEC6-953A-41B0-AB9E-7374EEB625E8@vicaya.com>
Luke Lu wrote:
> Hi, I've been using git for a month now and loving it.
Hello Luke, and welcome to the community :)
> This is my first ever patch for git using git.
It shows. The patch is whitespace damaged, and the commit message leaves
a little something to desire. I suggest you read through
Documentation/SubmittingPatches and then re-send your patch. Try sending
to yourself and looking at the result with a monospace font. It's what I
always do to make sure patches look okay before sending them to the list.
Not trying to be rude or anything. Oldtime list-members sometimes get to
hear the exact same thing.
Also, Junio, the maintainer, is currently away, so don't worry if your
patches are left in limbo for some time. Someone will pick it up and
carry it forward for Junio to pull, or he'll hack up some script to
get all patces from his mailbox and review them one by one. He's a very
thorough fellow, usually.
> I spent sometime to find out why the
> project listing is taking 200s, everytime! I guess that gitweb is mostly
> used to serve bare repositories, which would never encounter such
> problems. It takes .2s, after the patch on my laptop. That's 1000x
> improvement for me (on Mac OS X 1.4.10.)
>
Sweet job :)
I'll have to test this, as we've got a few repos at work with a checked out
working tree connected to the repos. I haven't run into your issues though,
but perhaps that's because we run it under Linux.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: Pierre Habouzit @ 2007-10-16 16:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: René Scharfe, git, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0710161742040.25221@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]
On Tue, Oct 16, 2007 at 04:44:44PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 16 Oct 2007, Ren? Scharfe wrote:
>
> > Pierre Habouzit schrieb:
> > > This bit is to allow to aggregate options with arguments together when
> > > the argument is numeric.
> > >
> > > +#if 0
> > > + /* can be used to understand -A1B1 like -A1 -B1 */
> > > + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> > > + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> > > + return 0;
> > > + }
> > > +#endif
> >
> > I don't like it, it complicates number options with unit suffixes (e.g.
> > --windows-memory of git-pack-objects).
>
> Why? It only means that you cannot say -W10mxabc instead of -W10m xabc.
>
> Remember: this is a special case for OPT_INTEGER. Nothing to do with
> OPT_SIZE, which you'd probably implement as a callback.
Yeah but the point is that you can't migrate an option currently being
an integer to an OPT_SIZE because of that (see my other mail). Meaning
that once an argument is of type OPT_INTEGER you can't change it's type
in the future _AT ALL_ without breaking backward compatibility badly.
I'd say it's a rather sucky design.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: Pierre Habouzit @ 2007-10-16 16:50 UTC (permalink / raw)
To: René Scharfe; +Cc: git, Shawn O. Pearce
In-Reply-To: <4714E90C.80305@lsrfire.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]
On Tue, Oct 16, 2007 at 04:38:36PM +0000, René Scharfe wrote:
> Pierre Habouzit schrieb:
> > This bit is to allow to aggregate options with arguments together when
> > the argument is numeric.
> >
> > +#if 0
> > + /* can be used to understand -A1B1 like -A1 -B1 */
> > + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> > + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> > + return 0;
> > + }
> > +#endif
>
> I don't like it, it complicates number options with unit suffixes (e.g.
> --windows-memory of git-pack-objects).
Oh yeah, you're right, well you example is not an issue, but indeed
you pointed out a real probable issue:
With that chunk, if an option that takes now an integer, becomes an
option with a suffix, we would then break backward compatibility. I'm
not sure I'm clear, but if you had a -S option (for size) that for now
gets sizes in kilooctet, git foo -S1000. Then if we decide that it's
worth understanting M/G/.. suffixes for this option, we would make the
type of the option be a CALLBACK using git_parse_ulong. This would mean
that with such a change:
before:
git foo -S1000a would mean git foo -S1000 -a
After:
git foo -S1000a would be rejected because 'a' isn't a valid size
suffix.
This of course become worse if we take git foo -S1000k where the
breakage would be silent.
This is a very strong argument _against_ this chunk IMO.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-svn: use "no warnings 'once'" to disable false-positives
From: Eygene Ryabinkin @ 2007-10-16 16:50 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20071016074318.GA32348@soma>
Eric, good day.
Tue, Oct 16, 2007 at 12:43:18AM -0700, Eric Wong wrote:
> Thanks, minor nit regarding fixed in the patch below.
>
> "{ no warnings 'once';"
>
> on the same line as the "{"
Yes, I did this intentionally to signify that this block is used
just for the pragma. But I felt that it is against the style, so
you're right.
Thank you!
--
Eygene
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: Nicolas Pitre @ 2007-10-16 16:44 UTC (permalink / raw)
To: René Scharfe; +Cc: Pierre Habouzit, git, Shawn O. Pearce
In-Reply-To: <4714E90C.80305@lsrfire.ath.cx>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 603 bytes --]
On Tue, 16 Oct 2007, René Scharfe wrote:
> Pierre Habouzit schrieb:
> > This bit is to allow to aggregate options with arguments together when
> > the argument is numeric.
> >
> > +#if 0
> > + /* can be used to understand -A1B1 like -A1 -B1 */
> > + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> > + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> > + return 0;
> > + }
> > +#endif
>
> I don't like it, it complicates number options with unit suffixes (e.g.
> --windows-memory of git-pack-objects).
This is my opinion too.
Nicolas
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: Johannes Schindelin @ 2007-10-16 16:44 UTC (permalink / raw)
To: René Scharfe; +Cc: Pierre Habouzit, git, Shawn O. Pearce
In-Reply-To: <4714E90C.80305@lsrfire.ath.cx>
Hi,
On Tue, 16 Oct 2007, Ren? Scharfe wrote:
> Pierre Habouzit schrieb:
> > This bit is to allow to aggregate options with arguments together when
> > the argument is numeric.
> >
> > +#if 0
> > + /* can be used to understand -A1B1 like -A1 -B1 */
> > + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> > + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> > + return 0;
> > + }
> > +#endif
>
> I don't like it, it complicates number options with unit suffixes (e.g.
> --windows-memory of git-pack-objects).
Why? It only means that you cannot say -W10mxabc instead of -W10m xabc.
Remember: this is a special case for OPT_INTEGER. Nothing to do with
OPT_SIZE, which you'd probably implement as a callback.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: René Scharfe @ 2007-10-16 16:38 UTC (permalink / raw)
To: Pierre Habouzit, git, Shawn O. Pearce
In-Reply-To: <20071016084510.GI6919@artemis.corp>
Pierre Habouzit schrieb:
> This bit is to allow to aggregate options with arguments together when
> the argument is numeric.
>
> +#if 0
> + /* can be used to understand -A1B1 like -A1 -B1 */
> + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> + return 0;
> + }
> +#endif
I don't like it, it complicates number options with unit suffixes (e.g.
--windows-memory of git-pack-objects).
René
^ permalink raw reply
* RE: Switching from CVS to GIT
From: Dave Korn @ 2007-10-16 16:23 UTC (permalink / raw)
To: 'David Brown', 'Eli Zaretskii'
Cc: raa.lkml, barkalow, make-w32, Johannes.Schindelin,
'Andreas Ericsson', git
In-Reply-To: <20071016155608.GA10603@old.davidb.org>
On 16 October 2007 16:56, David Brown wrote:
> On Tue, Oct 16, 2007 at 02:25:21AM -0400, Eli Zaretskii wrote:
>
>> On the other hand, what packages have 100K files? If there's only one
>> -- the Linux kernel -- then I think this kind of performance is for
>> all practical purposes unimportant on Windows, because while it is
>> reasonable to assume that someone would like to use git on Windows,
>> assuming that someone will develop the Linux kernel on Windows is --
>> how should I put it -- _really_ far-fetched ;-)
>
> Oh, I wish others could think this clearly. Quoting a serious line off of
> a task list at an unnamed company:
>
> - Make Linux kernel compile under windows.
>
> I don't think it will move past just being a wish list item, but there seem
> to be people that think it should be done.
>
> Admittedly, they don't want developers doing it on windows, but want to
> integrate kernel building into a windows-heavy build and release process.
Do that kind of thing here all the time, hence my previous post. Apart from
the netfilter stuff with the filenames-that-match-in-all-but-case, no real
problems, took me a couple of hours one afternoon.
Cygwin is a good match for linux dev work.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply
* Re: Some git mv questions
From: Lars Hjemli @ 2007-10-16 16:05 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git list
In-Reply-To: <200710161733.49185.wielemak@science.uva.nl>
On 10/16/07, Jan Wielemaker <wielemak@science.uva.nl> wrote:
> * On a somewhat bigger test I moved a large directory using
> "git mv dir newdir" (where newdir is an existing directory).
> Now "git status" gives a lot of new and deleted files!?
You could try to adjust diff.renameLimit in .git/config
--
larsh
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Nicolas Pitre @ 2007-10-16 16:04 UTC (permalink / raw)
To: David Brown
Cc: Eli Zaretskii, Andreas Ericsson, barkalow, raa.lkml,
Johannes.Schindelin, tsuna, git, make-w32
In-Reply-To: <20071016155608.GA10603@old.davidb.org>
On Tue, 16 Oct 2007, David Brown wrote:
> On Tue, Oct 16, 2007 at 02:25:21AM -0400, Eli Zaretskii wrote:
>
> > On the other hand, what packages have 100K files? If there's only one
> > -- the Linux kernel -- then I think this kind of performance is for
> > all practical purposes unimportant on Windows, because while it is
> > reasonable to assume that someone would like to use git on Windows,
> > assuming that someone will develop the Linux kernel on Windows is --
> > how should I put it -- _really_ far-fetched ;-)
>
> Oh, I wish others could think this clearly. Quoting a serious line off of
> a task list at an unnamed company:
>
> - Make Linux kernel compile under windows.
>
> I don't think it will move past just being a wish list item, but there seem
> to be people that think it should be done.
Linux is compilable on Windows, and has been for a long time already.
With Cygwin it is pretty trivial to do. I prefer native Linux though.
Nicolas
^ permalink raw reply
* Re: Switching from CVS to GIT
From: David Brown @ 2007-10-16 15:56 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Andreas Ericsson, barkalow, raa.lkml, Johannes.Schindelin, tsuna,
git, make-w32
In-Reply-To: <E1Ihfrl-0007w1-3I@fencepost.gnu.org>
On Tue, Oct 16, 2007 at 02:25:21AM -0400, Eli Zaretskii wrote:
>On the other hand, what packages have 100K files? If there's only one
>-- the Linux kernel -- then I think this kind of performance is for
>all practical purposes unimportant on Windows, because while it is
>reasonable to assume that someone would like to use git on Windows,
>assuming that someone will develop the Linux kernel on Windows is --
>how should I put it -- _really_ far-fetched ;-)
Oh, I wish others could think this clearly. Quoting a serious line off of
a task list at an unnamed company:
- Make Linux kernel compile under windows.
I don't think it will move past just being a wish list item, but there seem
to be people that think it should be done.
Admittedly, they don't want developers doing it on windows, but want to
integrate kernel building into a windows-heavy build and release process.
David
^ permalink raw reply
* Re: On Tabs and Spaces
From: Michael Witten @ 2007-10-16 15:51 UTC (permalink / raw)
To: Jeffrey C. Ollie; +Cc: git
In-Reply-To: <1192548367.3821.4.camel@lt21223.campus.dmacc.edu>
On 16 Oct 2007, at 11:26:07 AM, Jeffrey C. Ollie wrote:
> Instead of using "(setq indent-tabs-mode t)" use "(setq indent-tabs-
> mode
> nil)". This will force emacs to always use spaces to indent.
That's part of the problem to begin with:
people are using both way of indentation.
I suggest this not be allowed, or that it
be the only way of indenting.
However, 8 spaces per tab is a lot of wasted
information to be bandying about.
Michael Witten
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jeffrey C. Ollie @ 2007-10-16 15:26 UTC (permalink / raw)
To: Adam Piatyszek; +Cc: Lars Hjemli, Michael Witten, git
In-Reply-To: <47148F72.1090602@users.sourceforge.net>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote:
>
> And if one change the tab size, it will result in a messy alignment in
> line 5.
Which is why one should never should change the tab size from anything
but 8.
> I guess there is no ideal solution for this in Emacs.
Instead of using "(setq indent-tabs-mode t)" use "(setq indent-tabs-mode
nil)". This will force emacs to always use spaces to indent.
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: Switching from CVS to GIT
From: Dave Korn @ 2007-10-16 15:47 UTC (permalink / raw)
To: 'Eli Zaretskii', 'Andreas Ericsson'
Cc: git, barkalow, raa.lkml, make-w32, Johannes.Schindelin
In-Reply-To: <E1Ihfrl-0007w1-3I@fencepost.gnu.org>
[-- Attachment #1: Type: text/plain, Size: 803 bytes --]
On 16 October 2007 07:25, Eli Zaretskii wrote:
> On the other hand, what packages have 100K files? If there's only one
> -- the Linux kernel -- then I think this kind of performance is for
> all practical purposes unimportant on Windows, because while it is
> reasonable to assume that someone would like to use git on Windows,
> assuming that someone will develop the Linux kernel on Windows is --
> how should I put it -- _really_ far-fetched ;-)
Hi there! Did someone call?
Cross-development in general isn't what I'd call "far-fetched", and there's
no law of cross-development that says the host has to be the same platform as
the target. :-)[*]
cheers,
DaveK
[*] - this smiley sponsored by the Department of the Bleedin' Obvious.
--
Can't think of a witty .sigline today....
[-- Attachment #2: developed-on-windows.diff --]
[-- Type: application/octet-stream, Size: 3660 bytes --]
Index: firmware_class.c
===================================================================
RCS file: /sources/repository/external_source/linux/linux-2.6.12.2/drivers/base/firmware_class.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -p -u -r1.1 -r1.2
--- firmware_class.c 17 Jan 2006 16:49:35 -0000 1.1
+++ firmware_class.c 15 Feb 2006 14:01:29 -0000 1.2
@@ -31,6 +31,7 @@ enum {
};
static int loading_timeout = 10; /* In seconds */
+static char grow_faster = 1; /* Boolean */
/* fw_lock could be moved to 'struct firmware_priv' but since it is just
* guarding for corner cases a global lock should be OK */
@@ -79,6 +80,28 @@ firmware_timeout_store(struct class *cla
static CLASS_ATTR(timeout, 0644, firmware_timeout_show, firmware_timeout_store);
+static ssize_t
+firmware_grow_faster_show(struct class *class, char *buf)
+{
+ return sprintf(buf, "%d\n", grow_faster);
+}
+
+/**
+ * firmware_grow_faster_store:
+ * Description:
+ * Sets or clears a flag that causes the reallocate routine to
+ * grow the firmware buffer size more or less quickly.
+ *
+ **/
+static ssize_t
+firmware_grow_faster_store(struct class *class, const char *buf, size_t count)
+{
+ grow_faster = simple_strtol(buf, NULL, 10) != 0;
+ return count;
+}
+
+static CLASS_ATTR(grow_faster, 0644, firmware_grow_faster_show, firmware_grow_faster_store);
+
static void fw_class_dev_release(struct class_device *class_dev);
int firmware_class_hotplug(struct class_device *dev, char **envp,
int num_envp, char *buffer, int buffer_size);
@@ -198,18 +221,27 @@ static int
fw_realloc_buffer(struct firmware_priv *fw_priv, int min_size)
{
u8 *new_data;
+ int new_size;
if (min_size <= fw_priv->alloc_size)
return 0;
- new_data = vmalloc(fw_priv->alloc_size + PAGE_SIZE);
+#define ONE_MEG (1024 * 1024)
+
+ new_size = grow_faster
+ ? ((fw_priv->alloc_size >= ONE_MEG)
+ ? (fw_priv->alloc_size + ONE_MEG)
+ : ((fw_priv->alloc_size >= PAGE_SIZE) ? (fw_priv->alloc_size * 2) : PAGE_SIZE))
+ : (fw_priv->alloc_size + PAGE_SIZE);
+ new_data = vmalloc (new_size);
if (!new_data) {
- printk(KERN_ERR "%s: unable to alloc buffer\n", __FUNCTION__);
+ printk(KERN_ERR "%s: unable to alloc buffer old size %d new size %d\n",
+ __FUNCTION__, fw_priv->alloc_size, new_size);
/* Make sure that we don't keep incomplete data */
fw_load_abort(fw_priv);
return -ENOMEM;
}
- fw_priv->alloc_size += PAGE_SIZE;
+ fw_priv->alloc_size = new_size;
if (fw_priv->fw->data) {
memcpy(new_data, fw_priv->fw->data, fw_priv->fw->size);
vfree(fw_priv->fw->data);
@@ -249,6 +281,13 @@ firmware_data_write(struct kobject *kobj
goto out;
memcpy(fw->data + offset, buffer, count);
+ /* A successful write should cause us to reset the timeout
+ delay, as very large firmware files might take a while to
+ send through the sysfs file. We have the fw_lock taken at
+ the moment but the timeout function doesn't lock as it only
+ has to set a single volatile bit, so we're ok to mod it. */
+ if (timer_pending (&fw_priv->timeout))
+ mod_timer (&fw_priv->timeout, jiffies + loading_timeout * HZ);
fw->size = max_t(size_t, offset + count, fw->size);
retval = count;
@@ -568,6 +607,12 @@ firmware_class_init(void)
__FUNCTION__);
class_unregister(&firmware_class);
}
+ error = class_create_file(&firmware_class, &class_attr_grow_faster);
+ if (error) {
+ printk(KERN_ERR "%s: class_create_file failed\n",
+ __FUNCTION__);
+ class_unregister(&firmware_class);
+ }
return error;
}
[-- Attachment #3: Type: text/plain, Size: 134 bytes --]
_______________________________________________
Make-w32 mailing list
Make-w32@gnu.org
http://lists.gnu.org/mailman/listinfo/make-w32
^ permalink raw reply
* RE: Problem with git-svnimport
From: VAUCHER Laurent @ 2007-10-16 15:48 UTC (permalink / raw)
To: git
In fact, I think the problem appears not with undescore characters but spaces in tag and branche names.
Do you think there's a way around this (other than manually renaming tags and branches in the SVN repository)?
Laurent.
-----Message d'origine-----
De : git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] De la part de VAUCHER Laurent
Envoyé : 16 October 2007 14:31
À : git@vger.kernel.org
Objet : !! SPAM Suspect : SPAM-URL-DBL !! Problem with git-svnimport
Hi.
Trying to convert a svn repository to git, I encountered the following
error:
Use of uninitialized value in hash element at /usr/bin/git-svnimport
line 534.
Line 534 reads:
my $gitrev = $branches{$srcbranch}{$therev};
I have installed packages git-core and git-svn on Ubuntu. These
package have versions: "1:1.5.2.5-2-feisty1"
The tool seems to choke on tags or branches with special characters
(underscore, for instance).
Laurent.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-16 15:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: barkalow, raa.lkml, ae, tsuna, git
In-Reply-To: <Pine.LNX.4.64.0710161617490.25221@racer.site>
> Date: Tue, 16 Oct 2007 16:18:10 +0100 (BST)
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> cc: barkalow@iabervon.org, raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr,
> git@vger.kernel.org
>
> > That's a ``feature'': Explorer is the parent of all the desktop
> > display. Kinda like the login shell on Unix: if you kill it, there
> > goes your whole session. Except that on Windows, the OS pays
> > attention and restarts Explorer right away to get you back in
> > business. (In first versions of Windows, there was no restarting of
> > Explorer, so if you killed it, you needed to reboot :-()
>
> I kinda knew that. But what's now with your recommendation to never run
> Explorer?
I meant not to open "My Computer" and use the GUI for browsing the
directories. If you meant that the touching of files is done even if
you don't open the GUI, then just ignore my advice: Explorer cannot be
killed. I'm surprised that it touches files and directories,
though...
^ permalink raw reply
* Some git mv questions
From: Jan Wielemaker @ 2007-10-16 15:33 UTC (permalink / raw)
To: git list
Hi,
For the impatient, start [HERE].
I'm about to start shuffling files and directories around in a big project,
while others keep working on their files. This is a bit scary as I
still feel pretty much newbie in the GIT world :-)
I did a little test as follows. Given a shared repository sandbox.git
with a file in there I did the following, which worked fine.
* [player one] clone the DB, edit the file, commit and push
* [player two] clone the DB
- git branch shuffle
- git checkout shuffle
- mkdir SomeDir
- git mv file SomeDir
- edit SomeDir/file
- git commit -a
* Sofar so good, now merge:
- git checkout master
- git pull (get player 1 changes)
- git merge shuffle
- git branch -d shuffle
- git commit -a
- git push
Sofar so good, but during the tests I had two times problems:
* Instead of "git mv file SomeDir" I simply used "mv file SomeDir"
and git-add. Now I end up with two files and of course the changes
are not merged. I can understand that.
[HERE]
* On a somewhat bigger test I moved a large directory using
"git mv dir newdir" (where newdir is an existing directory).
Now "git status" gives a lot of new and deleted files!? I
guess I'm going to have a big mess if that happens in the
real project. Moving some smaller test directories simply
showed a series of renames.
Can this be explained? Is this a bug?
Thanks --- Jan
^ permalink raw reply
* Re: [PATCH 09/25] Port builtin-add.c to use the new option parser.
From: Michael Witten @ 2007-10-16 15:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0710161417150.25221@racer.site>
On 16 Oct 2007, at 9:17:29 AM, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 16 Oct 2007, Michael Witten wrote:
>
>> On 16 Oct 2007, at 4:39:42 AM, Pierre Habouzit wrote:
>>
>>> + OPT_BOOLEAN('u', NULL, &take_worktree_changes, "update only files
>>> that git already knows about"),
>>
>> "update only files that git already knows about in the current
>> directory"
>
> "update tracked files"
"update tracked files in ."
;-)
Consider the description for git-commit's -a:
> Tell the command to automatically stage files that have been
> modified and deleted, but new files you have not told git about
> are not affected.
However, that's not what -u does.
^ permalink raw reply
* Re: [PATCH 3/3] git-cvsexportcommit.perl: git-apply no longer needs --binary
From: Michael Witten @ 2007-10-16 15:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710161404220.25221@racer.site>
On 16 Oct 2007, at 9:04:34 AM, Johannes Schindelin wrote:
> Hi,
>
> does --binary hurt?
It's a no op according to the documentation.
In my experience, the healthier the trees are,
the healthier the forest is.
Michael Witten
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-16 15:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: barkalow, raa.lkml, ae, tsuna, git
In-Reply-To: <E1Ihnvq-0002Xr-F9@fencepost.gnu.org>
Hi,
On Tue, 16 Oct 2007, Eli Zaretskii wrote:
> > Date: Tue, 16 Oct 2007 14:24:34 +0100 (BST)
> > From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> > cc: barkalow@iabervon.org, raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr,
> > git@vger.kernel.org
> >
> > Funny. Last time I checked the toolbar went away, as well as the desktop,
> > when I killed explorer.exe.
>
> That's a ``feature'': Explorer is the parent of all the desktop
> display. Kinda like the login shell on Unix: if you kill it, there
> goes your whole session. Except that on Windows, the OS pays
> attention and restarts Explorer right away to get you back in
> business. (In first versions of Windows, there was no restarting of
> Explorer, so if you killed it, you needed to reboot :-()
I kinda knew that. But what's now with your recommendation to never run
Explorer?
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-16 15:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, git list
In-Reply-To: <471455ED.8070408@viscovery.net>
Hi,
On Tue, 16 Oct 2007, Johannes Sixt wrote:
> Shawn O. Pearce schrieb:
> > Johannes Sixt <j.sixt@viscovery.net> wrote:
> > > Unfortunately, "Fetch" does not yet work[*] from within git-gui, so you
> > > have to fall back to git-fetch on the command line.
> > >
> > > [*] Note the distinction between "not available" and "does not work".
> >
> > What's broken? Is this that Git protocol dump showing up in
> > git-gui's console window thing?
> >
> > Are you using the C based fetch that is in git.git's next branch,
> > or the shell script based one that is in master? Which Tcl/Tk
> > version are you using to run git-gui?
>
> It's the scripted fetch that does not work. The symptom is that the output of
> at least one of the commands (upload-pack, I think, because what I see is
> wire protocol) goes to a newly spawned console instead of wherever it was
> redirected to.
>
> I didn't bother reporting since builtin-fetch is on the way (which will
> hopefully make this a moot point) and our team here is comfortable with
> calling git fetch on the command line.
Note that Issue 57 on msysgit.googlecode.com talks exactly about the same
issue.
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-16 15:12 UTC (permalink / raw)
To: Johannes Schindelin
Cc: prohaska, git, robin.rosenberg.lists, barkalow, raa.lkml, tsuna,
ae
In-Reply-To: <Pine.LNX.4.64.0710161512450.25221@racer.site>
> Date: Tue, 16 Oct 2007 15:14:19 +0100 (BST)
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> cc: Git Mailing List <git@vger.kernel.org>,
> Robin Rosenberg <robin.rosenberg.lists@dewire.com>,
> Eli Zaretskii <eliz@gnu.org>, Daniel Barkalow <barkalow@iabervon.org>,
> Alex Riesen <raa.lkml@gmail.com>, tsuna@lrde.epita.fr,
> Andreas Ericsson <ae@op5.se>
>
> So I think this will always be something Windows users would wish to
> impose onto others, while Linux users would always refuse.
Here is one Windows user that will never try to impose that ;-)
However, it's possible that an option could be supported to do that
when the user particularly wants that in her database. Just a
thought...
^ 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