I just don't 'Git' it at all

[Unkle Nuke]

After spending many hours reading and experimenting with the Git Bash, I'm reaching the end of my patience.

So far, I've managed to download and then toss out about 2 GB of attempts but this whole Git thing is still about as clear as mud.

I've tried clone, branch, fetch, remote, and most of the other Git alphabet soup but nothing seems to work as anticipated. Is there such a difference between Windows and Linux that Git is unable to operate without downloading the same files over and over to each local repository or branch in Windows?

So how, exactly, step-by-step, does one set up a repo with many branches that will not eat up my hard drive?

I'm working from the 0.12 branch as my master. I used

git remote add origin git://github.com/mangos/mangos.git -t mangos-0.12 mangos0.12.243 

to create a repository in my local 'mangos-0.12.243 folder'.

Now here's where it gets dicey for me...adding branches for later merging or patching of the master branch.

• * I'd like to add a 'working' branch folder, with a copy of the mangos-0.12 master in it, for merges or manually adding patches so I can keep my master clean.
  * Have branches or folders with patch branches from various forks, like AH Bot, Alterac Valley, Anticheat, and others that can be merged into 'working' or generate patches that can later be added to 'working' with "git apply" but still leave those branches intact for later updating.
  

"git clone" doesn't seem to be the answer as I'm only interested in the branches that concern patches for mangos-0.12. Would I instead manually create a branch using "git branch [branch name]" and then use "git remote add [branchname] [remote url] -t [remote branch] [local branch]" as I did when pulling 0.12 as master? Would I then use 'git pull' or should 'git fetch' be my choice for updating?

I'm beginning to believe I either need to be a masochist or that Git was made for the understanding of only die-hard Linux geeks that eat compiler code and crap out bash scripts.

[Patman128]

git is actually one of the easier things I've come across. It's not really hard at all once you get the hang of it.

For getting mangos, just use the git clone command:

git clone git://github.com/mangos/mangos.git mangos-0.12

Or, you can cd into the directory you want to use and use init and pull instead:

git init
git pull git://github.com/mangos/mangos.git mangos-0.12

Once you actually have a git repository, you can then add your remotes, like your other command:

git remote add origin git://github.com/mangos/mangos.git mangos-0.12

This means that you can substitute "origin" for "git://github.com/mangos/mangos.git mangos-0.12" when pulling changes. To pull the latest changes from mangos:

git pull origin

Now, to make a working branch, simply use branch and checkout:

git branch work
git checkout work

This creates and switches to your new working branch. Now, let's say your system goes something like (pull new changes from mangos to master)-->(merge changes into work)-->(switch back to work) you could just use something like:

git checkout master
git pull origin
git checkout work
git merge master

And then your master and work would be up to date.

And that's some basic git commands. Any more questions?

[Unkle Nuke]

Thank you for simplifying things a bit, Patman!

The Git Manual can be a bit esoteric in its descriptions of the arguments and flags used with the commands. In fact, I'll probably never fully understand what is meant by <refspec> as it is explained in the Help regarding fetch. :unsure:

You have my gratitude for providing working examples. It helps to actually see these commands used in context. Clearly, your Git-fu is stronger than mine!

Regarding the establishing the master repo and the clone command, wouldn't I instead use

git clone git://github.com/mangos/mangos.git -o mangos-0.12 [local dir]

to pull and track only the 0.12 branch as the origin?

Allow me to digest and try this out. I'll probably have more questions and I appreciate your courtesy.

I know Git is very powerful for collaborative projects like MaNGOS, with the ability for literally everyone to contribute improvements, no matter how small. It's just been too many years since I've even looked at an sh shell of any kind and CLI has become a foreign word. The dark side (Windows) has become strong within me. <insert heavy Darth Vader breathing here>

[DasBlub]

i personally do clone the whole repo and then just checkout the mangos-0.12 branch (then i have my local master pointing to the remote master, my local mangos-0.12 to the remote mangos-0.12).

that would look like this:

git clone git://github.com/mangos/mangos.git # clone the mangos repo
cd mangos # go into the new folder
git checkout -b mangos-0.12 origin/mangos-0.12 #checkout mangos-0.12 in it's own local branch

if you want to have only mangos-0.12 in your local master branch:

mkdir mangos # create the folder for the repo
cd mangos # go into it
git init # initialize a new git repo
git remote add origin git://github.com/mangos/mangos.git # add the mangos repo as origin
git fetch origin # download the whole repo (this gets all data from the repo, starting from this moment you don't need your internet anymore, expect if you want to get newer commits). this does NOT copy the repo into your local repo (it's not a merge, only a fetch)
git pull origin mangos-0.12 # pull now the whole mangos-0.12 branch into the local master branch.

(all after # is a comment, you don't have to copy this out)

hope that helps.

PS: all commands just written out of my head... might be that there's a typo somewhere

[Unkle Nuke]

Thank you for also adding your knowledge for my benefit. I'll try to repay the kindness by passing on what I've learned.

Time to break out the Git Bash and have another crack at this. I've got several forks from which to pull branches, at least a few of them from your own repo, DasBlub.

[Alexstrasza]

alternatively there is a "download snapshot" thing at github web

[Unkle Nuke]

I had thought of that alternate means but it seemed a bit more laborious to manage each download, generate each patch, and then applying those patches. That's why I liked TortoiseSVN so much in the past. It made creating and applying patches so much easier.

I believe I have succeeded in creating my master repository, along with a working branch and patches branch for mangos-0.12.

First, I created a folder named mangos-2.0.12 then used the following commands:

 git init
git remote add -t mangos-0.12 origin git://github.com/mangos/mangos.git 
git pull origin
git branch working 
git checkout working
git merge master (only did this to verify that 'working' and 'master were already in sync)
git checkout master
git branch patched-0.12 (for later saving the merged patches+master from 'working' for compiling and to keep my working dir clean)

And that's as far as I've gotten. I seem to have hit a snag with the patch branches. For example, I tried to create a branch for balrok's fork branch of the Alterac Valley patch for v0.12 and then generate a patch to verify its contents:

git checkout -b alterac
git remote add -t alterac-0.12 alterac git://github.com/balrok/mangos.git
git fetch alterac

(got this response next)

$ git fetch alterac
remote: error: object directory /data/git/repositories/4/cc/9d/62/mangos/mangos.
git/objects does not exist; check .git/objects/info/alternates.
remote: Counting objects: 590, done.
remote: Compressing objects: 100% (212/212), done.
remote: Total 418 (delta 348), reused 264 (delta 206)
Receiving objects: 100% (418/418), 170.45 KiB, done.
Resolving deltas: 100% (348/348), completed with 59 local objects.
From git://github.com/balrok/mangos
* [new branch]      alterac-0.12 -> alterac/alterac-0.12

(ok..so far so good..I think)

git diff master alterac>alterac.patch

Now that's where the trouble starts. A patch of 0 kb is generated every time I try this. Am I supposed to use "git pull alterac" before creating the patch? Doesn't "pull" do a fetch+merge of the alterac branch with my master, even though I'm executing the pull from the alterac branch? I wanted to keep my master clean and use 'working' for merges.

Would I be better off creating a folder for each branch and then using "remote add -t..." in each folder to create my branch repositories?

[freghar]

Okay, as I see from the things below, you did some search, read some manpages and that kind of stuff. Let me see what I can do for you.

I had thought of that alternate means but it seemed a bit more laborious to manage each download, generate each patch, and then applying those patches. That's why I liked TortoiseSVN so much in the past. It made creating and applying patches so much easier.

It's in fact a lot easier to actually keep patches in commits. Say I have 10 patches, each in separate commit. When I want to update the sources, I simply rebase. All patches will be re-applied on the top of the new tree. If some of them fails to apply, you can fix the conflict and --continue, saving the resolved state. You can also --skip the patch or completely --abort the rebase, going back to the last stable state. It's also easily possible to move the commits (their "apply order"), add one between some other two, split a commit or melt several into one. Search for interactive rebase if you're interested.

I believe I have succeeded in creating my master repository, along with a working branch and patches branch for mangos-0.12.

Indeed you did. But it's not perfect, plain "git pull" won't work, because the local master branch (which is a reflection of remote mangos-0.12 branch) wasn't set to actually track origin/mangos-0.12.

So it should be:

git init

git remote add -f -t mangos-0.12 origin git://github.com/mangos/mangos.git

git branch master --track origin/mangos-0.12

git checkout master

Creating another branch for your custom work is also useless. We just created your local "master". Any modifications to it will only affect your repository on your hard drive. Nothing more. (unless you push)

To verify it, you can run

git log --pretty=oneline -1 master
git log --pretty=oneline -1 origin/mangos-0.12

If both hashes are the same, you have an exact "copy".

And that's as far as I've gotten. I seem to have hit a snag with the patch branches. For example, I tried to create a branch for balrok's fork branch of the Alterac Valley patch for v0.12 and then generate a patch to verify its contents:

git checkout -b alterac
git remote add -t alterac-0.12 alterac git://github.com/balrok/mangos.git
git fetch alterac
...

I think you're missing a point here. checkout -b created a new local branch named "alterac", a copy of the master. Then git-remote added "alterac" remote (which isn't branch, it's an .. alias for certain remote path/URI), tracking only alterac-0.12 remote branch.

Now this needs some explanation. Tracking in git-remote's meaning is "download only this refspec (= reference specification = branch,tag,hash,etc.) when a fetch-like command is issued. Nothing more. Tracking in git-branch's meaning is to allow "git pull" without specifying a source from where to pull. It's stored in .git/config.

If you read the manpage of git-remote, you might know that remote -t allows you to track more than one branch. That's what remotes are for. Say I want all branches from repository called "moron" (which is my local alias for it) with public URI of git://github.com/NoFantasy/mangos.git:

git remote add moron git://github.com/NoFantasy/mangos.git
git fetch moron

Now git-branch -a should display something like:

* master
 remotes/moron/alpha
 remotes/moron/beta
 remotes/moron/gamma
 remotes/moron/whatever

All those branches were downloaded and stored as "remote branches". See, there's a lot of redundancy in the git world. They, however, shall take only a few bytes if there aren't any massive differencies between them as git uses deltas whenever possible.

If you want only alpha and gamma branches (since you care about those few bytes, because it's about 6MB with mangos/master<-->mangos/mangos-0.12), you can use

git remote add -t alpha -t gamma moron git://github.com/NoFantasy/mangos.git

I don't know how to add/delete branches from this list using git-remote, I simply use text editor and .git/config. There are fetch lines in "moron" remote section, cleverly using the "what to fetch" mechanism (for example, you would use refs/*:refs/* for a mirror).

Okay, back on topic.

git diff master alterac>alterac.patch

From what I've said above, you should now see the error. git-remote isn't git-branch

Local branches can be specified using just their name (when there's nothing using that name), remote branches needs to be prefixed with a remote name they're stored under.

My local master branch can be specified as "master", "heads/master", "refs/heads/master". You can have a tag with "master" name, which makes you unable to use "master", so at least "heads/master" and "tags/master" is needed. All names mentioned here (like refs, heads, remotes, tags, ..) have their directory representation in .git/ directory. It's quite interesting to see the structure, list through it if interested.

Now that's where the trouble starts.

And where my post ends.

Oh, and ...

Doesn't "pull" do a fetch+merge of the alterac branch with my master, even though I'm executing the pull from the alterac branch? I wanted to keep my master clean and use 'working' for merges.

One branch with several patches stacked up is good for your own (and simple) patches. When you're applying someone else's complicated patch, it's best to pull (or fetch+merge). It shall connect both trees and create a merge commit.

To update the sources, you have to, however, hard-reset your master to a completely clean state (= latest upstream head, ... simply the commit you want to update to) and then re-pull everything. During the time your repository did nothing, others might have produced a better code in their remote branches, updated it to newer releases and such kinds of things. Note that git again downloads only differencies, things changed since your last pull.

I personally have my branch with stacked-up patches which I keep rebased, several branches with bigger things that need multicommit changes and a master branch. When I want to update, I hard reset my master to something like origin/master (that's why you don't have to keep local master clean all the time) and then merge all my branches to master. It's actually an octupus merge of (right now) 8 trees, but that shouldn't bother you.

Note that you can use several git-pull calls without any relation to hard reset. You have to be an upstream maintaiiner, though.

Would I be better off creating a folder for each branch and then using "remote add -t..." in each folder to create my branch repositories?

You can, as said before, have several branches in one remote and several remotes in one repository. Having separate repositories would greatly increase your disk space usage (and bandwidth), since several repositories can't easily share objects between remotes and branches.

Ugh, that was a long post.

[Unkle Nuke]

It may be a "wall o' text" but you have done a very good thing here, freghar.

Tracking in git-remote's meaning is "download only this refspec (= reference specification = branch,tag,hash,etc.) when a fetch-like command is issued.

It might have been incidental in your discourse yet that mention of how refspec is defined, in more practical terms, finally shed a light on that dark spot in my understanding.

The rest is quite a bit to digest but I'll sit down this evening with a hard-copy and the Git Manual to resume my efforts and, hopefully, finally get a handle on this. Sometimes it takes a while before the tumblers in the lock click into place. That's just how my brain works.

I appreciate your taking time out of your day to help, freghar. Thank you!

P.S. I did find out that balrok's repo had no refspec for tracking the alterac-0.12 patch so it requires a few extra steps.

Addendum:

Ok, I tried out your advice, freghar. The commands you outlined work well for branches but do not work for tracking mangos-0.12 as master. When trying the following:

 git init
git remote add -f -t mangos-0.12 origin git://github.com/mangos/mangos.git

...leaves me with an empty repository, after trying a pull or merge. The data is stored in the index but there are no corresponding files or folders in the repository.

Also, using "git branch master --track origin/mangos-0.12" returns the error "Cannot use branch. Master already exists." or something to that effect.

In further reading of the Git man pages, it does seem that "git remote add" used with the -t flag does establish tracking of the specified branch.

With -t <branch> option, instead of the default glob refspec for the remote to track all branches under $GIT_DIR/remotes/<name>/, a refspec to track only <branch> is created. You can give more than one -t <branch> to track multiple branches without grabbing all branches.

At least that's the way it reads to me.

So I tried the folowing:

git init
git remote add -t mangos-0.12 origin git://github.com/mangos/mangos.git
git pull
(then I got the following response)
remote: Counting objects: 15949, done.
remote: Compressing objects: 100% (5383/5383), done.
remote: Total 15949 (delta 11431), reused 14787 (delta 10514)
Receiving objects: 100% (15949/15949), 19.29 MiB | 559 KiB/s, done.
Resolving deltas: 100% (11431/11431), done.
From git://github.com/mangos/mangos
* [new branch]      mangos-0.12 -> origin/mangos-0.12
From git://github.com/mangos/mangos
* [new tag]         v0.12      -> v0.12

That does seem to work fine for establishing the master.

Now for branches, I'm still a bit confused about the way refspecs are used.

Taking the above as an example, am I correct in my perception that the 'remote' command is naming mangos-0.12 as 'origin' or, in other words, 'master'? So, using reno's fork of mangos to track the auctionhouse bot 0.12 branch, 0.12-ahbot, I tried the following:

git add remote -t 0.12-ahbot reno git://github.com/reno/mangos-patched.git
git branch ahbot-0.12 --track reno/0.12-ahbot
(Unfortunately, I got the following error)
fatal: Not a valid object name: 'reno/0.12-ahbot'.

From my readings, it seemed I did things right but I'm fairly certain I've somehow managed to mix up the local branch refspec with the remote branch refspec when establishing the <start point>.

In regards to this, I was wondering if it would be better to properly establish the refspec for the local branch by using 'set-head' with an additional 'remote' command? Using reno's repository again would the command look like this?:

git remote set-head reno 0.12-ahbot

This way the remote for my local ahbot-0.12 branch would always point to the remote branch 0.12-ahbot as the HEAD, assuming I'm only interested in that single branch of his fork.

Can such a strategy also work better for establishing only mangos-0.12 as the default HEAD for my local master?If I proceeded in this way to establish and track only mangos-0.12 as my master:

git remote add -t mangos-0.12 origin git://github.com/mangos/mangos.git
git remote set-head origin mangos-0.12

...would this be superior to simply tracking the remote master with only the "-t" flag?

I must apologize for all the questions, and probable ignorant misuse of some terms, but you guys have helped me to understand things in a way that no manual can teach and I am indeed honored that you all have taken the time from your busy days to impart your own wisdom in the use of Git.

[freghar]

Again, a lot of things were mixed together. Sorry, I haven't another two hours to split correctly your post and do proper inline quoting, so bad this isn't a mail.

Thus I'll try to explain things by references.

...leaves me with an empty repository

Wrong. An empty working tree. The working tree is "all the files and folders you can see". It's only a minor part of the repository, all the magic is stored underground in .git/ and the working tree can be created using objects in it, completely offline.

Also, using "git branch master --track origin/mangos-0.12" returns the error "Cannot use branch. Master already exists." or something to that effect.

Yep. Because pull is trying to be smart. That's why I excluded it. Let me explain my version a bit:

* git init - init an empty repository, no branches, no remotes, no master, no origin, nothing

* git remote add -f -t mangos-0.12 origin git://github.com/mangos/mangos.git - add new remote named "origin", track only mangos-0.12 refspec (NO relation to local branches and their tracking, this is just "what to fetch" thing - it also applies to future fetches/pulls .. thus you can't ever download anything else (besides mangos-0.12 refspec) from origin unless you explicitly state so) .. and fetch (-f) from it. I've added the fetch here, so it automatically creates origin/mangos-0.12 remote branch ("remote" means .git/refs/remotes, not that it's stored somewhere else) and thus you don't have to do "git fetch origin" in another step. You can, though. It's an analogy to pull (which is fetch+merge).

* git branch master --track origin/mangos-0.12 - create a new local "master" branch and set up a tracking entry for the origin/mangos-0.12 refspec. You can do something like "git branch woot --track master" and everytime you write "git pull" while being on the "woo" branch, you'll automatically merge your local master. As explained in my previous post, this is the "true" tracking. The git-remote thing is actually a nice hack (which I'll show you in a minute), nothing more.

* git checkout master - checkout the newly created master branch, thus creating all the files and folders you already know. Checkout actually means "throw all files from this refspec to my working tree". The feeling of moving over branches is just feeling and a small asterisk character in git-branch's output (and git-commit's ability to determine where to put a new commit).

Now - what advantage have this way over yours? It sets up a branch tracking entry (the --track). It's useless for me, since I feel more safe when explicitly stating source and destination, but it provides some kind of confort to most people.

Branch tracking looks like this:

[branch "master"]
       remote = origin
       merge = refs/heads/mangos-0.12

It tells the git-pull to automatically fetch "refs/heads/mangos-0.12" refspec from origin whenever is git-pull called without arguments and merge it with your current branch, all this only if your current branch is named master and you're "on" it right now.

An example:

I want to merge my branch with an upstream branch. I've my local branch checkouted (I'm "on" it) and already set up a branch tracking entry, like the one above.

I can:

git fetch origin refs/heads/mangos-0.12
git merge origin/mangos-0.12

OR simply

git pull

As you can see, in the second example, no arguments were needed. This and only this is the purpose of tracking branches. The comfort. Nothing more.

Now take a look what the manpage calls "remote tracking":

[remote "origin"]
       url = git://github.com/mangos/mangos.git
       fetch = +refs/heads/mangos-0.12:refs/remotes/origin/mangos-0.12
       fetch = +refs/heads/master:refs/remotes/origin/master

It says that whenever I type "git fetch origin", it downloads ONLY refs/heads/mangos-0.12 + refs/heads/master (those are paths on the remote side) and stores them to my local hierarchy, under refs/remotes/origin/mangos-0.12 and refs/remotes/origin/master, respectively.

When you specify just "git remote add moron git://github.com/whoever/somerepo.git", the entry looks like

[remote "origin"]
       url = git://github.com/mangos/mangos.git
       fetch = +refs/heads/*:refs/remotes/origin/*

meaning that it downloads anything from refs/heads/ (on the other side) and stores it under the same name in refs/remotes/origin/ (== .git/refs/remotes/origin/) .. which usually means "fetch any branches the remote side have".

Local branches are under refs/heads/my_branch, remote branches under refs/remotes/<name>/their_branch. Thus in both examples, you fetch ONLY remote side's local branches and tell git to store them as your remote branches. This is the default.

The above example is what I called "the git-remote tracking hack" few paragraphs before it. As you see, it's a nice "hacky" usage of the "what to fetch" mechanism. The important thing is that the git-remote's "tracking" is actually useful, while the git-branch's "tracking" gives only a small comfort.

So, that's "why tracking won't be like tracking".

That does seem to work fine for establishing the master.

It isn't smart to use git-pull if you don't have any branch (because it will treat you as a very stupid user and create the master branch for you, which you might not want), furthermore, even if you'd had master branch already, using "git pull" would simply pull from the branch¨s tracking entry in .git/config, not from the remote. You either need to "git pull origin mangos-0.12" to fetch+merge origin/mangos-0.12 into current branch, or simply "git fetch origin" to fetch everything specified by the "fetch=" line for the given remote in .git/config (which is "fetch = +refs/heads/*:refs/remotes/origin/*" by default).

fatal: Not a valid object name: 'reno/0.12-ahbot'.

I believe it's explained in some tutorials, I probably had some paragraph about it in the second chapter or my gitlog ( http://repo.or.cz/w/gitlog.git?a=tree;f=html;hb=master - click "raw" ). Simply - to be able to use any refspec, you need to have it locally downloaded. Yes, even "remote branches" (the moron/alpha thing) are stored locally. So you need to fetch first.

Taking the above as an example, am I correct in my perception that the 'remote' command is naming mangos-0.12 as 'origin' or, in other words, 'master'? So, using reno's fork of mangos to track the auctionhouse bot 0.12 branch, 0.12-ahbot, I tried the following:

Git-remote is just creating the [remote "moron"] section in .git/config and empty directory in .git/refs/remotes. Nothing more. Really.

With the -f argument, it calls "git fetch <remotename>" as well, but that's optional. The -t argument simply modifies/adds a fetch line under that [remote "moron"] section. There's really no magic or anything with "master".

From my readings, it seemed I did things right but I'm fairly certain I've somehow managed to mix up the local branch refspec with the remote branch refspec when establishing the <start point>.

Even if you probably don't realize it, adding -f to the git-remote line would solve your problem. Or doing it separately - "git fetch reno" before calling git-branch. See two quotes above.

In regards to this, I was wondering if it would be better to properly establish the refspec for the local branch by using 'set-head' with an additional 'remote' command?

Nothing personal, but set-head is pretty advanced command, it's main usage is during mirror tweaking, which is, I believe, not your goal. Furthermore, it's unrelated to anything we're doing here.

Can such a strategy also work better for establishing only mangos-0.12 as the default HEAD for my local master?

Uhh, a bit confused here. HEAD is HEAD. That's the refspec you're "on" right now. "git checkout master" and your HEAD == master. Something like "git reset --soft master@{2.days.ago}" and your HEAD points to that commit. See .git/HEAD.

It has several meanings, not just this one. The set-head works with it as well. It allows you to select a specific branch to be checkouted on the client's side when client clones your repo, instead of "master", which is the default. ... and many other things.

I must apologize for all the questions, and probable ignorant misuse of some terms, but you guys have helped me to understand things in a way that no manual can teach and I am indeed honored that you all have taken the time from your busy days to impart your own wisdom in the use of Git.

Well I think that at least the "tracking branches" are very well explained in all 42 tutorials I'm aware of, I simply explained it here just because of the (only by name!) relation to so-called "tracking" remotes.

I might have moved the quotes out of the original context (and shifted them a bit), sorry for that.

I'd suggest you some of the outdated links I have in my first gitlog chapter (pick chapter 01 - http://repo.or.cz/w/gitlog.git?a=tree;f=html;hb=master - again, the "raw" at end of the line).

[Unkle Nuke]

I think you may have struck upon one of the big reasons why I seem to be having some trouble here. I am making the mistake of looking for the "comfort" of actual directories and files whereas Git uses a virtual file system that is at the heart of its efficiency and flexibility.

Call me old-fashioned but I'm too used to "real" files and directories that I can see, a flaw introduced into my thinking from the days of DOS and further reinforced with the metaphors of "folders" and "desktop" in Windows. To think there was a time when I was more comfortable with a VT-100 terminal interface!

Thank you for pointing up my neglect of properly using fetch before creating and tracking the branch. I'm stumbling about a bit while trying to absorb these concepts and I thank you for your patience.

I cloned your tutorials for further reading. I must say that using Git to create a repository for tutorials on using Git is either sublime humor or just plain old mean! :lol:

The blame for that should rest squarely in Richard Stallman's lap. :rolleyes:

Before I close this reply, I might add you are certainly free to send me mail. However, I also think there may be others who can benefit from your wisdom in a public forum. In fumbling about for my own answers, perhaps our discussion has illuminated answers to other questions for those new to Git. Regardless, my address is available to you upon request.

Time to do some more reading!

[Unkle Nuke]

Please excuse the back-to-back posts but I felt a new post was warranted for clarity's sake.

First, I'd like to inform all of you who have helped that I now am the proud owner of a local git repository containing MaNGOS, its branches, and the numerous patch branches from their forks.

One trick I learned, and I do not know if there was a better way, create a remote for v0.13-dev that would fetch into my repository as a branch. I expected to receive an error, since v0.13-dev1 is not an actual branch but a tag, when trying to do a fetch. Indeed I was notified by Git that v0.13-dev1 was not a working branch. I went into the Git config file and changed this line:

fetch = +refs/heads/v0.13-dev1:refs/remotes/mangos-0.13.303/v0.13-dev1

to this:

fetch = +refs/tags/v0.13-dev1:refs/remotes/mangos-0.13.303/v0.13-dev1

...and Git fetched v0.13-dev1 into my 303 branch without a single complaint! I sure hope my assumption worked and there's not some esoteric reason my effort would be a failure.

It took many hours and more than a few occasions where I nearly gave up in frustration, yet I just couldn't let it go and waste not just my efforts but all of yours as well in teaching me. I owe you one, guys!

I'll skip over resolving merge conflicts with kDiff for Windows. I'm still reading up on that nifty little tool but the features I've seen have persuaded me to use it as a replacement for TortoiseDiff and TortoiseMerge and the default merge tool for Git.

Now my next hurdle...

Let's assume I've managed to merge my branches and apply any external patches. As it has been said, everything occurs "behind the scenes" in the '.git' directory. Call me old-fashioned or wary but how do I create the necessary files and folders to copy over to my 'Compile' folder for my compiler to have something it can use? Bear in mind I'm doing this on Windows XP SP2 with Visual C++ Express 2008 SP1 (9.0), Windows 2008 Platform SDK, and DirectX 9.0c March 2009 SDK for my compiling environment.

As an example, I have a branch called "working", where I merged various branches together and applied some patches. Would this in itself create the source code files and folders or am I overlooking an obvious command to create them?

[freghar]

fetch = +refs/tags/v0.13-dev1:refs/remotes/mangos-0.13.303/v0.13-dev1

Since a tag is static _forever_, it makes no sense to fetch it more than once, making the line meaningless. tag v0.13-dev1 will always point to the commit which it is pointing now.

So the cleaner way would be to fetch the tag and create a new local branch with the tag's commit as a base.

git fetch mangos-0.13.303 refs/tags/v0.13-dev1
git branch working v0.13-dev1
git checkout working

or something like that. You can sometime later use "v0.13-dev1" again, without any need for special fetch lines in .git/config.

Would this in itself create the source code files and folders or am I overlooking an obvious command to create them?

To make the life of svn-like users easier, git checkouts the working tree on many operations. When you merge, it creates a merge commit and checkouts it to working tree. When you apply a patch, the change exists ONLY in working tree (= files and folders) until you commit it to the virtual filesystem.

So for the most part, I wouldn't fear about anything being unavailable in the working tree.

And just btw .. I can recommend http://eagain.net/articles/git-for-computer-scientists/ for some basic knowledge about git objects.

[Unkle Nuke]

Wasn't my edit of the repository's config file accomplishing the same thing, more or less? Although it now resides in a local branch and there is no point to further fetches on a static codebase, would it cause any issues to arise with the branches for 0.13 and 0.12?

My thought at the time was to have an actual branch to facilitate any future work, should I ever become so daring as to try hacking together some code.

As for those phantasmal files and folders, I take your meaning of "working tree" to be the files and folders that are created outside the '.git' folder. So, when I do a merge of say...mangos-0.12 and alterac-0.12...the source code in the working tree will contain the merges. I would then copy those files and folders to my compiler projects folder, compile the code, and the resulting binaries would have the alterac patch incorporated. It sounds correct to me but is my reasoning sound?

[freghar]

I would then copy those files and folders to my compiler projects folder, compile the code, and the resulting binaries would have the alterac patch incorporated.

I have no idea why you can't just compile them in place, without any copying, but yes, it should work as expected.

[Unkle Nuke]

Thank you for confirming this for me, freghar. You've taught me a lot over the past several days and helped to make Git much more understandable.

It's an old habit I picked up a long time ago but I feel more comfortable keeping my compiling projects seperate from my source repositories. We all have our quirks when it comes to how we work and think.

Well, it's time to work on merges and conflicts. :eek:

Wish me luck, guys!

[NowonsHere]

Good luck!