I've written a guide to how our developers can use git while developing inkscape:
http://staging.inkscape.org/en/develop/using-git-repositories/
I've modified the required regular documentation to link these pages in too, we should have no problems allowing people to use git.
The hosting provider we use for inkscape's code is launchpad. I like launchpad and I also think it would be way too much work to move inkscape to a less-useful project host like github or savanna just for git based remotes.
Hopefully this kind of compromise on the client side can allow developers to not feel put out about our choice in repository technology.
On Sat, Sep 21, 2013 at 03:30:40PM -0400, Martin Owens wrote:
I've written a guide to how our developers can use git while developing inkscape:
http://staging.inkscape.org/en/develop/using-git-repositories/
I've modified the required regular documentation to link these pages in too, we should have no problems allowing people to use git.
The hosting provider we use for inkscape's code is launchpad. I like launchpad and I also think it would be way too much work to move inkscape to a less-useful project host like github or savanna just for git based remotes.
freedesktop.org could be another option to consider.
Hopefully this kind of compromise on the client side can allow developers to not feel put out about our choice in repository technology.
Thanks for documenting this.
Is bzr vs git something we should be giving consideration to again, or are developers pretty satisfied with bzr so far?
Maybe after 0.49 is out the door we could open discussion on any infrastructure changes folks would like to see considered.
Bryce
2013/9/21 Bryce Harrington <bryce@...961...>:
Is bzr vs git something we should be giving consideration to again, or are developers pretty satisfied with bzr so far?
Maybe after 0.49 is out the door we could open discussion on any infrastructure changes folks would like to see considered.
I prefer Bazaar over Git, for the following reasons:
1. Git does not support bound branches or lightweight checkouts.
2. It requires MSYS on Windows. (Maybe not a big problem, but btool exists exclusively to avoid relying on MSYS.)
3. The manpages are incomprehensible if you don't already know Git fairly well, and therefore not very useful. For instance the one for "git push" says "Update remote refs along with associated objects", and the one for "git reset" says "Reset current HEAD to the specified state". This could be partially addressed if we made a page similar to "Working with Bazaar".
4. The default behavior of basic commands is borderline malicious. For instance, "git pull" will autocommit a merge if it applies cleanly, even though it might not compile at all, "git diff" will not show changes in files added to the staging area, and "git commit" will do nothing if you don't first execute "git add". To get a sane behavior, one needs to always say "git pull --no-commit", "git diff HEAD" and "git commit -a".
5. The whole model of Git, where it's impossible to operate directly on remote branches, causes a lot of artificial complications and necessitates the existence of additional concepts such as "tracking branches", "fast-forward merges", "remotes" and so on. This complexity does not exist under the Bazaar model.
6. Some commands with names taken from Bazaar / SVN / CVS do something completely different, leading to confusion. For example, "git revert" is equivalent to "bzr merge -r -1..-2 && bzr commit", not to "bzr revert".
That being said, I would contribute to the project regardless of the VCS.
Regards, Krzysztof
On Sep 21, 2013 2:27 PM, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
I prefer Bazaar over Git, for the following reasons:
- Git does not support bound branches or lightweight checkouts.
Ugh. I use lightweights to follow GSoC student progress as well as the occasional feature branch.
- It requires MSYS on Windows. (Maybe not a big problem, but btool
exists exclusively to avoid relying on MSYS.)
I think that if we can get to a unified build system across platforms it would trump dependency requirements (with the exception of Cygwin... we should never impose that on anyone).
- The default behavior of basic commands is borderline malicious. For
instance, "git pull" will autocommit a merge if it applies cleanly, even though it might not compile at all, "git diff" will not show changes in files added to the staging area, and "git commit" will do nothing if you don't first execute "git add". To get a sane behavior, one needs to always say "git pull --no-commit", "git diff HEAD" and "git commit -a".
That sounds downright painful and scary.
- Some commands with names taken from Bazaar / SVN / CVS do something
completely different, leading to confusion. For example, "git revert" is equivalent to "bzr merge -r -1..-2 && bzr commit", not to "bzr revert".
Given that the three VCSs you listed are the only ones I've worked with deeper than only checking out and updating, that just seems like it would be unpleasant to retrain my brain.
Cheers, Josh
Em Sáb, 2013-09-21 às 23:26 +0200, Krzysztof Kosiński escreveu:
- Git does not support bound branches or lightweight checkouts.
I don't know what are bound branches, but for lightweight checkouts, git has something similar: http://mortalpowers.com/news/speed-up-git-clone-with-shallow-clones#.UkEEgVT...
- It requires MSYS on Windows. (Maybe not a big problem, but btool
exists exclusively to avoid relying on MSYS.)
This is indeed a problem.
- The manpages are incomprehensible if you don't already know Git
fairly well, and therefore not very useful. For instance the one for "git push" says "Update remote refs along with associated objects", and the one for "git reset" says "Reset current HEAD to the specified state". This could be partially addressed if we made a page similar to "Working with Bazaar".
The git documentation under git --help or via the manpages didn't teach me many things. But there is a lot of documentation around the net.
- The default behavior of basic commands is borderline malicious. For
instance, "git pull" will autocommit a merge if it applies cleanly, even though it might not compile at all, "git diff" will not show changes in files added to the staging area, and "git commit" will do nothing if you don't first execute "git add". To get a sane behavior, one needs to always say "git pull --no-commit", "git diff HEAD" and "git commit -a".
I think this is a matter of personal preferences. As long as the tool is customizable, there shouldn't be any problems.
- The whole model of Git, where it's impossible to operate directly
on remote branches, causes a lot of artificial complications and necessitates the existence of additional concepts such as "tracking branches", "fast-forward merges", "remotes" and so on. This complexity does not exist under the Bazaar model.
Topics too advanced for me, cannot say anything about it. =P
- Some commands with names taken from Bazaar / SVN / CVS do something
completely different, leading to confusion. For example, "git revert" is equivalent to "bzr merge -r -1..-2 && bzr commit", not to "bzr revert".
git is a old project and old projects are used to have this kind of problems. Emacs, for instance, is so old that it has its own concept of window. Then, when GUI were invented, Emacs created a new concept, frame, just to mean the window of GUIs. This is not a excuse for this problem, anyway.
On Tue, 2013-09-24 at 00:26 -0300, Vinícius dos Santos Oliveira wrote:
I think this is a matter of personal preferences. As long as the tool is customizable, there shouldn't be any problems.
'hard to use' is NOT just another way of saying 'Not my preference'. Hard to use can mean hard to use. The only way you can know for sure is by employing UX design principles and carrying out experiments with users.
git is a old project and old projects
Not that old:
git - 2005 (april) <- BitKeeper [perl/bash/tcl/C] hg - 2005 (april) <- BitKeeper [python/C] bzr - 2005 (march) <- baz <- arch [python/pyrex/C] svn - 2000 (octob) <- cvs [C] cvs - 1990 (novem) [C]
As you can see, something happened in 2005; you get 100 FSF points for knowing what, and why it's such an awesome example of why proprietary tools are bad for you ;-)
Martin,
On 21-9-2013 22:24, Bryce Harrington wrote:
On Sat, Sep 21, 2013 at 03:30:40PM -0400, Martin Owens wrote:
I've written a guide to how our developers can use git while developing inkscape:
http://staging.inkscape.org/en/develop/using-git-repositories/
I've modified the required regular documentation to link these pages in too, we should have no problems allowing people to use git.
How 'safe' is this bzr-git bridge? We've had a terrible experience with a similar versioning system A-to-B tool in the past.
Is bzr vs git something we should be giving consideration to again, or are developers pretty satisfied with bzr so far?
Maybe after 0.49 is out the door we could open discussion on any infrastructure changes folks would like to see considered.
Please please please let's not have any discussion about changing versioning system again. Just thinking about it already makes me want to cry :S
-Johan
Em Sáb, 2013-09-21 às 15:30 -0400, Martin Owens escreveu:
I've written a guide to how our developers can use git while developing inkscape:
http://staging.inkscape.org/en/develop/using-git-repositories/
Sounds great, just one typo: "...as if they were on hithub..."
I'll create an ArchLinux package and test this project.
participants (6)
-
Bryce Harrington -
Johan Engelen -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
Vinícius dos Santos Oliveira