I decided to experiment with adding and cancelling tags on the current checkin. I then noticed that doing so had rather messed up my timeline so I decided to shun the tag edits (and rebuild) before pushing upstream. (autosync off, by the way).

It turns out shunning the tag edits made no difference, i.e. the unwanted timeline entries are visible upstream.

I've read shunning.wiki but clearly my expectation and/or understanding of the mechanisms at work here are wrong.

It looks like you might have overlooked this part of the doc you linked to:

Shunning lists are local state

... The shunning list does not propagate to a remote repository by the normal "sync" mechanism, but it is still possible to copy shuns from one repository to another using the "configuration" command:

fossil configuration pull shun remote-url

fossil configuration push shun remote-url

That requires, of course, that you have enough permissions on the remote to modify the configuration.

Are you sure the autosync was off and/or that you didn't do a push before to do do the rebuild ?

I just try on a test repo and it works as expected.

Here's what I did:

1. I made sure autosync was already off

2. I start "fossil ui"

3. I edit the comment of my last checkin.

4. On the timeline, I select "Any Type" to see my Edit.

5. I click on the checkin hash of the edit

6. I press Shun on the top.

7. I press the Shun button beside the hash of the artifact

8. I press the rebuild button.
   (This will really restore the original comment seen on the timeline on the local repo)

9. I verify that the Edit I just shun doesn't appear anymore on my timeline (with "Any Type" selected)

10. I push to the remote (type fossil push)

My Edit doesn't appear on my remote. Did you do something different than me ?

If the artifact got shunned locally and you rebuild the repository, the artifact is gone and cannot be pushed to the the remote host.

I've just tried:

fossil> config push shun

but it's made no difference, i.e. the timeline entries are still visible upstream.

(The timeline entries are still visible locally too, so I would have been surprised if this had worked).

Solved, but questions remain

Summary

Shunning only works with full hashes (either 40 or 64 characters, depending on hash policy). It does not work with 40-character hash references (referring to 64-character hashes).

The UI documentation at /shun currently reads:

Note that you must enter the full 40- or 64-character artifact hashes, not an abbreviation or a symbolic tag.

May I suggest a small clarification:

Note that you must enter the full 40- or 64-character artifact hash, not an abbreviation, symbolic tag or 40-character hash reference (referring to a 64-digit hash).

Full explanation

I was passing the 10-digit hash reference gleaned from the timeline to info, and then copy/pasting the 40-digit hash reference (provided by info) into the 'Shun' box of the UI at /shun. I would then click 'Shun' and the 40-digit hash references would appear in the list at the bottom of the page, but nothing was actually being shunned.

On the other hand, when you click the 'Shun' button of the UI at /info - thank you Martin for outlining the steps you took - the 64-digit hash is used.

Questions

How do you find the 64-digit hash of an artifact using the command line?

Is it possible to shun artifacts using only the command line?

Is it possible to shun artifacts using only the command line?

Yes, you can do: fossil whatis <hash-prefix>

***Edit: Sorry, I’ve misread the question as « is it possible to get the full hash of an artifact from cli » .

As Stephan said, the answer is No.

I should not post on forum after I just woke up using my phone.

May I suggest a small clarification:

i've just changed it to:

Note that you must enter full artifact hashes, not abbreviations or symbolic tags.

The reference to 40/64 characters is already in the paragraph above that, and didn't need to be duplicated here.

Is it possible to shun artifacts using only the command line?

There is no CLI shun command. While it would be easy enough to implement, i assume (without being certain) that Richard has never done so in order to keep shunning from being "too accessible", as shunning really should not be used except in emergencies (it goes against fossil's Prime Directive but was added as a Necessary Evil for those cases where data Absolutely Must be removed).

Edit: Sorry, I’ve misread the question as « is it possible to get the full hash of an artifact from cli » .

I actually asked both questions. :-)

I should not post on forum after I just woke up using my phone.

I'm happy you did.

Note that you must enter full artifact hashes, not abbreviations or symbolic tags.

That's certainly more succinct.

Would you consider adding something like this:

"Gotcha: If your hashpolicy is sha3, sha3-only or shun-sha1, the uuid displayed by the info command is a 40-char hash reference to, or abbreviation of, the full 64-char hash.  On the command line, use the whatis command to determine an artifact's full 64-char hash."

There is no CLI shun command.  While it would be easy enough to implement, I assume (without being certain) that Richard has never done so in order to keep shunning from being "too accessible", as shunning really should not be used except in emergencies (it goes against fossil's Prime Directive but was added as a Necessary Evil for those cases where data Absolutely Must be removed).

Hmm... I have to say I would very much appreciate a CLI shun command.

The Prime Directive is a little harsh when you are learning how to publish code using Fossil, i.e. present your code and documentation to the world.  Learning how to publish in this sense, or at this stage, has very little to do with principles of good version control.

Grepping the output of test-all-help for the word 'shun' lead me to the reparent command, which comes with a clear warning:

This is an experts-only command.  [...] You should never need to reparent during normal operations.

Would it be so dangerous if there was an auxilliary shun command which came with a similar warning?

Gotcha: If your hashpolicy is sha3, sha3-only or shun-sha1, the uuid displayed by the info command is a 40-char hash reference to, or abbreviation of,...

That might actually be a cosmetic bug in info. i'd like to wait and hear what Richard, Warren, Andy, etc., can say about that before making that change.

Hmm... I have to say I would very much appreciate a CLI shun command.

Which is, i suspect, why we don't have one. It's not a command which should ever be used. If it's in easy reach, people will reach for it. It's easy to break a repository with shun so, like the proverbial firearm which it is, it "really needs" to be in a locked cabinet, requiring conscious thought and effort to get to.

(FWIW, in 11 years and 9 months of using fossil almost daily, i've never once shunned an artifact.)

The Prime Directive is a little harsh when you are learning how to publish code using Fossil, ...

Being new to fossil is no excuse to start shunning things. Being new to fossil is an even better reason not to shun because the implications of doing so are, in all likelihood, not fully appreciated.

(That ^^^ really should be printed on every new fossil user's coffee mug.)

Though fossil avoids, as a rule, enforcing project-specific/personal policies, its overall data model was built with the idea of never forgetting anything and keeping all data immutable. Shunning not only violates that model, but breaks it when it removes records which are referenced by other records. e.g., shunning a file semantically breaks any commit which refers to it and any commits which derive from those commits. Shunning effectively breaks the blockchain, bringing Grief and Disharmony to an otherwise Perfect World.

Fossil's model "encourages" its users to include any and all of their mistakes and warts in what they publish (and to not feel ashamed of doing so). Mistakes are, after all, part of the work record. (FWIW, i've got countless mistakes on record in numerous fossil repos :/.)

Would it be so dangerous if there was an auxilliary shun command which came with a similar warning?

There's no difference between an "auxiliary" and "primary" command in fossil except that the former is hidden behind one more layer of help flags. Once a user knows its there, it's easy to reach for whenever they feel they've "made a mistake." Being dangerous, shun belongs (IMO) locked away in a gun cabinet, spoken of only in hushed whispers.

IMO (as opposed to official project policy), shun should never be promoted to a CLI command. It's dangerous, and dangerous things generally need to be kept out of easy reach, especially of those who are new to the tool.

So the only time I ever shunned something in Fossil was because I made a commit that I wanted to back out of. At the time, shunning seemed to me (as a new user) the only way to accomplish that. So, what would be the proper way to back out a bad commit? And not end up with weirdness on the timeline?

Thanks.

If the bad check-in is still at the tip of its branch, or if all check-ins from that point forward are also "bad," then you can just move the check-in (or the first in the series of bad check-ins) to a special branch and hide that branch. You can do that from Fossil UI or with "fossil amend".

I usually call this branch "BOGUS", but you could give it a more specific name like "BAD CHECKIN" or similar. I like all-caps names for this to make it clear that this isn't a normal branch. If you look at the branch list for fossil-scm.org/fossil, you'll see several of these.

You have to remember to say "fossil up trunk" afterward to be sure you don't accidentally check the next thing in on the tip of the new branch.

This causes the bad check-in to be orphaned off to the side of its parent branch as a path not followed, which is what a bad check-in truly is. Yet, the info is still there if it's ever needed.

When the bad check-in(s) is not at the tip of its branch, but instead has good stuff checked in after it, you can use "fossil merge --backout" instead. This creates a diff at the tip of the current branch that reverses the bad check-in. You then build, test, and check that in to back out the change.

There is no way to back out a commit. i don't know of any SCM which makes that possible, other than possibly git (though i'm not certain that it directly supports it). (Edit: the backout merge which Warren and Andy mention is effectively that, but the old checkin is still in the history.)

Hypothetically it's possible to pop checkins/tags/etc. off of the "stack" one at a time to restore a repo to any prior state, but this has never been implemented. The data model theoretically supports that, but unwinding the changes as each version is removed is technically tricky to get right.

So the techniques mentioned by Andy and Warren would have done what I was after at the time, and would have been better than the shunning approach I took. Basically I wanted to go back to older code, but at the time couldn't figure it out. I was really new to fossil at the time... But I imagine this scenario may be what leads people to shunning to fix what they did, when what they really need to do is sideline the bad changes and go back to last known good. Perhaps a good explanation of how to do this would be beneficial to add to the documentation?

Thanks.

How's this? (New "Alternatives" section.)

I realize this is tangential to the prior topic of this article, but I suspect the reason people are finding this article is largely because of links recently added from other documents that talk about deleting content in passing without wanting to go into details. That gives the false impression that shunning is the way to "delete" content from the repository. We want to say instead "Yes, you can permanently delete content from a Fossil repo, but you almost always want one of these non-destructive alternatives instead."

In an ideal world, we'd rename this to the "deleting" article and cover shunning as a last-ditch case, but I don't want to rename it now and break all the external inbound links that must exist to this old article.

That's really good. Shunning successfully is really hard to do and took me far longer to accomplish than the alternate "move it to a bogus branch" solution. I've been far more careful and thoughtful since that one time, and haven't run into a situation yet where I needed to do the same thing again.

Thanks!

That might actually be a cosmetic bug in info. i'd like to wait and hear what Richard, Warren, Andy, etc., can say about that before making that change.

May I ask what you mean by 'cosmetic'?

Though fossil avoids, as a rule, enforcing project-specific/personal policies, its overall data model was built with the idea of never forgetting anything and keeping all data immutable. Shunning not only violates that model, but breaks it when it removes records which are referenced by other records. e.g., shunning a file semantically breaks any commit which refers to it and any commits which derive from those commits.

Fully understood.

Shunning effectively breaks the blockchain, bringing Grief and Disharmony to an otherwise Perfect World.

:-)

IMO (as opposed to official project policy), shun should never be promoted to a CLI command.

Fair enough.

How about a configure option --with-command-line-shun (or words to that effect) that is never used in distributed builds?

I have no intention of abusing the command, it's just that CLI commands can be easily noted/recorded/scripted/logged for future use, (or non-use).  Recording which GUI commands were performed, or must be performed, is much, much harder.

Now that I think about it, I'm also very used to the idea of the command line being full-featured, and the GUI being limited, rather than the other way round.

May I ask what you mean by 'cosmetic'?

Meaning it's just a matter of how the data are displayed, not breaking anything, but being misleading.

I have no intention of abusing the command...

My objection has nothing to do with your intent. It's solely about keeping fossil's nuclear arsenal out of everyone's easy reach.

How about a configure option --with-command-line-shun (or words to that effect) that is never used in distributed builds?

That would be for Richard to decide. My own stance is unchanged: hide shun as far away from users, especially new ones, as it can possibly be.

There is no CLI shun command.

True, but I just remind the very experimental "purge" command which seems to do the equivalent, except it move artifact to the graveyard before to delete it completely.

see: fossil help purge

So using this command to remove the edit tag would be something like:

fossil purge artifacts <full-hash-of-the-artifact>
fossil rebuild
   # Verify with "fossil ui" that everything is OK.

To permanently delete the artifact (deleting it from the graveyard):

fossil purge list    # locate the graveyard id of the artifact
fossil purge obliterate <id>

Also, this command looks even more powerful (or dangerous), since it allow to purge a branch (the last occurrence at least) by using the: fossil purge checkins <tag> subcommand.

History of this command

• This command was originally added in same time as the bundle subcommand which was merged on trunk here: DBP-workflow

• Further improvement was done and merge on trunk here. purge branch

If I am understanding the documentation correctly, this would only be useful before pushing/sync'ing.

Given how dangerous it could be, I'm very surprised this CLI command exists.

So much for keeping dangerous commands out of easy reach.

(Though, given it's still experimental, it could still be removed.)

This command was originally added in same time as the bundle subcommand

I wonder if "fossil purge" was originally a precursor to "fossil bundle purge". Even if so, given that DRH made the improvements introduced via the purge branch, I suspect it's here to stay despite last being worked in over 3 years ago.

There is one big difference between purge and shun. When you shun something it becomes part of the shunned artifacts list and the server will not accept those artifacts again. It will also publish the shunned artifacts list to clients and they will remove it from their repositories automatically.

True, but for the specific case of sebyte, he want a cli command to shun the latest tag-edit that was made while autosync was disabled. In this particular case purge could works, but I would not recommend it.

I just want to point out the existence of purge while we were talking about dangerous command that should be stay out of easy reach.

Also, I tend to agree with sebyte when he says:

I'm also very used to the idea of the command line being full-featured, and the GUI being limited, rather than the other way round.

I'm used to see advanced power-user command on cli rather than on a GUI.

example: fossil sql is one of the most power-user feature of fossil and it's on the cli.

CLI commands can be easily noted/recorded/scripted/logged

Reproducible processes are one of my hobby-horses. I love reproducible builds. I write tools to build software releases deterministically rather than make new releases by hand. I'm a huge fan of software like Jupyter and R which allow one investigator to communicate the entire method of reproduction for an experiment or scientific demonstration to another. And I store all of these works in Fossil repositories, which I can clone elsewhere and stand back up on a new substrate, perfectly replicating my prior setup, caps willing.

I should want your proposed feature, but while mentally composing my reply in support of your proposal, I asked myself, "Under what condition would I ever script a Fossil shun command?" and I came up empty.

EDIT: As for logging, Fossil already logs shun actions in its Administrative Log, if you've got that enabled.

I think we want a concrete use case now, not more persuasive prose.