[fossil-users] Why you should not shun
Richard Hipp
I keep all of my OpenOffice slide presentations in a private Fossil repository, so that I can develop presentations on my Ubuntu desktop, then sync to my macbook to take on the road. I spent this morning working on one such presentation. Part of my changes this morning involved a image that I copy/pasted from wikipedia. I didn't realize it at the time, but the image was a 24MB PNG. Everything worked fine. I saved my work and checked it in. But after checking in, Fossil then tried to push the changes to my master repository on a server at Hurricane Electric. 24MB of uncompressible image takes time to go over ADSL. So I realized there was a problem and cancelled the sync.
How to fix this? I down-sampled the image to a lower resolution JPEG, reducing its size from 24MB to about 400KB. But I still had the old version stored in my local repository. "No problem", I thought. I'll just shun it. Which I did. Then I did "fossil update previous" so that I could commit the new version. But (oops) that deleted all of my changes. Everything was lost. Despair and gnashing of teeth followed.
Fortunately, I later realized that I could do "fossil undo" to reverse the update and get my changes back.
Three lessons:
(1) Know what you are checking in before you do the check-in. If I had simply paid attention to the size of the *.odp file that I was committing, I would have realized that it would be a slow syncer.
(2) Don't use shun. Even if you think you know what you are doing, you are very likely to get into trouble.
(3) If you ignore the previous two warnings and find yourself in a bad situation, don't panic. Think about where you are and plan your recovery carefully. If I had panicked, I might have entered other Fossil commands which would have purged my undo stack. As it was, I walked away from the keyboard and later realized that a "fossil undo" would get my old files back.
Learn from my mistake: Don't shun on a whim. The only reason to shun is to remove truly harmful content, such as spam. I should have just let the sync proceed even if it was slower than I would like. If you must shun, plan your shuns very, very carefully. After shunning, test your repository before syncing. Don't do something you will later regret.
--
D. Richard Hipp
d...@sqlite.org
Stephan Beal
Learn from my mistake: Don't shun on a whim. The only reason to shun is to remove truly harmful content, such as spam. I should have just let the sync proceed even if it was slower than I would like. If you must shun, plan your shuns very, very carefully. After shunning, test your repository before syncing. Don't do something you will later regret.
----- stephan beal
http://wanderinghorse.net/home/stephan/
Jos Groot Lipman
From: fossil-use...@lists.fossil-scm.org [mailto:fossil-use...@lists.fossil-scm.org] On Behalf Of Richard Hipp
Sent: dinsdag 4 oktober 2011 20:07
To: fossil-users
Subject: [fossil-users] Why you should not shun
Konstantin Khomoutov
"Jos Groot Lipman" <dont...@home.nl> wrote:
> Is -without shunning- the 24MB-version still present in your local
> repository? Won't is be synced sooner or later anyhow now?
It will be present of course. To quote the original message:
"I should have just let the sync proceed even if it was slower than I
would like."
_______________________________________________
fossil-users mailing list
fossil...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Remigiusz Modrzejewski
On Oct 4, 2011, at 8:06 PM, Richard Hipp wrote:
> (3) If you ignore the previous two warnings and find yourself in a bad
> situation, don't panic. Think about where you are and plan your recovery
> carefully. If I had panicked, I might have entered other Fossil commands
> which would have purged my undo stack. As it was, I walked away from the
> keyboard and later realized that a "fossil undo" would get my old files
> back.
And why exactly do we have a single-level stack?
Kind regards,
Remigiusz Modrzejewski
v...@lavabit.com
> are
> very likely to get into trouble.
> Learn from my mistake: Don't shun on a whim. The only reason to shun is
> to
> remove truly harmful content, such as spam. I should have just let the
> sync
> proceed even if it was slower than I would like. If you must shun, plan
> your shuns very, very carefully. After shunning, test your repository
> before syncing. Don't do something you will later regret.
These are very good points. When fossil is used for version control (since
that's its main purpose). But fossil can be used for other purposes as
well, because it is such a great multifunctional swiss army knife - and
version control is just a nice free bonus then. There are some corner use
cases which I'd like to mention, now that best shunning (or rather not
shunning!) practices are being discussed.
Fossil makes a great mini CMS for hosting a small site. Built in wiki
makes it sweet. I think it is also possible to have something like a
forum, with wiki pages used as categories and tickets + comments to them
used as topics. In these scenarios, if anonymous posting to wikis and
tickets is allowed - there's a higher risk to get junk or malicious
content in the repo which may require forceful purge. A couple of places
where fossil could make it easier for a repo admin to clean up would be:
- in wiki page - shun the wiki page completely and also all changes to it
- in ticket page - shun a ticket completely, also all comments
- in ticket page - option to check certain ticket comments and nuke them
all in one shot
Konstantin Khomoutov
Richard Hipp <d...@sqlite.org> wrote:
[...]
> (1) Know what you are checking in before you do the check-in. If I
> had simply paid attention to the size of the *.odp file that I was
> committing, I would have realized that it would be a slow syncer.
Just a thought: what if `fossil status` showed the size of the affected
files? Something akin to what `vdir` or `ls -l` do but using the
metadata which is to be stored within the fossil repository upon commit.
That would be overkill for `fossil changes` but `fossil status`
already shows extended information so it seems that making it "more
extended" might turn out to be useful.
[...]
> (3) If you ignore the previous two warnings and find yourself in a bad
> situation, don't panic. Think about where you are and plan your
> recovery carefully. If I had panicked, I might have entered other
> Fossil commands which would have purged my undo stack. As it was, I
> walked away from the keyboard and later realized that a "fossil undo"
> would get my old files back.
I think this has been discussed already, but to me it appears something
resembling Git's "reflog" functionality could be of help in the cases
like this one. The basic idea is to implement a storage (kept in the
checkout database) for things `fossil undo` operates on, but with a
time-based expiration instead of being a stack (Git uses 30 days by
default IIRC). Conceptually Git's reflog looks just like a single line
of history ordered by time of events forming it.
Stephan Beal
Fossil makes a great mini CMS for hosting a small site. Built in wikimakes it sweet. I think it is also possible to have something like a
forum, with wiki pages used as categories and tickets + comments to them
used as topics.
Erlis Vidal
I would like to see the shun documentation, I'm not able to find it here http://www.sqlite.org/debug1/help
nor the command fossil help shun helps.
Thanks
Erlis
Stephan Beal
I would like to see the shun documentation, I'm not able to find it here http://www.sqlite.org/debug1/help
Erlis Vidal
Richard Hipp
And why exactly do we have a single-level stack?
On Oct 4, 2011, at 8:06 PM, Richard Hipp wrote:
> (3) If you ignore the previous two warnings and find yourself in a bad
> situation, don't panic. Think about where you are and plan your recovery
> carefully. If I had panicked, I might have entered other Fossil commands
> which would have purged my undo stack. As it was, I walked away from the
> keyboard and later realized that a "fossil undo" would get my old files
> back.
I was concerned about using too much disk space if I let the stack grow without bound. The undo/redo content is stored in the _FOSSIL_ database. When you are dealing with 25MB files, it doesn't take too many operations to results in a really big undo/redo stack.
Kind regards,
Remigiusz Modrzejewski
_______________________________________________
fossil-users mailing list
fossil...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Erlis Vidal
I would like to understand how you lost your changes, but probably because I'm ignorant of the internals I'm not able to understand what just happened here.
I've read the Shun documentation and the Update documentation, and I cannot see how what you said here could occur.
"No problem", I thought. I'll just shun it. Which I did. Then I did "fossil update previous" so that I could commit the new version. But (oops) that deleted all of my changes. Everything was lost. Despair and gnashing of teeth followed.
Please (if is not much to ask) can you explain what creates the issue?
Sincerely,
Erlis
Richard Hipp
Hi Richard,
I would like to understand how you lost your changes, but probably because I'm ignorant of the internals I'm not able to understand what just happened here.
I've read the Shun documentation and the Update documentation, and I cannot see how what you said here could occur.
On Tue, Oct 4, 2011 at 2:06 PM, Richard Hipp <d...@sqlite.org> wrote:
"No problem", I thought. I'll just shun it. Which I did. Then I did "fossil update previous" so that I could commit the new version. But (oops) that deleted all of my changes. Everything was lost. Despair and gnashing of teeth followed.
It looks like the udpate command was the one that actually create the problem, but following your entire story, it seems that the situation was created by the Shun you did.
Right. I "shunned" my most recent check-in, removing the content from the repository. Then I did an "update" to the previous check-in so that I could check in the changes again, but this time with the new smaller JPEG instead of the massive GIF. But the "update" overwrote *all* of the changes I had made over the course of the morning.
So the "shun" removed the content from the repository. And the "update" removed the content from the disk.
Fortunately, there was still one other copy in the undo stack....
Please (if is not much to ask) can you explain what creates the issue?
Sincerely,
Erlis
_______________________________________________
fossil-users mailing list
fossil...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Remigiusz Modrzejewski
On Oct 4, 2011, at 9:00 PM, Richard Hipp wrote:
> On Tue, Oct 4, 2011 at 2:37 PM, Remigiusz Modrzejewski
> <lr...@maxnet.org.pl>wrote:
>>
>> And why exactly do we have a single-level stack?
>>
>
> I was concerned about using too much disk space if I let the stack grow
> without bound. The undo/redo content is stored in the _FOSSIL_ database.
> When you are dealing with 25MB files, it doesn't take too many operations to
> results in a really big undo/redo stack.
But for most practical cases this is not an issue. I guess I'd be happier if it was time-based with maybe a hard limit somewhere around 1GB. I've never done a stupid thing with Fossil... Yet.
Erlis Vidal
This is from the update help command
Change the version of the current checkout to VERSION. Any uncommitted
changes are retained and applied to the new checkout.
If you do the same steps, without the shun, just modify some files, update previous. Would that remove my change in the current checkout?
Thanks,
Erlis
Richard Hipp
And that's what I don't understand, how could the Update "overwrote" your changes.
This is from the update help command
Change the version of the current checkout to VERSION. Any uncommitted
changes are retained and applied to the new checkout.
Because of the shun, Fossil was confused. It thought that the changes had been committed, since they had been committed immediately prior to the shun. So the files on disk were marked as clean. Hence, Fossil overwrote them.
Bill Burdick
Richard Hipp
You could handle that case -- if you shun the current commit, then check the disk against the current repo contents and mark files that are different as uncommitted.
But to do so would be hard. Shunning is done in the repository database file: "*.fossil". But the information about which files are uncommitted is held in the check-out database file: "_FOSSIL_". And while the check-out database knows about the existance of the repository database, the repository does not know about individual checkouts. So if you run the "fossil rebuild" following the shun from the web interface (which does not know about individual check-outs) the rebuild operation has no way of finding the check-out databases and patching them up.
So what you'd probably have to do is modify the "update" command (as well as other similar commands) to check to see if any shunning has taken place and modify their behavior accordingly. It would be tricky to implement and get right. And it would be a lot of work. All for something that is officially discouraged.
Lluís Batlle i Rossell
> On Tue, Oct 4, 2011 at 4:09 PM, Erlis Vidal <er...@erlisvidal.com> wrote:
>
> > And that's what I don't understand, how could the Update "overwrote" your
> > changes.
> >
> > This is from the update help command
> >
> > changes are retained and applied to the new checkout.
>
>
> Because of the shun, Fossil was confused. It thought that the changes had
> been committed, since they had been committed immediately prior to the
> shun. So the files on disk were marked as clean. Hence, Fossil overwrote
> them.
Ah, I thought you had shunned the artifact of the PNG file, not that of the
checkin. What would have happened, if you had removed only the artifact of the
PNG?
In any case, what do you think of a (at least) temporary 'fail-fast' code that
will make fossil die in that unfortunate situation (the update removing files)?
I'd prefer a fast abort() than the behaviour you saw.
Thank you,
Lluís.
Erlis Vidal
you can delete with git files that has history with
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch file_name' HEAD
and that will generate a new commit without the file you just deleted (yes I know, that git command is really cryptic that's why I'm liking fossil so much :)
but I don't see how this will affect modified files. If the files are commited before, then you will never will lose those changes... unless you have shun those files, but I don't think that's the case, the file that was shun was a big image file, or I'm wrong?
I don't understand, but I feel that maybe I have to learn more fossil before continue, because I have the feeling this was more a bug than a misuse of a feature.
Why the shun confused the update? That's the question I'll try to answer...
Thanks everyone...
Erlis
Richard Hipp
You shun a commit or a file in a commit? Is in fossil the shun generating a different commit?
I shunned both the commit artifact and the file that was changed, the openoffice *.odp file.
you can delete with git files that has history with
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch file_name' HEAD
and that will generate a new commit without the file you just deleted (yes I know, that git command is really cryptic that's why I'm liking fossil so much :)
but I don't see how this will affect modified files. If the files are commited before, then you will never will lose those changes... unless you have shun those files, but I don't think that's the case, the file that was shun was a big image file, or I'm wrong?
Both the commit and the file were shunned.
I don't understand, but I feel that maybe I have to learn more fossil before continue, because I have the feeling this was more a bug than a misuse of a feature.
The problem was operator error, not a bug in fossil.
Erlis Vidal
Regards,
Erlis
Mike Meyer
You shun a commit or a file in a commit? Is in fossil the shun generating a different commit?
you can delete with git files that has history with
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch file_name' HEAD
and that will generate a new commit without the file you just deleted (yes I know, that git command is really cryptic that's why I'm liking fossil so much :)
but I don't see how this will affect modified files. If the files are commited before, then you will never will lose those changes... unless you have shun those files, but I don't think that's the case, the file that was shun was a big image file, or I'm wrong?
I don't understand, but I feel that maybe I have to learn more fossil before continue, because I have the feeling this was more a bug than a misuse of a feature.
Bill Burdick
On Tue, Oct 4, 2011 at 4:33 PM, Bill Burdick <bill.b...@gmail.com> wrote:You could handle that case -- if you shun the current commit, then check the disk against the current repo contents and mark files that are different as uncommitted.
But to do so would be hard. Shunning is done in the repository database file: "*.fossil". But the information about which files are uncommitted is held in the check-out database file: "_FOSSIL_". And while the check-out database knows about the existance of the repository database, the repository does not know about individual checkouts. So if you run the "fossil rebuild" following the shun from the web interface (which does not know about individual check-outs) the rebuild operation has no way of finding the check-out databases and patching them up.
So what you'd probably have to do is modify the "update" command (as well as other similar commands) to check to see if any shunning has taken place and modify their behavior accordingly. It would be tricky to implement and get right. And it would be a lot of work. All for something that is officially discouraged.
Gilles
<d...@sqlite.org> wrote:
>Learn from my mistake: Don't shun on a whim. The only reason to shun is to
>remove truly harmful content, such as spam. I should have just let the sync
>proceed even if it was slower than I would like.
Thanks for sharing this experience. I think it'd be useful to update
the documentation so that users know what to do when they eg. commited
big files by mistake, and how to cancel this commit entirely so that
the repo doesn't grow needlessly
www.sqlite.org/debug1/doc/trunk/www/shunning.wiki
Lluís Batlle i Rossell
I use to make an analogy to open-software/closed-software, talking about
open-development/closed-development.
git looks to me as a tool for publishing development steps, not necessarily very
related to the development history. The 'git version graph' is determined by the
users the same way as they choose filenames or directories, and many git groups
even consider keeping the git graph close to development history as a 'basic and
inexpert approach' to git.
And as determined by the creator, Linus, git is more like a tool meant for
sharing code preserving contributions authorship, other than storing development
history. I think Linus did not want for the kernel a storage for development
history; he only wanted to manage the contributions.
Regards,
Lluís.
Michal Suchanek
It is because it is not useful to have every *actual file edit*
recorded as commit. You often edit multiple files to perform a change,
or do some work on the project, save it, go for lunch, and then do
some more work on it.
From a totally purist point of view should the history be recorded
every time you save a file? Every time you write or delete a
character? No, it is saved in logical pieces - commits.
And when you find an issue with a commit that is some way back in your
personal branch it is more logical and easier to review your branch if
you append the fix to the commit where it belongs logically or if you
append it at the top of the history interspersed with some possibly
unrelated changes?
You can always create a new branch and put the commits in a different
order on that branch, merging the original commit with the fixup,
start applying your local changes at a later time in the upstream
project history. Git provides more tools to make this history
rewriting easier so that the presented development steps are easier to
understand to a reviewer.
You have to find some balance between shunning all history and
recording every character typed.
I don't mind fossil keeping these dead branches. In fact, git does so
too until you manually prune the repository of unreferenced objects.
You can also select to show only live branches in fossil so the
difference is mostly cosmetical, as are all the differences between
distributed VCSes.
In one you get a command shipped as part of core, in other you can
find a dozen contributed scripts that do the same or roll your own.
It's just a matter of taste or the core tools and available scripts
being more fitting for a particular task at hand.
Thanks
Michal
Lluís Batlle i Rossell
> 2011/10/5 Lluís Batlle i Rossell <viri...@gmail.com>:
> > related to the development history. The 'git version graph' is determined by the
> > users the same way as they choose filenames or directories, and many git groups
> > even consider keeping the git graph close to development history as a 'basic and
> > inexpert approach' to git.
>
> It is because it is not useful to have every *actual file edit*
> recorded as commit. You often edit multiple files to perform a change,
> or do some work on the project, save it, go for lunch, and then do
> some more work on it.
>
> From a totally purist point of view should the history be recorded
> every time you save a file? Every time you write or delete a
> character? No, it is saved in logical pieces - commits.
I consider commits as relevant milestones in the development, and I use branches
to keep differentg granularity of commits.
> And when you find an issue with a commit that is some way back in your
> personal branch it is more logical and easier to review your branch if
> you append the fix to the commit where it belongs logically or if you
> append it at the top of the history interspersed with some possibly
> unrelated changes?
Exactly, these are usual arguments among git lovers.
Nevertheless, git manuals say "every commit represents a state of the tree".
Then you may find logical to expect that every commit log talks about a state of
the tree. BUT all this goes away, when you start using 'rebase'. The commit logs
once written do not match anymore the 'state of the tree' at the time of commit
log writing. Assertions in commit logs like "this part works" may easily not
fit what was meant at the commit time, for example.
git even comes with 'quick automatic rebase' facilities, that allow not
rechecking any commit log (a task hard to do, in any case).
Making a review 'easier' by manipulating history can also end up being some
kind of manipulation to a reviewer. A reviewer may judge better by understanding
the development.
> I don't mind fossil keeping these dead branches. In fact, git does so
> too until you manually prune the repository of unreferenced objects.
> You can also select to show only live branches in fossil so the
> difference is mostly cosmetical, as are all the differences between
> distributed VCSes.
git even cannot store branch histories, beyond the big resulting graph of
unnamed commits. For example, a branch name can only designate a commit (leaf),
not more than one. And branch names are not part of history.
Some git deployments even forbid or limit pushing new branches to a public
repository.
On the other hand, fossil will always respect the checkin order, and the states
related to every checkin log. As many other VCS, but not with git.
Regards,
Lluís
Ron Wilson
> Fortunately, there was still one other copy in the undo stack....
I would add a fourth lesson: Always backup your work.
Konstantin Khomoutov
Lluís Batlle i Rossell <viri...@gmail.com> wrote:
[...]
> > And when you find an issue with a commit that is some way back in
> > your personal branch it is more logical and easier to review your
> > branch if you append the fix to the commit where it belongs
> > logically or if you append it at the top of the history
> > interspersed with some possibly unrelated changes?
>
> Exactly, these are usual arguments among git lovers.
>
> Nevertheless, git manuals say "every commit represents a state of the
> tree". Then you may find logical to expect that every commit log
> talks about a state of the tree. BUT all this goes away, when you
> start using 'rebase'. The commit logs once written do not match
> anymore the 'state of the tree' at the time of commit log writing.
> Assertions in commit logs like "this part works" may easily not fit
> what was meant at the commit time, for example.
>
> git even comes with 'quick automatic rebase' facilities, that allow
> not rechecking any commit log (a task hard to do, in any case).
>
> Making a review 'easier' by manipulating history can also end up
> being some kind of manipulation to a reviewer. A reviewer may judge
> better by understanding the development.
That sort of "we don't need it, we don't need it" mantra is a typical
case of the famous "Blub paradox".
I mean, if we have two DVCS tools one of which makes you able to
rewrite history and another one which doesn't, the first one is more
powerful _in this particular respect_. It's as simple as that.
By supporting a feature, the tool does not force you to employ that
feature in your workflow.
Mike Meyer
That sort of "we don't need it, we don't need it" mantra is a typical
case of the famous "Blub paradox".
I mean, if we have two DVCS tools one of which makes you able to
rewrite history and another one which doesn't, the first one is more
powerful _in this particular respect_. It's as simple as that.
By supporting a feature, the tool does not force you to employ that
feature in your workflow.
Michal Suchanek
> On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov
> <flat...@users.sourceforge.net> wrote:
>>
>> That sort of "we don't need it, we don't need it" mantra is a typical
>> case of the famous "Blub paradox".
>> I mean, if we have two DVCS tools one of which makes you able to
>> rewrite history and another one which doesn't, the first one is more
>> powerful _in this particular respect_. It's as simple as that.
>> By supporting a feature, the tool does not force you to employ that
>> feature in your workflow.
>
> First, note that there is a difference between "rewriting history", which
> is what git supports, and "deleting unwanted items", which is the request
> that started this.
> Second, that a feature doesn't affect you if you "just don't use it" is a
> fallacy. Sure, I think history should be sacrosanct, so I won't use rebase
> even if it's available. That doesn't stop others on the project (who don't
> agree with me) from using it . The only way to make sure that doesn't happen
> is to not have the feature available *at all*.
No, that's not how things work.
Rebase is nothing more than taking commits comprising a branch from
its branching point and applying them somewhere else. Not that
complicated, really.
As applying patches is doable, even patches stored in fossil history
already, this is doable with a bit of scripting around fossil as it is
doable with git. So not having the feature is not perfect defence, it
only defends against people who don't care about the feature. People
who find it useful for their workflow and want to use fossil for
compatibility with upstream of for other features it provides can do
so.
As an alternative you could use export/rebase/import which is just
different way to script this on a higher level.
>Finally, having a feature that powerful available tends to cause the API to *not* include safe versions of common tasks that >that dangerous feature handles. To see what I mean, take a look at mercurial, which shares the fossil philosophy, but >provides a (disabled by default) rebase command. It has a number of commands (*not* disabled by default) for tasks that >are handled in git using rebase. Unlike rebase, those commands are safe, in that mistakes with them can't wreck your repo >the way a mistake with rebase can. It may not make a difference if you never make mistakes, but in that case you don't >need rebase.
You can shoot yourself in the foot with any tool. Using tools that
suit your workflow makes that less likely, being dangerous or not.
I personally make a copy of any branch before rebasing it because in
the case rebasing fails you can still revert it but comparing with the
old branch makes it much clearer where you ended up.
If you never delete anything it makes your work safer but your
repository more hairy.
Thanks
Michal
Konstantin Khomoutov
Mike Meyer <m...@mired.org> wrote:
> > That sort of "we don't need it, we don't need it" mantra is a
> > typical case of the famous "Blub paradox".
> > I mean, if we have two DVCS tools one of which makes you able to
> > rewrite history and another one which doesn't, the first one is more
> > powerful _in this particular respect_. It's as simple as that.
> > By supporting a feature, the tool does not force you to employ that
> > feature in your workflow.
> First, note that there is a difference between "rewriting history",
> which is what git supports, and "deleting unwanted items", which is
> the request that started this.
Correct.
> Second, that a feature doesn't affect you if you "just don't use it"
> is a fallacy. Sure, I think history should be sacrosanct, so I won't
> use rebase even if it's available. That doesn't stop others on the
> project (who don't agree with me) from using it . The only way to
> make sure that doesn't happen is to not have the feature available
> *at all*.
I'm not entirely convinced.
Look at the workflow used by the Git team: they maintain the set of
well known branches, of which the only one, named "pu" ("proposed
updates"), is allowed to be rebased and that's actually what happens
with it each time the new release is made--it's cut from the master
afresh. I mean, while every committer has `git rebase` at their
disposal and knows how it works this does not mean they go off and break
the repository with rebases. So your point is only really valid when
the project is run by a bunch of idiots or complete newbies.
> Finally, having a feature that powerful available tends to cause the
> API to *not* include safe versions of common tasks that that
> dangerous feature handles. To see what I mean, take a look at
> mercurial, which shares the fossil philosophy, but provides a
> (disabled by default) rebase command. It has a number of commands
> (*not* disabled by default) for tasks that are handled in git using
> rebase. Unlike rebase, those commands are safe, in that mistakes with
> them can't wreck your repo the way a mistake with rebase can. It may
> not make a difference if you never make mistakes, but in that case
> you don't need rebase.
Git handles it from the opposite direction by having "the reflog".
But I find this point to be valid, yes, safety nets are a must when it
comes to handling precious data. BTW I'm a fan of `fossil undo` for
that matter.
> Bottom line: while "more features" may imply "more powerful", it
> doesn't imply "better".
Moot point.
I really miss Git's "index" and `git add --patch` here.
Is Fossil better than Git in this respect by not having those "more
features"? Surely it completely is in the eye of the beholder.
Mike Meyer
On 5 October 2011 20:12, Mike Meyer <m...@mired.org> wrote:
> On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov
> <flat...@users.sourceforge.net> wrote:
>>
>> That sort of "we don't need it, we don't need it" mantra is a typical
>> case of the famous "Blub paradox".
>> I mean, if we have two DVCS tools one of which makes you able to
>> rewrite history and another one which doesn't, the first one is more
>> powerful _in this particular respect_. It's as simple as that.
>> By supporting a feature, the tool does not force you to employ that
>> feature in your workflow.
>
> First, note that there is a difference between "rewriting history", which
> is what git supports, and "deleting unwanted items", which is the request
> that started this.
> Second, that a feature doesn't affect you if you "just don't use it" is a
> fallacy. Sure, I think history should be sacrosanct, so I won't use rebase
> even if it's available. That doesn't stop others on the project (who don't
> agree with me) from using it . The only way to make sure that doesn't happen
> is to not have the feature available *at all*.
No, that's not how things work.
Rebase is nothing more than taking commits comprising a branch from
its branching point and applying them somewhere else. Not that
complicated, really.
As applying patches is doable, even patches stored in fossil history
already, this is doable with a bit of scripting around fossil as it is
doable with git. So not having the feature is not perfect defence, it
only defends against people who don't care about the feature. People
who find it useful for their workflow and want to use fossil for
compatibility with upstream of for other features it provides can do
so.
Erlis Vidal
Yesterday I was confused because I though the shun was done in the big file, but indeed the shun was done in the commit also... will that modify the history? I got the feeling that shunning a commit will change the history... not sure about it, you tell me.
If I'm working under the premisses that the history cannot be changed, is shunning a commit (in case it change the history) a valid operation? Maybe fossil shouldn't allow to shun a commit, just individual files, if you really want to shun all files in that commit, then fossil could allow that, (shun --all) but that shouldn't touch ever the commit artifact..
Regards,
Erlis
Gé Weijers
On Wed, 5 Oct 2011, Michal Suchanek wrote:
> And when you find an issue with a commit that is some way back in your
> personal branch it is more logical and easier to review your branch if
> you append the fix to the commit where it belongs logically or if you
> append it at the top of the history interspersed with some possibly
> unrelated changes?
One of the downsides of rebasing is that the following workflow does
present problems:
- develop & commit
- sync with upstream, rebase/commit
- test
- sync with upstream, rebase/commit and push
The version you tested now no longer exists in the repository. This may
not be a big issue in some environments, but it may be a showstopper
elsewhere (where I work it is).
If you have to use a Git repository in such an environment you end up
using hooks to log all updates, and block all forced updates (updates that
edit history). Otherwise one clueless developer can do serious damage.
Ge'
Michal Suchanek
>
>
> On Wed, 5 Oct 2011, Michal Suchanek wrote:
>
>> And when you find an issue with a commit that is some way back in your
>> personal branch it is more logical and easier to review your branch if
>> you append the fix to the commit where it belongs logically or if you
>> append it at the top of the history interspersed with some possibly
>> unrelated changes?
>
> One of the downsides of rebasing is that the following workflow does present
> problems:
>
> - develop & commit
> - sync with upstream, rebase/commit
> - test
> - sync with upstream, rebase/commit and push
>
> The version you tested now no longer exists in the repository. This may not
> be a big issue in some environments, but it may be a showstopper elsewhere
> (where I work it is).
>
> If you have to use a Git repository in such an environment you end up using
> hooks to log all updates, and block all forced updates (updates that edit
> history). Otherwise one clueless developer can do serious damage.
Most sane git workflows require that sync with upstream does not
require forced updates. Some project have experimental branch that may
but all else should update cleanly. You can always make a copy of your
branch before you rebase so that you do have a copy.
Thanks
Michal