David Jeske wrote: > To re-ask the same question I asked in my last post, using your ascii > pictures... > > > Let's assume we're here.. > > .<---.<---.<---A<---X<---Y <--- master > \ > \--B<---C <--- customer_A_branch <=== HEAD > > > And this person and everyone else moves their head pointers back > to master without merging: You could simply say: they stop working on 'customer_A_branch' branch (moving HEAD poter is simply switching to / checking out / working on different branch). > .<---.<---.<---A<---X<---Y <--- master <=== HEAD > \ > \--B<---C <--- customer_A_branch > > > Now, five years down the road, our tree looks like: > > > .<---.<---.<---A<---X<---Y<--.(3 years of changes).--ZZZ <--- master <=== HEAD > \ > \--B<---C <--- customer_A_branch > > And someone does: > > git-branch -f customer_A_branch ZZZ If they are using '-f', i.e. force, they should know and be sure what they are doing; it is not much different from 'rm -f *'. If reflog for 'customer_A_branch' expired it would be hard to go back to old 'customer_A_branch', and impossible after garbage collector pruned history. What you _should do_, if you want to preserve old 'customer_A_branch' pointer is to *tag* it, e.g. something like 'Attic/customer_A_branch'; if you use annotated tags you can even state why do you want to keep old work, and why old work wasn't merged into long-lived branch, and why the work was abandoned. -- Jakub Narebski Poland -- 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
