On Wed, Jun 3, 2015 at 10:24 AM, Jan Nijtmans
wrote:
> 2015-04-25 1:29 GMT+02:00 Ron W :
> > Would it be reasonable for Fossil to have a setting, or option in the
> > diff/gdiff command setting, to indicate that relative paths should be
> > supplied?
>
> You suggesti
On Fri, May 29, 2015 at 6:29 PM, wrote:
> As to what happened you probably guessed right. I must have used the
> --branch option from within the 'mistake' branch. I was (until just now)
> under the impression that the --branch option either starts a new branch
> (if the name given is not alread
On Fri, May 29, 2015 at 10:45 AM, Andy Bradford
wrote:
> Thus said Luca Ferrari on Fri, 29 May 2015 13:59:17 +0200:
>
> > But if I could say, the option "newbranch" does not look good at me,
> > since it a little too long.
>
> Fossil can have both long and short names for a given option,
On Fri, May 29, 2015 at 7:59 AM, Luca Ferrari wrote:
> On Fri, May 29, 2015 at 1:56 AM, Andy Bradford
> wrote:
> > fossil edit UUID ?OPTIONS?
>
> I'll second that!
> But if I could say, the option "newbranch" does not look good at me,
> since it a little too long. Coming from git I'm used to a s
On Thu, May 28, 2015 at 1:50 PM, Andy Bradford
wrote:
>
> It is possible. I've done it. It just takes a strong understanding of
> how propagating tags works and requires multiple commands with just the
> right types of tags. There is not yet a single command that will do
> this, so you
On Thu, May 28, 2015 at 2:56 PM, Andy Bradford
wrote:
>
>
> So perhaps something similar like:
>
> fossil branch mv BRANCH-NAME BASIS
I think "fossil branch mv BASIS BRANCH-NAME" is more intuitive (also
consistent with "fossil mv OLDNAME NEWNAME")
___
On Thu, May 28, 2015 at 8:31 AM, Luca Ferrari wrote:
> On Tue, May 26, 2015 at 6:14 PM, Ron W wrote:
> > As I understand it, you need to add 2 tags: "branch=mybranch" and
> > "sym-mybranch"
>
> Uhm..I've done a few experiments and appar
On Wed, May 27, 2015 at 3:06 PM, j. van den hoff
wrote:
> On Wed, 27 May 2015 19:24:38 +0200, Ron W wrote:
>>
>> On Wed, May 27, 2015 at 6:10 AM, j. van den hoff <
>> veedeeh...@googlemail.com>
>> wrote:
>>
>> the "request to work on branch&q
On Wed, May 27, 2015 at 8:01 AM, Martin Gagnon wrote:
>
> I wonder if it would be a good idea to implement a new feature that
> would be half way between per-branch push permission and emailing
> bundles ?
>
I am wondering if there's a way to do a pull in such a way that it could be
"purged" simi
On Wed, May 27, 2015 at 7:25 AM, Richard Hipp wrote:
> Fossil provides capabilities that make
> it trival for the instructor to see that a student has pushed to
> trunk
It would be even more trivial to see such pushes if fossil time line could
color the user names in the timeline display. Even
(Sorry, accidently clicked the "Send" button when trying to click the
"unfold" icon in the editor.)
On Wed, May 27, 2015 at 6:10 AM, j. van den hoff
wrote:
> the "request to work on branch" is the catch: he wants to ensure that
> students can never mess up trunk
You could achieve a "safety net
On Wed, May 27, 2015 at 6:10 AM, j. van den hoff
wrote:
> a colleague is considering to use fossil in a setup where he (the group
> leader) supervises several students having dedicated tasks within a larger
> project. what he would like to do is
>
> * set up master repo
>
> * give student(s) clon
On Wed, May 27, 2015 at 7:25 AM, Richard Hipp wrote:
> The other approach would be to deny "push" privileges to the students
> and force them to email in "bundles" that contain their changes, to be
> added back to the trunk administratively by the instructor. That's a
> lot more work on the inst
This is certainly an interesting project. Thanks.
I think this is a further example of the value of having a page on the
Fossil website listing community projects that could be useful to other
users of Fossil.
On Wed, May 27, 2015 at 11:42 AM, Remco Schoen wrote:
> Hi all,
>
> I have been play
On Mon, May 25, 2015 at 6:48 AM, Luca Ferrari wrote:
> Hi all,
> I tried to move commits to another thread using tags but I was unable to
> do it:
>
> fossil tag add --propagate mybranch 455802dfc6
> fossil tag cancel trunk 455802dfc6
>
> but the timeline always shows me the commits as being in t
On Mon, May 25, 2015 at 5:02 AM, Luca Ferrari wrote:
>
> Great, this works!
> Is there a way to make this inter-repository? I would not have to
> redefine the report for every repository.
Fossil has a means to export/import configuration settings, see
http://localhost:8080/help?cmd=configuration
On Fri, May 22, 2015 at 7:54 AM, Luca Ferrari wrote:
>
> I'm just curious to know if there is a way to list open tickets from
> the command line, that would be useful for instance to see the ticket
> id to place in a commit message without using the ui. I don't believe
> the timeline is appropriat
On Tue, May 19, 2015 at 10:33 PM, bch wrote:
> I don't understand what you mean when you say "tag". Could you elaborate
> or rephrase your problem?
>
See http://fossil-scm.org/index.html/help?cmd=tag
Basically, Michai is requesting a --recent option to the "fossil tag list"
command, where "recen
On Sun, May 17, 2015 at 3:42 PM, Andy Goth wrote:
> I just checked in something that's been lurking in my stash since April
> of last year. It inhibits links from check-in comments to deleted/empty
> wiki pages.
>
In the context of a commit comment, it does make sense despite the very
common Wi
I think you have to login to A.fossil to obtain a (shared) session cookie.
After that your users should be able to access B.fossil with out loging in
to B.fossil
On Friday, May 15, 2015, Ross Berteig wrote:
> I use fossil a lot internally. I've meant to try the login-group feature
> since it wa
On Thu, May 14, 2015 at 4:37 PM, paul wrote:
>
> But a developer could just disable the hook code in the local repository?
> There wouldn't be anything to stop that. Or am I misunderstanding something?
>
If a dev wants to do that, he could. But a dev who is merely distracted, is
unlikely to do th
On Thu, May 14, 2015 at 1:51 PM, paul wrote:
> It wouldn't offer much control over a distracted programmer, because
> your local repo is always going to be under the full control of the user on
> the local machine - no hacking required.
>
As I previously pointed out, with any DVCS - not just Fo
On Wed, May 13, 2015 at 11:45 AM, Ramon Ribó wrote:
> A reasonable solution could be a pre-commit hook, where the script in TH1
> or TCL had access to the branch name of the commit and other details. As a
> result, the hook could accept the commit, raise a warning, ask for
> confirmation or deny
On Tue, May 12, 2015 at 7:51 PM, Scott Robison
wrote:
>
> None of these are impossible obstacles to overcome, but taken together as
> a whole they do mean there is a significant amount of work to be done to
> ensure policies are enforced, because the first time a policy is not
> enforced for any r
On Mon, May 11, 2015 at 11:52 PM, Andy Goth wrote:
> On 5/11/2015 3:08 PM, Ron W wrote:
> > Another possible work-around (besides what Andy and I suggested) would
> > be for contributing devs to mark their trunks (and other designated
> > "protected" branches)
On Mon, May 11, 2015 at 10:51 AM, Abilio Marques wrote:
>
> Note also that this goes against one of the founding principles of
>> Fossil: that the VCS should implement mechanism not policy. That is
>> to say, details of who should be able to check-in to which branches
>> and whatnot should not b
Fossil has the capability to exclude private branches. Could a variation of
this capability be used to push only a particular named branch?
If this could be done, then a minor change to pull could allow a named
pull. (By telling the remote Fossil which branch to "push".)
__
On Mon, May 11, 2015 at 12:48 PM, Andy Goth wrote:
>
> Of course this is far too much to ask to directly build into Fossil, but
> that doesn't mean Fossil's scripting mechanism can't be extended to the
> point where it can enforce this policy.
>
I have yet to even experiment with Fossil's recentl
On Mon, May 11, 2015 at 10:51 AM, Abilio Marques wrote:
>
> Note also that this goes against one of the founding principles of
>> Fossil: that the VCS should implement mechanism not policy. That is
>> to say, details of who should be able to check-in to which branches
>> and whatnot should not b
On Thu, May 7, 2015 at 5:39 AM, Alaric Snell-Pym
wrote:
>
> For various reasons, I'd like to split the wiki out of a repo I have
> into a fresh new repo of its own. I'm guessing I can do something like a
> fossil deconstruct, delete anything that's not a wiki-change artifact,
> and then reconstru
On Mon, May 4, 2015 at 2:09 PM, John Found wrote:
> On Fri, 1 May 2015 14:34:46 -0400
> Richard Hipp wrote:
>
> > We need the signed Contributors Agreement (CA) so that we can prove
> > that your code is open source if that fact is ever disputed.
> >
> > The CA says, in essence, "yes my contribu
On Fri, May 1, 2015 at 8:56 PM, Andy Goth wrote:
>
> My point is that any attempt to access my repository other than through
> one of the few expected hostnames is clearly illegitimate, and I wish to
> block it. Because this is an application-layer thing, this cannot be
> done with iptables, onl
On Thu, Apr 30, 2015 at 5:03 PM, John Found wrote:
> Well, the first version of my new skin is ready and uploaded. I named it
> "ProgrammingClassic".
>
> Any opinions about improvements are welcome.
I like it. The maximum width of the main text area (the "paper") is a
little low, so I see a lot
On Thu, Apr 30, 2015 at 2:57 PM, Scott Robison
wrote:
> On Thu, Apr 30, 2015 at 11:36 AM, Ron W wrote:
> True, but I can see the utility of the request. If someone is looking for
> an exploitable host, they probably haven't built a table of every host name
> that maps to t
On Thu, Apr 30, 2015 at 10:36 AM, Andy Goth wrote:
> Seems I have a lot of people trying to access my repository who have no
> business doing so:
>
> I'd like to limit access based on the HTTP/1.1 Host: header. If Host:
> isn't un.is-a-geek.com or un.is-a-geek.com. (note final period) then
> jus
On Tue, Apr 28, 2015 at 3:05 PM, Jonathan Hankins <
jhank...@homewood.k12.al.us> wrote:
> First of all, is this the intended behavior?
>
The --ignore option behaves as documented.
> Secondly, is this common enough to warrant complicating the processing of
> the existing --ignore option?
>
I en
On Mon, Apr 27, 2015 at 4:04 PM, Richard Boehme wrote:
> Tried again and it didn't hang:
>
> SSL: proxy connect failed with HTTP status code 403
> Sync done, sent: 0 received: 0 ip:
>
HTTP 403 is a general "forbidden" response. Further explanation by the
server sending this response is optiona
The existing --ignore option overrides any "ignores" in the project's
settings. Sometimes, it would be very useful to have a "++ignore" option to
specify additional "ignores".
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fo
On Mon, Apr 27, 2015 at 9:07 AM, Richard Boehme wrote:
> They are distinct, but I needed some way to see what my proxy's
> response was, and it looks like it needs to look like a certain web
> browser - it looks like the proxy rejects anything that isn't
> Internext Explorer 9. When I try to conn
On Sat, Apr 25, 2015 at 6:05 PM, Matt Welland
wrote:
> A fork is seen as a failure of fossil to handle a commit that requires
> tiresome manual intervention to fix.
>
But, doesn't a blocked merge due to a pull that results in a fork require
significant manual intervention to resolve?
It's all w
On Sat, Apr 25, 2015 at 6:05 PM, Matt Welland
wrote:
> The expectation is that if a commit succeeds *it is a part of the series
> of commits on that branch*. This expectation is valid in git, it is valid
> in subversion, it is valid in DesignSync. It is not valid in Fossil.
>
Regarding Git, if c
A new coworker opted to use Cygwin on her PC rather than have a second PC
with Linux. The external gdiff command she configured is winmerge.exe - a
Windows application.
In the Cygwin command window, she did a "fossil gdiff". Winmerge complained
about
"/cygdrive/c/Projects/JL_PEPS_KVM/code/source/d
On Fri, Apr 24, 2015 at 6:51 AM, Alaric Snell-Pym
wrote:
>
> I know we could fit a Web forum in there "relatively easily" (just,
> y'know, all the work producing a usable user interface and that). But I
> find web forums less usable than mailing lists :-)
>
The "technote" feature already allows a
On Fri, Apr 24, 2015 at 8:26 AM, Svyatoslav Mishyn
wrote:
>
> What am I missing ?
>
> https://cloud.openmailbox.org/public.php?service=files&t=a42e1dab28fe9574bca06dca77feb8fd
>
> I made
> initial:
> git fast-export --all --export-marks=$new > $export
> cat $export | fossil import --git $fossilRep
On Wed, Apr 22, 2015 at 9:50 PM, Andy Bradford
wrote:
> Also, it only warns if it encounters a fork that has not
> previously been seen
Only for sync, or does it also only report new forks when "fossil forks" is
run? In my opinion, "fossil forks" should report all forks, even previously
detect
On Wed, Apr 22, 2015 at 4:03 PM, Svyatoslav Mishyn
wrote:
>
> lightweight (non-annotated) tags vs. annotated tags
> How to export tags (from fossil to git) ?
>
> I got this error, and did not get any tags
> error: Multiple updates for ref 'refs/tags/release' not allowed.
>
> with quick fix (aka li
On Tue, Apr 21, 2015 at 5:27 AM, Natacha Porté
wrote:
>
> So to make it short, the fossil repository is a prefix of what the git
> mirror currently is, with the extra git nodes being generated by git.
>
> Is there any way to backport the git commits into the fossil repository
> and still have an a
On Mon, Apr 20, 2015 at 12:43 PM, Warren Young wrote:
>
> Obviously such files need to live in their native tool to allow for
> updates, but most people you are communicating a “finished” design to don’t
> need to have the ability to edit the original diagram. If the diagram
> needs to change aft
On Mon, Apr 20, 2015 at 6:20 PM, Kevin Youren wrote:
>
> Hence the superiority of Fossil with a Wiki versus GIT without. My guess
> is GIT will catch up.
>
FYI, wiki and issue tracking can be layered on top of Git, SVN and others
using Trac, Redmine or similar. While there are pre-integrated pack
On Sat, Apr 18, 2015 at 7:14 AM, Matt Welland
wrote:
>
> For fossil to be a viable long term solution in a intensely busy project I
> believe the following is needed:
>
> 1. The optimal solution, where possible, don't let forks happen at all.
> Git does this at a very slight cost to data safety.
On Fri, Apr 17, 2015 at 6:41 PM, wrote:
> Thank you but I wanted this for a Win7 machine, not Linux.
> (I have MINGW installed but its 'patch' is a bit unstable as it crashes
> most of the time besides not being available on most Win7 machines.)
>
> Thanks, anyway. I guess I need to look for a r
On Fri, Apr 17, 2015 at 7:24 AM, Joerg Sonnenberger wrote:
> As discussed earlier, a fork means more than one
> leaf for the same branch.
And merging the leaf of a branch to another branch (maybe trunk) does not
make that leaf not-a-leaf. So why should merging a "fork-leaf" to whatever
make the
Hello,
Did you mean for your reply to go only to me? You did not CC the Fossil
list.
On Thu, Apr 16, 2015 at 9:07 PM, Steve Stefanovich wrote:
>
>*From: *Ron W
> *Sent: *Friday, 17 April 2015 11:04
> *To: *Fossil SCM user's discussion
> *Reply To: *Fossil SCM user
On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford
wrote:
> And a fork that ends in being merged is also no longer a fork.
I disagree. While it might be the most common case, merging does not
explicitly state any intent beyond the merge itself, even a full merge.
After all, a merge doesn't automati
On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison
wrote:
>
> Some thoughts:
>
> More seriously, the Wikipedia article on forking is probably worth a read:
> http://en.wikipedia.org/wiki/Fork_(software_development)
>
> I would claim that github is the odd man out here, having appropriated a
> term tha
On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland
wrote:
> Since these are effectively forks that have been resolved by merging is it
> possible to detect them as such and not report them?
>
I think they probably could be reported as "merged forks", but I'm not sure
that adds value. What if someone
On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland
wrote:
>
>
> On Thu, Apr 16, 2015 at 5:37 AM, Jan Nijtmans
> wrote:
>
>> 2015-04-16 13:44 GMT+02:00 Matt Welland :
>> > I'm confused by this. If the fork was merged to trunk it is no longer a
>> fork
>> > and should not be detected. Can you elaborate
On Thu, Apr 16, 2015 at 2:41 PM, Andy Bradford
wrote:
> This document contains what Fossil considers a fork:
>
> https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki
Yes. And the _connotation_ of the term "fork" within the Fossil community
is unintended/accidental commit to a pare
On Thu, Apr 16, 2015 at 1:30 PM, James Moger wrote:
> Mercurial would call a Fossil fork a "head"[1].
>
> -J
>
> [1]: http://mercurial.selenic.com/wiki/MultipleHeads
>
That would be what Fossil calls a "Leaf". I suppose, one could argue that,
in Fossil, a "fork" is a special case of a "leaf", bu
As the flurry of discussion of "forks" starts to ebb, it occurred to me
there is a conflict between how Fossil defines "fork" and how many open
source project define "fork".
Fossil defines "fork" as an accidental, unintended "branch" in the commit
history.
But, to many in the open source communit
On Tue, Apr 14, 2015 at 3:11 PM, Andy Bradford
wrote:
> What if the fork is intentially left unhandled? This means that all
> parties will be alerted to the fact that there exists a fork because it
> was intentionally left a fork. Is this acceptable? Will this be
> confusing for a
On Fri, Apr 10, 2015 at 2:16 PM, Matt Welland
wrote:
> I myself prefer not to see additional info like this that can be derived
> from querying the db added to the timeline. I'm keen to see the work that
> Andy and Jan have done make it into the trunk and will test it ASAP.
>
There is a differen
On Thu, Apr 9, 2015 at 12:07 AM, Matt Welland
wrote:
>
> On Wed, Apr 8, 2015 at 5:57 PM, Andy Bradford
> wrote:
>
>> Thus said Matt Welland on Wed, 08 Apr 2015 08:27:00 -0700:
>>
>> > What we are seeing is that forks happen due to simultaneous, partially
>> > overlapping, commits and that neit
On Thu, Apr 9, 2015 at 11:21 AM, Andy Bradford
wrote:
>
> If Fossil is not installed in the normal system PATH, you can instruct
> the client to clone using the fossil query parameter. For example, if
> you have installed fossil in ~/bin/fossil you can clone like:
>
> fossil clone ssh://user@
On Wed, Apr 8, 2015 at 8:57 PM, Andy Bradford
wrote:
> Perhaps this will help:
>
> http://www.fossil-scm.org/index.html/info/6b410f914ef5be53
Thanks.
I would still like to see a special tag automatically added to a fork
commit when one is detected.
2 reasons:
1. If there is an intermediate r
On Wed, Apr 8, 2015 at 1:58 PM, Scott Robison
wrote:
> Or whatever your team dictates. :)
>
In our case, we are required to follow "industry guidelines", except where
compelling technical issues require a deviation. And such deviations must
be documented. Also, use of NULL is considered more ind
On Wed, Apr 8, 2015 at 12:25 PM, Andy Goth wrote:
> I hesitated to do much more than move existing code around since I don't
> know how strong the stylistic preferences are. For example, one thing I
> wanted to do was treat pointers as booleans, e.g. "if(pointer)" rather than
> "if(pointer!=0)",
On Wed, Apr 8, 2015 at 6:55 AM, Martin Gagnon wrote:
> Fossil have a nice timeline graph that will show you
> the FORK clearly. And the CLI timeline command tell you that there's a
> FORK. (by adding *FORK* to the checkin entry):
I had not encountered this. Nor the "would fork" warning when doi
On Wed, Apr 8, 2015 at 2:19 AM, Matt Welland wrote:
> A much better solution is to block a push that creates a fork and inform
> the user that they need to fix the fork and push again.
>
I disagree.
Automatic shunning of an incoming commit by the receiving repo is anathema
to Fossil's underlyin
On Tue, Apr 7, 2015 at 10:14 PM, Andy Bradford
wrote:
> The software already warns users that a fork is imminent. They have the
> choice to ignore the warning, or not.
>
Even when auto-sync is enabled and the upstream repo can be contacted,
there is still a window where 2 (or more) commits can
On Mon, Apr 6, 2015 at 3:48 PM, Matt Welland wrote:
> On Mon, Apr 6, 2015 at 10:05 AM, James Moger
> wrote:
>>
>> By default non-fast-forward pushes (fork in Fossil terms) are blocked.
>>
>
> This is what I thought. So what technical obstacles are there preventing
> fossil from adopting this beh
On Mon, Apr 6, 2015 at 1:05 PM, James Moger wrote:
> There is no *direct* analog of the Fossil fork feature, although you could
> crudely simulate one, I suppose, with server-side refs.
>
Forks are not a feature, just an "unnamed" branch. I use the quotes because
a fork could happen in a named b
On Mon, Apr 6, 2015 at 12:27 PM, Matt Welland
wrote:
> Fossil "pretending" to be centralized is a fantastic feature. For me at
> least this *is* about factors that make Fossil simple to learn and use.
> Autosync is a plus. Forks are a minus.
>
Fossil doesn't pretend to be centralized, unless you
On Wed, Apr 1, 2015 at 4:21 AM, Vikrant Chaudhary
wrote:
> > If users could somehow share repositories without copying them in full,
> > that would help a lot.
>
> You are probably thinking about a "shallow clone".
> By "clone --cheap", I was thinking more along the lines of "ATTACH
> DATABASE".
On Tue, Mar 31, 2015 at 2:16 AM, Vikrant Chaudhary
wrote:
>
> Maybe I should roll with "Lagerstätte" as project's name, but we still
> need the ASCII approximation to use in code.
In the actual code or in string constants? If in string constants, why not
use the ISO-8859-1 encoding? Or even Unic
On Sat, Mar 14, 2015 at 7:24 PM, Richard Hipp wrote:
> On 3/14/15, Ron W wrote:
> >
> > The key difference is that, in git, the puller can force the in coming
> > commits to be remapped into branches of their own. That is, I could
> commit
> > my changes to &quo
On Mon, Mar 30, 2015 at 6:50 AM, Vikrant Chaudhary
wrote:
> Hello everyone,
>
> I've been working on a project named "Lagerstatte", a front-end for
> Fossil repositories.
>
Looks interesting.
>
> Features that you can evaluate today:
>
> * Navigating through files.
> * Viewing latest revision o
When I do "fossil info" in a checkout, I get:
tags: ts11
When I look at the same commit in the "/info" web page, I get:
branch=ts11
sym-ts11
I also tried "fossil tags list --raw", which shows me all of the tags. But
I want only the ones for the current checkout, so I then tried "fossi
On Fri, Mar 20, 2015 at 4:55 PM, Steve Stefanovich wrote:
>
> If we are discussing "partial", I'm more interested in partial checkouts
> than partial commits, i.e. having the ability to checkout a specific
> directory only. Now that would be useful for us with big source trees where
> there are th
On Fri, Mar 20, 2015 at 3:32 PM, Marcel Graf
wrote:
>
> I was more thinking about a command line only version of stash/snapshot
> --interactive asking for each file if i want it entirely or split and in
> case of the latter, letting me select each chunk without the use of an
> external gui (I vagu
On Fri, Mar 20, 2015 at 2:55 PM, Richard Hipp wrote:
> On 3/20/15, Abilio Marques wrote:
> > fossil ci -m "first commit" --ignore file1 file2
>
> I have your request. In the meantime, consider this work-around:
>
> fossil stash save file1 file2
> # test
> fossil ci -m "first commit"
On Fri, Mar 20, 2015 at 2:28 PM, Abilio Marques wrote:
>
> So including that patch right now seems really important. But I have a mix
> between the patch and the unfinished (and also untested).
>
> Until yesterday, what did I do?
>
> fossil stash snapshot
> go to the editor, find the lines that I
On Fri, Mar 20, 2015 at 1:30 PM, Marcel Graf
wrote:
> On Fri, Mar 20, 2015 at 6:04 PM, Richard Hipp wrote:
>
>> On 3/20/15, Martin S. Weber wrote:
>> ...
>
> > in itself). So you end up with intermingled changes which one would
>> > like to split cleanly.
>> >
>> The way I deal with this in SQL
On Fri, Mar 20, 2015 at 7:56 AM, Abilio Marques wrote:
> Yet before that, I knew about stash. But sometimes it was already too late
> to simply stash and begin doing some other changes, as both changes were
> already in the file.
>
Never too late to stash. If I decide I need to split out changes
On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques wrote:
> But you're right, now that I think about it, is the only time I've ever
> seen a home directory not owned by the corresponding user but by root.
>
Does the hosting service provide special commands for creating directories
and files in your
On Thu, Mar 19, 2015 at 11:53 AM, Richard Hipp wrote:
> On 3/19/15, Joerg Sonnenberger wrote:
> > On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote:
> >> On 3/19/15, Joerg Sonnenberger wrote:
> >> > On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
> >> >> On 3/19/15, a..
On Wed, Mar 18, 2015 at 12:13 PM, Richard Hipp wrote:
> On 3/18/15, Ron W wrote:
> > I was going to suggest changing:
> > combobox severity $severity_choices 1
> >
> > to:
> > combobox severity $severity_choices 3
> >
>
> Did you make the
On Wed, Mar 18, 2015 at 7:23 AM, Markus Laire wrote:
> I would like to change "New Ticket Page" in admin-section so that
> default severity is Important, but user still can choose another
> severity. Also I want to keep proper order in severity_choices so I
> don't want to just move "Important" a
On Mon, Mar 16, 2015 at 5:48 PM, jungle Boogie
wrote:
> IMO, putting a private, internally worked on repo behind a firewall is
> good.
>
> There are many new features we'd all like Fossil to have but I'll take
> fewer and fewer bugs over new features. ;)
Agree on both points.
__
On Mon, Mar 16, 2015 at 4:01 PM, Graeme Pietersz
wrote:
> What would still be missing would be some way of letting users decide
> which tickets they wanted to be notified about. Customise the tickets table?
>
Another option would be to use a list server. But even with one that could
automaticall
On Mon, Mar 16, 2015 at 4:01 PM, Graeme Pietersz
wrote:
> What would still be missing would be some way of letting users decide
> which tickets they wanted to be notified about. Customise the tickets table?
>
We added a custom field to hold email addresses. Similar to the CC field in
Bugzilla. Y
On Mon, Mar 16, 2015 at 3:51 PM, jungle Boogie
wrote:
>
> Yes, this is a great plan.
I didn't say it was great or even good. Only that is what we were told to
do. Or not be allowed to generate email from the Fossil repos.
___
fossil-users mailing list
On Mon, Mar 16, 2015 at 3:22 PM, jungle Boogie
wrote:
> You're right, it won't be private, so you'll be stuck having your
> password in some rss fetch thing. One would have to weigh the risks.
>
Where I work, we allow - in Fossil - "nobody" to view the time line because
only PCs connected to the
On Mon, Mar 16, 2015 at 3:45 AM, John Found wrote:
>
> The first step towards such achievement is to allow all Fossil users to
> exists in
> one common username space.
> OpenID authentication could help to make this without big effort.
>
OpenID support would be a nice addition.
But, even in an e
On Mon, Mar 16, 2015 at 5:05 AM, Graeme Pietersz
wrote:
> (there is a ticket change hook now?).
>
Supposedly there is, and other hooks, but I've never seen documentation.
But, supposedly, the TH1 thus invoked by the hook can, if enabled, "touch"
a URL. With an appropriately constructed URL, a s
On Mon, Mar 16, 2015 at 4:33 AM, Graeme Pietersz
wrote:
> On 16/03/15 13:30, Ron W wrote:
> > On Sun, Mar 15, 2015 at 3:56 AM, Graeme Pietersz
> <mailto:gra...@pietersz.net> > wrote: >> 1) email
> notifications, the most important for me > > Can currently
On Sun, Mar 15, 2015 at 11:37 AM, Andy Bradford
wrote:
> The requirement, specifically, is that the first artifact that the
> server sends during a clone, must be a checkin, or older Fossil clients
> will end up in this state.
Could the server side be modified to insure the first artifac
On Sun, Mar 15, 2015 at 3:56 AM, Graeme Pietersz
wrote:
> No one system has all these, but looking at multiple ticket trackers, the
> obvious things to me are:
>
> 1) email notifications, the most important for me
>
Can currently be accomplished with external (to Fossil) service, using, for
exam
On Saturday, March 14, 2015, Richard Hipp wrote:
> On 3/14/15, Ron W > wrote:
> >
> > The key difference is that, in git, the puller can force the in coming
> > commits to be remapped into branches of their own. That is, I could
> commit
> > my changes to "t
On Sat, Mar 14, 2015 at 5:28 AM, j. van den hoff
wrote:
my understanding was that a github "fork" is nothing but a clone and not
> "really" part of the original project, no? so it really is not comparable
> to a branch (be it `git' or `fossil'), no?
>
Almost the same as pulling from a clone of a
201 - 300 of 556 matches
Mail list logo
