Re: [fossil-users] Fossil mentioned on HN

On Thu, Dec 17, 2015 at 06:57:06PM +0300, Konstantin Khomoutov wrote: > On Thu, 17 Dec 2015 13:16:43 +0100 > Joerg Sonnenberger wrote: > > > Now the tricky part is this can be done *without rewriting history*. > > Essentially, you can (semi-automatically) reapply all

Re: [fossil-users] Fossil mentioned on HN

Thus said "Gaurav M. Bhandarkar" on Thu, 17 Dec 2015 11:04:06 +0530: > 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

Re: [fossil-users] Fossil mentioned on HN

On Dec 16, 2015, at 5:25 PM, Scott Robison wrote: > > fossil commit -m "" --branch sue --private It never occurred to me that you could combine --branch and --private, probably because the possibility isn’t mentioned on this page:

Re: [fossil-users] Fossil mentioned on HN

On Wed, 16 Dec 2015 14:28:39 -0700 Scott Robison wrote: [...] > I realize that 'get rebase -i' gives a lot more tools, but couldn't > 99% of rebase use cases be handled with private branches? `git rebase` is about rewriting history. It has several modes of operation

Re: [fossil-users] Fossil mentioned on HN

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

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

Re: [fossil-users] Fossil mentioned on HN

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

Re: [fossil-users] Fossil mentioned on HN

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

Re: [fossil-users] Fossil mentioned on HN

, 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 <sgb...@googlemail.com> wrote: On Wed, Dec 16, 2015 at 11:59 AM, Gaurav M. Bhandarkar <gaurav.a...@gmail.com> wrote: &q

Re: [fossil-users] Fossil mentioned on HN

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

Re: [fossil-users] Fossil mentioned on HN

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

Re: [fossil-users] Fossil mentioned on HN

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

Re: [fossil-users] Fossil mentioned on HN

>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

Re: [fossil-users] Fossil mentioned on HN

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

Re: [fossil-users] Fossil mentioned on HN

> 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

Re: [fossil-users] Fossil mentioned on HN

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

Re: [fossil-users] Fossil mentioned on HN

>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

Re: [fossil-users] Fossil mentioned on HN

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

Re: [fossil-users] Fossil mentioned on HN

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

Re: [fossil-users] Fossil mentioned on HN

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

Re: [fossil-users] Fossil mentioned on HN

I also mentioned it on our 'Code Thoughts' forum: https://codethoughts.org/index.php/topic,6.0.html ___ fossil-users mailing list fossil-users@lists.fossil-scm.org

Re: [fossil-users] Fossil mentioned on HN

On Tue, Dec 15, 2015 at 9:20 AM, Richard Hipp wrote: > On 12/15/15, Warren Young wrote: > > On Dec 15, 2015, at 5:54 AM, Richard Hipp wrote: > >> > >> https://news.ycombinator.com/item?id=10737131 > > > > Could someone who understands “git

Re: [fossil-users] Fossil mentioned on HN

git: "History is written by the victors." fossil: "History is recorded as it happens." - 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

Re: [fossil-users] Fossil mentioned on HN

On 12/15/15, jungle Boogie wrote: > > I say let them think what they want. This is how mistakes are > corrected in git: http://xkcd.com/1597/ I've had that cartoon on the Fossil website since it came out. http://www.fossil-scm.org/fossil/doc/trunk/www/quotes.wiki - item

Re: [fossil-users] Fossil mentioned on HN

On 15 December 2015 at 18:49, Richard Hipp wrote: > I've had that cartoon on the Fossil website since it came out. > http://www.fossil-scm.org/fossil/doc/trunk/www/quotes.wiki - item 10. > But I suppose it is buried pretty deeply in the documentation, where > it is hard to