Re: [fossil-users] wiki pages
Clear enough, Thank you very much for answering... that fast!! Wonderful product by the way!! On Fri, Dec 2, 2011 at 1:38 PM, Richard Hipp wrote: > > > On Fri, Dec 2, 2011 at 1:33 PM, Erlis Vidal wrote: > >> Hi, >> >> This is a quick question: Is it possible to "rename" a wiki page. Let's >> say I've change my mind after naming it. Is it possible to rename or delete >> a page? >> > > Fossil does not let you rewrite history. So if you historically had a > wiki page named "xyz" then that page will exist forever. You can create a > new, replacement page with a different name. And you can remove all > content from the latest version of "xyz" to indicate that it is no longer > an active page. But you cannot remove historical contents of wiki pages > (except via the "shun" mechanism, which is a different topic). > > Fossil follows accounting rules: You never erase. If a mistake is found, > instead of erasing, you enter a correction. Always preserve the audit > trail. > > >> Thanks >> Erlis >> >> ___ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> >> > > > -- > 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 > > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] wiki pages
Hi, This is a quick question: Is it possible to "rename" a wiki page. Let's say I've change my mind after naming it. Is it possible to rename or delete a page? Thanks Erlis ___ 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] GUI client for Windows?
Take a look to protocol buffers. The implementation is not restricted only to java, c++, python. Other people are adding more languages... this gives you kind of "portability" -Erlis On Thu, Oct 6, 2011 at 11:19 AM, Stephan Beal wrote: > On Thu, Oct 6, 2011 at 4:47 PM, Erlis Vidal wrote: > >> Do you know about "protocol buffers". I'm asking because I didn't know >> about them since recently. >> >> >> http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html >> > > Never heard of them. Thanks for the link :). > > >> Could this help in order to allow binaries and improve the serialization >> performance? >> > > No idea just yet :). But i will take a look at that. > > One thing to remember is that JSON != JavaScript, meaning that if we > include ANY algorithms for binary data, ALL clients which want to use > fossil/json HAVE to implement those algorithms. e.g. if we decide on base64, > ALL client languages have to support it if they want to use those features > of the API. Because of this, i would like to stick "non-formatted" data > where possible, falling back to non-JSON-specified algos only when > absolutely necessary. > > My current thinking on binary is that it "probably should" be encoded the > same way one encodes binary in sqlite: X'aabbccdd', i.e. a simple list of > hex value pairs. The down-side is that it literally doubles the size, which > means that those fossil users which version-control 500MB files (which is > insane, IMO, but people do it) will have a memory cost of approximately 3x > that file's size when turning the artifact into JSON (1x for the original > copy and 2x for the X'...' encoding, and possibly even more for the > underlying sqlite statement to/from that data). Try to commit a 2GB file and > you can't - your machine (or the remote fossil server) will die with an OOM > error. The up-side is that en/decoding it is absolutely trivial - even an > absolute beginner could figure out how to encode/decode it and it can be > done in any language which supports binary data (e.g. NOT in shell code, but > in JS/Python/Perl/PHP/Java, etc). > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > > ___ > 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] GUI client for Windows?
On Thu, Oct 6, 2011 at 9:04 AM, Stephan Beal wrote: > There are some (a small few) features which we can't provide over JSON > without some major workarounds and/or caveats. Namely binary data (which > JSON cannot natively support), which means committing binary files this way > will not be implemented, at least initially, and will have some significant > limitations if it is ever implemented (e.g. the RAM cost of committing > base64-encoded binary content in JSON form would be roughly 2-3x the > original content size, so it would likely fail miserably for those people > who think that having files >500MB in their repo is somehow a good idea). > > Hi Stephan, Do you know about "protocol buffers". I'm asking because I didn't know about them since recently. http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html Could this help in order to allow binaries and improve the serialization performance? --Erlis ___ 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] git vs fossil again (was: why you should not shun)
I get the two points of view and I'm not saying one is right or wrong.
Modifying the history versus keeping everything as indeed happens (the
history after all)
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
On Wed, Oct 5, 2011 at 2:40 PM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:
> On Wed, 5 Oct 2011 11:12:31 -0700
> Mike Meyer 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.
> ___
> 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] Why you should not shun
Ok I got it, following your story it was not clear that you shun the commit, thinking that you just shun the big file was what lead me to the big confusion... Regards, Erlis On Tue, Oct 4, 2011 at 4:53 PM, Richard Hipp wrote: > > > On Tue, Oct 4, 2011 at 4:50 PM, Erlis Vidal wrote: > >> 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. > > >> >> Why the shun confused the update? That's the question I'll try to >> answer... >> >> Thanks everyone... >> Erlis >> >> >> On Tue, Oct 4, 2011 at 4:33 PM, Bill Burdick 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. >>> >>> >>> Bill >>> >>> >>> On Tue, Oct 4, 2011 at 3:15 PM, Richard Hipp wrote: >>> >>>> >>>> >>>> On Tue, Oct 4, 2011 at 4:09 PM, Erlis Vidal wrote: >>>> >>>>> 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. >>>> >>>> >>>> >>>>> ** >>>>> 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 >>>>> >>>>> >>>>> On Tue, Oct 4, 2011 at 3:59 PM, Richard Hipp wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Oct 4, 2011 at 3:55 PM, Erlis Vidal wrote: >>>>>> >>>>>>> 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 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. >>>>>>>> >
Re: [fossil-users] Why you should not shun
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. Why the shun confused the update? That's the question I'll try to answer... Thanks everyone... Erlis On Tue, Oct 4, 2011 at 4:33 PM, Bill Burdick 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. > > > Bill > > > On Tue, Oct 4, 2011 at 3:15 PM, Richard Hipp wrote: > >> >> >> On Tue, Oct 4, 2011 at 4:09 PM, Erlis Vidal wrote: >> >>> 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. >> >> >> >>> ** >>> 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 >>> >>> >>> On Tue, Oct 4, 2011 at 3:59 PM, Richard Hipp wrote: >>> >>>> >>>> >>>> On Tue, Oct 4, 2011 at 3:55 PM, Erlis Vidal wrote: >>>> >>>>> 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 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 >>>>> >>>>> ___ >>>>
Re: [fossil-users] Why you should not shun
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. * 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 On Tue, Oct 4, 2011 at 3:59 PM, Richard Hipp wrote: > > > On Tue, Oct 4, 2011 at 3:55 PM, Erlis Vidal wrote: > >> 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 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-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> >> > > > -- > 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 > > ___ 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] Why you should not shun
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 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. Please (if is not much to ask) can you explain what creates the issue? Sincerely, Erlis ___ 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] Why you should not shun
I have fossil documentations bookmarked everywhere, I'll be fixing those bookmarks, thanks. Maybe I have to blame google :) On Tue, Oct 4, 2011 at 2:55 PM, Stephan Beal wrote: > n Tue, Oct 4, 2011 at 8:53 PM, Erlis Vidal wrote: > >> I would like to see the *shun* documentation, I'm not able to find it >> here http://www.sqlite.org/debug1/help > > > Why would it be on the sqlite site? It's here: > > http://www.fossil-scm.org/index.html/doc/trunk/www/shunning.wiki > > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > > ___ > 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] Why you should not shun
Before I ask 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 On Tue, Oct 4, 2011 at 2:50 PM, Stephan Beal wrote: > On Tue, Oct 4, 2011 at 8:39 PM, wrote: > >> 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. > > > Side note: the JSON API makes it possible to use wikis (and soon tickets) > from within your own custom HTML interface, meaning that it can be used as a > wiki back-end independently of the version control features (but > automatically inheriting those features, should you need to back-rev a wiki > page or whatever). Additionally, it allows clients to use their own wiki > formats if they like (because it can serve the content in raw or > fossil-parsed forms) provided that the client have a client-side renderer > for the content. Creating a demo of such an app is on my todo list. i have a > wiki management app (implemented in HTML+JS) which uses a different (but > conceptually similar) back-end and it should not be difficult to port to a > fossil back-end. The JSON API has all the features needed for this but i > would first like to make more progress on the artifact fetching APIs so that > it will be possible (client-side) to look through historical versions of > pages. > > A _very_ rough prototype of this idea can be seen here: > > http://fossil.wanderinghorse.net/repos/fossil-sgb/json/wiki-editor.html > > but you cannot save from that demo page unless you crack my password ;). > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > > ___ > 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] delete a branch
I've been following fossil community just a couple of weeks ago and you guys rocks! I really appreciate all your answers and the "welcome" I've received... Thanks once more for this amazing project Erlis On Fri, Sep 30, 2011 at 8:04 PM, Stephan Beal wrote: > On Fri, Sep 30, 2011 at 10:38 PM, Erlis Vidal wrote: > >> My mistake was that I create a branch but forgot to check it out, and did >> a couple of commits. Then I realized that the branch was there, but empty... >> it was my bad. >> > > In such a case you can use: > > fossil commit -m '...' --branch branchname ...file list... > > to commit the changes to a specific branch. i _think_ that will work with > existing branches, but it might require a _new_ branch name. > > I just noticed in the timeline that with fossil, creating a branch creates >> also a commit... hmmm now I see something different... >> > > LOL. There was a long debate about that behaviour a couple months back. > Some prefer it that way, some prefer to commit to a specific branch to start > the branch. > > Is there something I can read that could explain me better the "fossil >> internals" a wiki? >> > > All of those docs are over on the fossil web site. Try: > > http://fossil-scm.org/index.html/doc/trunk/www/permutedindex.wiki > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > > ___ > 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] delete a branch
thanks! On Fri, Sep 30, 2011 at 4:44 PM, Brian Smith wrote: > http://fossil-scm.org/index.html/doc/trunk/www/branching.wiki > > On Fri, Sep 30, 2011 at 1:38 PM, Erlis Vidal wrote: > > Hi all, > > > > thanks for the answers, maybe I'm approaching fossil from the git side. > > Maybe I have a misconception. In Git a branch is just a pointer to a > given > > commit, removing the branch won't remove any content, unless the branch > is > > not merged so I need to do the force thing but that's not the case. > > > > My mistake was that I create a branch but forgot to check it out, and did > a > > couple of commits. Then I realized that the branch was there, but > empty... > > it was my bad. > > > > I just noticed in the timeline that with fossil, creating a branch > creates > > also a commit... hmmm now I see something different... > > > > Is there something I can read that could explain me better the "fossil > > internals" a wiki? > > > > Thanks for this job, > > Erlis > > > > On Fri, Sep 30, 2011 at 4:32 PM, Stephan Beal > wrote: > >> > >> On Fri, Sep 30, 2011 at 10:01 PM, Erlis Vidal > >> wrote: > >>> > >>> Is it possible to delete a branch? I've created a branch by mistake, > in > >>> this case I don't want to merge the branch, I'm looking for the git > >>> equivalent -f (force delete) > >> > >> http://www.fossil-scm.org/index.html/doc/trunk/www/shunning.wiki > >> -- > >> - stephan beal > >> http://wanderinghorse.net/home/stephan/ > >> > >> ___ > >> 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 > ___ 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] delete a branch
Hi all, thanks for the answers, maybe I'm approaching fossil from the git side. Maybe I have a misconception. In Git a branch is just a pointer to a given commit, removing the branch won't remove any content, unless the branch is not merged so I need to do the force thing but that's not the case. My mistake was that I create a branch but forgot to check it out, and did a couple of commits. Then I realized that the branch was there, but empty... it was my bad. I just noticed in the timeline that with fossil, creating a branch creates also a commit... hmmm now I see something different... Is there something I can read that could explain me better the "fossil internals" a wiki? Thanks for this job, Erlis On Fri, Sep 30, 2011 at 4:32 PM, Stephan Beal wrote: > On Fri, Sep 30, 2011 at 10:01 PM, Erlis Vidal wrote: > >> Is it possible to delete a branch? I've created a branch by mistake, in >> this case I don't want to merge the branch, I'm looking for the git >> equivalent -f (force delete) >> > > http://www.fossil-scm.org/index.html/doc/trunk/www/shunning.wiki > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > > ___ > 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] delete a branch
I'm sorry for this so n00b question but I'm not able to find this anywhere. Is it possible to delete a branch? I've created a branch by mistake, in this case I don't want to merge the branch, I'm looking for the git equivalent -f (force delete) Thanks, Erlis ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] ignoring files
Hi guys, I'm start using fossil and at this moment I'm just playing with it. One thing I'm doing is migrating some .git repositories and see how it goes. With git I tend to put all files I want to keep out of the repo in the .gitIgnore file. I see in the documentation that fossil uses a command argument in the add command for this (--ignore) The problem with this is that the list on some of my git projects are really big and I don't want to type all those files. Do fossil has a syntax to exclude all files in certain folder? Example: exclude all files in the folder bin/ This option has the scenario when I want any bin/ folder to be excluded, or a specific folder /dev/project/files-to-be-excluded-from-repo/ is there something for this? I'm pretty sure there is by my fossil-ignorance at this point prevent me to find the answer Thanks for you patient Erlis ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
