2009/9/14 Aaron Spike <aaron@...749...>:

Ted Gould wrote:

...

On Sun, 2009-09-13 at 21:30 -0700, Joshua A. Andler wrote:

...

I guess the question at this point is what does git have over bzr? To me it seems like there is more benefit to bzr than git for our project. So, if you want to discuss, go for it... Let's vote otherwise.

Aaron: Git

I prefer git as well (although/because I haven't worked with bzr yet). But I agree with what Aaron said in a different thread that I'm happy with whatever DVCS we get since I won't do the migration work. One question, though (sorry if this has been answered before): Can I continue to use git locally with bzr instead of svn? I.e., is there something like git-svn for bzr? [1] If so, I happily vote for bzr, too.

Max

[1] I found http://github.com/pieter/git-bzr but haven't tried it yet, and given the comments on the page that it is not developed any more I wonder how stable/useful it is and especially will be with newer versions of git and bzr.

2009/9/14 the Adib <theadib@...1439...>:

there is a svn plugin for bzr. So you can work localy using bzr and then push to a central svn repository.

Thanks, but what I meant was: If we switch to bzr for our Inkscape repository, can I continue using git locally for my own development work (i.e., can I push to a central bzr repo from a local git repo)?

Max

On Mon, Sep 14, 2009 at 11:16:45AM -0500, Ted Gould wrote:

On Mon, 2009-09-14 at 18:00 +0200, Maximilian Albert wrote:

...

2009/9/14 the Adib <theadib@...1439...>:

...

there is a svn plugin for bzr. So you can work localy using bzr and then push to a central svn repository.

Thanks, but what I meant was: If we switch to bzr for our Inkscape repository, can I continue using git locally for my own development work (i.e., can I push to a central bzr repo from a local git repo)?

I think there are a couple of starts at tools to do that, I don't know of any that are used widely. There was a group (that I can't remember the name of now) that was trying to do a generic DVCS hub for all of them.

The difficult part (as far as I know) is that since git doesn't track files you have to use some of the heuristics that in the client for tracking that.

I imagine that it will be solved sometime, if not already.

I chatted up one of the bzr guys at All Hands, and asked about this (and some of the other issues we'd flagged when we looked into bzr previously). There's definitely been some progress made, although unfortunately I can't remember the specifics. Ted or I could probably chase down some more info on this if it's desired.

That said, I use both git and bzr very heavily in my day job (X.org upstream and debian are 100% git, whereas more Ubuntu-focused areas of my job use bzr). I learned git well before bzr and in fact was a bit skeptical about bzr. However, I definitely find bzr a lot easier and a lot more comfortable. In terms of syntax and workflow, the two seem to be analogous enough that switching back and forth between them is pretty straightforward. I may well be biased, but with my own personal projects (including a non-work-related game project) I have been going with bzr exclusively.

Bryce

On Mon, Sep 14, 2009 at 02:32:58PM -0700, Joshua A. Andler wrote:

On Mon, 2009-09-14 at 14:17 -0700, Bryce Harrington wrote:

...

That said, I use both git and bzr very heavily in my day job (X.org upstream and debian are 100% git, whereas more Ubuntu-focused areas of my job use bzr). I learned git well before bzr and in fact was a bit skeptical about bzr. However, I definitely find bzr a lot easier and a lot more comfortable. In terms of syntax and workflow, the two seem to be analogous enough that switching back and forth between them is pretty straightforward. I may well be biased, but with my own personal projects (including a non-work-related game project) I have been going with bzr exclusively.

Rather than assume anything, I'll ask... care to vote?

Oops, sorry, baby interrupted before I could cast it.

Bryce: bzr

2009/9/14 Ted Gould <ted@...11...>:

On Mon, 2009-09-14 at 11:14 -0600, Joshua L. Blocher wrote:

...

Here is my logic. Lets start here http://whygitisbetterthanx.com/

From the website, there are many things that are off, but the one that bothers me is that they list the feature of "staging area", which is a total misfeature.  It basically means you need to commit twice, instead of supporting an easy "uncommit" command.

Personally, I find the staging area quite useful and use it on a regular basis. The reason for this is that it allows me more fine-grained committing during my development work (normally, I realize that it would be sensible to store my changes in a commit when other files are already changed; using the staging area I don't have to undo these newer changes before committing). But maybe that's a personal thing, and if you don't like it you can simply ignore it and commit as you used to with other version control systems (using the -a switch).

Regarding an easy "uncommit" command: One of the main reasons I love git is that you have incredible power with undoing commits, reordering commits, combining multiple commits in a single one, etc. I'd be interested which of this is possible with bzr.

Max

2009/9/14 Ted Gould <ted@...11...>:

...

Regarding an easy "uncommit" command: One of the main reasons I love git is that you have incredible power with undoing commits, reordering commits, combining multiple commits in a single one, etc. I'd be interested which of this is possible with bzr.

You can do most of that with the bzr-rebase plugin, but I'd recommend against it.  Honestly, the only reason I've seen to reorder commits is to lie and say you never make mistakes, or to clean up a visualization to make it look better.  I don't think either of those are good reasons to "change history."  I'm kinda a historian on that point, it seems like history is history -- leave it alone :)

I agree as far as the "official" history is concerned (i.e., the history of the central repository). But for things like finding (and especially understanding!) the commit where a bug was introduced, I find it immensely helpful if commits come in chunks of reasonable size, are relatively self-contained and do sensible things. For this reason I am *very* grateful that git allows me to rewrite my (local!) history before pushing my changes. It's not so much about not admitting mistakes but rather about helping others not to have to go through these same mistakes again when investigating your development later on. I guess it depends on your workflow as a programmer, but in my work I often find that I have to take a slightly different approach than originally intended, and if rearranging commits helps me to present a cleaned up version of my work to others then I'm all for it.

And, while git can do it, it's not nearly as simple as "uncommit".  You have to use some commands with really scary sounding arguments to pull that off.

You mean scary commands like

git reset HEAD~n

in order to undo the last n commits? :-P

Max

On Mon, 2009-09-14 at 22:19 +0200, Maximilian Albert wrote:

2009/9/14 Krzysztof Kosiński <tweenk.pl@...400...>:

...

Disclaimer: I do not use any DVCS heavily. I used Bazaar for a small two-person project and was satisfied with it. I tried to use Git once but was somewhat intimidated, so other developers which do not use VCS tools heavily might feel the same.

I can understand this intimidation (because I once felt it, too) and I have to admit that it took me quite some time to learn git when I first started using it. But I have the impression that this was mainly due to the fact that there were hardly and well-written tutorials out there at the time. My feeling is that this situation has changed (although admittedly I haven't done any research recently [1]) and I think it would be very easy to compile a short list of commands needed by the average developer.

The GNOME guys made one when they moved to git. It is here:

http://live.gnome.org/Git/Developers

I have still not been able to get everything to work even with those instructions though. So I'm not sure if the instructions are correct or not. I still find git intimidating :)

--Ted

On Sep 14, 2009, at 2:14 PM, Kees Cook wrote:

This is my thinking too. I don't care about performance, they're so close it's meaningless. I care about easy-of-use, and git comes with loads of negative feedback in that department. I find bzr an easy step in the right direction for continuing to do centralized VCS with trivial changes in work-flow to do DVCS. git is hugely unfriendly, IMHO.

Thanks.

I think you've brought up a very good point. Among the "social problems" that I mention git mismatching our needs is the one of the target audience. The Kernel development realm is very different from ours, and I think that highlights one place where different tools are appropriate for different jobs.

Given than "low barrier to entry" is a key tenant of the Inkscape community goals, I think Bazaar gets a much higher "win" in that category.

You can vote as an uninformed individual... how do you think we got bush 2 twice here in the US? ;-)

Anyway, yes bzr and lp have some good strengths together.

On Sep 15, 2009 12:44 AM, <J.B.C.Engelen@...1578...> wrote:

I had a quick look at TortoiseBzr. It seems it is under active development, and that it is maturing quickly. It it awesome to see they try to mimic TortoiseSVN (much better than TortoiseCVS). TortoiseGit seems nice too.

Are there perhaps special benefits in using Bzr together with LP? (automatically linking revisions with bug reports perhaps?)

I have no preference (or can I vote SVN?)

Ciao, Johan

------------------------------------------------------------------------------ Come build with us! ...

I won't vote because my opinion does not really matter for this and because I have no experience with bzr but I thought I could add some comments:

they list the feature of "staging area", which is a total misfeature. It basically means you need to commit twice, instead of supporting an easy "uncommit" command. I'll never understand that, and in arguments I've had on the topic most git user end up saying "committing shouldn't be that easy," which just makes me laugh.

As Ted, I was initially skeptical about this staging area and could not understand why committing had to be that complex. Yet I grew to appreciate this feature when I need to commit *some* of the changes in the tree but not all of them.

When several files are involved, instead of having to type one long command with all the paths, you can just move around in your source tree and put files in your "staging area"-bag before throwing all that in a commit. I gives you a chance to review which changes are left in your working tree (because git diff ignores the changes in the staging area by default) and helps you not forgetting anything.

What's even more powerful is when committing only part of the changes in one/several files. Let say you are reviewing some files looking for a bug and, in the meantime, you correct some typos or weird syntax which is unrelated to the bug. You can first put the changes related to the bug in one commit and then put the syntax cleaning in another, even when those changes are in the same file(s). That makes for a much more sensible history. Can bzr commit only chunks of code in a file?

(NB: you could also do a "git stash"/"bzr shelve", work on the syntax cleaning, commit that and go back to working on the bug but this is not half as practical as working down the files solving both issues in parallel and sort them at commit time.)

I care about easy-of-use, and git comes with loads of negative feedback in that department. I find bzr an easy step in the right direction for continuing to do centralized VCS with trivial changes in work-flow to do DVCS. git is hugely unfriendly, IMHO.

I tried to use Git once but was somewhat intimidated, so other developers which do not use VCS tools heavily might feel the same.

I think this is just coming from the bad history git has in this department. Initially, git was very difficult to use apparently. But this has changed (and had already changed a over a year ago, when I started using it): git is now much better documented than svn for example (the man pages are comprehensive and very clear), the everyday commands are completely straightforward and there are plenty of tutorials targeting a wide range of audiences. http://git-scm.com/documentation The UI was heavily critiqued but I now find it brilliant. The feedback you get from every command is clear and helpful. Even the formatting of the output is nice: coloured status, logs, and diffs (you can even get a coloured diff in the editor where you type your commit message, which is very helpful to write a sensible commit message), diff summary per file (the lines with the + and - after each file name), clear organization of the status output etc. The CLI is so nice that I only use a GUI (GitX in my case) to commit chunks of code (which is not as easily done on the command line).

I had a non-computer savvy intern use git to collaborate with me on a project and he picked it up quickly (clone, status, diff, add, commit, push, pull is basically all you need for everyday use and all those are very simple to understand).

Among the "social problems" that I mention git mismatching our needs is the one of the target audience. The Kernel development realm is very different from ours, and I think that highlights one place where different tools are appropriate for different jobs.

It is not because kernel developers created and use git that it is only suited for them. Things like email patches are evidently targeted at them. But I use git for all my personal projects and find it completely appropriate even though they are small projects, on which I mostly work alone, on my machine. I even used it to manage the latex and svg files for my PhD thesis and found it very practical (thanks to coloured word-diff) while this is probably as far from the kernel as you could get!

I remember from previous discussions that one difference between git and bzr which might influence the choice is their handling of remote branches. When you create a local branch in git and eventually want to make it public as a remote branch, you need to: - push your local branch to the server, - move to the master, - delete the local branch (hence all your changes need to be committed), - recreate a local branch which tracks the remote one you just created. It is easier to create the remote branch directly and then check it out but I guess that, in most cases, people would start a local branch and, only after a while, need some help on it and want to make it public. I seemed to be easier with bzr+launchpad because you could create a remote branch through launchpad and then push your local branch to it easily, but I don't remember the specifics.

Finally, in terms of functionality, git supports importing a specific revision of another git repository as a submodule. Then the submodule is a separate, full fledged git repository and it is very easy to work on both the main project and the submodule at the same time. This might be useful for the progressive separation of libraries (2geom, croco, etc.) which were mentioned earlier. It would also be possible to extract the history of those libraries from the global Inkscape tree so that they wouldn't need to be restarted with no history, e.g.: git clone --no-hardlinks inkscape/trunk only-libcroco cd only-libcroco git filter-branch --subdirectory-filter src/libcroco -- --all git reset --hard git gc --aggressive git prune I don't know if bzr can do all that.

I hope that helps,

JiHO --- http://maururu.net

Yes, but I would consider things like a two-stage commit process more focused on people who review lots of changes and do partial commits on those changes rather than those who do small changes on a personal branch.

I agree with you on that. However, the way I see it is that git allows for small commits (with git commit -a) and large ones (with git add and git commit) while an enforced one stage commit process makes it more difficult with large/complicated commits. I guess that refactoring work probably involves commits that touch many files and can be complicated. It does not require a large team to get large commits (even when I work alone I usually do partial/large commits when I review old code).

...

I even used it to manage the latex and svg files for my PhD thesis and found it very practical (thanks to coloured word-diff) while this is probably as far from the kernel as you could get!

Heh, I used CVS for my Master's thesis, but I'm not suggesting that ;)

In case it wasn't clear, I was just pointing that to show that git is very practical for me while I mostly work alone and on projects that are far from being the linux kernel. I am not saying that bzr wouldn't be equally good for me, just that git is not "for" kernel developers anymore.

...

I remember from previous discussions that one difference between git and bzr which might influence the choice is their handling of remote branches.

I'm not sure that I understand what you're saying with the git stuff, but with for instance the Launchpad plugin and Bazaar you can create branches and push to them at the same time. [...] I'm not sure if that matches what you were saying.  But, hopefully it answers your question :)

It shows that this is easier with bzr which was the question indeed.

...

Finally, in terms of functionality, git supports importing a specific revision of another git repository as a submodule.

<snip> > I don't know if bzr can do all that.

I'm pretty sure that bzr quilt can do that,

From what I read about quilt (or loom), it is very different from git

submodules. Git submodules are similar to svn:externals. In bzr the equivalent would rather be "nested trees": http://bazaar-vcs.org/NestedTreesDesign But I cannot figure from this page whether it is implemented or not. In any case it seems to add complexity to the base commands. I find submodules quite straightforward in git.

Let say you have an "inkscape" repository and a "libcroco" repository. You would:

git clone address-of-inkscape cd inkscape # add libcroco git add submodule address-of-libcroco src/libcroco git commit -m "Add libcroco as a submodule of Inkscape" # now inkscape contains a reference to the last commit of libcroco (number n) and the complete libcroco repository # # work on inkscape vi whatever.c git commit -a # the above command commits to "inkscape" # # now work on libcroco cd src/libcroco vi a-file.c git commit # the above commits changes to the "libcroco" repository # the only thing that changed in the "inkscape" repository is that the reference to libcroco changed from commit n to commit n+1 # # now you've finished your work on a new feature of Inkscape that required a change in libcroco. Time to push everything to the public # require the latest version of libcroco in Inkscape git commit src/libroco -m "Bumped libcroco version" # this basically says: "the reference version is now commit n+1" # commit your work in inkscape git commit -a -m "Cool new feature" # publish everything git push

So basically you have two full fledged repositories and the ability to specify on which specific version of libcroco Inkscape depends. Of course, if I understood well, the goal in the end would be to have libcroco (or 2geom or...) be completely separate and have Inkscape link to them. But submodules look like they could be a useful tool for the progressive migration towards this state so that's why I mentioned them.

JiHO --- http://maururu.net

Instead of a vote, I have a question: Ted, what was the piece of software with which you did that horrendous hole in our SVN history, erasing many past revisions of many files? Was it bzr? If so how can we be sure this never happens again? Sorry to bring it up again but I run into this "black hole" quite often when I do research in our code and it's really a sore spot.