This is exactly the class of problem that version control is designed for. Far better programmers than anyone in this thread have worked for decades to develop the version control concept. Give it a try, and you’ll be kicking yourself for not having done it years ago. Git automates 99% of the work of tracking and merging different codepaths. (Mainly excepting the case where both of you make functional changes to the same line. It will ask you what to do there; if it guessed it might break stuff badly.)
Here, this is copy-pasted from that link I posted earlier:
[spoiler]
Have you ever:
Made a change to code, realised it was a mistake and wanted to go back?
Lost code or had a backup that was too old?
Had to maintain multiple versions of a product?
Wanted to see the difference between two (or more) versions of your code?
Wanted to prove that a particular change broke or fixed some piece of code?
Wanted to submit a change (patch) to someone else's code?
Wanted to see how much work is being done (where/when/who)?
Wanted to experiment with a new feature without interfering with working code?
In all these cases a version control systems should make your life easier.
and
Even if you work alone you can benefit from source control. Among others, for these reasons:
You don't lose anything. I never again commented out code. I simply delete it. It doesn't clutter my screen, and it isn't lost. I can recover it by checking out an old commit.
You can experiment at will. If it doesn't solve the problem, revert it.
You can look at previous versions of the code to find out when and where bugs were introduced. git bisect is great in that regard.
More "advanced" features like branching and merging let you have multiple parallel lines of development. You can work in two simultaneous features without interference and switch back and forth without much hassle.
You can see "what changed". This may sound basic, but that's something I find myself checking a lot. I very often begin my one-man workflow with: what did I do yesterday?
Just go ahead and try it. Start slowly with basic features and learn others as you go. You will soon find that you won’t ever want to go back to “the dark ages” of no VCS.
[/spoiler]
Can you give me some example of how is formatting preventing you to do anything? How does it matter, exactly?
Okay, I don’t really have time to type up a lecture on coding with a team; as you can probably guess I don’t get to the forums enough as is. But let’s go over a couple basic things.
Reformatting doesn’t matter to the compiler, but human beings are not compilers, they deal with source code as text so VC systems do too. In addition, version control covers things like comments, changelogs, documentation, all things in the text that the compiler ignores, but are vitally important to the people doing the coding.
The basic unit of all this is the patch (called a commit once you enter it in git) which looks like this. The patch is basically a listing of the changes that have been made to a text file, usually source code. Here’s an old patch I hacked up way back in the Whales days.
*** mapgen.cpp~ 2011-01-05 21:11:01.000000000 -0800
— mapgen.cpp 2011-01-07 15:25:32.000000000 -0800
*** 3024,3030 ****
ter(i, j) = t_rock_floor;
}
}
! switch (rng(1, 3)) { // TODO: More types!
case 1: // Weapons cache
for (int i = 2; i < SEEX * 2 - 2; i++) {
ter(i, 1) = t_rack;
— 3024,3030 ----
ter(i, j) = t_rock_floor;
}
}
! switch (rng(1, 4)) { // TODO: More types!
case 1: // Weapons cache
for (int i = 2; i < SEEX * 2 - 2; i++) {
ter(i, 1) = t_rack;
*** 3067,3072 ****
— 3067,3085 ----
ter(SEEX - 1, SEEY * 2 - 2) = t_stairs_up;
ter(SEEX , SEEY * 2 - 2) = t_stairs_up;
break;
- case 4: // Handyman’s workshop
- for (int i = 1; i < SEEY + 4; i++) {
-
ter(1 , i) = t_counter;
-
ter(SEEX * 2 - 2, i) = t_counter;
- }
- place_items(mi_hardware, 90, 1, 1, 1, SEEY + 3, false, 0);
- if (one_in(3))
-
place_items(mi_mischw, 90, SEEX*2-2, 1, SEEX*2-2, SEEY + 3, false, 0);
- else
-
place_items(mi_tools, 90, SEEX*2-2, 1, SEEX*2-2, SEEY + 3, false, 0);
- ter(SEEX - 1, SEEY * 2 - 2) = t_stairs_up;
- ter(SEEX , SEEY * 2 - 2) = t_stairs_up;
- break;
}
break;
You can see it contains a bit of context above and below the changes, and lists lines altered with an !, added with a +, and subtracted with a -. A patch like this makes it trivial to read and see just what code is altered in a given change. This makes reviewing code very simple.
Now, if I run it through a reformatter, too, here’s what happens to the patch:
*** mapgen.cpp~ 2013-04-11 14:45:03.000000000 -0700
— mapgen.cpp 2013-04-11 14:47:49.000000000 -0700
*** 11,38 ****
#endif
ter_id grass_or_dirt()
! {
! if (one_in(4))
! return t_grass;
! return t_dirt;
! }
!
! enum room_type {
! room_null,
! room_closet,
! room_lobby,
! room_chemistry,
! room_teleport,
! room_goo,
! room_cloning,
! room_vivisect,
! room_dorm,
! room_living,
! room_bathroom,
! room_kitchen,
! room_bedroom,
! room_split
! };
bool connects_to(oter_id there, int dir_from_here);
void house_room(map *m, room_type type, int x1, int y1, int x2, int y2);
— 11,39 ----
#endif
ter_id grass_or_dirt()
! {
! if (one_in(4))
! return t_grass;
! return t_dirt;
! }
!
! enum room_type
! {
! room_null,
! room_closet,
! room_lobby,
! room_chemistry,
! room_teleport,
! room_goo,
! room_cloning,
! room_vivisect,
! room_dorm,
! room_living,
! room_bathroom,
! room_kitchen,
! room_bedroom,
! room_split
! };
bool connects_to(oter_id there, int dir_from_here);
void house_room(map *m, room_type type, int x1, int y1, int x2, int y2);
*** 45,147 ****
void square(map *m, ter_id type, int x1, int y1, int x2, int y2);
void map::generate(game *g, overmap *om, int x, int y, int turn)
! {
! oter_id terrain_type, t_north, t_east, t_south, t_west, t_above;
! int overx = x / 2;
! int overy = y / 2;
! if (x >= OMAPX * 2 || x < 0 || y >= OMAPY * 2 || y < 0) {
// This happens when we’re at the very edge of the overmap, and are generating
// terrain for the adjacent overmap.
! int sx = 0, sy = 0;
! overx = (x % (OMAPX * 2)) / 2;
! if (x >= OMAPX * 2)
! sx = 1;
! if (x < 0) {
! sx = -1;
! overx = (OMAPX * 2 + x) / 2;
! }
! overy = (y % (OMAPY * 2)) / 2;
! if (y >= OMAPY * 2)
! sy = 1;
! if (y < 0) {
! overy = (OMAPY * 2 + y) / 2;
! sy = -1;
! }
! overmap tmp(g, om->posx + sx, om->posy + sy, om->posz);
! terrain_type = tmp.ter(overx, overy);
! if (om->posz < 0 || om->posz == 9) { // 9 is for tutorial overmap
! overmap tmp2 = overmap(g, om->posx, om->posy, om->posz + 1);
! t_above = tmp2.ter(overx, overy);
! } else
Cut off because it’s freakin’ huge.Virtually every line is changed, now. This is ugly and unreadable, and my small change is lost in the huge mass of reformatting changes. For this reason, etiquette usually says you should keep your code in the style of the main project, even if you don’t like it. The main branch’s style is awful, and there are plans to reformat it to 1tbs style IIRC, but it’s to be done in a piece-by-piece fashion to prevent that kind of big ugly commit from going in all at once.
Actually, I did work for you, and if I had access I would have merge it for you as well. But you want of me to maintain my own git, for some strange reason, when you already have one and can upload it yourself in a matter of seconds.
You still don’t understand what git does for you. You’re making more work for yourself, and more work for others by not learning it. “Maintaining your own git” is actually easy as pie, it just requires a half an hour or so’s time to learn the basics of the tools. I hope for your sake, and the project’s, that you’ll learn how to handle this stuff one of these days.
