No differently to the previous way of doing stacked PRs? There's no getting around the fact that you're force-pushing a new version of each branch in the stack.
This just automates the previously-manual process of checking out branch2 and rebasing it to point to branch1, instead of pointing to the commit that branch1 referenced pre-rebase.
I usually just `git rebase --onto` any dependent branches. I will have to see if `--update-refs` is more convenient (it should be) and if it works well enough for me.
That explains why it was added to git/contrib. It seems to have moved out of contrib with essentially no discussion.
The original commit adding it to contrib anticipated moving parts of it into git proper:
For example, we previously discussed the idea of a "git big-clone" that does
much of what "scalar clone" is doing. This patch series is a step to make
such functionality exist in the Git code base while we simmer on what such a
"git big-clone" command-line interface would look like.
This is one of many possible ways to do this. Creating a 'git big-clone'
could lock Git into backwards compatibility concerns so it is necessary to
approach such an endeavor with caution.
Seems like now it is locked into backwards compatability concerns around including the scalar command.
it seems like it was made at microsoft, using .net[0]
I agree it seems quite strange that it's not a git subcommand now that it seems like it's been incorporated into the git core release. I'm not exactly sure of it's utility...seems kinda heavy weight to just be setting recommended configurations? I guess it does some background automation for fetching and gc?
Since that original patch, the codebase was moved out of contrib and is now scalar.c alongside the other git source files.
Remaining a seperate command rather than a subcommand is motivated by command line backwards compatibility for users of the c version from microsoft/git, but also for users of the older C# version.
If they did git-scalar then they would still need a contrib subfolder command wrapper executable (not just a script, as many users are on windows and rely on it being an executable, not just a bash script).
Anyone have experience with using Scalar? How is it? How far can it scale?
I'm also curious how they managed to drive it into the Git project. Presumably there can't be that many orgs out there for whom git repo size is a bottleneck. My rationale there is that the Linux kernel has thousands of contributors and vanilla Git scales ok there. Maybe I'm being naïve about something?
I know there are advantages to monorepos but when I hear such stories I just scratch my head. How did they let things get so bad that this would be the case? Surely the advantages monorepos provide would eventually have been overshadowed by the abysmal performance. It seems like they must have already split the repo, switched to something other than git, or devised custom tooling to handle the pain.
Obviously MS devised such tooling and here we are... but have others just been quietly doing similar internally and never showing it the light of day?
Other day I started using a remote machine and after some months a git command behaved unexpectedly. I checked git version and it was a very old one. I realized that I'm not using any new feature of git.
What am I missing? Which somewhat newer Git feature or configuration are you using that is useful?
3-way conflict visualisation is excellent. It allows you the original parent as well as the current and incoming. Saves so much faff figuring out how to resolve a conflict.
switch and restore, though still both marked experimental, are often cleaner interfaces to common tasks otherwise buried in branch, checkout, and reset
git range-diff is great for seeing what changed after a rebase. It shows you which commits were added, removed, reordered, and changed (with a diff of course) all with color.
As far as I know, in its current shape, rust is much less toxic than c++ or the upcoming C47392483274. Namely, it is easier to code a rust compiler than for those.
It seems rust syntax is more complex than C4738974389, and may require some specific runtime (the syntax can do a "heavy free" in your back if I am not too much mistaken), hence you would need more time and effort to write a naive rust compiler.
That said, in linux, it will be, probably, rust with tons of extensions, so more time and effort to write such a naive rust compiler. I hope it won't be the case, and Linus T. will care.
In a sane world, linux rust code should compile with a simple, self-compiling with minimal SDK, rust-written rust compilers. Are we is such a sane world?
And yes, rust syntax is still billions of times less toxic than c++ syntax.
