On Sat, Dec 29, 2012 at 8:20 AM, Lluís Batlle i Rossell <[email protected]>wrote:
> (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'm one of those "losers" who uses fossil as a sort of backup work area sync tool in addition to a pure SCM. Now I don't personally feel the label loser applies to me but I'm using it here because repeatedly now on this list, intentional or accidentally, folks are using words that leave the impression that people who use fossil this way are, well, losers. Judging others in this way is not constructive IHMO. Perhaps instead try to understand why people are compelled to do this "wrong" behavior and perhaps enhance the tool(s) to make it unnecessary. Rebase exists because it meets a real need. The question is, can that need be met in a more elegant way with fossil? I work on several projects that are spread out over different machines and are not always accessible to me from all locations where I work. I often (yes, often) have work in progress that is far from polished yet if I don't check it in I have no easy way to continue working later from a different location. The pragmatic solution for me is to check in the current state of the code regardless of whether it is polished or not. I even (horrors) occasionally check in stuff that won't compile. I could use private branches to keep this clean but that adds another thing to remember and manage to my already overfilled plate and I've found it very easy to accidentally lose work with private branches. What I would like is a way to mark branches as hidden. A hidden branch does not show up on the timeline. In the UI there would be a "show hidden branches" button but by default they would not show. I could do my messy work on a branch that I will later hide and when happy with the result merge to a branch that I would keep visible. This keeps history intact but makes a nice uncluttered clean view available that captures only the important aspects of development and hides the noise. Just my $0.02. Cheers and seasons greetings to all fossilers :) > > 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 <[email protected]> > 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 > > [email protected] > > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
