Let's try something else:
$ fossil rm win/include
DELETED win/include/dirent.h
DELETED win/include/unistd.h
$ rm -rf win/include
$ fossil status
..
DELETEDwin/include/dirent.h
DELETEDwin/include/unistd.h
$ fossil commit win/include
not found: win/include
continue (y/N)? y
none
2013/7/4 Jan Nijtmans jan.nijtm...@gmail.com:
Well, when I did this commit:
http://core.tcl.tk/itcl/info/0805477fbf
what I did was a fossil commit . while the current directory
was generic. So, why was Makefile.in committed then?
Found the bug:
2013/6/28 Stephan Beal sgb...@googlemail.com:
i dunno - it kinda looks like 3 minutes of your work to me:
http://www.fossil-scm.org/index.html/info/c8253f4066
But the beer's still on the table, as it were, if you want to claim it.
;)
Well, when I did this commit:
On Fri, Jun 21, 2013 at 4:00 PM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Jun 21, 2013 at 3:57 PM, Richard Hipp d...@sqlite.org wrote:
I've already been working on the problem for 10 minutes.
Okay, we'll take your word for it! ;)
i dunno - it kinda looks like 3 minutes of your
2013/6/20 Stephan Beal sgb...@googlemail.com:
Any chance of adding the same to ls as well?
Hm..
$ ./fossil ls win/include
win/include/dirent.h
win/include/unistd.h
$ rm -rf win/include;fossil status
MISSINGwin/include/dirent.h
MISSINGwin/include/unistd.h
$ ./fossil ls win/include
just a thought: a somehow related feature would be the ability to do
something like
fossil ci {dirname}
where {dirname} is one of the directories found in the checkout which then
should restrict the ci to everything recursively found in {dirname} and
below. personally I don't miss such a
2013/6/21 j. van den hoff veedeeh...@googlemail.com:
just a thought: a somehow related feature would be the ability to do
something like
fossil ci {dirname}
Yes, that would be consistant with fossil clean|extras|ls to allow that, but
it's not completely trivial. The query that should be
On Fri, Jun 21, 2013 at 3:43 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
That will no longer be true.. Richard can do that in 5 minutes, but
for everyone else it will take much longer ;-)
i'll bet 5 Euros that he could do it in THREE minutes ;)
--
- stephan beal
On Fri, Jun 21, 2013 at 9:54 AM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Jun 21, 2013 at 3:43 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
That will no longer be true.. Richard can do that in 5 minutes, but
for everyone else it will take much longer ;-)
i'll bet 5 Euros
On Fri, Jun 21, 2013 at 3:57 PM, Richard Hipp d...@sqlite.org wrote:
I've already been working on the problem for 10 minutes.
Okay, we'll take your word for it! ;)
I think that means you owe me a weissbier the next time I'm in München!
Duly noted!
--
- stephan beal
2013/6/21 Stephan Beal sgb...@googlemail.com:
On Fri, Jun 21, 2013 at 3:57 PM, Richard Hipp d...@sqlite.org wrote:
I've already been working on the problem for 10 minutes.
Implemented fossil changes and fossil status now, which is much
simpler. It took me 25 minutes
Regards,
Jan
Hello all,
I would like to see this feature request granted. Is there any
objection to merging branch [ticket-967cedbf20] to trunk?
It will allow the fossil extra and fossil clean to be given
extra arguments, specifying a subset (directories or files)
of the directory structure where the
On Thu, Jun 20, 2013 at 9:26 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
I would like to see this feature request granted. Is there any
objection to merging branch [ticket-967cedbf20] to trunk?
:)
Any chance of adding the same to ls as well?
Side-note: the graph view in the www ui never
+1
On Thu, Jun 20, 2013 at 6:26 AM, Stephan Beal sgb...@googlemail.com wrote:
On Thu, Jun 20, 2013 at 9:26 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
I would like to see this feature request granted. Is there any
objection to merging branch [ticket-967cedbf20] to trunk?
:)
Any
14 matches
Mail list logo
