Hi Colin,
Yes this solution is a bit heavy handed. I think it's most dangerous if other
people have already updated from upstream.
> The fix is really brute force--we're basically invalidating our shared
> definition of the master branch is and replacing it with an individual one,
> forcing everyone to update all their branches to match.
In regards to the above comment, I'm not sure this is actually as big an issue
as it may seem. Basically, I believe a replacement actually happens, pretty
much, every time we push up to the project repos master; which is why the graph
ever flips. We actually rarely, if ever, merge into the project repos master,
we always replace it with one of ours. This theory may seem weird, but I'll try
to explain.
So the first thing to remember is that our copy of the master branch, our local
master, is not the same branch as the remote one. They are two separate
branches on two separate repos, they just happen to contain the same changes.
When we push up to the project repo, it is likely that we are not doing a
merge, but rather a fast forward.
I think I'm finally understanding the process of a fast forward, and what it
actually does. If you attempt to merge Branch A into Branch B and Branch A
already contains all of the changes that are in Branch B, a fast forward will
occur. What a fast forward will do is to replace Branch B with Branch A.
I'll represent this in some pseudo code.
if ( all change in branchB are in BranchA) {
branchB = BranchA;
}
So you can see that we are commonly replacing the master repo with one of our
own.
All that being said, I don't think we need to worry about this most of the
time. The graph flipping caused by the commit last Friday was much more serious
because it stretched back so far, and it contained some unusual commit logs and
etc. I think for minor flips here and there we needn't worry about. The code is
always there at any rate. The history does become harder to navigate though,
but for small flips I think it shouldn't be too much of an issue.
Thanks
Justin
On 2011-05-19, at 5:10 PM, Colin Clark wrote:
> Hi everyone,
>
> This afternoon, I forgot to include the --no-ff flag when merging Mike's
> FLUID-4243 branch into the project repo. This caused the graph to "flip."
> Justin kindly walked me through the steps to fix it, which involved deleting
> the master branch in the project repo and replacing it with a version that
> had been reset to the point immediately prior to my merge.
>
> The result, however, was an unbelievably massive commit message to
> fluid-commits documenting every change to Infusion since its inception in
> 2007. If you're feeling nostalgic, have a look. If not, avoid it. It caused
> my email client to thrash for a good 30 seconds.
>
> The more I think about this, the more the fix seems wrong. It's an easy
> mistake to make--virtually any time you forget the "no fast forwards" flag,
> you'll cause the graph to flip. The fix is really brute force--we're
> basically invalidating our shared definition of the master branch is and
> replacing it with an individual one, forcing everyone to update all their
> branches to match. It takes time, and it's a really high cost thing.
>
> Are we sure we want to keep doing a fix like this when people flip the graph,
> or the graph flip something we can live with from time to time?
>
> Colin
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> http://fluidproject.org
>
> _______________________________________________________
> fluid-work mailing list - [email protected]
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
