Hmm …
Hmm …
Posted Nov 4, 2018 10:39 UTC (Sun) by smurf (subscriber, #17840)In reply to: Hmm … by moltonel
Parent article: Apache Subversion 1.11.0 released
So what happens when another branch has changed the same line?
In git, the whole point of one commit is that it completely and unambiguously describes one particular state of your work (and its history). So "all branches with the same commit" doesn't even mean anything.
It's reasonably easy to write a post-commit hook that auto-applies your change to all other branches – including handling merge conflicts.
Posted Nov 4, 2018 17:46 UTC (Sun)
by moltonel (subscriber, #45207)
[Link] (4 responses)
Commiting to multiple branches is indeed meaningless for git, but it's natural for svn, and a useful feature for a vcs in general.
To me, the issue isn't about how to apply the commit to multiple branches (script, cherry-pick, patch, manual, etc...) it's about ending up with proper coherent cross-branch history. There's a single point in the commit logs where you see the fix applied, it's easy to check which branches it got applied to, and there's no risk to checkout the fix for one branch but not another.
It's not a must-have that would make me stick with svn, but it's definitely something that felt like a downgrade when switching to git.
Posted Nov 5, 2018 12:29 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (2 responses)
That depends on your philosophy. Svn operates in terms of tree snapshots while git operates in terms of changesets. With git, it is straightforward to see which sequence of changesets has resulted in the current state (“branch”), and it could be argued that the exact state and provenance of other branches actually isn't that important at that point. Svn gives you the “big picture” and of course that may also have its advantages every so often. OTOH, in git, a “branch” is a much more lightweight object than in svn, and that encourages the use of single-feature branches where you end up with a whole lot of them.
Git also makes it easier to transplant changesets from one branch to another after the fact, or to publish or consume them remotely, and that of course is at the root of the whole “decentralised” thing that svn doesn't really address at all. Working with git, I find myself doing rebases and fixups quite a lot just to keep the development history of my code nice and logical, and unless svn has improved considerably in that area since I used it I have no idea at all how I would do that with svn.
Posted Nov 5, 2018 18:47 UTC (Mon)
by johill (subscriber, #25196)
[Link] (1 responses)
Hm. I think that came out wrong?
git doesn't really care about the changes at all, each commit just records the current state of the tree and the parent commit.
Perhaps you meant to say something else?
(FWIW, I've (ab?)used this property of git to great effect in some projects, e.g. tracking an automatically modified version of one tree in another, where you just have to provide a tree->tree mapping "function", and then git will sort out everything else basically by itself)
Posted Nov 12, 2018 16:26 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
This is what we do to track third-party library imports in our projects. We take the upstream tree, select out files we want and then `git merge -Xsubtree=import/path/` into the "right place" in the project tree. There are then commit checks to ensure that all changes do that subdirectory are done via the importing process.
Posted Nov 9, 2018 19:55 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Hmm …
Hmm …
An svn commit is actually better at "completely and unambiguously describ[ing] one particular state of your work (and its history)" than a git commit, because it encompasses all the repo's branches, not just the branch(es) the commit belongs to.
Hmm …
Hmm …
Hmm …