nullplan wrote:
What I usually need from a VCS is what SVN would offer if creating a new repository was a bit more expedient.
Pretty exactly where I am coming from. I never really understood the hype about git, and especially not the trashtalking SVN got in the process -- SVN pretty much hit my sweet spot, and in some regards I am using it as inspiration for improvements (e.g. 'svn info', which git has no equivalent for at all, and 'svn blame' which is readable while 'git blame' is not).
Quote:
...tag...
I am thinking hard about this one, and am currently considering to suggest using SVN's approach for tags instead of 'git tag': Just create an appropriately-named branch...
Quote:
Even the ability to have multiple remotes I don't need all that often. Hell, I have lots of repos on my disk right now that have no remote at all.
I was wondering if that (multiple remotes) is a scenario people are actually using. Virtually all environments I've seen so far use a very classic approach with one single repo that everyone is cloning from and done with.
Quote:
One thing I dislike about git is how it handles deleted branches...
Another bit of valuable advice. I positively
despise the casual way in which git makes outright deletion of information possible, indeed part of its workflow. My idea for this wrapper is to allow for local modifications any which way, but once it's public, it's public, and should not be tampered with. That, to me, is the whole idea of version control: Always being able to walk back on the timeline.
Korona wrote:
Regarding the OP's question: I regularly use "git commit --fixup" / "git rebase -i --autosquash" to prepare commit series before publishing them.
I understand the desire to "fix up" commits locally before pushing. So far I offer two subcommands for that -- 'squash' to merge multiple (by default: all) local commits into one (done by 'reset --soft' and a recommit plus lots of sanity checks), and 'uncommit', which undoes a commit so you could re-do it correctly (a 'git reset --mixed' with sanity checks so you do not walk back into already published history.)
The idea here is to
not add complex command line options and "magic commit messages" and whatnot, but work with simple and intuitive operations.
Would that float your boat, or is there something you'd be missing?
'apply' is something done just as well by 'patch'... but yes, I've been thinking about a 'mkpatch' / 'patch' command pair of some description. WIll think about that.
And yes, the naming and command overloading is part of what I abhor about git. Linus might have been looking for a powertool to maintain the kernel sources, but most people are looking for a tool that makes version control easy
and then gets out of the bloody way.
Thanks for your input!