Windows: problems with too long command line calls

Matt Mackall mpm at
Fri Oct 28 16:14:01 CDT 2011

On Fri, 2011-10-28 at 20:20 +0200, Marc Strapetz wrote:
> On 28.10.2011 19:12, Matt Mackall wrote:
> > On Fri, 2011-10-28 at 17:59 +0200, Martin Geisler wrote:
> >> Marc Strapetz <marc.strapetz at> writes:
> >>
> >>> For our Mercurial GUI client, the user can select an arbitrary set of
> >>> files to perform local operations (like add or commit) for. This set
> >>> of files is directly passed to the hg executable. The problem is that
> >>> (at least) on Windows, there is a limitation on the maximum command
> >>> line length. Hence, if too many files are specified, the user will get
> >>> "The filename or extension is too long.":
> >>>
> >>>
> >>>
> >>> We can work-around that for many commands, by splitting the overall
> >>> set of files into multiple smaller sets. However this does not work
> >>> for "hg commit" and "hg addremove --similarity".
> >>>
> >>> As far as I understand there is currently no alternate way to specify
> >>> the set of files e.g. through a file, similar as for "hg commit
> >>> --message <file>"? Are there any other work-arounds for that problem?
> >>
> >> Use the 'listfile:' syntax described in 'hg help patterns'.
> Thanks, this works perfectly!
> > Or use the command server protocol:
> > 
> >
> Looks promising. The page mentions "Text parsing required" as a downside
> of the command line. This will obviously be helpful for commands like
> "status" or "log", but will the command server give more detailed and
> better processable information also for commands like "commit" or
> "addremove"? Currently, for these commands we are just piping Hg's
> output to a text area. A more structured output would be desirable and
> I'm wondering if we could gain something here when using the command server?

No and yes. No: the protocol is more or less identical to the command
line. Yes: the parsing 'smarts' can be put in a library that everyone
can use.

Mathematics is the supreme nostalgia of our time.

More information about the Mercurial-devel mailing list