(top post, due to the complexity of the previous post) I've found many git-fans that are completely ashamed of how they develop. And they would never make public how they commit things (how they use the VCS), so they don't accept other VCS that hasn't git rebasing capabilities.
I can't tell what was first: the shame, shameful vcs usage, or the access to rebase feature. I dislike how git handles rebase, because by default it does not invite to rewriting commit logs. If you read git manuals, you are told that each commit (and its log) refers to a unique *file tree* (represented by the hash), and not to a *diff*. But then, they wrote 'rebase', which keeps the commit logs, but changes all the file trees they were meant for. Then you have commit logs that say "I tested this, and this works". If you rebase that commit, that looses all that meaning. In fossil, a hash refers to a specific file tree, that never changes, and checkin comments refer to that hash. History rewriting also implies that what you could have in your brain memory on how you developed something could not match what you have left in the VCS - after mangling with rebase. I find this also another source of problems. Regards, Lluís. On Sat, Dec 29, 2012 at 02:53:23PM +0000, Eric wrote: > On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams <n...@cryptonector.com> > wrote: > <snip> > > Actually I agree with most of Mike Meyer's reply, but I wanted to pick > this paragraph apart: > > > How many times have you submitted a patch to an upstream > > Well, phrasing it like that says that you are thinking git-style anyway. > Let's assume a Fossil push with one commit nominated as "this is my > current contribution". > > > and then been told to make a bunch of changes, > > That's only to be expected, so you create a new commit based on your > previous nominated one, push it and tell them which is your new commit. > > > re-organize your commits, > > I don't see why they (the centre) should do that. It's the result that > matters, and if they want a pristine tree that includes only approved > commits they can do that. (See below.) > > > make specific changes to specific commits, > > Why, why, why? It's the result that matters, this is just rewriting > _your_ history because they feel like it. > > > and/or squash commits? > > Again, this is about them wanting a pristine tree. Their problem. > > > Yeah, that's why rebase is good. > > Rebase is a lie! > Rebase is a lie! > Rebase is a lie! > > > Now for the "pristine tree" thing. I don't agree with it but if that's > what the project leads want, they can > > 1) not permit pushes or syncs, only pulls, and take only real patches, > which they turn into commits themselves > > or > > 2) have two repositories, a working rep which everybody syncs with, and > a clean one. Then have a command/script like > > accept <commit-in-working-rep> <parent-in-clean-rep> > > which creates a new child commit in the clean rep and does a pull back > into the working rep, and which is simple in concept, though there > will be issues about moves and deletes. > > Working this way also raises issues about what to do with wiki pages, > tickets, and events. > > These approaches are not the outright lie that rebase tends to be, > but merely the leads saying "here is the history of the things we have > approved". They are then depriving everyone of the history of blind > alleys (which will therefore be followed again and again) and of the > ideas whose time had not yet come (which will therefore have to be > re-invented from scratch, or may even be forgotten altogether!). > > I think the correct way to deal with "unwanted" commits is to make proper > use of branches, and perhaps to have a UI option which shows only things > in a specified set of branches. > > > Incidentally, there is nothing stopping you, as a remote, barely-trusted > developer (which is what you are in that sort of scenario) from running > the two-repository process yourself, so that you sync only from your > "clean" repository. > > I also think that much of the "mess" in repositories that people seem to > want to hide is the result of committing far too frequently, usually in > the mistaken belief that their VCS is some sort of backup system. > > Eric > -- > ms fnd in a lbry > _______________________________________________ > 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
