Yes i don't care to much about the disk space But if i make a commit in to 1.4 that also want to merge over 1.5 and trunk
What is then the nicest way? Because must i then do a commit the local on 1.4 push that to the remote then go to 1.5 and pull it, then merge the 1.4 changes to 1.5, commit that (this could be slightly different because of some changes) push that again to remote, and then do that for trunk/master/1.6 all over again? Of course this can all be different i am just starting to look at git, so i maybe don't see all the different handles.. But the above approach is quite a bit harder and way more steps (at least it looks that way to me now) then what i would do with svn.. (using the merge client shipped with subclipse) On Wed, Jan 4, 2012 at 16:40, Martijn Dashorst <martijn.dasho...@gmail.com>wrote: > On Wed, Jan 4, 2012 at 4:25 PM, Johan Compagner <jcompag...@gmail.com> > wrote: > > Currently i just have 3 workspaces for wicket (1.4,1,5 and trunk/master) > > > > But git works with a/one working directory... > > > > thats always one of those.. > > > > So is the only solution to have the remote git repo dumped three times on > > my disk? > > I don't find that very logical.. > > It is logical: it is no different than having 3 checkouts of SVN > living on your hard disk. > > A git checkout with full history is probably the size of O(1) of a SVN > checkout (especially for SVN < 1.7). You can still use your normal > flow just as you'd do with SVN. > > If you don't like having to wait for the full checkout coming from the > apache server, you can easily just clone locally, and set the remote > afterwards. > > You don't have to use the one folder for all branches paradigm, but > you can. Or I can, or Igor can, or Emond can. With git we have a > choice ourselves. WIth SVN not so. > > Martijn >
