Chameleon > DevTalk

moving to GIT?

<< < (4/7) > >>

Mozodojo:
As I know, It's possible to work with SVN via GIT, something like this. But I completely noob related to setting up internet services.

Kabyl:

--- Quote from: zef on October 02, 2010, 11:21:28 PM ---Hi guys,

Thanks for the humble reports! ;) I agree that there are more sophisticated tools are available, but I still believe that discussing and organizing is the most important task. There are many examples in this forum where a new idea or bugfix is incorporated into the trunk within a fairly acceptable timeframe.

We already have a dedicated trac fronted for the public chameleon repo (use the same user and extra pass): http://forge.voodooprojects.org/trac/chameleon/

We can also extend this default trac setup, but in this case I would need valv's help :) We can even configure git here on this server. Let me check how painful it would be...

--- End quote ---

If it's possible to have git and bzr (maybe hg too), try them all, and see what's best? I know, it's probably asking you too much :P

valv:
we can rely on bzr's implementation to get all 3 (hg, git and svn) in one place.

Mozodojo:
I am using git now for HWSensors. It's simple, I am generally using only 3 commands:

cd \path_to_project
git commit -a -m "commit message"
git push

If I've deleted or renamed files, git tracks it automatically. Only if I need to add new unracked files I use "git add -i" and choose files I wish.



Moderator Edit: Discussion about the structure of the DevTalk category has its own thread here. Let's keep this one for Repo front/back end preferences. Sorry for the temp off-topic guys. 

r007:
*sigh* Sorry for the massive bump. It's been mostly triggered by my current issue -- getting my 5870 to work -- where I find it incredibly hard to keep up with what branch has what features and is based on what other code. This has elevated to a major itch for me right now, so that I feel the need to scratch it in here.

Please allow me to rant madly, after which I shall offer you suggestions. Here goes: *inhale*
FOR CRYING OUT LOUD SWITCH TO A DECENT SOURCE CODE AND ISSUE MANAGEMENT SYSTEM ALREADY!
*pant* Glad I've got that out of the way.

Personally, I've had very good experiences with git, and while the strategy outlined in the first post may be a little strict it's pretty much best practice. :) Of course, I expect bzr or hg to behave nicely as well, but git seems to be all the rage today, so I first got into that. I'm not trying to lull you into thinking git may be the do-all end-all solution to all your problems, but let me tell you about my experience...

I started out in the SVN world. I was happy to set up read/write repositories with Apache and DAV, which gave me TLS transport and authentication pretty much for free. Git... was different. To work really well, git needs SSH access to the central repository (which is still something I like to have, despite git being all about distributed). But after that, there are things like gitosis or gitolite which give you back authorization while only requiring a single shell user on the host box. So there is a little more micro-management involved there.

The command-line is admittedly even more different, but that pretty much only reflects the increased capabilities. Usually, you can start out with a core set of commands (clone, add, commit, rebase, push) that will get the job done, and if you need a certain function, you will most probably find it (point in case: I had edited several files and only wanted to commit part of the changes -- turns out you can do that, "gut add -p" will allow you to select only the hunks you want to commit). You need to, however, stop thinking in terms of revisions, but rather in terms of changesets (patches is pretty much equivalent).

So why would you want to use git? Well:
- Everyone gets the complete history and all branches of the project -- that's your backup strategy covered.
- You can be sure to get out of the repository what you put in -- git revisions are sha1 hashes over the whole tree. If you checkout a revision, it's pretty much guaranteed to be what you expect BIT-BY-BIT.
- Merging is easy, because as I said git thinks in terms of changesets. Unless changesets conflict (which they rarely do), merging functionality from another branch is as easy as specifying the changes you want to have.
- Branching is trivial, it's only an operation on the metadata of the repository. No duplicate files, only the changes are actually stored and evaluated upon checkout.

If you want more info or help, I'd be glad to join in on the effort.

tl;dr -- use git, it's awesome :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page