Re: branch proposal

[John Darrington]

On Mon, Sep 01, 2008 at 11:29:01AM -0700, Ben Pfaff wrote:
     John Darrington <address@hidden> writes:
     
     > Yes.  There is always that possibility, and obviously if that happens,
     > then what I described won't work.  But in the simpler case, (where a
     > file is touched in the parent, but not in the branch) the branch will
     > receive the changes from the parent.  If the file is touched in both,
     > then it'll attempt to merge; if there's a conflict then that'll have
     > to be resolved by hand as you say.
     
     Thanks.  That makes a lot of sense.
     
     Git could support this kind of thing if it were done from a
     "hook", so that when you committed to one branch it would also
     make the same commit to other branches.  But I do not know of
     anyone who has implemented such a thing.
     
     > What confuses me about your proposal, if I understand it correctly, is
     > that changes checked into the "development" branch will also appear in
     > the "bug fix" branch whether we want them to or not. Usually it's not
     > what we want; we want the opposite.
     
     Yes, we do want the opposite.  I think that my proposal must have
     been misunderstood then.  Here it is again:
     
             * Check bug fixes (only) into the "stable" branch.
     
             * Check everything else into the "master" branch.
     
             * Periodically, pull the bug fixes from the stable branch
               into the master branch, so that the master branch also
               receives those fixes.

OK.  So I've completely misunderstood how branching works in git.  If
this is the way it works, then your suggestion is as good as any. So
long as we remember to do those perodic pulls from "stable" to
"master"; it might be a good idea to make a point of doing it after
every commit to "stable".

I think we've discussed this long enough.  We ought to go ahead and
make that branch.

J'

PS:  I've always thought of branches as having a parent-child
relationship to other branches.  Is there any meaning to such
relationships in the git model?   How does making a branch in git
differ, from the user's point of view, from making a completely new
copy of the repository (if at all)?


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

signature.asc
Description: Digital signature