On Aug 1, 2014, at 4:40 PM, Nico Williams <n...@cryptonector.com> 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 

> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to