Re: [fossil-users] Fossil mentioned on HN
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: > > http://fossil-scm.org/index.html/doc/tip/www/private.wiki I didn't notice that part at the top. I read the plural of "branch" multiple times in the bottom half the document which lead me to think I had to name a branch. :) -- 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
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
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
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
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 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. Here I means that if we do `git diff A U` and compare the result to `git diff A' U'` they may be substantially different. IOW, there might be a difference between those differences even though they both logically introduce the same change to the content. ___ 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
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 (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. > > The important point here is rewrite vs recreate. That's quite a > different, both practically and semantically. It would be useful to > have a "linearise" command, however you want to call it, which > performs *one* part of what rebase does: I'm writing a bunch of > changes in disconnected mode and want to push them back. Someone else > has committed a change in the mean time and I don't want to merge. > "No merge on the main branch" is a pretty useful property for things > like bisect and the like. > > 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. 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. 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. I hence insist on that you can't rebase and not re-write commits at the same time. Even your specific "linearization" case still requires commit re-writing. ___ 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
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 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. The important point here is rewrite vs recreate. That's quite a different, both practically and semantically. It would be useful to have a "linearise" command, however you want to call it, which performs *one* part of what rebase does: I'm writing a bunch of changes in disconnected mode and want to push them back. Someone else has committed a change in the mean time and I don't want to merge. "No merge on the main branch" is a pretty useful property for things like bisect and the like. 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. 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
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
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
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
>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
> 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
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
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 command (or option to existing command) to purge a private branch at the local level? Well, "fossil purge checkins " should do this? Reimer Behrends ___ 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
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
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: > > > 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.) ___ 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
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:23 PM, Scott Robison wrote: > 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 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 --private,” or something else, like >> running with autosync disabled, so that all new branches are created only >> in your private clone of the repo? >> >> Would you mind posting a session transcript that someone could paste into >> a terminal to recreate your test repo? >> ___ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> > > > > -- > Scott Robison > > -- 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
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 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 --private,” or something else, like > running with autosync disabled, so that all new branches are created only > in your private clone of the repo? > > Would you mind posting a session transcript that someone could paste into > a terminal to recreate your test repo? > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- 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
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 --private,” or something else, like running with autosync disabled, so that all new branches are created only in your private clone of the repo? Would you mind posting a session transcript that someone could paste into a terminal to recreate your test 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
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
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
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
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
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
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
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
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 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
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
> 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
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
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 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
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. This is how mistakes are corrected in git: http://xkcd.com/1597/ That was from a thread a few months ago here that carried over 70+ emails, which I'm sure you remember. -- --- 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
Re: [fossil-users] Fossil mentioned on HN
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 rewriting history. Andy -- TAI64 timestamp: 400056705852 ___ 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
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
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 reading the HN post won’t be reading this mailing list thread. And posting a link to it work work, because people are lazy. They want to see the whole argument laid out on the same web page. ___ 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
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
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
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
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." -- 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
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 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]. :) People who think there's no difference between Git and Fossil supposedly do not need correcting their beleifs: they either lack knowledge or are just trolling. Or, even more probably, I reckon, they lack deep knowledge of both systems and are too lazy to gain one while are okay with posting random stuff into the intertent. So... why bother? ___ 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
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]. :) [1]: https://xkcd.com/386/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users