|
|
Home » Community » Coffee corner » GIT
|
|
|
|
|
GIT essentials [message #24333 is a reply to message #23330] |
Mon, 11 January 2010 12:00   |
 |
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
hi people,
i have been using svn in my company now for some time and it was ok, sometiimes it was a pain. and one time we even had a crash on the server, boom, the repo was gone, the history too. my fault, though. should have done backup before. well, life continued with the revision that was on my work laptop. with git, that cant happen.
the trunk/branches/tags model in svn (which is not obligatory though, but used widely) is kinda strict in a sense. it does not motivate a developper much to try and experiment with the codebase, because one fears the whole commit/revert/reread and filter the changes stuff.. and you always need the repo connection for looking up the history, the graph etc.. with git that is far esier.
admittable, git has a hard learning curve in the beginning, since the concepts are remarkably different from svn, so svn users espacially have their what?s and how?s at the beginning. but one could simply present them some tutorials and explain the basic things, so they get the picture.
the fact that everyone has its own repository, and mirek would need to pull is both an advantage and a disadvantage. he would not need to care much about commit right of other users, because *HE* needs to decide from whom to pull or not, this is all. he does not need to give anyone the commit right to its own git repo at all, basicly. so user management is franly different. mirek could be able try out some ideas and reject them without comment or polluting its own repo master branch. having a bunch of remote branches from *trusted* co contributers would make it easy to keep track. but probably this would make more work for him (more decision work especially), whereas now, he grants commit right to some users, trusting them not to pollute the trunk and does not need to take care of it anymore (but this is also possible in git). but if we consider that linus has as little time as mirek and manages to handle kernel development with git (it actually was developped for that purpose), then it should be even easier.
i'd personally prefer to switch from svn to git, it is way superior to svn and many other scms (as far as i understood) and it should even be prefered over mercurial and other commercial projects, cause git will have a much wider accaptance and be wider used in future due to its open source nature. one can even say its more *standard* now. (look at all the major projects one by one dropping svn and heading for git).
we clearly have to destinct 2 things concerning usage of git for u++:
1) usage of git as scm for the Ultimate++ project *itself*
2) providing a git interface (among others, just like svn) in TheIDE to sync the user's project codebase when he uses git for it (has nothing to do with the ultimate++ project itself at all)
i think that was not clear cut apart in the preceeding posts
beeing using svn for quite some time, i started to switching to git, and still learning, have strived some of the tutrials and infos on the net over git. and so far, became more and more fixed in my decision to stay with git.
hope U++ will consider to move to git too. sorry for the long post 
PS: Linus, the godfather of GIT making a really enjoyable talk about GIT itself, at google talk, focusing and adressing most of the topics we descuss here. is worth watching, makes some harsh jokes . this video made me think about switching. is quite long, but woth it.
http://www.youtube.com/watch?v=4XpnKHJAok8
|
|
|
|
|
|
|
Re: GIT essentials [message #24345 is a reply to message #24343] |
Mon, 11 January 2010 17:19   |
mr_ped
Messages: 826 Registered: November 2005 Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
Well, the problem is that cloning(branching) with GIT is cheap, while with SVN it will take those 5+min. That's not good.
Then again as almost all U++ devs have limited access to SVN, and only very few people change the core of it (most of them used to old non-SVN way of syncing), they rarely run into conflicts or need of branches. Rest of us work mostly in Bazaar, which are reasonably small projects to rarely need a branch during development, and even then we would more likely create package_2 in bazaar in the very same trunk, mimicking branch behavior.
So I don't think right now there's huge benefit from using GIT.
If Mirek and other core developers have some spare time, it would probably make sense to try it out. If U++ core contributors will grow more in the future, the benefit from switch may be even greater. But right now I personally don't see this as big priority (then again I'm not core dev and rarely contributing even into bazaar, so who cares what I think ).
Also I think if you are proposing this, you should maybe try also design the work-flow model, i.e. how Mirek will remain the master of U++, yet other contributors will submit patches with GIT to him. So once he will want to try it out, he can read some ideas how it should work in U++ community. (because GIT allows many ways of cooperation)
What's puzzling *me* as non-user of git is the "pull". I understand anyone can clone repo, do his changes, prepare public commit (patch) and tell maintainer of project it's really great improvement and he should adopt it. Then comes the "pull" by maintainer from the contributor's repo? So everyone's personal repository has to be on public IP? (I find this unlikely with current U++ contributors)
I know this can be worked around by submitting patches for example trough e-mail, or by letting contributor to instead push into central repo, I'm just asking if I understand this part correctly. I think for really democratic/decentralized development (I'm NOT saying the U++ needs this, I think current way works quite ok right now, maybe in future we will need change, but not yet?) everyone should have his own repo and basically Mirek as site owner will use very likely his own repo to create official distribution, so if he does like something from somebody else, he will pull it and add to official U++. I wonder how well that works in current age of IPv4 and NATs. Maybe I misunderstood something important about DVCS/GIT?
|
|
|
Re: GIT essentials [message #24347 is a reply to message #24345] |
Mon, 11 January 2010 17:59   |
andrei_natanael
Messages: 262 Registered: January 2009
|
Experienced Member |
|
|
mr_ped wrote | Well, the problem is that cloning(branching) with GIT is cheap, while with SVN it will take those 5+min. That's not good.
|
Actually branching in git takes almost not time.
real 0m0.044s
user 0m0.000s
sys 0m0.010s
Cloning the main repository takes 1 minute and equivalent of clone is checkout in svn I guess(in git checkout is a different operation).
mr_ped wrote |
Also I think if you are proposing this, you should maybe try also design the work-flow model, i.e. how Mirek will remain the master of U++, yet other contributors will submit patches with GIT to him. So once he will want to try it out, he can read some ideas how it should work in U++ community. (because GIT allows many ways of cooperation)
|
Mirek will remain the master of U++. We may follow Linus work-flow, Mirek as dictator and perhaps if U++ will grow more other persons as lieutenants. Right now Mirek being single person who will decide what goes in repo is the right choice.
mr_ped wrote |
What's puzzling *me* as non-user of git is the "pull". I understand anyone can clone repo, do his changes, prepare public commit (patch) and tell maintainer of project it's really great improvement and he should adopt it. Then comes the "pull" by maintainer from the contributor's repo? So everyone's personal repository has to be on public IP? (I find this unlikely with current U++ contributors)
I know this can be worked around by submitting patches for example trough e-mail, or by letting contributor to instead push into central repo, I'm just asking if I understand this part correctly. [...] Maybe I misunderstood something important about DVCS/GIT?
|
You shouldn't have a public IP, for that exists sites like gitorious, googlecode, sourceforge. If someone wants to let Mirek see his changes he will push changes to his own repo from one of those sites and send to Mirek a link to it.
Perhaps if we take a realistic situation it will be more easier to understand that. I have a clone of U++ at gitorious, and also a local clone of if. If i will make changes to local clone and merge changes with the master branch from gitorious my repo will diverge from current U++ repo (supposing it's using git). Now i may send to Mirek a link to my repo, he will clone it (or only clone last revision) and if he like it he will merge mine repo with U++ main repo. I don't have to tell to anyone my IP (my IP is dynamic anyway and telling one will have no effect next time because it may get changed). No need to use a central repo, no emailed patches.
I don't understand yet very well git but as i understand now it makes more sense to me to use it than using svn. If I'll make changes to Chameleon with git i have to do simple operations:
git branch cham-changes
git checkout cham-changes
// change the code
git commit -a
git checkout master
// if i'm glad with changes
git merge cham-changes
git commit -a
git branch -d cham-changes
// if i'm not pleased with changes
git branch -D cham-changes
With svn i'll have to change the files... if i dislike the changes... revert them... in the meantime i cannot work on something else because the repo is blocked by my changes to Chameleon. To solve this i have to use branches in svn too, it take time and i don't know how hard is to merge them... perhaps someone with merging experience will tell me. In git merging is so simple .
|
|
|
Re: GIT essentials [message #24352 is a reply to message #24347] |
Tue, 12 January 2010 06:07   |
Novo
Messages: 1430 Registered: December 2006
|
Ultimate Contributor |
|
|
Just my two cents.
A couple years ago I had the same problem: my CVS server broke down and I lost one year history. Fortunately, I had backups from previous years.
After a short research I chose "monotone".
Cons:
1) It is just one executable (plus a couple of dlls). You don't really need to install it.
2) It is quite powerful. Actually, GIT borrowed a lot of ideas from monothone.
3) It is easy to use. Monotone has not that big set of commands.
4) Repository and workspace can be located in different places. (You can have different workplaces for the same branch. Actually, I'm using this for a different purpose.)
Pros:
1) No usable GUI. Nothing similar to TortoiseSVN or TortoiseGIT.
2) Not very popular. Actually, the same can be told about U++. Though, that doesn't make it bad.
The only thing I'm missing about monotone is GUI, which can be easily developed using U++, because monotone stores repository in SQLITE database. 
A week ago I tried to migrate from monotone to GIT because of lack of GUI. That didn't happen because I couldn't resolve several work-flow issues.
1) GIT keeps repository and workspace in the same directory. In order to checkout another branch you need to clone repository. Basically, this means that you cannot store several projects in one repository. This is not a problem with monotone. In my case "branch" is often equal to "project".
2) U++ is a set of "packages". When I create a new project I want to assemble it from several "packages". This is possible with GIT, but in this case each package should be represented as a separate GIT repository. This seems to be way too complicated.
I'd like to get more feedback about work-flows with distributed VCS from you guys.
TIA
Regards,
Novo
|
|
|
|
Re: GIT essentials [message #24359 is a reply to message #24352] |
Tue, 12 January 2010 10:58   |
andrei_natanael
Messages: 262 Registered: January 2009
|
Experienced Member |
|
|
Novo wrote on Tue, 12 January 2010 07:07 |
After a short research I chose "monotone".
Pros:
1) It is just one executable (plus a couple of dlls). You don't really need to install it.
2) It is quite powerful. Actually, GIT borrowed a lot of ideas from monothone.
3) It is easy to use. Monotone has not that big set of commands.
4) Repository and workspace can be located in different places. (You can have different workplaces for the same branch. Actually, I'm using this for a different purpose.)
|
I like your writing mistake about pros and cons, IMO your pros are cons .
1) How extensible is it? If we want to create a hook for some operation or replace one part with our i.e. diff?
2) ... (the counterparts are too) ...
3) Easy to use not always means less commands, monotone stay in my way because it's doing simple things complicated. I've tried once to help pidgin development and implement some features which i needed but I've hit monotone wall and I quited. A scm should not stay in your way, it should be expressive enough not to impose limits but not too expressive to let you doing same thing in thousand different ways.
4) IMO it just complicate my life
Novo wrote |
The only thing I'm missing about monotone is GUI, which can be easily developed using U++, because monotone stores repository in SQLITE database. 
|
While others want a GUI on top of scm tool I want it to be integrated with my tools. I.e. I create project in theIDE (or other ide), i'm adding new source files, do some codding, then i initialize a repository (from theIDE) and do initial commit. Supposing that i have a working program and want to test new stuff. I'm creating a branch (from theIDE AnySCM->NewBranch), theIDE reloads all opened files and these contain data from new branch, note that i've not changed project location, so the branch reside in same directory and i may switch to other branch if i want and that's cool because i don't have to create a different package in theIDE just to try new things (i'm reusing the same interface, just switching from one branch to another). I'm doing some modification to this branch, i'm testing changes and if it's ok i'm merging it in master branch (AnySCM->Merge<branch-name>).
IMO that's a nice way to get stuff done.
Novo wrote |
1) GIT keeps repository and workspace in the same directory. In order to checkout another branch you need to clone repository. Basically, this means that you cannot store several projects in one repository. This is not a problem with monotone. In my case "branch" is often equal to "project".
2) U++ is a set of "packages". When I create a new project I want to assemble it from several "packages". This is possible with GIT, but in this case each package should be represented as a separate GIT repository. This seems to be way too complicated.
I'd like to get more feedback about work-flows with distributed VCS from you guys.
|
1) I think you don't have to clone the repo to checkout another branch. You do the checkout and reuse the same space and if you want to switch to master branch just checkout it.
~$ git branch
master *
your-cool-branch
~$ git checkout your-cool-branch
# now where your project is, you have your-cool-branch source code in place
# working...
~$ git commit -a
~$ git checkout master
# yay, we are on master branch on the same location
# and i think that's cool
2) Not every package should be a separate repository, i would make assembly(nest?) a repository, perhaps only for MyApps i wouldn't do that because packages from it may not be related one to other.
Just my 2 cents.
I think we should consider others dvcs for scm but IMO the leading scm which will be used for a long time from now will be git, hg and bzr.
Git - surfer from code fragmentation(shell code, perl, python, C, tcl, etc.), making it a bit unportable.
Bzr - a bit slow, it's written in python but cross-platform is achieved.
Hg - i don't have an opinion, i've used it only once (tried the tutorial) so no real life experience with it.
|
|
|
Re: GIT essentials [message #24360 is a reply to message #24355] |
Tue, 12 January 2010 11:36   |
 |
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
the basic question is indeed, as somone above mentioned: does it matter to migrate *right now*? the workflow seems to be alright for now, but could significantly change in future.
it s really the question of workflow models, so far nobody can imagine a truely practicable solution. maybe it's due to the fact that git *is* different from svn, it stores repo/history locally and completely (if you clone, or partially if you pull). as far as everyone can pull from anyother, there is a different user handling model.
now, as far as i understand, there is almost the dictator/leutnant model, using svn. mirek beeing master commiter, having some trusties, who also have commit rights, but use them with care (paying head and pants to mirek if things go wrong ), so this is bit of security issue. people contributing and lacking commit rights do this by supplying test projects in forum, or like me most times, just some lines in plain text with the file:line pattern so mirek needs to sit down, search the file, *think*, change the line and commit. he is actually a busy master/dictator.
with git this could go just as before, but somehow ease it for mirek. he could have his own git repo, the "MAIN" repo, creating releases from, often times refered as the "blessed repository", publically readable, but commit rights only for mirek.
his leutnants, just as the rest of the world, keep synced with the blesses repo, always pulling from it (as the origin repo, in git terms).
the leutnants are just helpers in u++ case, and either have an own and somehow accessable repo for mirek, where *he* can pull from in his branches, and then he can merge. or it would be easier for now, if they also had comit rights to the blessed repo as well, so this would be just the same situation as before with svn.
he would mainly benefit from the easyness of branch merging with git.
when we expect u++ users to supply patches, just as in kernel issues, this would be too much. they are not that experienced, and neither that engaged with u++ . so even the workflow with forum bugfix posting and contributions would go on for quite a while just the same, as long as we dont provide some better means for contributions, i.e. a howto setup own public git repo, where a engaged contributer can commit his changes and mirek pull from.
so its mainly a ideologic dessision for now, it *would* have some benefits, but they are not that extraweighted as to justify a migration to git. i personally would still prefer git, for even more but presently for u++ unimportant reasons. maybe just one still to mention: it seems not to be that much fixed in structure, is really flexible, where every developper is responsable for itself. this is not the case with svn, where 'anyone' can pollute the repo.
attached is a one popular model of how things are drive, bold arrows is commit, other is pull. all are repos, either private on working machine or public on github or gitorious.
if we really want mirekt to be convinced, we need to more clearly elaborate a better workflow model, though. so far, he'd understandably not see the need to migrate.
-
Attachment: gitmodel.JPG
(Size: 33.29KB, Downloaded 381 times)
|
|
|
|
Re: GIT essentials [message #24371 is a reply to message #24364] |
Wed, 13 January 2010 05:36   |
Novo
Messages: 1430 Registered: December 2006
|
Ultimate Contributor |
|
|
Didier wrote on Tue, 12 January 2010 15:28 | Currently I use an HG repository for the UPP code.
I update it directly from the UPP SVN
repository by using the hgpullsvn utility.
The pending hgpushsvn utility also exists.
So I use HG locally while the repo is still under SVN.
This approach could be a good test before deciding SCM A or B
|
I completely agree with this. GIT can be easily synchronized with SVN. If your favorite DVCS doesn't have native synchronization support, then you can use Tailor (http://progetti.arstecnica.it/tailor).
Regards,
Novo
|
|
|
|
Re: GIT essentials [message #24373 is a reply to message #24359] |
Wed, 13 January 2010 06:40   |
Novo
Messages: 1430 Registered: December 2006
|
Ultimate Contributor |
|
|
andrei_natanael wrote on Tue, 12 January 2010 04:58 |
Novo wrote on Tue, 12 January 2010 07:07 |
After a short research I chose "monotone".
Pros:
1) It is just one executable (plus a couple of dlls). You don't really need to install it.
2) It is quite powerful. Actually, GIT borrowed a lot of ideas from monothone.
3) It is easy to use. Monotone has not that big set of commands.
4) Repository and workspace can be located in different places. (You can have different workplaces for the same branch. Actually, I'm using this for a different purpose.)
|
I like your writing mistake about pros and cons, IMO your pros are cons .
1) How extensible is it? If we want to create a hook for some operation or replace one part with our i.e. diff?
2) ... (the counterparts are too) ...
3) Easy to use not always means less commands, monotone stay in my way because it's doing simple things complicated. I've tried once to help pidgin development and implement some features which i needed but I've hit monotone wall and I quited. A scm should not stay in your way, it should be expressive enough not to impose limits but not too expressive to let you doing same thing in thousand different ways.
4) IMO it just complicate my life
|
1) Monotone uses Lua for scripting. It allows you to create hooks. Though, I haven't tried to do that myself.
2) I just wanted to say that they are similar. 
3) Could you, please, describe the problem in more details? I'm trying to learn different workflows.
4) You need to synchronize your repository only once in this case. May be I'm wrong, but if my project is build from a dozen of independent submodules, and I want to update the code, then I need to update all these repositories manually (or to develop a script).
Quote: |
Novo wrote |
The only thing I'm missing about monotone is GUI, which can be easily developed using U++, because monotone stores repository in SQLITE database. 
|
While others want a GUI on top of scm tool I want it to be integrated with my tools. I.e. I create project in theIDE (or other ide), i'm adding new source files, do some codding, then i initialize a repository (from theIDE) and do initial commit. Supposing that i have a working program and want to test new stuff. I'm creating a branch (from theIDE AnySCM->NewBranch), theIDE reloads all opened files and these contain data from new branch, note that i've not changed project location, so the branch reside in same directory and i may switch to other branch if i want and that's cool because i don't have to create a different package in theIDE just to try new things (i'm reusing the same interface, just switching from one branch to another). I'm doing some modification to this branch, i'm testing changes and if it's ok i'm merging it in master branch (AnySCM->Merge<branch-name>).
IMO that's a nice way to get stuff done.
|
IMHO all VCS can be integrated with TheIDE. IMHO all DVCS let you use the same directory to checkout different branches. Not all DVCS let you checkout into multiple places. And DVCS's do not let you do partial checkout. You get all or nothing.
I personally need GUI to be able to browse big logs, and to be able easily compare different versions of a file. It is hard for me to type long SHA1 keys. I'm not using mouse. 
Quote: |
Novo wrote |
1) GIT keeps repository and workspace in the same directory. In order to checkout another branch you need to clone repository. Basically, this means that you cannot store several projects in one repository. This is not a problem with monotone. In my case "branch" is often equal to "project".
2) U++ is a set of "packages". When I create a new project I want to assemble it from several "packages". This is possible with GIT, but in this case each package should be represented as a separate GIT repository. This seems to be way too complicated.
I'd like to get more feedback about work-flows with distributed VCS from you guys.
|
1) I think you don't have to clone the repo to checkout another branch. You do the checkout and reuse the same space and if you want to switch to master branch just checkout it.
~$ git branch
master *
your-cool-branch
~$ git checkout your-cool-branch
# now where your project is, you have your-cool-branch source code in place
# working...
~$ git commit -a
~$ git checkout master
# yay, we are on master branch on the same location
# and i think that's cool
2) Not every package should be a separate repository, i would make assembly(nest?) a repository, perhaps only for MyApps i wouldn't do that because packages from it may not be related one to other.
Just my 2 cents.
|
1) Yes, GIT is designed to use only one directory and work with only one project. It is a fixed workflow. Actually, the way you use GIT in your example is not exactly a GIT way. You completely bypass Index. Index is a nice feature to get rid of temporary branches.
2) I personally have ~30 packages in my MyApps. I do not want to checkout this mess all the time. I want to checkout a project and get only necessary packages. And when I update my project, I want these packages get updated. But in case when I use an external code, I do not want it to be updated all the time. I want to "rebase" it manually.
Probably, I want too much. 
This all is about workflows.
I personally trying to figure out which DVCS i need to use (and how to use it) in case of complicated code structure, many projects, many external projects, many versions of same code, plus U++, plus e.t.c.
All your suggestions are welcome. I appreciate your feedback.
Regards,
Novo
[Updated on: Wed, 13 January 2010 06:52] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Tue Apr 29 09:27:08 CEST 2025
Total time taken to generate the page: 0.01382 seconds
|
|
|