Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fossil vs Git

fossil-scm.org

Post reply on HN
Print view View original

241–250 of 252 posts

Re: Fossil vs Git

#241

Post by cryptonector »

slavik81 wrote: post #227
mannykannot wrote: post #194

Earlier quoted context omitted.

Could you give an example of where it is necessary (in principle, not just because that's the way the tool works) to rewrite the detailed history in order to get the history you want? I realize that we generally have to work with the available tools, but it is also useful to think about how things would optimally work. When I wrote that frequent rebasing looks like a process smell, that could because the tool is not…

No. I worked for years with software that had no way of changing history. It was never required.

It was required at Sun, in Solaris engineering. Merge commits were absolutely verboten (which prohibition was enforced by tooling) -- therefore pushes had to be linear. Commit commentary had a very specific required format.

Clean, linear history has never been required anywhere else I've worked, but I've done it ever since Sun taught me to. Just because it's not required doesn't mean it's not a good idea, and it can't be forbidden ("what happens on my dev instances, stays in my dev instances", and the only thing seen in the end is what I choose to publish, and it's going to be clean and linear).

Large projects at Sun used a rebase-heavy / rebase-only workflow like so:

                +-----------------+
                | Upstream "gate" |
In large projects individuals tracked a project fork of the upstream, which forks were periodically rebased onto the latest "build" of the real upstream, and the individuals' forks of the project "gates" were rebased onto the latest project fork as needed. At the end, when all the i's were dotted and t's crossed, the tech lead would push the project gate's linear history additions to the upstream.

We did this with early 90s tech known as Teamware, with lots of scripting on top. We later did it with Mercurial (again, with lots of scripting on top). Mercurial was a mistake. Git is much, much easier to use this way than any other VCS I've ever worked with, which for me includes: CVS, Clearcase, PRCS, Subversion, Mercurial, Git.

Re: Fossil vs Git

#242

Post by sigzero »

war1025 wrote: post #70
sys_64738 wrote: post #26

Earlier quoted context omitted.

Linus definitely helped and he pretty much killed cvs (not the drug chain).

You mean git killed SVN right? SVN killed CVS in my understanding.

SVN is probably the most prolific in the "Enterprise" arena.

Re: Fossil vs Git

#243

Post by shawkinaw »

SQLite wrote: post #214
shawkinaw wrote: post #162

Earlier quoted context omitted.

I have to say, I’ve used Git for many years now and I’ve never, ever, ever wished for this, nor even knew it wasn’t possible. So this seems like a silly thing to claim as an advantage for Fossil.

I never thought I needed bisect, until I had it. Now I can't live without it.

Yeah totally fair point. I figured there’s probably some usecase I haven’t run into for this feature. Still, I think it says something that I’ve never missed it despite some fairly advanced Git usage.

Re: Fossil vs Git

#244

Post by Drdrdrq »

bensummers wrote: post #50

I choose fossil at a time when it wasn't clear which one of fossil, Mercurial, or git would "win". I choose it because it had a very clear and easy UI, guided you towards a way of working that is suitable for small teams (ie 99.99% of all projects), and had an approach to history which made it unlikely you'd ever accidentally lose work. The only thing which has ever made me sad about my choice is pressure from people…

Been there, but with Mercurial. We chose it because it has sane CLI interface (as opposed to git), but eventually had to switch because we wanted to use GitLab. Not much difference all in all, except with git I still need to search the net to find a proper command, while with hg I could usually guess it and just checked help for confirmation. It saddens me that git won... Awful UX. But they had GitHub and now GitLab.

Re: Fossil vs Git

#245

Post by atombender »

jordigh wrote: post #182
atombender wrote: post #174

Earlier quoted context omitted.

Ideally it should be this way, but it's impractical in reality. It requires that you either stop your development workflow to commit as you go along, or that you untangle all the pieces after they're already entangled. If you commit as you go, it's an expensive mental switch to fire up git and also run all the tests (since surely part of this workflow is to apply the principle that no commit should ever break the bui…

Untangling is what I mostly do. I consider the untangling my own internal code review. I need to read my own diff and figure out what goes where and what each part does and why it's necessary. My commit messages are then my own code review comments. I figure if I don't carefully read my own diff, why would anyone else? And once it's untangled, I am hoping others will find it easier to read too. Git doesn't provide as…

That's a cool script. I will definitely try that. Augmenting commits by doing partial commits then fixing with "git rebase -i" and squashing with "fixup" takes so much time and mental effort just to not make a mistake.

It still doesn't solve how to disentangle changes that have become interdependent. For that you have to concentrate on committing atomically and planning ahead a lot.

Re: Fossil vs Git

#246

Post by Groxx »

raimue wrote: post #212
Groxx wrote: post #199

Earlier quoted context omitted.

`git clone --local` does hardlinks, space usage is quite low, so I'm not really sure that part holds up. Maybe in Windows? Switching branches can definitely be slow tho, yeah. Do worktrees change that somehow tho? From all I've read so far (quite limited!) they just sound like replacements for `git stash` or making a temporary commit / branch, but with a new set of commands and rules to learn. I don't find `git commi…

git worktrees can also be useful if your build system needs different arguments per branch. For example if you keep multiple release branches installed side-by-side on your machine, it is easier to just run `./configure --prefix=/opt/release-X.Y` only once on a worktree instead of repeating this procedure every time you switch branches. That way you can even keep all your object files around and save the time to comp…

aaahh, so it can track un-tracked files too? that I can definitely see being useful - the lack of a "local" / "remote" git ignore split makes this kind of thing hard :|

(yea, there's .git/info/exclude, but you can't add it to a branch and have it only exist locally. and it has weird interactions when something becomes tracked later.)

Re: Fossil vs Git

#247

Post by slavik81 »

cryptonector wrote: post #239
slavik81 wrote: post #229

Earlier quoted context omitted.

You're just assuming that. And, despite your snark, you are completely incorrect about what my commits looked like.

Ay, I meant the general you, and the snark was directed to VCSes that lack an index and rebase. You wrote this: > > > When I worked with VCS that couldn't rebase, my strategy was simply to not commit until everything was perfect. I had a local branch. It was just not version controlled. if I were to do that (and I have) with anything other than Git, I'd have a hard time splitting up the commits in the end. Mercurial…

Ah. I see what you were saying now, but for me it was just more work to split things manually. The end result didn't change. At least, not much.

This highlights one of the benefits to framing comments in a positive manner: they tend to be inoffensive even when misunderstood.

Re: Fossil vs Git

#249

Post by iggldiggl »

cryptonector wrote: post #239
slavik81 wrote: post #229

Earlier quoted context omitted.

You're just assuming that. And, despite your snark, you are completely incorrect about what my commits looked like.

Ay, I meant the general you, and the snark was directed to VCSes that lack an index and rebase. You wrote this: > > > When I worked with VCS that couldn't rebase, my strategy was simply to not commit until everything was perfect. I had a local branch. It was just not version controlled. if I were to do that (and I have) with anything other than Git, I'd have a hard time splitting up the commits in the end. Mercurial…

`hg record` has been supplanted by `hg commit -i` (for `--interactive`), which has an improved UI that is certainly more flexible than the old `hg record`.

Re: Fossil vs Git

#250

Post by eesmith »

mewse wrote: post #228
pseudalopex wrote: post #191

Earlier quoted context omitted.

Git makes it difficult to lose committed data. It's easy to lose uncommitted changes. Also, someone can know that changes are in the reflog but not how to recover them without making a bigger mess.

That's a really interesting criticism to make. Can you specify a version control system which doesn't make it easy to lose uncommitted changes?

A versioning file system tracks all changes to each file. On an old VMS machine, you might have X;1, X;2, and X;3 where the number after the ';' is the version number. Normally directory listings only show the 'X', which refers to the most recent version, but you could have it display all the files.

This makes it easy to compare, say, the state of the file now with the state of the save from 3 hours previous.

https://en.wikipedia.org/wiki/Versioning_file_system points out "Subversion has a feature called "autoversioning" where a WebDAV source with a subversion backend can be mounted as a file system on systems that support this kind of mount (Linux, Windows and others do) and saves to that file system generate new revisions on the revision control system."

Quoting http://svnbook.red-bean.com/en/1.4/svn.webdav.autoversioning... :\

> the use case for this feature can be incredibly appealing to administrators working with non-technical users: imagine an office of ordinary users running Microsoft Windows or Mac OS. Each user “mounts” the Subversion repository, which appears to be an ordinary network folder. They use the shared folder as they always do: open files, edit them, save them. Meanwhile, the server is automatically versioning everything. Any administrator (or knowledgeable user) can still use a Subversion client to search history and retrieve older versions of data. ...

> however, understand what you're getting into. WebDAV clients tend to do many write requests, resulting in a huge number of automatically committed revisions. For example, when saving data, many clients will do a PUT of a 0-byte file (as a way of reserving a name) followed by another PUT with the real file data. The single file-write results in two separate commits. Also consider that many applications auto-save every few minutes, resulting in even more commits.

It adds that Clearcase supported a similar feature.

I have never used that combination.

Post reply on HN