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
>>
On Wed, Dec 16, 2015 at 7:15 PM, Warren Young wrote:
>
> At least with Git fast-export, it’s becoming something of a lingua
> franca. What is the lingua franca of issue tracking?
Actually, I think it's "spread sheets". In the company I work for, it's
customers and it's suppliers, when we meet w
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:
>
>
This reads better then previous version and more detail is given, thanks.
The very 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 c
On Wed, Dec 16, 2015 at 7:15 PM, Warren Young wrote:
> On Dec 16, 2015, at 10:52 AM, Eric Rubin-Smith wrote:
> >
> > Providing an outbound export interface to at least one such tool
>
> Which one? I count over 40 in the Wikipedia list:
>
> https://en.wikipedia.org/wiki/Comparison_of_issue-tra
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
> Many check-outs per repository
It should be noted that git has acquired this feature (as of v2.5.0)
https://git-scm.com/docs/git-worktree
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/
On Dec 16, 2015, at 10:52 AM, Eric Rubin-Smith wrote:
>
> Providing an outbound export interface to at least one such tool
Which one? I count over 40 in the Wikipedia list:
https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
At least with Git fast-export, it’s becoming someth
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
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
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: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 produc
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 tel
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 attache
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 Hip
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 fo
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 comman
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
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
>
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: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 w
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.
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.
36 matches
Mail list logo