Switch from svn to git without redownloading everything?

[Mattn]

just stash them away (a simple script like:)

Code: [Select]

#!/bin/sh
cd /path/to/ufoai
git fetch
git stash save
git upbase
git stash pop


[Mattn]

@duke: about working on single bugs - there is nothing wrong in doing one local branch for each bug. switching branches, merging branches - stuff like that is a lot faster and more advanced compared to svn.

the problem with .cproject and .project is not related to stashing. you would have the same problem when doing svn up - a merge conflict is a merge conflict. we have to think about a solution for these files - but for this we have to get eclipse + mingw working for windows first (which i'm still working on btw)

[H-Hour]

* Unfinished maps that I don`t want to share yet (is not enough quality).

These shouldn't create any problems as long as you haven't comitted them locally. I also have unfinished maps in the directory.

* Some playing with ump (again unfinished).

Yeah, this will cause a problem. You could rename the file to "(mapname)_test.ump" and then add a new .ufo file that points to (mapname)_test, so you have both the trunk and the modified version as options in skirmish.

* normal version of compile_maps.bat (I hate current version of it).

I just renamed mine to compile_maps_old.bat and I run that instead when I need it.

[geever]

> btw. which changes are needed in your local copy but should not get commited? something build related?
* Unfinished maps that I don`t want to share yet (is not enough quality).
* Some playing with ump (again unfinished).
* normal version of compile_maps.bat (I hate current version of it).
* some others tests, playings and so on.

My oppinion is: you should create local branches for these and commit on top of them.

-geever

[dodon]

I have not worked with Git (yet)

But I hope to get rid of all my unversioned files and changes. These things should go into a local branch.

@duke: as Mattn proposed one local branch per bug seems appropriate.

[Duke]

@duke: as Mattn proposed one local branch per bug seems appropriate.

I believe you and Mattn that this is the way to go with GIT.
But isn't that trading stashing for branching ?

My point is that it's *overhead* compared to SVN. I don't want to manage branches, I want to squash bugs.

[keybounce]

What do I do that doesn't get committed?

Debugging builds trying to track down the graphic issues (although I've got a new idea to try to track it down, that goes back to the older stuff in svn)

Modifying the make scripts to make sure that there's a locally compiled map ready when I type "make".

At one point, when I had some files on an external drive for space reasons, I had some symbolic links and needed to modify some "find" commands in the makefiles to include (I think) -L

Sometimes I've had to play around with configure.

Branches

With SVN, I could make a local modification (such as to the Makefiles, or debugging output in the renderer), and then move around from revision to revision, and my changes stay in. So if I'm trying to track something in rendering, I can.

The point is?
It sounds like the only way to play with git is to commit everything that you do.
That sounds like saying that you have to allow anyone that wants to play with the source to commit changes to the development tree.

Unless I'm missing something, that's horrible.

What is supposed to be git's benefit over svn?

[Mattn]

a commit is not going to become part of the development tree on sf.net - you still have to publish it (push it).

you can always stash your local working copy changes besides, checkout the revision you like to have, and pop back your stashed changes into your current working copy (this is btw. nothing git specific, it's the same for mercurial and the like, too)

if you try to nail down a revision that introduced a bug, you should try the git bisect feature.

[Mattn]

one more note maybe. we don't have to allow anything to anyone on the local git repo clone. it's a repository everybody on the world can cherry-pick or clone from again. what we have to allow is the pushing of your commits back into the sf.net repository. you can make as many commits as you like in your local copy, or create as many branches as you like.

[dodon]

But isn't that trading stashing for branching ?

I don't think so.
With stashing all your changes are in one place, you risk publishing unfinished code and one bugfix affecting an other one.
With branching you separate the changes for each task, with regular commits to the branche you reduce the risk of loosing your codechanges with awrong delete, edit or merge, you can use all the tools git provides for the code you develop (changehistory, bisect, ...) and you can even "ignore" the changes in the masterbranch (but if you wait to long mergin the changes back will be painful)

My point is that it's *overhead* compared to SVN. I don't want to manage branches, I want to squash bugs.

Yes it is overhead. All I can do is to urge you to try branching (and if it does not work for you at the moment to try it again, when you are comfortable with git) and then decide if it's worth it.

[dodon]

The point is?
It sounds like the only way to play with git is to commit everything that you do.
That sounds like saying that you have to allow anyone that wants to play with the source to commit changes to the development tree.

Unless I'm missing something, that's horrible.

Well SVN is a VCS and Git is a DVCS (distributed version control system)
As Mattn pointed out, the commits are on your mashine. Unles you push them to an other repository or someone fetches/pulls them from you, nobody else is affectet.
 

What is supposed to be git's benefit over svn?

The "distributed" part in DVCS gives the administrators of the repository additional freedom to tailor the way the repository works to the development process. That won't matter for you but it can relieve the main developers of a lot of work.

An other benefit that depends on the circumstances you work in is, that you have (a part of) the repository on your mashine and you don't have to be connected to the server to work with the repository. (view code, change branches ...)

And you can commit your changes to the local repository and use all the tools git provides for your code development.

Actualy the last one is the important one for me. And if you don't know the tools git provides for you should start to explore your new posibillities

[Thrashard96]

@muton and everyone: can i get a newest make_ufoai_win32.exe? My old hdd lost the file.

[Muton]

What for?
Its broken!

but .... make_UfoAI_win32.exe

[Thrashard96]

how did it break?

[Borsti67]

it doesn't support GIT (yet? )