On Tue, Mar 18, 2014 at 4:57 PM, B. Lachele Foley <lfoley.ccrc.uga.edu>wrote:
> I think you can edit elsewhere if you do this. If this is wrong, I need
> to know, so please say. :-)
>
> 1. Make a branch for your changes. Don't pull from main into that branch
> until you are finished with the changes. The latter is important.
>
> 2. When done, be sure you have the branch checked out and copy your file
> over to it. Commit the file(s). (use "git status" first to be sure all
> changes committed are expected.)
>
> 3. Switch back to the master branch and pull the updates from the main
> AMBER repo into master.
>
> 4. Merge your changes from the branch into master.
>
> This way, git knows that the work in the branch is from an older common
> ancestor, and it will do a more intelligent merge -- or ask you to deal
> with conflicts.
>
This approach works, but it may trip people up. It's effectively using a
separate branch as a merge buffer. The key is that you can't merge (or
pull, which performs a fetch then merge) any upstream changes BEFORE
copying a file into your working repo. You could accomplish the same thing
in the master branch simply by waiting to do a git pull until after
you've committed your new file.
To each his-or-her own, but I think the most straightforward approach is to
_always_ modify the files that are directly inside a git repository --
never create a working copy outside a repo and move it back in after you're
done (you can have as many repos as you want). If you do choose the route
of working on an untracked file outside of a git repo, then you have to be
extra careful not to inadvertently (and silently!) reverse previous commits
by doing so. Either by following Lachele's suggested workflow or
self-imposing a (strict) pull hiatus until you finish your edits.
And the standard advice that Dave espouses consistently: small, frequent
commits and frequent merging will help minimize conflicts and ease the pain
when they do occur.
All the best,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Mar 18 2014 - 17:00:03 PDT
