On Tue, Feb 17, 2009 at 5:05 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > So at work, you would have a checkout of your work "deployment branch", > and find needs to change things. It is Ok to edit both work.sh and > generic.sh (without being able to edit both, it would be hard to verify if > the changes would work together) at this time, but don't commit the result > in the work branch. > > Save the changes to work.sh away (e.g. "git diff work.sh >P.diff" and then > "git checkout HEAD work.sh"), switch to the common branch, and commit the > changes to the generic file. Switch back to the deployment branch, merge > the common branch (to pick up the changes to home.sh), reapply the changes > specific to the deployment you saved earlier (e.g. "git apply P.diff"), > tne commit the result. > Thanks. Well, I should have said in my initial request: "Without manually forwarding changes from branch to branch and without having to remember special rules about what I can and cannot merge into which branch", since that is likely to get forgotten. :) The answer I am hearing you say is that git doesn't have a way to automatically exclude files akin to how rsync handles include/exclude. Is that what you are saying? Or, could the hook mechanism be exploited to get this behavior? bg -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
