Re: [fossil-users] Fossil mentioned on HN

[Andy Bradford]

Thus said Stephan Beal on Wed, 16 Dec 2015 10:36:18 +0100:

> One of  the reasons i always  liked StarWars better than  Star Trek is
> because in Star Trek everything  is so antiseptically _clean_, whereas
> in Star Wars ships have dirt ("carbon scoring") and scratches on them,
> and the lights don't all work (some flicker).

You must have been a big fan of Firefly/Serenity ;-)

Andy
-- 
TAI64 timestamp: 40005671c93c


___
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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

[Stephan Beal]

might not be fault tolerant in the Enterprise marketing sense of the term,
but it's fairly tolerant of faults at various levels. ;) In any case, it's
undisputedly more tolerant of storage-system failures than git is.

- stephan beal, sgb...@googlemail.com
Written on a keyboard attached to a telephone attached to a TV screen, via
an app written for use on touchscreens. Please excuse brevity, typos, and
whatnot.
On Dec 16, 2015 6:09 PM, "Scott Robison"  wrote:

> Is a sql database fault tolerant? I guess so, but think that is not what
> most people consider fault tolerant.
> On Dec 16, 2015 9:36 AM, "Stephan Beal"  wrote:
>
>> Section 4.1: in fossil, but not git: fault-tolerant storage.
>>
>> - stephan beal, sgb...@googlemail.com
>> Written on a keyboard attached to a telephone attached to a TV screen,
>> via an app written for use on touchscreens. Please excuse brevity, typos,
>> and whatnot.
>> On Dec 16, 2015 5:16 PM, "Richard Hipp"  wrote:
>>
>>> Based on comments on HN and on this mailing list, I have attempted to
>>> rewrite the fossil-v-git.wiki document
>>> (https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
>>> better summarize the differences between the two products.
>>>
>>> Your feedback on the rewrite, and especially suggestions for improving
>>> it, are welcomed.
>>>
>>> --
>>> 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 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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

[Eric Rubin-Smith]

On Wed, Dec 16, 2015 at 11:16 AM, Richard Hipp  wrote:

> Based on comments on HN and on this mailing list, I have attempted to
> rewrite the fossil-v-git.wiki document
> (https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
> better summarize the differences between the two products.
>
> Your feedback on the rewrite, and especially suggestions for improving
> it, are welcomed.
>

The doc says:

> If you start out using one DVCS and later decide you like the other
better, it is easy to change
.

DRH and crew have defined "easy to change" (meaning easy to migrate away
from) in a way that is misleadingly narrow for many people.  The reason is
that if you are using Fossil with its ticket tracker, then there is no
simple way to export those tickets to any current member of the Git
ecosystem that does ticket tracking (e.g. Jira).

Providing an outbound export interface to at least one such tool would
further strengthen the claim that it is easy to migrate away from Fossil.
Otherwise, users will be "locked in" in the sense that their tickets are
stuck in Fossil, where it is hard to properly cross-reference them with the
ongoing stream of check-ins after export to Git.

In the past, DRH has criticized my above observations by saying that since
Fossil is backed by an SQLite database which the user may query at his or
her leisure, this should suffice for an export capability for tickets.
This criticism does not hold much water, however, since we can observe the
following:

(1) The raw check-in data is *also* backed by an SQLite database.  But the
Fossil dev team saw fit to write an export-to-git capability on top of
that.  This is an internal inconsistency in DRH's argument, since
ostensibly the devs don't think the git export capability was a mistake.

(2) The reasons for having written an export-to-git capability are good
reasons.  Analogously to Word's ability to export to PDF, the application
in question knows both the source and target data formats and how to do the
relevant translations.  Indeed, the whole purpose of export can be seen as
relieving the user of the burden of understanding the source and target
data formats and performing the conversions.  (In a prior thread on this
topic, someone criticized this point by saying that Microsoft has more
developer power than does Fossil.  This, while true, is irrelevant to
questions about whether such an export feature would be useful.)  And in
particular, merely having a well-understood data format does not suffice:
Word cannot claim to have the ability to export to PDF *merely* because its
internal data format is public.

(3) The reasons in (2) generalize to the case of tickets.

DRH has made another criticism of my observations which was that no other
ticket manager permits easy export of its tickets to a 3rd-party ticket
manager.  Whether this is true or not, it is again irrelevant to my claim
that Fossil's ticket system is not, in fact, easy to migrate away from.

Eric
___
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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

[Scott Robison]

Is a sql database fault tolerant? I guess so, but think that is not what
most people consider fault tolerant.
On Dec 16, 2015 9:36 AM, "Stephan Beal"  wrote:

> Section 4.1: in fossil, but not git: fault-tolerant storage.
>
> - stephan beal, sgb...@googlemail.com
> Written on a keyboard attached to a telephone attached to a TV screen, via
> an app written for use on touchscreens. Please excuse brevity, typos, and
> whatnot.
> On Dec 16, 2015 5:16 PM, "Richard Hipp"  wrote:
>
>> Based on comments on HN and on this mailing list, I have attempted to
>> rewrite the fossil-v-git.wiki document
>> (https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
>> better summarize the differences between the two products.
>>
>> Your feedback on the rewrite, and especially suggestions for improving
>> it, are welcomed.
>>
>> --
>> 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil mentioned on HN

[Scott Robison]

On Wed, Dec 16, 2015 at 4:06 AM, Stephan Beal  wrote:

> On Wed, Dec 16, 2015 at 11:59 AM, Gaurav M. Bhandarkar <
> gaurav.a...@gmail.com> wrote:
>
>> "git rebase -i" seems to enable me to work on multiple projects at the
>> same time. Because of it I can maintain versioned "development sessions" of
>> not only my code but other things that were required/relevant to make that
>> code. Without it I find it impossible to handle the "context switch" that
>> comes when you work on multiple projects.
>>
>
> fossil supports multiple open checkouts of any given repo db copy, which
> is arguably a cleaner approach than temporarily sticking stuff into SCM
> (when you've no intention of keeping it there). It's a matter of taste, of
> course, but fossil does offer an option other than keeping separate trains
> of thought in the same physical copy of the tree. To me that seems simpler
> than [ab]using the SCM for that type of thing, in particular because a
> context switch is a simple 'cd' instead of SCM commands.
>

I realize that 'get rebase -i' gives a lot more tools, but couldn't 99% of
rebase use cases be handled with private branches? I've never used private
branches until today (just for testing purposes), and from what I see I can
do whatever I want in the private branch, merge from trunk, cherry pick,
reverse out, whatever to make the tip of my private branch 100% pristine
and proper, and only then merge it to trunk. I could just as easily have
created a new branch off the tip of trunk,and merged my private branch to
the public branch, which I could then merge to trunk so that people aren't
upset at me for working on trunk.

-- 
Scott Robison
___
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] Fossil mentioned on HN

[Warren Young]

On Dec 16, 2015, at 2:28 PM, Scott Robison  wrote:
> 
> couldn't 99% of rebase use cases be handled with private branches?

Probably not with the current design.  For one thing, there are no “branches”, 
only “branch.”  That is, the private branch is always called “private”, so that 
when you commit to it, return to trunk, and create a new private branch, you’re 
actually forking the original private branch.

In order to have Git-like private branches, I think the design would have to 
change to allow multiple independent private branches.

Not that I’m asking for such a thing.  I already made public my opinions about 
working in private.  (“Guy in the room” syndrome.)

> I can do whatever I want in the private branch, merge from trunk, cherry 
> pick, reverse out, whatever to make the tip of my private branch 100% 
> pristine and proper, and only then merge it to trunk.

That’s pretty much the definition of “guy in the room.”  Why are we re-learning 
this lesson 44 years after its dangers were first published?
___
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] Fossil mentioned on HN

[Scott Robison]

On Wed, Dec 16, 2015 at 4:12 PM,  wrote:
>
> Hmm.. If one can create a private branch, do all draft work there and
when done merge to trunk (or other non-private branch), then sync with the
main repo, the main repo will not contain any traces of the private branch
(with the draft work).  Am I correct?

That seems to be the case based on my limited testing earlier today.

> So, if then the local repo is deleted and a new one created by cloning
the main repo, we end up with the desired effect: a repo that does not
include any ‘bloat’ from the private work.

That sounds correct.

> But, since many people (myself including) seem to like the idea of draft
work that once merged into mainstream branches should no longer take up
space (forever) in the repo, and given that the above procedure actually
achieves this goal, wouldn’t be nicer to have an explicit command (or
option to existing command) to purge a private branch at the local level?


>From http://fossil-scm.org/xfer/doc/trunk/www/private.wiki:

> You can remove all private branches from a repository using this command:
> fossil scrub --private
> Note that the above is a permanent and irreversible change. You will be
asked to confirm before continuing. Once the private branches are removed,
they cannot be retrieved (unless you have synced them to another
repository.) So be careful with the command.

I just tried it and it worked. Also included is a warning that it is all or
nothing. You can scrub all private or no private, but not one or some
private (unless one or some are equal to all). :)

SDR
___
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] Fossil mentioned on HN

[tonyp]

Hmm.. If one can create a private branch, do all draft work there and when done 
merge to trunk (or other non-private branch), then sync with the main repo, the 
main repo will not contain any traces of the private branch (with the draft 
work).  Am I correct?
So, if then the local repo is deleted and a new one created by cloning the main 
repo, we end up with the desired effect: a repo that does not include any 
‘bloat’ from the private work.
But, since many people (myself including) seem to like the idea of draft work 
that once merged into mainstream branches should no longer take up space 
(forever) in the repo, and given that the above procedure actually achieves 
this goal, wouldn’t be nicer to have an explicit command (or option to existing 
command) to purge a private branch at the local level?
(BTW, multiple check-outs is not the same.  You have to work with stash.  
Copying the repo file to take with you on another computer does not bring along 
the stash.  It also carries the risk of losing the stash if you accidentally 
delete the current directory.)
This would have the same effect as Git rebase (to some extent), wouldn’t it?
From: Scott Robison 
Sent: Wednesday, December 16, 2015 11:28 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Fossil mentioned on HN

On Wed, Dec 16, 2015 at 4:06 AM, Stephan Beal  wrote:

  On Wed, Dec 16, 2015 at 11:59 AM, Gaurav M. Bhandarkar 
 wrote:

"git rebase -i" seems to enable me to work on multiple projects at the same 
time. Because of it I can maintain versioned "development sessions" of not only 
my code but other things that were required/relevant to make that code. Without 
it I find it impossible to handle the "context switch" that comes when you work 
on multiple projects.


  fossil supports multiple open checkouts of any given repo db copy, which is 
arguably a cleaner approach than temporarily sticking stuff into SCM (when 
you've no intention of keeping it there). It's a matter of taste, of course, 
but fossil does offer an option other than keeping separate trains of thought 
in the same physical copy of the tree. To me that seems simpler than [ab]using 
the SCM for that type of thing, in particular because a context switch is a 
simple 'cd' instead of SCM commands.

I realize that 'get rebase -i' gives a lot more tools, but couldn't 99% of 
rebase use cases be handled with private branches? I've never used private 
branches until today (just for testing purposes), and from what I see I can do 
whatever I want in the private branch, merge from trunk, cherry pick, reverse 
out, whatever to make the tip of my private branch 100% pristine and proper, 
and only then merge it to trunk. I could just as easily have created a new 
branch off the tip of trunk,and merged my private branch to the public branch, 
which I could then merge to trunk so that people aren't upset at me for working 
on trunk.

-- 
Scott Robison 




___
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] Fossil mentioned on HN

[Scott Robison]

On Wed, Dec 16, 2015 at 4:53 PM, Warren Young  wrote:

> On Dec 16, 2015, at 2:28 PM, Scott Robison 
> wrote:
> >
> > couldn't 99% of rebase use cases be handled with private branches?
>
> Probably not with the current design.  For one thing, there are no
> “branches”, only “branch.”  That is, the private branch is always called
> “private”, so that when you commit to it, return to trunk, and create a new
> private branch, you’re actually forking the original private branch.
>

I have a test repo at present with three private branches named test, bob,
and sue.


> In order to have Git-like private branches, I think the design would have
> to change to allow multiple independent private branches.
>
> Not that I’m asking for such a thing.  I already made public my opinions
> about working in private.  (“Guy in the room” syndrome.)
>
> > I can do whatever I want in the private branch, merge from trunk, cherry
> pick, reverse out, whatever to make the tip of my private branch 100%
> pristine and proper, and only then merge it to trunk.
>
> That’s pretty much the definition of “guy in the room.”  Why are we
> re-learning this lesson 44 years after its dangers were first published?
>

I'm not advocating working that way. I'm just allowing that fossil could
work for people who want to work that way in some / most cases.

-- 
Scott Robison
___
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] Fossil mentioned on HN

[Ron W]

On Wed, Dec 16, 2015 at 4:27 AM, Gaurav M. Bhandarkar  wrote:
>
> fast forward merges is just one of the advantages of rebase. It is done to
> avoid the extra “merge-commit” and thus reduces the noise in repo history.
>

Don't need rebase to use fast-forward merge. As I said, I usually only
submit the final revision - after merging in the lastest tip from the trunk
of the (open source) projects I'm contributing to. (For work, we keep all
revisions in our department repos.)


> Then I run “git rebase -i master” which gives me an option to “squash”
> commits that happened after “where-master-is-currently-at”. I can now
> remove those commits that had binary files, code samples etc. from my local
> branch’s history while keeping the actual code-changes and their commit
> messages. In the end I get a clean revision history ready to be merged in
> the master.
>
>
> I really miss this feature when I use fossil.
>

You can use private branches to the same effect, optionally scrubbing the
private branches when done. But even if you don't scrub the private
branches, they won't get sync'd to the upstream repo (unless you use the
 --private option on the pull command (possibly also push and sync as
well)).

While I have used rebase a few times when I was asked to preserve the
change history, I strongly prefer to not use it as it results in commits
with questionable content. Granted those intermediate commits are rarely
used to build run-able or releasable code, but I dislike "publishing" them.
___
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] Fossil mentioned on HN

[Scott Robison]

On Wed, Dec 16, 2015 at 6:41 PM, Ron W  wrote:

> On Wed, Dec 16, 2015 at 6:53 PM, Scott Robison 
> wrote:
>
>> > You can remove all private branches from a repository using this
>> command:
>> > fossil scrub --private
>> > Note that the above is a permanent and irreversible change. You will be
>> asked to confirm before continuing. Once the private branches are removed,
>> they cannot be retrieved (unless you have synced them to another
>> repository.) So be careful with the command.
>>
>
> But scrub doesn't accept names to specify which branches to purge. (Just
> pointing that out. I've not yet had a reason to purge any branches.)
>

Right. I think I said that. If not, I said corrected.

-- 
Scott Robison
___
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] Fossil mentioned on HN

[Gaurav M. Bhandarkar]

>It's a matter of taste

I agree.


>To me that seems simpler than [ab]using the SCM for that type of thing

I think the power of versioning given by the SCM may not be limited to just
the publishable code that I write. IMO using it to version other things
isn't abusing but realizing its true potential :)




On Wed, Dec 16, 2015 at 4:36 PM, Stephan Beal  wrote:

> On Wed, Dec 16, 2015 at 11:59 AM, Gaurav M. Bhandarkar <
> gaurav.a...@gmail.com> wrote:
>
>> "git rebase -i" seems to enable me to work on multiple projects at the
>> same time. Because of it I can maintain versioned "development sessions" of
>> not only my code but other things that were required/relevant to make that
>> code. Without it I find it impossible to handle the "context switch" that
>> comes when you work on multiple projects.
>>
>
> fossil supports multiple open checkouts of any given repo db copy, which
> is arguably a cleaner approach than temporarily sticking stuff into SCM
> (when you've no intention of keeping it there). It's a matter of taste, of
> course, but fossil does offer an option other than keeping separate trains
> of thought in the same physical copy of the tree. To me that seems simpler
> than [ab]using the SCM for that type of thing, in particular because a
> context switch is a simple 'cd' instead of SCM commands.
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> "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] Fossil mentioned on HN

[Gaurav M. Bhandarkar]

Yes, rebase is just a faster way to cherry-pick and other things:
http://think-like-a-git.net/sections/rebase-from-the-ground-up/using-git-cherry-pick-to-simulate-git-rebase.html



On Thu, Dec 17, 2015 at 11:43 AM, Scott Robison 
wrote:

> On Wed, Dec 16, 2015 at 10:34 PM, Gaurav M. Bhandarkar <
> gaurav.a...@gmail.com> wrote:
>
>> > Don't need rebase to use fast-forward merge.
>>
>> Normal merge or rebase both "enables" fast-forward merges. But the
>> advantage "rebase-before-ff-merge" has is that it avoids other(s) extra
>> "merge commits" that you would have done to get your branch updated with
>> changes from remote.
>>
>> See the section "Don't merge upstream code at random points":
>> https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
>>
>>
>> > You can use private branches to the same effect
>> I'm not sure. The thing that immediately comes to mind is that fossil's
>> private branches will show up as a single commit in the public branch.
>>
>
> It depends on how you go about it:
>
> Create a private branch off trunk. Edit, commit, do whatever you want with
> it.
>
> When you're finished and ready to rebase, create a public branch off trunk
> and cherry pick merge the private commits you want in the public history.
> You have as much opportunity as you want to clean and massage them.
>
> Now you can merge that branch to trunk.
>
> I'm not trying to suggest it is in any way nearly as "elegant" as "rebase
> -i" (those who prefer that would find this clunky at best). Still, it seems
> possible.
>
> --
> Scott Robison
>
>
> ___
> 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] Fossil mentioned on HN

[Gaurav M. Bhandarkar]

> Don't need rebase to use fast-forward merge.

Normal merge or rebase both "enables" fast-forward merges. But the
advantage "rebase-before-ff-merge" has is that it avoids other(s) extra
"merge commits" that you would have done to get your branch updated with
changes from remote.

See the section "Don't merge upstream code at random points":
https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html


> You can use private branches to the same effect
I'm not sure. The thing that immediately comes to mind is that fossil's
private branches will show up as a single commit in the public branch.

> I strongly prefer to not use it(rebase) as it results in commits with
questionable content
I agree and thus I use rebase to remove only those commits that had binary
files, sample test codes and misc. stuff.


On Thu, Dec 17, 2015 at 7:12 AM, Ron W  wrote:

> On Wed, Dec 16, 2015 at 4:27 AM, Gaurav M. Bhandarkar <
> gaurav.a...@gmail.com> wrote:
>>
>> fast forward merges is just one of the advantages of rebase. It is done
>> to avoid the extra “merge-commit” and thus reduces the noise in repo
>> history.
>>
>
> Don't need rebase to use fast-forward merge. As I said, I usually only
> submit the final revision - after merging in the lastest tip from the trunk
> of the (open source) projects I'm contributing to. (For work, we keep all
> revisions in our department repos.)
>
>
>> Then I run “git rebase -i master” which gives me an option to “squash”
>> commits that happened after “where-master-is-currently-at”. I can now
>> remove those commits that had binary files, code samples etc. from my local
>> branch’s history while keeping the actual code-changes and their commit
>> messages. In the end I get a clean revision history ready to be merged in
>> the master.
>>
>>
>> I really miss this feature when I use fossil.
>>
>
> You can use private branches to the same effect, optionally scrubbing the
> private branches when done. But even if you don't scrub the private
> branches, they won't get sync'd to the upstream repo (unless you use the
>  --private option on the pull command (possibly also push and sync as
> well)).
>
> While I have used rebase a few times when I was asked to preserve the
> change history, I strongly prefer to not use it as it results in commits
> with questionable content. Granted those intermediate commits are rarely
> used to build run-able or releasable code, but I dislike "publishing" them.
>
>
> ___
> 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] Fossil mentioned on HN

[Scott Robison]

On Wed, Dec 16, 2015 at 10:34 PM, Gaurav M. Bhandarkar <
gaurav.a...@gmail.com> wrote:

> > Don't need rebase to use fast-forward merge.
>
> Normal merge or rebase both "enables" fast-forward merges. But the
> advantage "rebase-before-ff-merge" has is that it avoids other(s) extra
> "merge commits" that you would have done to get your branch updated with
> changes from remote.
>
> See the section "Don't merge upstream code at random points":
> https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
>
>
> > You can use private branches to the same effect
> I'm not sure. The thing that immediately comes to mind is that fossil's
> private branches will show up as a single commit in the public branch.
>

It depends on how you go about it:

Create a private branch off trunk. Edit, commit, do whatever you want with
it.

When you're finished and ready to rebase, create a public branch off trunk
and cherry pick merge the private commits you want in the public history.
You have as much opportunity as you want to clean and massage them.

Now you can merge that branch to trunk.

I'm not trying to suggest it is in any way nearly as "elegant" as "rebase
-i" (those who prefer that would find this clunky at best). Still, it seems
possible.

-- 
Scott Robison
___
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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

[Steve Stefanovich]

This ‎reads better then previous version and more detail is given, thanks.
‎
The ve‎ry last bit (4.2 - Fossil inability to push/pull single branch) sounds 
somewhat weak, though. 
‎
Perhaps it could be strengthened by mentioning bundle command as a way to 
export a branch, but I also think bundle command should be extended to make it 
truly useful for scenarios like these. 

What needs to be additionally done is:

1. Ensure --standalone option extracts the full artifact, not just the last 
delta which will make a bundle, well, a standalone repo  - unless I'm wrong 
what standalone is supposed to mean. 

2. (Optional) Extend the bundle export command ‎so 
‎a new repo can be created with export contents automatically imported into it. 
For example, this way people can export a single check-in as the root before 
adding further bundles to it.  This is useful because cross-merges between 
repos could be done this way with --force option.
‎
Richard, what do you think? 

Cheers,
Steve‎

---
‎
  Original Message  
From: Richard Hipp
Sent: Thursday, 17 December 2015 03:16
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: [fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned 
on HN

Based on comments on HN and on this mailing list, I have attempted to
rewrite the fossil-v-git.wiki document
(https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
better summarize the differences between the two products.

Your feedback on the rewrite, and especially suggestions for improving
it, are welcomed.

-- 
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] Fossil mentioned on HN

[Gaurav M. Bhandarkar]

>The forced "merge commit" is (IMO) a design flaw in git
Ya. But people can enforce a merge process where the contributor has to
rebase(not rebase -i) and test before the ff-merge to avoid the flaw. Ron W
has explained that in detail.

> If "cleanliness is godliness" then git might have fossil beat in that
regard.
My e.g. doesn't stress cleanliness. I don't seem to mind a noisy commit
history.

"git rebase -i" seems to enable me to work on multiple projects at the same
time. Because of it I can maintain versioned "development sessions" of not
only my code but other things that were required/relevant to make that
code. Without it I find it impossible to handle the "context switch" that
comes when you work on multiple projects.

-Gaurav

On Wed, Dec 16, 2015 at 3:06 PM, Stephan Beal  wrote:

>
>
> On Wed, Dec 16, 2015 at 10:27 AM, Gaurav M. Bhandarkar <
> gaurav.a...@gmail.com> wrote:
>
>> > The end result is theoretically the equivalent of having started your
>> branch at the latest trunk tip instead of where ever you really started it
>>
>>
>> fast forward merges is just one of the advantages of rebase. It is done
>> to avoid the extra “merge-commit” and thus reduces the noise in repo
>> history.
>>
>
> The forced "merge commit" is (IMO) a design flaw in git, as such a forced
> commit _could not possibly_ have been tested by a person before the
> committing.
>
> Then I run “git rebase -i master” which gives me an option to “squash”
>> commits that happened after “where-master-is-currently-at”. I can now
>> remove those commits that had binary files, code samples etc. from my local
>> branch’s history while keeping the actual code-changes and their commit
>> messages. In the end I get a clean revision history ready to be merged in
>> the master.
>>
>>
>> I really miss this feature when I use fossil.
>>
>
> If "cleanliness is godliness" then git might have fossil beat in that
> regard. One of the reasons i always liked StarWars better than Star Trek is
> because in Star Trek everything is so antiseptically _clean_, whereas in
> Star Wars ships have dirt ("carbon scoring") and scratches on them, and the
> lights don't all work (some flicker).
>
> While we're cleaning up, we can go ahead and do:
>
> git branch -D master
> git push origin:master
>
> :-D
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> "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] Command line access to technotes and attachments

[Ron W]

On Wed, Dec 16, 2015 at 4:38 AM, David Vines 
wrote:

Run various subcommands to work with wiki entries or tech notes.
>
>Options:
>  -M|-mimetype TEXT-FORMAT   The mime type of the update
> defaulting to the type used by the
> previous version of the page or (for
> new pages) text/x-fossil-wiki.
>  -t|-technote DATETIME  Specifies the timestamp of the
> technote to be created or updated.
>  -technote-tags TAGSThe set of tags for a technote.
>  -technote-bgcolor COLORThe color used for the tehnote on
> the timeline.
>

Minor issue: While Fossil is inconsistent with this, the common convention
for "long options" is
--option

with 2 dashes. I haven't used the "-mimetype" option so I don't know if
it's a documentation error
or implementation oversight. In other Fossil commands the double dash,
"--", is accepted.

If there are no objections, I would suggest supporting both "--" and "-"
for the long options. (and
updating the documentation)

Otherwise, looks very good. Thanks.
___
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] Command line access to technotes and attachments

[Stephan Beal]

Fossil internally treats single and double dashes the same (unless i'm
sorely misremembering).

- stephan beal, sgb...@googlemail.com
Written on a keyboard attached to a telephone attached to a TV screen, via
an app written for use on touchscreens. Please excuse brevity, typos, and
whatnot.
On Dec 16, 2015 4:51 PM, "Ron W"  wrote:

> On Wed, Dec 16, 2015 at 4:38 AM, David Vines 
> wrote:
>
> Run various subcommands to work with wiki entries or tech notes.
>>
>>Options:
>>  -M|-mimetype TEXT-FORMAT   The mime type of the update
>> defaulting to the type used by the
>> previous version of the page or (for
>> new pages) text/x-fossil-wiki.
>>  -t|-technote DATETIME  Specifies the timestamp of the
>> technote to be created or updated.
>>  -technote-tags TAGSThe set of tags for a technote.
>>  -technote-bgcolor COLORThe color used for the tehnote on
>> the timeline.
>>
>
> Minor issue: While Fossil is inconsistent with this, the common convention
> for "long options" is
> --option
>
> with 2 dashes. I haven't used the "-mimetype" option so I don't know if
> it's a documentation error
> or implementation oversight. In other Fossil commands the double dash,
> "--", is accepted.
>
> If there are no objections, I would suggest supporting both "--" and "-"
> for the long options. (and
> updating the documentation)
>
> Otherwise, looks very good. Thanks.
>
>
> ___
> 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] Command line access to technotes and attachments

[David Vines]

On 16/12/2015 15:50, Ron W wrote:


Minor issue: While Fossil is inconsistent with this, the common
convention for "long options" is
 --option

with 2 dashes. I haven't used the "-mimetype" option so I don't know if
it's a documentation error
or implementation oversight. In other Fossil commands the double dash,
"--", is accepted.



The preexisting implementation in find_option allows both single and 
double dashes for both the long and short forms of the options.


I'll make sure my documentation matches the desired double form of the 
option.  In the rest of the documentation there a few inconsistencies, 
but only a few (the ones I've spotted are in the rss, search and version 
commands).


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

[fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

[Richard Hipp]

Based on comments on HN and on this mailing list, I have attempted to
rewrite the fossil-v-git.wiki document
(https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
better summarize the differences between the two products.

Your feedback on the rewrite, and especially suggestions for improving
it, are welcomed.

-- 
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

Re: [fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

[Stephan Beal]

Section 4.1: in fossil, but not git: fault-tolerant storage.

- stephan beal, sgb...@googlemail.com
Written on a keyboard attached to a telephone attached to a TV screen, via
an app written for use on touchscreens. Please excuse brevity, typos, and
whatnot.
On Dec 16, 2015 5:16 PM, "Richard Hipp"  wrote:

> Based on comments on HN and on this mailing list, I have attempted to
> rewrite the fossil-v-git.wiki document
> (https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
> better summarize the differences between the two products.
>
> Your feedback on the rewrite, and especially suggestions for improving
> it, are welcomed.
>
> --
> 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] Fossil mentioned on HN

[Gaurav M. Bhandarkar]

> The end result is theoretically the equivalent of having started your
branch at the latest trunk tip instead of where ever you really started it


fast forward merges is just one of the advantages of rebase. It is done to
avoid the extra “merge-commit” and thus reduces the noise in repo history.



> If you have changes on a branch you actually care about the change history


But sometimes you don’t really care about some of the change history on
your branch. Let me explain.


What I think is the real power of rebase is the “git rebase -i". This
command helps me use git as a “development session manager”.


E.g. Suppose I’m tasked with writing a small webserver. I update my local
master branch with changes from remote master branch and I create a new
local branch “initial-webserver”.


Now I google samples for webserver like those using the "select" api, those
using epoll etc. etc. I also find some command line tools (binary files)
that can stress the webserver. I just commit them to my local branch
“initial-webserver”.


I then start writing my code, and keep on committing frequently in my local
branch. If my task takes 1 week, my “development session” is saved in the
branch.


When I say “development session” I mean relevant code samples, relevant
articles found on web, temp makefile changes to automatically copy files to
test machine after build, misc. binary files and even huge entire virtual
machine’s snapshot images.


After my job is complete I just delete those binary files, sample codes
etc. and make another commit to local branch “initial-webserver”. Those
files are now deleted from the tip of my local branch but not from the
earlier revisions.


Then I run “git rebase -i master” which gives me an option to “squash”
commits that happened after “where-master-is-currently-at”. I can now
remove those commits that had binary files, code samples etc. from my local
branch’s history while keeping the actual code-changes and their commit
messages. In the end I get a clean revision history ready to be merged in
the master.


I really miss this feature when I use fossil.



On Tue, Dec 15, 2015 at 10:33 PM, Ron W  wrote:

> On Tue, Dec 15, 2015 at 11:04 AM, Warren Young  wrote:
>
>> Could someone who understands “git rebase” weigh in on that thread?
>> People are claiming that “fossil shun” means there is no difference between
>> Git and Fossil.
>>
>> Either my understanding of fossil shun is just as weak as my
>> understanding of git rebase, or this is a false equivalency,
>>
>
> Fossil shun only excludes selected artifacts while git rebase actualy
> rewrites history. Shun requires you find the IDs of the artifacts you
> want/need to exclude. Rebase does the dirty work for you.
>
> In the simple cases I've had to deal with git, the core maintainers of the
> projects involved required that submissions be "fast-forward merge" ready.
> That is, the affected files are up to date with respect to the trunk (aka
> "master") tip.
>
> Since the project maintainers were completely uninterested in my local
> revision history, for me, this amounted to updating my local git, merging
> trunk tip to my branch, build/test/fix/, then finally, merging my
> branch tip to trunk, pushing to my github fork and sending a pull request
> to the maintainers. If their "fast-forward merge" failed, I would have to
> repeat the above process and resubmit my pull request.
>
> If you have changes on a branch you actually care about the change
> history, git rebase can be used to, effectively, transplant your branch
> from whichever truck commit it started from to the trunk tip. This is sort
> of like merging the trunk tip into your branch;s first commit, then into
> each subsequent branch commit. The end result is theoretically the
> equivalent of having started your branch at the latest trunk tip instead of
> where ever you really started it.
>
>
> ___
> 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] Fossil mentioned on HN

[Stephan Beal]

On Wed, Dec 16, 2015 at 10:27 AM, Gaurav M. Bhandarkar <
gaurav.a...@gmail.com> wrote:

> > The end result is theoretically the equivalent of having started your
> branch at the latest trunk tip instead of where ever you really started it
>
>
> fast forward merges is just one of the advantages of rebase. It is done to
> avoid the extra “merge-commit” and thus reduces the noise in repo history.
>

The forced "merge commit" is (IMO) a design flaw in git, as such a forced
commit _could not possibly_ have been tested by a person before the
committing.

Then I run “git rebase -i master” which gives me an option to “squash”
> commits that happened after “where-master-is-currently-at”. I can now
> remove those commits that had binary files, code samples etc. from my local
> branch’s history while keeping the actual code-changes and their commit
> messages. In the end I get a clean revision history ready to be merged in
> the master.
>
>
> I really miss this feature when I use fossil.
>

If "cleanliness is godliness" then git might have fossil beat in that
regard. One of the reasons i always liked StarWars better than Star Trek is
because in Star Trek everything is so antiseptically _clean_, whereas in
Star Wars ships have dirt ("carbon scoring") and scratches on them, and the
lights don't all work (some flicker).

While we're cleaning up, we can go ahead and do:

git branch -D master
git push origin:master

:-D

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"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] Command line access to technotes and attachments

[David Vines]

On 15/12/2015 09:55, Stephan Beal wrote:


Here's an encouraging anecdote for you: my first C work after 1995[1]
was implementing the wiki CLI commands Richard mentioned :). i concur
that the wiki commands would be the best starting point for adding Tech
Note (formerly "event") CLI support.




It has indeed proved quite straightforward! Since I have done enough for 
a prototype, I'd like to get feedback on my proposed CLI change for
technotes before I discard the prototype and redo it into something I'd 
be prepared send in as a patch:


Usage: ../fossil wiki (export|create|commit|list) WikiName

Run various subcommands to work with wiki entries or tech notes.

../fossil wiki export ?PAGENAME? ?FILE? [-t|-technote DATETIME ]

   Sends the latest version of either the PAGENAME wiki
   entry or the DATETIME tech note to the given file or
   standard output. One of PAGENAME or DATETIME must be specified.

../fossil wiki (create|commit) PAGENAME ?FILE? ?OPTIONS?

   Create a new or commit changes to an existing wiki page or
   technote from FILE or from standard input.

   Options:
 -M|-mimetype TEXT-FORMAT   The mime type of the update
defaulting to the type used by the
previous version of the page or (for
new pages) text/x-fossil-wiki.
 -t|-technote DATETIME  Specifies the timestamp of the
technote to be created or updated.
 -technote-tags TAGSThe set of tags for a technote.
 -technote-bgcolor COLORThe color used for the tehnote on
the timeline.

../fossil wiki list ?-technote?
../fossil wiki ls ?-technote?

   Lists all wiki entries, one per line, ordered
   case-insensitively by name. The -technote flag
   specifies that technotes will be listed instead of
   the wiki entries, which will be listed in order
   timestamp.

David
___
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] Command line access to technotes and attachments

[Stephan Beal]

On Wed, Dec 16, 2015 at 10:38 AM, David Vines 
wrote:

> It has indeed proved quite straightforward!


:-D


> Usage: ../fossil wiki (export|create|commit|list) WikiName
>
> Run various subcommands to work with wiki entries or tech notes.
>


i hadn't considered the option of combining the two (i was thinking
'technote' as a separate command, mostly copied from the wiki command), but
if it works, then why not?


 -technote-bgcolor COLORThe color used for the tehnote on
> the timeline.
>

minor typo: "...for the tehnote..."


> ../fossil wiki list ?-technote?
> ../fossil wiki ls ?-technote?
>
>Lists all wiki entries, one per line, ordered
>case-insensitively by name. The -technote flag
>specifies that technotes will be listed instead of
>the wiki entries, which will be listed in order
>timestamp.


looks good to me.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"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