I don't have a good answer, being a newbie. But I'm wondering why you
have people doing a git push on "not ready for prime-time" changes.
The OSX people, or just each individual, can keep a "local" branch in
their working directory. When they need to move a file or files into
development, they can do a "git merge" on their own desktop into the
devel branch on their desktop. They then push the devel branch up to
the global repository. If they want, they can maintain multiple
"local" branches on their desktop. Or, instead of doing a "git merge",
perhaps they could do something like:

#we are normally in the local branch
git checkout devel
git cat-file -p local:file-to-copy-to-devel >file-to-copy-to-devel
git add file-to-copy-to-devel
git cat-file -p local:file2.txt >file2.txt
git add file2.txt
# and so on
git commit
git push
git checkout local #back to local branch

or, to merge all the files from local to devel

git checkout devel
git merge local
git push
git checkout local

Again, the local branch exists only on the individual user's system,
not in the global repository.

If I'm totally out of wack, I'm sure one of the truly knowledgeable
will kindly correct me.

Does this sound reasonable?

On Tue, Jan 8, 2013 at 2:12 PM, Ray Shaw <rsh...@umbc.edu> wrote:
> I'm trying to solve a problem with git, but I think I'm going about it the
> wrong way.  I've tried searching for a lot of related terms, but either the
> answer isn't out there, or I'm not trying the right words.  It's possible
> git can't do what I want, but I hope so.
> We've been using git to manage our puppet manifests and content files for
> over a year now.  We have 2 branches, master and devel.  We make changes to
> the "devel" branch, do a git pull of "devel" on the development server, then
> test with the development workstations.  When the changes are ready, we
> merge them into "master", do a git pull of "master" on the production
> server, and the production network (Linux) clients get the changes.
> This has been working well enough.  There are only 2 of us making changes,
> so there are few conflicts.  The issue is that now we're adding 2 more
> developers for a different platform (OS X), but they'll be working with
> files in the same filesystem tree (and currently the same git branch) as we
> are for Linux.  99% of their work will be on different files, but in the
> same directories as our files.
> What we'd like to be able to do is push either:
> a) changes just made to the Linux files
> b) changes made by one person
> c) select commits
> to the "master" branch, and thus production server, without also merging any
> potentially not-ready-for-prime-time changes made to the OS X files and/or
> one or both of the OS X developers.  It would be nice for Linux developer A
> to be able to exclude Linux developer B's changes too, sometimes, but not as
> critical.
> We initially thought of creating a separate development branch that only had
> their files, but trying to have two git branches share a single filesystem
> location doesn't work, at least not the way we're doing it (check out the OS
> X branch, and /etc/puppet/darwinstuff is there, but /etc/puppet/linuxstuff
> vanishes, and vice-versa).  Complicating things is the fact that their files
> (currently a small quantity, but sure to grow) are currently in the "devel"
> branch as the result of a previous effort.
> I feel like this has to be easier than I'm making it, and I'm just going
> about it the wrong way because I don't understand Git well enough.  But the
> documentation I've found doesn't really seem to describe how to solve this.
> --

Maranatha! <><
John McKown


Reply via email to