On Mon, Feb 6, 2012 at 23:26, Richard Hipp d...@sqlite.org wrote:
A lot of people have been telling me that they prefer the unified or
context style in-line diffs over side-by-side diffs. And I have to admit
that sometimes an in-line diff is easier to read and understand. But
side-by-side
On Mon, Feb 06, 2012 at 11:26:16PM -0500, Richard Hipp wrote:
A lot of people have been telling me that they prefer the unified or
context style in-line diffs over side-by-side diffs. And I have to admit
that sometimes an in-line diff is easier to read and understand. But
On Mon, Feb 06, 2012 at 10:54:50PM -0600, Bill Burdick wrote:
I think something like this would help the traditional diff format a
lot: http://www.redmine.org/issues/7139
Bill
Latest changes doesn't something like that?
--
Martin G.
___
On Tue, Feb 07, 2012 at 06:11:42AM -0500, Martin Gagnon wrote:
On Mon, Feb 06, 2012 at 10:54:50PM -0600, Bill Burdick wrote:
I think something like this would help the traditional diff format a
lot: http://www.redmine.org/issues/7139
Bill
Latest changes doesn't something like
Hi Richard,
please, find attached a patch that introduces --brief (short -q)
option to fossil diff that acts analogous to regular diff --brief
or diff -q. It suppresses diff contents and outputs just the file
names that differ. Output format is similar to fossil changes.
But unlike fossil changes
Sorry -- I didn't explain that. Look at the second highlighted section:
foo = User is shown in light colors both red and green because those
parts of the lines are the same in each version but the parts of the lines
that are different are shown in darker colors.
Bill
2012/2/7 Lluís Batlle i
hi there,
the motivation for this patch was that the zip and tarball links
from the web ui get a filename and checkout for free, while they
are a mandatory parameters for the command line.
so i tried to unify it a bit: the default archive name is now both
from web and cli the same, a lowercased
On Tue, Feb 7, 2012 at 7:48 PM, frantisek holop min...@obiit.org wrote:
so i tried to unify it a bit: the default archive name is now both
from web and cli the same, a lowercased project name followed by the
artifact ID. spaces are substituted with '-'.
Hi!
Out of curiosity: why force
hmm, on Tue, Feb 07, 2012 at 08:59:37PM +0100, Stephan Beal said that
On Tue, Feb 7, 2012 at 7:48 PM, frantisek holop min...@obiit.org wrote:
so i tried to unify it a bit: the default archive name is now both
from web and cli the same, a lowercased project name followed by the
artifact
On Tue, Feb 7, 2012 at 9:44 PM, frantisek holop min...@obiit.org wrote:
hmm, on Tue, Feb 07, 2012 at 08:59:37PM +0100, Stephan Beal said that
Out of curiosity: why force lower-case? That seems like an arbitrary
decision without a technical reason. i have one Java tree in Fossil for
which i
hmm, on Tue, Feb 07, 2012 at 09:48:23PM +0100, Stephan Beal said that
In any case, i like the feature, i just don't like the forced lower-casing.
(To be clear: not that my vote counts for anything!)
well it all comes down to if project name is a good
data source for a filename..
anyway, i feel
Agreed completely - spaces in filenames are evil. (let the flame wars begin
;)
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
On Feb 7, 2012 10:21 PM, frantisek holop min...@obiit.org wrote:
hmm, on Tue, Feb 07, 2012 at 09:48:23PM +0100, Stephan Beal said that
Hi List,
I wonder why _FOSSIL_ file grows so fast. I did some little work with
a clone of fossil source code repository (23MB) and over space of two
days _FOSSIL_ reached 10MB. What gives?
--Leo--
___
fossil-users mailing list
On Tue, Feb 7, 2012 at 7:24 PM, Leo Razoumov slonik...@gmail.com wrote:
Hi List,
I wonder why _FOSSIL_ file grows so fast. I did some little work with
a clone of fossil source code repository (23MB) and over space of two
days _FOSSIL_ reached 10MB. What gives?
The _FOSSIL_ file contains
14 matches
Mail list logo
