Friday, October 12, 2012

git - copying one repo into another with history, preserving the folder structure

I'm new to git and I'm learning to be wary of it (like a sharp knife); on one hand the more I dive into it, the more I see how powerful it can be. On the other hand I am starting to understand why the designers of all the big-name commercial source control systems hid all of this flexibility from you; in the right hands (and mindset) git is insanely cool. In the wrong hands it's frustrating, difficult and immensely destructive (to your code and your time). It's like letting a toddler play with a lightsaber sometimes.

With that preface out of the way - a developer had a local repo he had created and worked in for some time, and he needed it pushed up to the corporate git server (where it never existed).
We're currently using gitosis for management (but we're transitioning to Stash - no worries)(unless I should be worried?) so I couldn't figure out how I could just clone it to our server's gitosis folder structure.

The more I read, the more it seemed like my best path was to merge the one repo into a repo I create on the corporate server; but root to root - not into separated folders; 99.9% of the results from google were predicated that you're trying to merge one repo into another at a sub-level, i.e. ProjectA + ProjectB = ProjectA with a ProjectB subfolder in it (or vice versa, or even Project A + Project B = Project C with A & B subfolders).  I needed to merge his repo at the root level into another repo at the root level, if possible.

In the end, I had a couple technical difficulties that I haven't quite conquered -
1) I kept getting odd errors (or no error but it didn't actually do anything) during and after the merge; it was suggested on several similar solutions that merging into an empty repo is problematic. "They say" to always add a dummy file to an empty repo before trying to merge to it. Every log file/screenshot that I found of someone actually successfully merging to a brand new empty repo showed them adding a dummy file to the beginning, before their merge. I had so many issues I ended up doing the same thing.
2) At the end, a git push would hang at a high % (say 75% or 100%) and never finish. I ended up suspecting the Kaspersky Endpoint Antivirus was blocking the connection my PC was trying to make to the git server. I worked around this by repeating all of these steps verboten while putty'd to the git server, logged in as myself in my home dir. I also opened up a helpdesk ticket to add git.exe to the exclusion list for KAV, but that's another story. I'll try to circle back and re-try this if I ever get KAV under control.

Here’s (essentially) my steps. I think there was about 100 ways I could have done this, but this is what I ended up doing:


1) Create the empty repo on the git server itself and add it to gitosis’s administration
2) In my home directory, pull down the empty repo.
git clone git://server/newrepo.git
3) Create dummy.txt with contents, add, commit & push it back to origin
ps -ef > dummy.txt
git add .
git commit -m "adding dummy file prior to merge"
git push origin master
4) Add the developer's repo as a remote
git remote add devs_initials mylogin@devs.pc.com:devsrepo
5) Fetch his repo
git fetch devs_initials
6) Merge the master branch into the new repo and push it to origin again.
git merge devs_initials/master
git push
7) Remove the dummy.txt (its purpose is done)  and commit & push to origin
git rm dummy.txt
git commit -m "Removing dummy.txt, as it's no longer needed."
git push
8) Profit.

Sigh.

Feel free to comment with what a smarter, more experienced git user would have done.

Monday, October 8, 2012

New Job - What Do You Master First?

Sorry for the lack of updates for the last 12 months; I finished up at a place I was at for almost six years, spent 7 months at a different place, then changed yet again. Today marks exactly two weeks since I started at my new place.

So - what do you master first at a new job? What do you make a top priority in scoping out?
What is the first and foremost necessary skill needed to survive a new workplace?

If you have a CM/DevOps bent, you might say "the build system" or "the source control toolset". If you're a developer maybe "the software development lifecycle" or "the nearest Five Guys or In & Out".  Finally, if you're in QA/SA, you might say "the defect system" or "the test case management tool".

As I mentioned earlier, today marks my 2 week anniversary since starting here, and I've mastered the most important and foremost necessary survival skill -

Upon opening the door & taking a single (silent) step inside, I can immediately tell which stall doors are closed and locked (and occupied) versus empty stalls that have swung shut on their own, on the three closest restrooms to my desk.
The results of said single glance will determine if I continue into the restroom or depart as silently as I first arrived.

---

I'll try to be more dutiful with updates for the rest of this year. Thanks everyone!

-Kelly