On Thu, Dec 17, 2015 at 3:33 PM, Warren Young wrote:
> 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
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:
http://fossil-scm.org/index.html/doc/tip/www/private.wiki
It
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 f
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 changes on top
> > of the new
On Thu, 17 Dec 2015 18:57:06 +0300
Konstantin Khomoutov wrote:
[...]
> Another point is that when you rebase (or "linearize"), the new
> upstream tip might actually contain changes which will make some or
> all of the commits in the series being rebased/linearized be apply
> with some fuzz, and i
On Thu, 17 Dec 2015 13:16:43 +0100
Joerg Sonnenberger 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
On Thu, Dec 17, 2015 at 02:43:56PM +0300, Konstantin Khomoutov wrote:
> 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 ab
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 (that is, it can be used for
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 <
>
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"
>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 poten
> 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 "
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
>>
to...@acm.org wrote:
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
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
On Wed, Dec 16, 2015 at 6:53 PM, Scott Robison
wrote:
> On Wed, Dec 16, 2015 at 4:12 PM, wrote:
> > 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:
>
>
Wait, that's not exactly what I mean. Each of my private branches were
originally created with this command line:
fossil commit -m "" --branch sue --private
Note that I do give it a name and mark it as private. So perhaps --private
only is the difference you're seeing.
On Wed, Dec 16, 2015 at 5:
That is exactly what I mean. I'll see what I can do later to provide a
transcript.
On Wed, Dec 16, 2015 at 5:18 PM, Warren Young wrote:
> On Dec 16, 2015, at 4:58 PM, Scott Robison
> wrote:
> >
> > On Wed, Dec 16, 2015 at 4:53 PM, Warren Young wrote:
> >
> > > the private branch is always call
On Dec 16, 2015, at 4:58 PM, Scott Robison wrote:
>
> On Wed, Dec 16, 2015 at 4:53 PM, Warren Young wrote:
>
> > the private branch is always called “private”
>
> I have a test repo at present with three private branches named test, bob,
> and sue.
By “private branch” do you mean “f ci --pri
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
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 commi
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 corre
, 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 mu
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" o
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
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/relev
>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
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 r
> 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.
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 find
That's right.
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 10.
But I suppose it is bu
On 15 December 2015 at 08:04, Warren Young wrote:
> Either my understanding of fossil shun is just as weak as my understanding of
> git rebase, or this is a false equivalency, and we can’t have [people getting
> away with being wrong on the Internet][1]. :)
I say let them think what they want.
Thus said Warren Young on Tue, 15 Dec 2015 09:04:40 -0700:
> Could someone who understand ``git rebase'' weigh in on that thread?
> People are claiming that ``fossil shun'' means there is no difference
> between Git and Fossil.
Add to that the claim that ``autosync'' is equivalent to rew
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 rebase” weigh in on that thread?
> People
> > are claim
On Dec 15, 2015, at 10:33 AM, Stephan Beal wrote:
>
> git: "History is written by the victors."
>
> fossil: "History is recorded as it happens.”
I’m not the one who needs convincing. These replies need to be comments on the
Hacker News post, not replies to my request for clarification.
Those
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 15,
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 understandin
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo
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 rebase” weigh in on that thread? People
> are claiming that “fossil shun” means there is no difference between Git and
>
On Tue, 15 Dec 2015 09:04:40 -0700
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 rebase” weigh in on that thread?
> People are claiming that “fossil shun” means there is no dif
On Dec 15, 2015, at 5:54 AM, Richard Hipp wrote:
>
> https://news.ycombinator.com/item?id=10737131
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
41 matches
Mail list logo
