[ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits

[Arthur Jones]

hi michael, ...

On Wed, Jul 25, 2007 at 10:34:35AM +0300, Michael S. Tsirkin wrote:
> > > - A single git reset ORIG_HEAD recovers from a conflicting merge
> > 
> > if, though, you must have a pristine environment,
> > this is easily solved by using an intermediate repo:
> > 
> > git clone -s <canonical repo>
> > <run the pull>
> > <any conflicts, dump this guy, otherwise, pull this in>
> 
> Ah, you now see how git reset is broken.
> What about git rebase? Broken too I'm afraid.
> Anything that rewrites history is.

no, git reset is not broken, nor is git rebase,
what i described is a way to import multiple
branches and allow you to backout easily if
_any_ of the pulls failed.  this is certainly
_not_ the only way.  you could also write a
script to capture the HEADS and then git reset
them if there were any issues.  this would be
faster, but more complicated.  there is _no_
loss in functionality.  i would be willing
to write and maintain this script for you
if wanted to give it a try...

i think, if you tried the branches, you would
find that you wouldn't need to require all
branches to pull cleanly.  you would prob be
able to easily fixup the problem and continue
the merge...

> > i bet this is very similar time-wise to running the
> > merge, then the ofed_scripts/configure over all supported
> > branches.  merges in git are _fast_...
> 
> Full tree checkout is slow though.

yes.  it would prob be worth the effort to
capture the HEADS and replay them if you
really found that it was a requirement to
pull all branches cleanly or none at all...

> > > - A single tag tags all code for all kernels
> > 
> > store commit ids in a file and tag that?
> 
> This trick breaks some more git utilities.
> E.g. git describe, git web displaying tags ...

yes, i agree it's ugly.  tags are not nice
for multiple branches in a repo, do you know
if there is any movement in the git project
to work on this?

arthur