Re: [Inkscape-devel] DVCS Discussion & Vote
I don't think Max was saying that, when you are on a personal branch, you might commit something that you later discover breaks Inkscape. Git allows you to reorganize/rework your commits before they are pushed, so that each of your commits leaves Inkscape working. That way, when you merge back in trunk, all revisions are valid. This seemed like the goal of the svn trunk at some point: always have the development version working because some people use that for actual work.
I am not sure whether this is specific to git or a general behaviour, but in git, when you merge back a branch, you see its full history in the trunk, not just the merge commit. For example, let say your history is something like (best viewed with a fixed width font): master: A--B-------C-------D-- \ / branch: --A'---B'--/ A,B,C are commits on the master (=trunk); A',B' are commits on the branch; D is your merge commit. After the merge, "git log" on the trunk will show: D B' C A' B A You get all the commits, in chronological order, *including* those on the branch. So you don't "only look at the history of the trunk". Of course git keeps a memory of what was on the branch and what was on the master but you still see everything from the master. This is a reason why it is sometimes interesting to rework your branch history before a merge. I don't know whether this is a feature or a drawback, but this is the way (I think) it works.
JiHO --- http://maururu.net
2009/9/16 JiHO <jo.lists@...400...>:
(Disclaimer: The email quoted above was not from me.) In any case, I was mainly talking about my current workflow when working on Inkscape. I use git-svn to work with git locally and to push my changes back to the central SVN repository when I'm done. During my development I usually create a lot of temporary branches to examine ideas or to reorganize/cherry-pick previous work (which git makes very easy). Since the "best" way to achieve things usually only emerges during the work, it's extremely helpful to combine or reorder patches in this process. When I think my work is ready to push, I can arrange everything so that the patches make most sense, push the patch-set to the SVN repository and delete the temporary branches. Thus the visible result in trunk is (hopefully) easy to follow and comprehend while I still have maximal freedom during my local programming work. I hope this makes things a bit clearer.
Max
P.S.: Just to make sure there is no misunderstanding: I'm *not* talking about rewriting publicly visible history (which AFAIK isn't possible anyway). But for rewriting/reordering your local history before making it visible, git's tool's are immensely useful.
(Disclaimer: The email quoted above was not from me.)
Ooops indeed! My fault sorry :/ Anyhow, the rest of your reply goes in the same direction so I guess I that was not too bad of a mistake.
As for rewriting history that has been made public, it will make a big mess on the next push and will break everyone else's repositories. It's still "doable" with the proper --force option added everywhere but is indeed not recommended.
JiHO --- http://maururu.net
On Wed, 2009-09-16 at 15:06 +0200, JiHO wrote:
I guess I still believe that trunk should be buildable, but I'm not worried about the revisions on a sub-branch. Perhaps that's the difference. To relate it to your example bellow, I think it's important that A, B, C and D are buildable, but A and B prime, not so much.
Bzr log works differently. It, by default, will show you:
D C B A
So as long as the commit message shown on D is reasonable the whole history is easy to read. Now, what is a little unintuitive is that if you show the whole history it will be:
D B' A' C B A
So it tries to show the comments as they're relative to the merge indented so that they're easier to read.
Sometimes I find this difficult as I think it hides the "process" as you don't know the relative times of two commits. But, I like the way it works for just finding out what happened on a branch.
--Ted
participants (3)
-
JiHO
-
Maximilian Albert
-
Ted Gould