Am 13.03.2013 um 10:32 schrieb jamwiki-devel@...:
> Ryan Holliday:
>> As to switching to Git, if enough people want to do so then I'm not
>> opposed to the idea. My main issue with Git (vs Subversion) is that
>> with Git it's much easier to screw up your repository in a way that is
>> difficult to undo, such as with funky merges or rebases,
Maybe this impression comes from suboptimal usage in the past, but in fact I found it much easier to "undo" a change with git than with subversion.
I can commit locally and - if absolutely necessary - rearrange the commits before pushing.
That's virtually impossible using Subversion.
Never ever rebase a repository others might have fetched from, but until there you're free to reset soft, mixed and hard and rebase whatever you want to.
Additionally I'm free to test and try in a local-only branch and (fast-forward, if appropriate) merge only the relevant changesets.
>> while with
>> Subversion you can always just undo the problem commit.
Which results in another commit shown in history, while git supports "real" undo (git reset --hard) ;-)
>> If there are enough active JAMWiki
>> developers with Git knowledge who can fix any such issues then I'm happy
>> to switch,
Define "enough", but whatever this means: count me in :-D
>> but if the responsibility is mostly on me to deal with any
>> SCM problems then I'd prefer to continue using Subversion.
I'd volunteer to deal with SCM related questions too.
>> Again, any thoughts that anyone else has on Git vs. Subversion are
I personally prefer git for some reasons (and I have to work with SVN at work, so I "feel" the (pain of the) difference:
- completely "offline" development: I fetch. I code. I test. I merge back and forth. I branch, I stash. I finish my work. Than I push.
- "real" undo: I commit something (locally). I recognize this has been a PITA. I "git reset --hard". Or I was clever enough to "git branch ..." before and I just plainly "git branch -D". No trace left, no confusion anywhere else about "what's this been? WTF?"
- easy and fast "feature" branches: branch, develop feature, see you fail, drop it. Restart from scratch.
- easy and fast "got an idea" branches: work on A, get an idea about B, create new branch (form common root or if it fits in: where ever you currently are), test idea and drop, keep or modify it later.
- easy idea sharing: fork the repo, create your own feature branches, give another developer repository access, ask him/her to fetch your feature testing change sets (e.g. branch) and merge it into his/her own local repository. Get feedback, deal with it. And if it's finished: merge it to real development branch that is pushed to "commonly declared: MAIN" repository.
- want to test some Git stuff? Clone your clone! As there's no "technically defined" primary source, there's no hassle creating another copy to test something. And if your tests end up with something useable: it's pretty easy to get it merged into "your primary" repository.
- get patches the easy way: people can easily create and send patches and you can easily merge them. It's more than just a "diff". And you can easily create a local branch, apply the patch and if it work simply merge it to your main developing branch. Else there's nothing more easy than throwing the change away without it having affected your current work.
So all in all: Git made my development work much easier. It's sometimes hard to understand in it's inner techniques and for "unusual" needs a little more difficult to handle, but it's flexible and simply does it's job. And honestly: if I don't know, how to add a second remote source for fetching merges and find the documentation hard to read about it: SVN can't even deal with this requirement. So blaming Git for being not as easy as SVN in tasks SVN does not even cope with, is ... ;-)
All in all: if JAMWiki repository would stay SVN I'd have to - and do - deal with it. - If it's switched to Git, I'd be happy. :-D
> Hi Ryan,
> since Peter is now also using git-svn, should we do the switch after the next
I'm in! :-D
> I'm currently on job search so there's a bit uncertaincy. But I think I can
> promis to be available to solve any Git-related issue. (I'm also very
> confident that there shouldn't be any...)
Me too. Not about the search, but the availability and the confidence :-)
> I think I might even know Peter from some course at Fernuni Hagen? :-)
Do we? Which ones? :-)