On Mon, Nov 2, 2015 at 7:00 AM, Konstantin Khomoutov < [email protected]> wrote:
> On Sat, 31 Oct 2015 09:53:52 +0100 > Stephan Beal <[email protected]> wrote: > > > > Unless you delete .git your checkout is always in well defined > > > state. > > No, it's not. i once literally had one of the libgit maintainers at > > my desk for a full hour trying to get my repo (of a project we were > > both working on for our employers) back in a pushable state after it > > got jumbled up by me copy/pasting commands suggested by StackOverflow > > (about the worst place to get git advice). If one of the developers > > takes that long to straighten it out, then something is (IMO) > > fundamentally wrong. > > That's still barking at the wrong tree. > > You're unlikely to screw up a Fossil repo *that* much by > mindlessly copying-and-pasting something from SO but that's because > Fossil simply does not expose commands which allow you do perform > intricate surgeries on your repo. To perform such fine operations, you > have to be trained at them or just abstrain from doing them. Or at > least try them in a sandbox first. It's like you being able to > actually disassemble your car and them have a skilled technician > assemble it back again because you have no idea how to do that. > > Sure, not everyone wants to be able to perform low-level operation on > their repos, and not everyone wants to have the necessary skills. > That's absolutely OK, but claiming that that not having tools to do that > is somehow superior to another approach appears to be perfectly the same > as fanboyism of those praising the products originating from a > well-known company headquartered at Cupertino. :-) > I don't think such a claim is strictly a case of fanboyism. I propose that the intended fossil model and design does not require such low level tools, whereas git is a more fragile system and thus its low level tools were born of necessity. Getting back to the comic itself: At my job we have a particular repo that includes a bunch of tools / scripts / whatever used in the CM process. It is only written / updated by the CM team, and I only have to clone it / pull it to use it. I never edit it in any way. So imagine my surprise a couple weeks ago when I tried to pull some updates and was warned that I was some number of edits ahead of the remote head (ie, I had uncommitted changes). In reviewing my supposed "changes" (which I did not make) I could only come to the conclusion that someone (contrary to policy) had made some sort of remote repo modification (rewrote history) that left me in a bad state. I wound up deleting and re-cloning just as the comic suggests. I don't think that state would be attainable in fossil without some sort of extreme case. Certainly the normal set of commands provided and used in fossil repo maintenance / usage would not make that possible. Or maybe it would. I'd love to hear some example of how that might happen in fossil. It's one thing to be actively using a repository and using the full set of repo management commands (open, update, commit, branch, etc) and getting into some state where merging is difficult. It is another to have made no changes to a clone of a repo and to be told you have uncommitted changes. -- Scott Robison
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
