Re: [fossil-users] backing out an incorrect commit?

[Baruch Burstein]

On Wed, Aug 16, 2017 at 10:09 PM, Stephan Beal 
wrote:

> It's hypothetically possible, and i investigated it 3 or 4 years ago, but
> the devil is in the details :/. Not impossible, but you have to take care
> of details like properly undelta'ing anything which is deltad against the
> to-be-popped head. At the time i wasn't confident enough in my knowhow of
> the internals to implement it. Also, it would only work up until you push
> to a remote, at which point all bets are off. You should be able to pop any
> number of consecutive heads up until that point, though.
>
> - stephan
> Sent from a mobile device, possibly from bed. Please excuse brevity,
> typos, and top-posting.
>
> On Aug 16, 2017 20:30, "bch"  wrote:
>
>>   We really should have (and it's not against philosophy) ability to
>> pop commits off top, though. I've miscommited to a branch, and I think
>> I'd just like to redo it, to say nothing of accidentally committing
>> something sensitive like a credit card number or password.
>>
>> -bch
>>
>
A couple of years ago I added the ability to shun a whole commit at a time,
which would effectively "pop" the last commit if used carefully. I don't
remember the details of how to use it and don't have a fossil repo around
to check, though.


-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[Stephan Beal]

On Wed, Aug 16, 2017 at 9:59 PM, bch  wrote:

> That doesn't sound unreasonable. Sort of doubly-constrained 1) from newest
> to older, per branch 2) on conflict, retarget branch, go-to 1
>

That's basically it, at least hypothetically. In principal "easy", and the
code is in place to do all the un/re-deltification. It would "simply" be a
matter of back-tracking one commit at a time and cleaning up/reaping
now-dead artifacts as as you go.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[bch]

On Aug 16, 2017 12:54, "Stephan Beal"  wrote:

On Wed, Aug 16, 2017 at 9:19 PM, bch  wrote:

>
>
> On Aug 16, 2017 12:10, "Stephan Beal"  wrote:
>
> It's hypothetically possible, and i investigated it 3 or 4 years ago, but
> the devil is in the details :/. Not impossible, but you have to take care
> of details like properly undelta'ing anything which is deltad against the
> to-be-popped head.
>
>
>
> Oh - I didn't realize that's the direction the deltas worked...
>


Fossil tries to keep the undelta'd copy at the head, since it's the one
most likely to be accessed. That's not a guaranty, though - just a
preference/habit. Thus if you pop the head, you need to make sure and go
undelta all artifacts in that head which are not referenced by anything
else in the tree.


>
> At the time i wasn't confident enough in my knowhow of the internals to
> implement it. Also, it would only work up until you push to a remote, at
> which point all bets are off.
>
>
> Well... I suspect that's true, but still not entirely useless depending on
> context. Depending on project, one may simply redistribute the new
> ("popped") repo out to remotes and pick up from there.
>

Right. i believe there are certainly uses for it.

Another detail i forgot about earlier is the handling of branches: you can
only pop  from the tip of any given branch and only if no other branch
derives from that point in the branch. As soon as something derives from
what you want to pop, you have to go pop all that off first. When i
realized how ugly that gets, i stopped researching an implementation :/.


That doesn't sound unreasonable. Sort of doubly-constrained 1) from newest
to older, per branch 2) on conflict, retarget branch, go-to 1

Right?



-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[Stephan Beal]

On Wed, Aug 16, 2017 at 9:54 PM, Stephan Beal  wrote:

> just a preference/habit. Thus if you pop the head, you need to make sure
> and go undelta all artifacts in that head which are not referenced by
> anything else in the tree.
>

Parson me: you'd need to undelta anything in the NEW head and reap/purge
any popped-off artifacts which are no longer referenced by anything in the
repo.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[Stephan Beal]

On Wed, Aug 16, 2017 at 9:19 PM, bch  wrote:

>
>
> On Aug 16, 2017 12:10, "Stephan Beal"  wrote:
>
> It's hypothetically possible, and i investigated it 3 or 4 years ago, but
> the devil is in the details :/. Not impossible, but you have to take care
> of details like properly undelta'ing anything which is deltad against the
> to-be-popped head.
>
>
>
> Oh - I didn't realize that's the direction the deltas worked...
>


Fossil tries to keep the undelta'd copy at the head, since it's the one
most likely to be accessed. That's not a guaranty, though - just a
preference/habit. Thus if you pop the head, you need to make sure and go
undelta all artifacts in that head which are not referenced by anything
else in the tree.


>
> At the time i wasn't confident enough in my knowhow of the internals to
> implement it. Also, it would only work up until you push to a remote, at
> which point all bets are off.
>
>
> Well... I suspect that's true, but still not entirely useless depending on
> context. Depending on project, one may simply redistribute the new
> ("popped") repo out to remotes and pick up from there.
>

Right. i believe there are certainly uses for it.

Another detail i forgot about earlier is the handling of branches: you can
only pop  from the tip of any given branch and only if no other branch
derives from that point in the branch. As soon as something derives from
what you want to pop, you have to go pop all that off first. When i
realized how ugly that gets, i stopped researching an implementation :/.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[bch]

On Aug 16, 2017 12:10, "Stephan Beal"  wrote:

It's hypothetically possible, and i investigated it 3 or 4 years ago, but
the devil is in the details :/. Not impossible, but you have to take care
of details like properly undelta'ing anything which is deltad against the
to-be-popped head.



Oh - I didn't realize that's the direction the deltas worked...

At the time i wasn't confident enough in my knowhow of the internals to
implement it. Also, it would only work up until you push to a remote, at
which point all bets are off.


Well... I suspect that's true, but still not entirely useless depending on
context. Depending on project, one may simply redistribute the new
("popped") repo out to remotes and pick up from there.


-bch


You should be able to pop any number of consecutive heads up until that
point, though.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Aug 16, 2017 20:30, "bch"  wrote:

>   We really should have (and it's not against philosophy) ability to
> pop commits off top, though. I've miscommited to a branch, and I think
> I'd just like to redo it, to say nothing of accidentally committing
> something sensitive like a credit card number or password.
>
> -bch
>
> On 8/16/17, Stephan Beal  wrote:
> > On Wed, Aug 16, 2017 at 8:15 PM, Stephan Beal 
> > wrote:
> >
> >> On Wed, Aug 16, 2017 at 7:59 PM, Steve Schow  wrote:
> >> > Is that possible at all or if not, what is the best way to handle that
> >> kind of situation with fossil?
> >>
> >> Fossil is designed to never forget anything, not even mistakes. It's
> >> possible to move a commit to a new branch, thereby "kind of hiding it",
> >> but
> >> not to remove it.
> >>
> >
> > Lol - seems we were all typing at the same time.
> >
> > --
> > - stephan beal
> > http://wanderinghorse.net/home/stephan/
> > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
> > those who insist on a perfect world, freedom will have to do." -- Bigby
> > Wolf
> >
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[Stephan Beal]

It's hypothetically possible, and i investigated it 3 or 4 years ago, but
the devil is in the details :/. Not impossible, but you have to take care
of details like properly undelta'ing anything which is deltad against the
to-be-popped head. At the time i wasn't confident enough in my knowhow of
the internals to implement it. Also, it would only work up until you push
to a remote, at which point all bets are off. You should be able to pop any
number of consecutive heads up until that point, though.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Aug 16, 2017 20:30, "bch"  wrote:

>   We really should have (and it's not against philosophy) ability to
> pop commits off top, though. I've miscommited to a branch, and I think
> I'd just like to redo it, to say nothing of accidentally committing
> something sensitive like a credit card number or password.
>
> -bch
>
> On 8/16/17, Stephan Beal  wrote:
> > On Wed, Aug 16, 2017 at 8:15 PM, Stephan Beal 
> > wrote:
> >
> >> On Wed, Aug 16, 2017 at 7:59 PM, Steve Schow  wrote:
> >> > Is that possible at all or if not, what is the best way to handle that
> >> kind of situation with fossil?
> >>
> >> Fossil is designed to never forget anything, not even mistakes. It's
> >> possible to move a commit to a new branch, thereby "kind of hiding it",
> >> but
> >> not to remove it.
> >>
> >
> > Lol - seems we were all typing at the same time.
> >
> > --
> > - stephan beal
> > http://wanderinghorse.net/home/stephan/
> > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
> > those who insist on a perfect world, freedom will have to do." -- Bigby
> > Wolf
> >
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[bch]

  We really should have (and it's not against philosophy) ability to
pop commits off top, though. I've miscommited to a branch, and I think
I'd just like to redo it, to say nothing of accidentally committing
something sensitive like a credit card number or password.

-bch

On 8/16/17, Stephan Beal  wrote:
> On Wed, Aug 16, 2017 at 8:15 PM, Stephan Beal 
> wrote:
>
>> On Wed, Aug 16, 2017 at 7:59 PM, Steve Schow  wrote:
>> > Is that possible at all or if not, what is the best way to handle that
>> kind of situation with fossil?
>>
>> Fossil is designed to never forget anything, not even mistakes. It's
>> possible to move a commit to a new branch, thereby "kind of hiding it",
>> but
>> not to remove it.
>>
>
> Lol - seems we were all typing at the same time.
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
> those who insist on a perfect world, freedom will have to do." -- Bigby
> Wolf
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[Stephan Beal]

On Wed, Aug 16, 2017 at 8:15 PM, Stephan Beal  wrote:

> On Wed, Aug 16, 2017 at 7:59 PM, Steve Schow  wrote:
> > Is that possible at all or if not, what is the best way to handle that
> kind of situation with fossil?
>
> Fossil is designed to never forget anything, not even mistakes. It's
> possible to move a commit to a new branch, thereby "kind of hiding it", but
> not to remove it.
>

Lol - seems we were all typing at the same time.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[Stephan Beal]

On Wed, Aug 16, 2017 at 7:59 PM, Steve Schow  wrote:
> Is that possible at all or if not, what is the best way to handle that
kind of situation with fossil?

Fossil is designed to never forget anything, not even mistakes. It's
possible to move a commit to a new branch, thereby "kind of hiding it", but
not to remove it.

To move a commit:

fossil ui
select the commit in the timeline
Find the "edit" link and click it.
Find the "Make this check-in the start of a new branch named", give it a
name, and check that checkbox.

Fossil has an option called "shunning" for removing "really bad" mistakes,
such as credentials and illegally copied materials, but that is a "nuclear
option" which can have side effects and is not intended to be used for
"honest, but harmless, mistakes".

--
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[Roy Keene]

Steve,

	Usually what is done here is the incorrect commit is moved to a 
different branch, which is typically hidden.  This can be done using 
"fossil amend".  Then you update to the new head of your branch (the 
previous commit) using "fossil update" and retry your commit.


It's also possible to shun the commit artifact on every system that has 
learned of it (given that no new commits are based off it) and a rebuild 
will drop the un-referenced data artifact.  This is not recommended in the 
normal case of a simple error being made, since you'll have to touch every 
clone that has the commit artifact.


Thanks,
Roy Keene

On Wed, 16 Aug 2017, Steve Schow wrote:

I know the fossil paradigm generally frowns on the idea of undoing 
commits.  Please tell me your thoughts about the best approach to handle 
the following situation.


a few file is added to the checkout and committed.  So the commit has 
one new file, nothing else.  It is later determined that the entirely 
wrong version of that file was committed for the first version of the 
file and we?d like to back it out to do it properly?


Is that possible at all or if not, what is the best way to handle that 
kind of situation with fossil?



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[Richard Hipp]

On 8/16/17, Steve Schow  wrote:
> I know the fossil paradigm generally frowns on the idea of undoing commits.
> Please tell me your thoughts about the best approach to handle the following
> situation.
>
> a few file is added to the checkout and committed.  So the commit has one
> new file, nothing else.  It is later determined that the entirely wrong
> version of that file was committed for the first version of the file and
> we’d like to back it out to do it properly…
>
> Is that possible at all or if not, what is the best way to handle that kind
> of situation with fossil?

To "undo" a commit:

(1)  Bring up the /info page for the bad commit in the web interface.
(Use "fossil ui" if you do not have a server at hand.)

(2)  Click on the "edit" link to the right of the "Other Links:" label

(3)  Click on "Make this check-in the start of a new branch named:"
and type in "mistake" for the new branch name.

(4)  Click on "Mark this leaf as closed"

(5)  Edit the check-in comment to explain why the check-in is being backed out.

(6)  Click the "Apply" button

(7)  You are done with the web interface for the moment.  Go back to
your shell in your check-out directory and type "fossil update trunk"
to move your check-out back to what it was before you made the bad
check-in.

There are lots of examples of this in the SQLite source tree.  One
such example: https://www.sqlite.org/src/timeline?c=4b0f44848

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users