On Aug 3, 2015, at 4:20 PM, Andy Goth wrote:
>
> On 8/3/2015 3:24 PM, Warren Young wrote:
>> I thought I saw reference on this list to a way to lop off the
>> most-recent checkin
>
> Using the web interface, you can edit the existing check-in to be in a
> branch (I usually use the name "mistake"
On Tue, 4 Aug 2015, Ron W wrote:
> On Tue, Aug 4, 2015 at 11:37 AM, Stephan Beal wrote:
> On Tue, Aug 4, 2015 at 5:23 PM, Ron W
> wrote:
> I think this would be a useful feature.
>
>
> To me this all sounds like fossil enforcing project-specific policy,
> which is somethi
On Tue, Aug 4, 2015 at 11:37 AM, Stephan Beal wrote:
> On Tue, Aug 4, 2015 at 5:23 PM, Ron W wrote:
>
>> I think this would be a useful feature.
>>
>
> To me this all sounds like fossil enforcing project-specific policy, which
> is something it most certainly should not be doing.
>
I was commen
On Tue, Aug 4, 2015 at 11:37 AM, Stephan Beal wrote:
> On Tue, Aug 4, 2015 at 5:23 PM, Ron W wrote:
>
>> I think this would be a useful feature.
>>
>
> To me this all sounds like fossil enforcing project-specific policy, which
> is something it most certainly should not be doing.
>
> Case in poi
On Tue, Aug 4, 2015 at 5:23 PM, Ron W wrote:
> I think this would be a useful feature.
>
To me this all sounds like fossil enforcing project-specific policy, which
is something it most certainly should not be doing.
Case in point:
[odroid@host:~/fossil/cwal/s2]$ ls -d *
1mod_porex.c s
On Mon, Aug 3, 2015 at 6:33 PM, Andy Goth wrote:
>
> Maybe split this functionality from the commit command and make a new
> warning or audit or check command which will print all the things that
> may prevent a commit from going forward, but also toss in extra files if
> the check-extras setting
On 8/3/2015 3:24 PM, Warren Young wrote:
> On Aug 3, 2015, at 1:31 PM, Andy Goth wrote:
>> Usually I don't bother, especially if there have been check-ins since
>> the error was committed.
>
> Wouldn’t a better solution to that problem be a continuous integration
> system, so you get an email sho
On 8/3/2015 3:24 PM, Warren Young wrote:
>> After making this mistake, I know I'm supposed to move the bad commit to
>> a hidden branch
>
> Who supposes this, and why do you take their opinion as normative?
When a commit to Fossil causes a problem, I've seen drh move it to a
branch (usually not h
On Aug 3, 2015, at 1:31 PM, Andy Goth wrote:
>
> Many times I've created files, modified existing files to reference
> them, tested, and committed, only to later discover I forgot to add the
> newly created files to the repository.
Yup, been there. :)
> After making this mistake, I know I'm sup
On 3 August 2015 at 21:31, Andy Goth wrote:
> Many times I've created files, modified existing files to reference
> them, tested, and committed, only to later discover I forgot to add the
> newly created files to the repository.
>
> After making this mistake, I know I'm supposed to move the bad co
Many times I've created files, modified existing files to reference
them, tested, and committed, only to later discover I forgot to add the
newly created files to the repository.
After making this mistake, I know I'm supposed to move the bad commit to
a hidden branch and try again. Usually I don'
11 matches
Mail list logo
