On 5/17/2016 9:01 PM, John P. Rouillard wrote:
> Would it be worth mentioning that shunning a commit does not shun the
> artifacts checked in during that commit?
The shun page should give more information about its effective use.
> Is there any way to identify and remove these unconnected
On 5/17/16, John P. Rouillard wrote:
>
> Is there an expand(content) or something that I
> could use?
>
Use the "content()" SQL function to decode the blobs. The argument is
any symbolic name (like a prefix of the SHA1 hash). Example:
SELECT content('trunk');
Hi Andy:
In message <0dc19ff1-f9f1-67af-7119-62bf62462...@gmail.com>,
Andy Goth writes:
>On 5/14/2016 4:59 PM, John P. Rouillard wrote:
>> fossil init shun.fossil
>> mkdir shun
>> cd shun
>> fossil open ../shun.fossil
>> echo 2 > 2
>> fossil addremove
>> fossil ci -m "initial commit"
>> echo 2a
On 5/16/2016 8:00 PM, Richard Hipp wrote:
> On 5/16/16, Andy Goth wrote:
>> I've wanted reparenting capability to support importing old history into
>> a Fossil repository.
>
> I interpret your sentence above as "I volunteer to test out the new
> code!". Thanks!
I
On 5/14/2016 4:59 PM, John P. Rouillard wrote:
> fossil init shun.fossil
> mkdir shun
> cd shun
> fossil open ../shun.fossil
> echo 2 > 2
> fossil addremove
> fossil ci -m "initial commit"
> echo 2a > 2
> fossil ci -m "second commit"
> echo 2b > 2
> fossil ci -m "third commit"
> echo 2shun > 2
>
On 5/16/16, Andy Goth wrote:
>
> I've wanted reparenting capability to support importing old history into
> a Fossil repository.
>
I interpret your sentence above as "I volunteer to test out the new
code!". Thanks!
I added a "fossil reparent" command on the "reparent"
On 5/16/2016 11:41 AM, John P. Rouillard wrote:
> Richard Hipp writes:
>> On 5/15/16, Andy Goth wrote:
>>>
>>> To fix, you're going to have to go back to the version prior to the shun
>>> and redo every check-in since that point.
>>
>> Another option is to "reparent" the
Hello Richard:
In message
On 5/15/16, Andy Goth wrote:
>
> To fix, you're going to have to go back to the version prior to the shun
> and redo every check-in since that point.
Another option is to "reparent" the first check-in after the shun such
that it's parent becomes the last check-in before
On Mon, May 16, 2016 at 12:37 AM, John P. Rouillard <
rouilj+fos...@cs.umb.edu> wrote:
> Fortunately there are no artifact references in
> tickets/wiki/comments. But if there was, would some SQL magic
> be needed to find/change these references?
>
The SQL-usable parts of the repo are just a
In case it applies to you, if you haven't rebuilt the repo since the mistake
shunning, I believe you can un-shun what was shunned, and it should all come
back to the way it was.
On 5/14/2016 4:59 PM, John P. Rouillard wrote:
I had to recently shun some artifacts from a fossil repo (due to
Hi Andy:
In message <5538e894-bdfa-ad31-be79-26383e8ea...@gmail.com>,
Andy Goth writes:
>On 5/14/2016 4:59 PM, John P. Rouillard wrote:
>> I had to recently shun some artifacts from a fossil repo (due
>> to embedded security credentials). Now when I look at the
>> fossil timeline that spans that
On 5/14/2016 4:59 PM, John P. Rouillard wrote:
> I had to recently shun some artifacts from a fossil repo (due to
> embedded security credentials). Now when I look at the fossil timeline
> that spans that shunning I no longer have a single connected trunk.
>
> So is there some way to reintegrate
Hi Everybody:
I had to recently shun some artifacts from a fossil repo (due to
embedded security credentials). Now when I look at the fossil timeline
that spans that shunning I no longer have a single connected trunk.
To reproduce use:
fossil init shun.fossil
mkdir shun
cd shun
fossil open
14 matches
Mail list logo