231–240 of 252 posts
That comparison table made me dislike fossil even more. Fossil took something that’s not broken, and broke it.
I disagree. I would suggest you to atleast research it more before coming to such strong conclusions.
I'm a big, huge fan of recording what should have happened instead of recording every typo and forgotten semicolon in your history. There's a difference between draft commits and published commits. When I'm reading published commits, i.e. history, I just want to know your intent, not your typos. So what are the tools that Fossil offers to make sure I don't have to see your typos in the history?
In git you can do `git commit --amend --no-edit` to update your last commit, in case anyone is wondering.
Earlier quoted context omitted.
Merge commits stop being interesting when you have thousands of people working on a codebase and you have tens or hundreds of thousands of branches. At that point clean, linear history is much, much simpler to understand.
If you mean a squashed history, I agree. At that scale I think the advantages outweigh the disadvantages.
Add feature XYZ
Fix bug I just found around that code
Fix typos in XYZ
Fix bug in XYZ
Add tests for XYZ
Fix another bug I found around that code
Fix bug in XYZ
fixup! Add feature XYZ
fixup! Fix bug I just found around that code
Fix bug ... (not related to XYZ)
Fix second bug ... (not related to XYZ)
Add feature XYZ
Reword the commits to add ticket IDs to the commit subjects for all of these, if you have this as a requirement or have an issue tracker.
Force push your branch, do one last round of build, test, review, and push when all looks good (else rinse, repeat).
Maybe you'll realize that XYZ is two features, not one, and then you might split that up into two commits (again, using `git rebase -i`, mark that commit for "edit", `git reset HEAD^`, `git add -e`, `git commit -m 'Feature WXY'`, then `git add`, then `git rebase --continue`.
Some commits got squashed, maybe some got split, and all got reordered.
The resulting history is easy to read.
This takes a bit more work. But once you get into this workflow, it begins to become second nature, and you get good at it and it doesn't slow you down. The benefits are well worth the learning curve, and it's not that steep.
Git: One check-out per repository Fossil: Many check-outs per repository git allows multiple checkouts per repo. Official docs (good luck): https://git-scm.com/docs/git-worktree Random person's blog that explains it more clearly: https://www.saltycrane.com/blog/2017/05/git-worktree-notes/
I have no idea what use case is satisfied by git worktree, based on that blog post. In the case that you desperately needed to have two branches checked out, why not just clone twice?
- website generator (JS stuff) on "master" branch checked out at $PROJECT_ROOT, and website content (Markdown files) on "content" branch checked out using git-worktree at $PROJECT_ROOT/content.
- Project source code on "master" branch checked out at $PROJECT_ROOT, and images needed for GitHub README file in "media" branch checked out using git-worktree at $PROJECT_ROOT/media.
I never use it for quickly switching topics (that's the git-stash use case, it you can just make a temporary commit).
Earlier quoted context omitted.
I mostly agree with you, but I think this might be going a little too far: > You created a new function? That's one commit. Take a moment to explain why this function is going to be useful in future commits. > You called that new function from several new spots? That's another commit. Explain why each of these calling sites requires this function. In my opinion each commit should make sense on its own. It doesn't rea…
Maybe. I think both ways can make sense, and if you insist on having the function and the calling sites in the same commit, that can make sense. I think my proposal can also make sense because (1) it splits up the commits into two units that still keeps the codebase in a stable state [this is my rough metric for what "atomic" means] and (2) defining a function requires some independent contemplation about why that fu…
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?
Is this not terrifying? I've always thought the distributed nature of git is part of why it's so incredible. Not relying on a few handful of individuals.
Earlier quoted context omitted.
Yup, and then you had no real history. And one big commit. Super useful, not.
You're just assuming that. And, despite your snark, you are completely incorrect about what my commits looked like.
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 has `hg record`, which is akin to an atomic `git add -p && git commit`. I don't think Fossil has anything even like Mercurial's `hg record`, and it famously lacks an index/staging area.
(So Mercurial has an index! but as always with Git features belatedly adopted by Mercurial, it's a pain to use in Mercurial. If you want to stop in the middle your choices are: say 'N' and commit what hunks you've accepted so far, or quit and abandon the hunk selection work you've done so far. And you don't get to edit hunks.)
> > > When I later started using git, my workflows simply became safer and easier.
Mine too.
Earlier quoted context omitted.
Yeah, it's probably not "widely" used. I know the Tcl dev team uses it for Tcl and Tk. That's pretty much the only one I know. There is a online hosting service: http://chiselapp.com A list of public projects (I was kind of surprised there were so many): http://chiselapp.com/repositories/
I run ChiselApp.com if there are any questions about it. I inherited it from James Turner, the creator of it.
I would be happy to use the site for publishing software. But to see if I can rely on the site for backup, aswell as simply general interest; I would enjoy reading (maybe a page on the site) about where it came from / what your plans are for it / longevity / intent
i.e. I want to hear more about you ;)