Re: [fossil-users] Fossil mentioned on HN

[Joerg Sonnenberger]

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 commit and record which commit they were originally. This
> > allows three things:
> > (1) Tight main line with keeping incremental stages.
> > (2) Preservation of what commits originally happened in case you need
> > the full audit trail because there was a subtil merge fault or the
> > like.
> > (3) It allows automated follow-up rebases for 3rd parties that already
> > got the initial changes. I.e. you can safe push your work-in-progress
> > and still transplant it later.
> > 
> > "git rebase" only really allows the first point.
> 
> Not quite.  Well, `git rebase` does indeed replace the tip of the
> branch it operated on with a set of changed commits, but this counts as
> a so-called "drastic head movement" in the Git parlance.  Such
> movements are recorded in the so-called "reflog" ("reference log" --
> with refs or references being heads (branches) and tags), so as soon as
> a rebase operation completes successfully (as opposed to having been
> aborted using `git rebase --abort` where the branch being operated on
> is left intact), you can retreive the previous tip of the affected
> branch from the reflog.  The reflog keeps about 30 days worth of such
> changes by default which is more than enough to cover the "oops!"
> situations.

The very need for reflog and the 30days recovery frame is one of the
saddest part of the git design. It is an arbitrary implementation detail
and not really related to the way "git rebase" works.

> As to "without rewriting history" bit, this might be a terminological
> issue but in a (typical) DVCS you simply cannot cherry-pick or
> otherwise (re-)apply an existing commit to some tip to produce another
> commit without essentially rewriting it because the commit hash includes
> the commit creation date.  And once you've changed a commit's hash, the
> next commit being applied on top of this one will have its hash changed
> also because it will refer to the changed hash-name of its parent
> commit, and this "link" is hashed as well.

The part you are still missing is that the original commit never
got lost. That's why am I talking explicitly about *recreating* and not
*rewriting*. It's like kind of like editing the commit message -- that
doesn't change the original commit either, but creates an update entry
in fossil that just says "well, take that commit, but show *this* commit
message".

> 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 in complicated cases they might even fail to apply.  In this
> case, even "the contents" (as opposed to metadata) of the
> rebased/linearized commits will be re-written quite literally.  In the
> sense that if you had a commit A on top of upstream's U, and then
> rebased A on top of the updated U' to produce A', the differences A':U'
> and A:U might be substantial.

Yes, some commits might have been getting obsoleted. That's why it can't
be a fully automated process. So you start transplanting the other
commits and either include a dummy entry for nothing at all. Unless the
3rd party was explicitly basing the changes on that now irrelevant
commit, the transplating of their changes can still continue.

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

[Andy Bradford]

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

Among the  reasons that brought me  to Fossil, over Git,  was that there
are fewer surprises in how it behaves  and that it was so much easier to
use. I've  never had to  worry about  ``rebase'' with Fossil.  Indeed, I
find that I use Git more like I use Fossil.

Do I need  the ``power'' that Git supposedly has?  I've always felt more
in control with Fossil.

Andy
-- 
TAI64 timestamp: 40005672ef59


___
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 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 talks about automatic naming of the branch to “private,” so I assumed that 
was the only way it could work.

Perhaps someone with checkin rights could add an example of an explicitly-named 
private branch.

If you let Fossil name the branch for you, it behaves as I said: after creating 
the second private branch, you get complaints like "WARNING: multiple open leaf 
check-ins on private:” from “f stat”.

I wonder if automatic naming is a good thing.  Maybe --branch should be 
required by --private?
___
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

[Konstantin Khomoutov]

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 tasks different from its
original intent -- rebasing -- such as squashing several commits
together, editing a commit, splitting commits, deleting commit etc) but
no matter what mode `git rebase` is being used in, it rewrites
(recreates) commits.

If a VCS assumes the dogma of never touching a commit once it's created,
it can't have rebase-like functionality.

On the other hand, whatever is being said here about having rebasing
in Git is mostly religious bs: any sensible Git user knows that
you never rebase what you already pushed to a repo accessible by anyone
other than whoever did that push.  So if the talk is about not touching
the sacred history on a branch but rather creating another (private)
branch and recreating some of the original work there differently
(through using cherry pick etc) then yes, it's almost like rebasing,
just less convenient to use.

And there's another problem: say, if I support a pile of code I intend
to eventually submit upstream on a dedicated branch (a typical case for
"classic" rebasing) I do periodic synchronization with upstream by
pulling in their changes and replaying my changes on top of theirs.
Each time after this act I have a changed branch, and I want to push it
somewhere (to another maching I work at, for instance), and to support
that, the VCS has to 1) allow me to do that; 2) support "forced
pushing" where I explicitly tell it I want to overwrite a remote branch
with the branch I'm pushing.  IIUC, Fossil's private branches as of now
don't quite cut it because they don't support the points above.
Hence to me, private branches look more like what's known in some VCS
systems as "shelving": a possibiliy to keep some bits uncommitted/not
sent to a rendez-vous repo.
___
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

[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] 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 <sgb...@googlemail.com> 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
___
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] 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] 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] Fossil mentioned on HN

[Ron W]

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

Re: [fossil-users] Fossil mentioned on HN

[Ron Aaron]

  
  
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/fossil-users

Re: [fossil-users] Fossil mentioned on HN

[Scott Robison]

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 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, and we can’t have [people
> > getting away with being wrong on the Internet][1]. :)
> >
>
> Shun does *not* provide the equivalent of rebase.  Claims that it does
> are misinformed.
>
> I think people are making a bigger deal out of this than it deserves.
> The main different between Fossil and Git with regard to rebasing is
> summarized well in the docs:
>
>   "Git remembers what you should have done whereas Fossil remembers
> what you actuallydid."


Having been forced to use git more and more often of late at work (I held
onto the legacy svn repo as long as possible) I think we get a little
caught up in rebase when we really don't need to. Yes, rebase can be (and
is) abused. I think a rebase-like command could be implemented in fossil
(based on previous of many discussions) that preserved the history (moved
to a different branch, marked appropriately) yet gave the benefits people
are looking for, and that would not necessarily be a "bad thing".

If we want to talk about how git is inferior because it supports first
class deletion of history, we need look no further than branch deletion. "
http://stackoverflow.com/questions/14005854/what-to-do-with-branch-after-merge
"

git supports, and appears to encourage, a workflow where you create a
branch, do the work, merge to master/trunk/whatever, then delete the
branch. So:

1. Create a branch.
2. Commit to the branch regularly.
3. Get ready to merge by rebasing your branch.
4a. Merge your branch to trunk and only push trunk.
4b. Push your branch and merge it.
5. Delete branch.

This workflow makes me long for the days where all I had to worry about was
a usually simple rebase operation.

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

[Stephan Beal]

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, 2015 6:03 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

[Richard Hipp]

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 buried pretty deeply in the documentation, where
it is hard to find

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

[jungle Boogie]

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. I remember seeing the commit now.

When you make your cartoon on the usability of Fossil, be sure proudly
display it on the homepage!

-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users