From: Eloy P. <pe...@ch...> - 2013-07-07 17:08:44
|
Hello, On 07/07/2013 11:59 AM, Michael Stovenour wrote: > On July 6, 2013 6:24 PM H Plato wrote: >> So, stupid question. I'm a long time svn user, and still not that familiar with the git >> approach. I have a git repository now, which a bunch of custom files that are unique to >> my setup. I tried to pull down the 3.0 files: >> >> I changed into the directory that I clones MH, and tried to pull it down (I'm guessing >> that's similar to the svn update I used to run). How can I keep local files, yet easily >> bring down the master improvements. I'm looking to migrate all my X10 to Insteon, so I'd >> like to get with the current development platform. > > There are probably as many ways to keep locally unique changes as there are developers > using Git. I personally keep my "master" merged with hollie/misterhouse/master so the two > are identical. I then have a separate "running" branch where I maintain my own unique mix > of local and upstream changes. To update my running branch with changes to > hollie/misterhouse, I pull upstream on my master branch then I merge from master into > running. From what I've read there are easier and harder ways to manage local changes and > it all depends upon your goals. > > That's all easy enough if you are starting with a point where master and running are the > same, then applying unique changes to running. In your case you are starting with changes > that are not included in any Git controlled branch and are based on a common ancestor > many/many commits back. Your initial challenge is to merge those uncontrolled changes > into a current Git branch (e.g. running). > > This will require that you identify all of "your" changes. "Your" changes are the bits of > code that are different between your local files and the last SVN copy your files were > based on; this has little relation to the current Git repository. When I first switched > to Git, I: > 1. Checked out a clean SVN copy into a new directory that was as close as possible to my > local files > 2. Copied all my files over the SVN directory path > 3. Used svn diff to find all my changes against SVN > 4. Manually applied my changes to my Git "running" branch with an editor > > Now that I know Git a little better I would be tempted to do this again by creating a new, > separate Git repository on my local system to automate the process. It might go something > like this: Import the SVN checkout into the new Git repository; copy my files over the > new Git repository; use Git tools to diff, stage, commit just the changes I wanted to > keep; cherry-pick the changes using SHAs into my running branch of hollie/misterhouse; fix > each merge issue. Good stuff. I'd venture to say that a very simplistic, but I think workable, approach to keeping local changes to some parts of the MisterHouse code, is to clone the official Git repository and then incorporate one's changes in the cloned repository. No branches or anything more "sophisticated". Running "git status" would allow one to see what files have been modified locally, and running "git diff" would allow one to see the exact changes. Running "git pull" would bring in new changes in the master repo. Any conflicts would be resolved then by editing the local files. Of course, I'd advice to keep local changes to a minimum by not modifying files that should be modified elsewhere (like web pages), and by contributing any local changes so they can be merged into the official repository. My MH source code tree that I use in production in my house is read-only. I believe there's documentation in the wiki on how to do this. How to do customization of the web interface without touching files in the original distribution is documented here: https://github.com/hollie/misterhouse/wiki/ia5-web-interface-customization Cheers, Eloy Paris.- |