On Fri, Aug 08, 2014 at 10:34:43AM -0700, Mike Stump wrote:
> On Aug 6, 2014, at 10:11 PM, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
> > Nah. Sun managed this for decades without a hitch, and for products
> > much larger than GCC. See above.
>
> Ok. Ah, ok, perfect. I see how that method of working would cure the
> cherry-pick and merge don’t work problem mentioned at the top of the
> thread.
>
> > Do some experiments based on the above hardcopy. If that doesn't
> > convince you that it works, oh well, I'll have given it a good try.
>
> Thank you for taking the time to diagram that as it appears to violate
> everyones how to use git guide. I see the workflow does an onto,
> which was the ‘fix’ people talked about on stack overflow, and I see
> just how things would work.
There's nothing scary about --onto. You're saying "figure out which are
my local commits (the ones on top of the previous upstream) and pick
them onto the new upstream".
We only need to do it manually (though it can be scripted[*]) because
git doesn't track rebase history so that it can be done automatically.
[*] And then there's Tony Finch's
https://git.csx.cam.ac.uk/x/ucs/git/git-repub.git , which is kinda
awesome!
> If the old master branches are deleted and gc is run, then all the old
> references go away, and then the refs from email and bugzilla then
> don’t work. Did you guys ever remove them and then prune (or gc)?
Product gates' repos and snapshots stuck around forever, though it was
Teamware, and finding really old ones wasn't necessarily easy,
particularly since their names didn't always reflect product names.
Prominent project gate repos and their snapshots also stuck around
forever.
Lesser project gate repos tended to be as ephemeral as the project.
> Now, the biggest issue, if that is recognized as `fixing’ the
> cherry-pick problem, then certainly the problem is understood to be a
> problem. If one recognized it as a problem, then one can envision
Not really. This isn't about git. We followed a rebase-only workflow
with VCSes that nominally didn't support rebase. We did it because it
was easier on everyone and kept history in the upstream clean. We
didn't do it because git has issues when combining merge and
cherry-pick.
> cherry-pick and merge working together so that the problem doesn’t
> need fixing in the first place. And, if it doesn’t need fixing, then
If you buy into the Sun model then this is all a non-issue. If you
don't then I think you have other problems (because I have bought into
the Sun model) :)
> the cost of the solution isn’t needed either. The biggest problem
> with git, is that two features don’t work nicely together when they
> [...]
The Sun model has no additional cost. It moves costs around so that the
people dealing with conflicts are the downstreams, not the upstreams,
and that's exactly as it should be.
(Keep in mind that Solaris gates tended to have large numbers of commits
on any given day, so it was quite common that one would have to rebase
multiple times before successfully pushing. For large projects with
long test cycles the gates would close to avoid the need to rebase and
re-test.)
> I still favor fixing the underlying problem with cherry-pick and merge
> not working. :-) That said, I see how to work around the bug with
> rebase, if I need to.
IMO it could be done, but I can't help that.
> I wish the top google hit were your guide and I wish I never saw all
> the other pages… I see now your position, and I see why all the
Me too! I should blog it.
> guides are wrong, if you know just how to use rebase. I wish the git
> documentation were improved to say as the first sentence under
The Sun model is not the only way to use git though.
> cherry-pick, this feature sucks and doesn’t really work well, it can
> cause excess merge conflicts. rebase can be used to work around the
> bugs in cherry-pick for now. And under rebase, instead of saying what
> it said now, that how one can can trivially and effortlessly use git,
> instead of saying, Do not rebase commits that you have pushed to a
> public repository which I now see is wrong.
I'm glad you understand the Sun model now. You should evaluate its
applicability to your use case on its own merits. Don't use it just to
workaround a problem in git; use it because it's good, or don't use it
because it doesn't fit your team's needs.
Nico
--
--
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