Consider the following three (separate) scenarios: 1. Git is tracking a file in multiple branches. I want to code up a quick fix for a showstopper bug in the release branch, but don't want this change to ever be propagated into the master when I later merge the release branch into the master. (Assume that we will be making a far more robust and elegant change in the master when we have "world enough and time." As we all know, that's "after the release goes out.")
2. I add a new file to the release branch but don't want it be added to the master when I later merge the release branch into the master. 3. Git is tracking a file in multiple branches. I want to remove it in the release branch but don't want it to be removed when I later merge the release branch into the master. How are these best done? I have workarounds for (1) and (2), but not (3). For (1) and (2), I would do the merge into the master, then, for (1), edit out my change, or, for (2), "git rm" the file in the master branch, then commit. Hopefully there is a better way -- ideally, one that allows me to do something to prevent the later merge while I am still right there in the branch (i.e., before I forget about it). I don't see a workaround for (3). If I allow the merge to take place, an attempt to add a saved copy of the deleted file will create a brand new file, losing all history. Maybe there's a way to re-checkout the deleted file by referring to a previous tree-ish? That would be a workaround, and if you know how please tell me; but, s with (1) and (2), it would be much better to be able to avoid the merge of the deletion in the first place. Thanks, -P. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/github?hl=en -~----------~----~----~----~------~----~------~--~---
