11–20 of 93 posts
Is it just me or "simple semantics" is not at all simple? Compare with: hg push -- pushes everything to "default push location" hg push -r . -- pushes currently checked out branch hg push -r foo where -- pushes foo to where
Pushing only the current branch by default is a good thing, I think. If you are using a more centralized setup you can change the configuration of push.default to 'matching'.
Earlier quoted context omitted.
I agree! Overall I truly prefer git subtree over submodules. I've noticed that most devs seem to have strong opinions one way or another. Perhaps git subtree just seems so good because submodules are so clunky. If only someone would invent a "best of both worlds".
>I've noticed that most devs seem to have strong opinions one way or another. I've personally noticed that most devs don't have an opinion either way since they don't use subtrees nor submodules. I don't know what subtrees offer but using submodules has been very pleasant once you know how they work. For example if you version control your .vim I think that adding submodules for extensions is way better than cloning…
Is this released already or are those just preliminary release notes?
Is it just me or "simple semantics" is not at all simple? Compare with: hg push -- pushes everything to "default push location" hg push -r . -- pushes currently checked out branch hg push -r foo where -- pushes foo to where
There was a thing going around twitter lately: > If ping was designed by the git people: net-ping host --no=dns,bind --proto=TCP,rfc:492 eth0@ipv4:: http://1.0.0.127.IN -ADDR.ARPA --stats -v
Minor feature that's really nice: the pull.ff config setting. I had made an alias for doing that manually, now I can start actually using git pull again.
The problem with git is that new options aren't simply ignored by old git versions, meaning that if you synchronize your gitconfig as part of your dotfiles, then the machines that have old git versions will start spitting error messages at every command for options specific to new versions. I learned that painfully with push.default=simple.
Earlier quoted context omitted.
Any chance you could outline the downside of subtree? I've always thought it was better in every way.
Subtree operations modify commits (and trees). As a result, cryptographically signing or validating a subtree operation does not extend to an independent module, and vice versa. If you care about these things, it's a big deal.
Is it just me or "simple semantics" is not at all simple? Compare with: hg push -- pushes everything to "default push location" hg push -r . -- pushes currently checked out branch hg push -r foo where -- pushes foo to where
It's just you.
It's about time we'd put "hg vs. git" to the category of flamebait topics (similar to "emacs vs. vi" etc) that should be avoided. Every time there's a git topic, someone comes and derails the whole discussion with a not-quite-apt comparison with hg.
AFAIK, there are decent two-way conversion tools so you can use hg with a git repo and vice versa. There should be no need to argue because you can pick the one you like and use it.
Earlier quoted context omitted.
I agree! Overall I truly prefer git subtree over submodules. I've noticed that most devs seem to have strong opinions one way or another. Perhaps git subtree just seems so good because submodules are so clunky. If only someone would invent a "best of both worlds".
>I've noticed that most devs seem to have strong opinions one way or another. I've personally noticed that most devs don't have an opinion either way since they don't use subtrees nor submodules. I don't know what subtrees offer but using submodules has been very pleasant once you know how they work. For example if you version control your .vim I think that adding submodules for extensions is way better than cloning…