111–120 of 197 posts
Didn't know about fossil. It's unfortunate many people are saying they stopped reading at the "fossil is everything into one" part because It still looks an interesting way of doing vcs. > 95% of the code in SQLite comes from just four programmers, and 64% of it is from the lead developer alone. The SQLite developers know each other well and interact daily. Fossil was designed for this development model. They propose…
Earlier quoted context omitted.
> squash your commits into a single unit change. Again, Git gets its bias from Linux kernel development. You can not present your entire work as a single unit change to sub-system maintainers for inclusion in the mainline. You can use the power of Git to present it in a digestible way that aids understanding, and allows piecemeal selection of acceptable bits, and rejection of others. This is clearly not relevant to e…
> You can not present your entire work as a single unit change to sub-system maintainers for inclusion in the mainline. If we take away “this is how it’s historically done” or “because I know how these maintainers act and they would not accept it” - why not? From what principles is the Linux kernel special that standalone incremental units of change are inappropriate or undesirable? > allows piecemeal selection of ac…
Human limitations. You are simply better able to digest small incremental changes, instead of one big blob. This is not controversial and i don't understand why you would even raise this as a point.
> Sure, is a good thing, but doesn’t have much to do with git and can be done without rebasing.
It does have something to do with Git. Git has tools to facilitate it. And that is the case because Git was born out of Linux kernel development where it was the norm, and necessary.
If you want to use another tool to achieve the same result, nobody is stopping you. Or if you don't want to do it at all, that's fine too. But the simple fact of the matter is, you must do it today if you want to participate in kernel development.
In the past I used Mercurial, among other things, for my open source work. And various issue trackers of my own choosing. I am not particularly wedded to Git. But I keep getting sucked into GitHub these days.
To get publicity or outside contributions it's hard to avoid the GitHub trap. It's become a discovery service for open source (like Freshmeat.net back in the day), a common reference point for how to do code reviews ("merge requests") and issue tracking (even though it doesn't really do either all that awesomely), but most importantly it's become a place where people network generally.
I don't love that this is the case but it's hard to avoid.
Stopped reading at first point; why would I want my versioning system coupled to a bunch of random services? Doing one thing and one thing only is a feature, not a bug.
Wouldn’t it be great if my car also brewed coffee? I drink coffee every day on the way to work. I’m always in a hurry. It would be convenient to just build that in. I always drink coffee while driving, I may as well just build it in. Cut to a month later because my car won’t start because I’m out of coffee grounds. This is how fossil seems to me. I probably have hundreds of repos with just versioned files. That’s it.…
Earlier quoted context omitted.
> You can not present your entire work as a single unit change to sub-system maintainers for inclusion in the mainline. If we take away “this is how it’s historically done” or “because I know how these maintainers act and they would not accept it” - why not? From what principles is the Linux kernel special that standalone incremental units of change are inappropriate or undesirable? > allows piecemeal selection of ac…
> From what principles is the Linux kernel special that standalone incremental units of change are inappropriate or undesirable? Human limitations. You are simply better able to digest small incremental changes, instead of one big blob. This is not controversial and i don't understand why you would even raise this as a point. > Sure, is a good thing, but doesn’t have much to do with git and can be done without rebasi…
Because I agree with you on your assessment of human limitations, and rebase doesn’t change this. If I need to merge 500 lines of code over 20 affected files, and none of that can be merged individually while retaining functionality, it doesn’t matter if I split that into 50 10-line commits if I need to merge in the monolith at once, which means understanding the set of changes as a monolith, regardless of git history.
If for some reason any of this can be merged in as standalone, you just do that instead. This is what I mean by bikeshedding. Rebase culture is purely preference. There is nothing it offers that is not solved equally as well by potentially less complicated alternatives. It’s not the wrong way to do things, it’s just not also objectively right, and creates more work than it claims to solve.
Didn't know about fossil. It's unfortunate many people are saying they stopped reading at the "fossil is everything into one" part because It still looks an interesting way of doing vcs. > 95% of the code in SQLite comes from just four programmers, and 64% of it is from the lead developer alone. The SQLite developers know each other well and interact daily. Fossil was designed for this development model. They propose…
I haven’t used Fossil but I have used gittrac, cvstrac in git mode. Cvstrac was what SQLite used before fossil, basically wiki and issue tracker built on top of SQLite, just add CVS, SVN or Git. A very small system compared to Gitea or other forges, but incredibly powerful thanks to SQL and very productive. Fossil is just the logical continuation and shares the same clarity of design and elegant implementation of SQL…
Earlier quoted context omitted.
Source control is all about managing diffs. Large files are fine, binary doesn’t make sense. Most of the time binary file diffs aren’t human readable. I store binary files outside of git but keep build logs containing binary file CRCs on git
> Source control is all about managing diffs. Large files are fine, binary doesn’t make sense In git, diffs are literally just a UI thing.
Earlier quoted context omitted.
> From what principles is the Linux kernel special that standalone incremental units of change are inappropriate or undesirable? Human limitations. You are simply better able to digest small incremental changes, instead of one big blob. This is not controversial and i don't understand why you would even raise this as a point. > Sure, is a good thing, but doesn’t have much to do with git and can be done without rebasi…
> Human limitations. You are simply better able to digest small incremental changes, instead of one big blob. This is not controversial and i don't understand why you would even raise this as a point. Because I agree with you on your assessment of human limitations, and rebase doesn’t change this. If I need to merge 500 lines of code over 20 affected files, and none of that can be merged individually while retaining…
That is a misunderstanding of how to use this feature. It is not meant to break changes down into useless divisions. It is meant to allow the grouping of changes into logical units. Logical units that help human comprehension.
This is very important when communicating with people who have never seen your code before. It allows you to include a narrative description (commit message) with each logical group of changes that is directly connected to the source code implementation of just that descriptive piece. It also allows you to connect a chain of those logical units into a progression toward a greater, cohesive goal.
You may dismiss all this as irrelevant to your particular environment, and that is fine. But Git provides tools that are directed toward it, and they're quite powerful and useful for those who understand and use them correctly.
If Fossil is so against deleting commits, what do you do if you've accidentally committed sensitive information that cannot live in any form in the repo?
Every Fossil repository maintains a list of the hash names of "shunned" artifacts. Fossil will refuse to push or pull any shunned artifact. Furthermore, all shunned artifacts (but not the shunning list itself) are removed from the repository whenever the repository is reconstructed using the "rebuild" command.
Earlier quoted context omitted.
I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history? The project is what it is. What happened, happened. If there are a couple of weird commits, who cares? At most, maybe edit the commit messages to explain.
Because when I am developing in my local repo I have a stream of commits that go “adding xyz because abc is being a pain”. They’re informational for me as I progress through iterating on a feature, but when I’m ready to merge I really don’t want that mess polluting the global commit history. I may also be working on multiple things in parallel and want to isolate them from each other, both to keep a cleaner history b…
What doesn't make sense to me is rebasing instead of merging. If master has a lot of changes and you want to pick those up, you can merge in which case history reflects reality - each commit has an actual state of the repo that you had on your machine.
Or you can rebase, in which case all of the commits on your branch now contain code that no-one ever had on their machine, not tested, never run, maybe it doesn't compile, maybe it's nonsense.
Both result in the same diff from master so are equivalent for submitting a patchset.
It's really hard for me to see the value of trashing your history like that. People like linear history but history actually is not linear sometimes.