On Aug 1, 2014, at 4:40 PM, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: > As for rebase, I still don't understand why it doesn't work for you. http://git-scm.com/docs/git-rebase says: Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea If you read stack-overflow, you will discover a ton of people that like doing this, and they get hammered because of it. My use case fits exactly (as near as I can tell) the hammer case. If you make a different command that isn’t guaranteed to screw me and my co-workers over, and tell us to use that, then I’d be happy to use it. Bet the farm that it won’t bite you, just to be bitten isn’t what I want to try and recover from. > You didn't really explain. If you say it will never bit you and then fix all the documentation to not say it will bite you… I’d be happy to contemplate it again. Now, I found the stack-overflow commentary first, and all the horrors of it, and all the nuances. I carefully read what people were doing, how what I wanted to related to what they were doing, and it sure felt like I was in the, don’t go there camp. > Suppose we're right and it's the right solution for you, then you might be ecstatic, but you gotta try it > first. So, I like to know if I’m driving off a cliff, before I do. I’m the type of person that would rather know were the road goes, and merely avoid driving off the cliff. When stack-overflow is littered with the bodies of people that thought it would be fun, I tend to just say, that’s not for me. > The only case where I can imagine not using a > rebase-heavy workflow is where I have to track multiple forked > upstreams and so I want to merge each into my branch. So, sounds like I fit that use case and rebase could be my friend. How do I square what you said and: Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea ? I want all old refs in old emails to work. I want all refs in bugzilla to work. I want to see the original dates of all the work. I want git blame to report those artifacts in email and bugzilla. I have coworkers that I push to, pull from (through a single sharing point, we call the master tree). We work on gcc, we pull git gcc down to a local copy, then merge it into our tree. I want to cherry pick changes from upstream. I do work and push to our master, I pull work of coworkers from the master, my coworkers do the same. Isn’t this the canonical open source use case? > (I find that many users are allergic to rebasing. Many people have > told me that rebase is lying, that history must be immutable, and so > on, all ignoring that: git users don't rebase published branches, So, when I push, and someone else pulls, is that published? I thought it was.-- 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