[Natty] [ti-omap4] [Pull Request]: 2.6.38.2 based updates
Andy Whitcroft
apw at canonical.com
Thu Apr 14 05:33:22 UTC 2011
On Wed, Apr 13, 2011 at 05:20:51PM -0700, Bryan Wu wrote:
> On Wed, Apr 13, 2011 at 4:53 PM, Dechesne, Nicolas <n-dechesne at ti.com> wrote:
> >
> >
> > On Thu, Apr 14, 2011 at 1:33 AM, Bryan Wu <bryan.wu at canonical.com> wrote:
> >>
> >> in ti-omap4 tree, I just wanna get all the patches on top of a commit
> >> which is 2.6.38 kernel release. So I found that SHA ID of that commit
> >> and use "git format-patch -o /tmp/ SHA_ID.." to get patches. Very
> >> strange, I got lots of patches which are not on top of that commit.
> >>
> >> So Brad told me to do "git format-patch -1633 -o /tmp" to get 1633
> >> patches on top of that 2.6.38 release commit.
> >
> > you might get confused by the definition of 'on top'. 'on top' as being a
> > child, or 'on top' as being more recent.
> >
> > git log A.. will list all commits who are not an ancestor of A, which are
> > reachable in your branch. but some of these commits can be older than A, and
> > still aren't ancestor of A.
> >
>
> Hmmm, I still fail to understand how come the commits shown in git log
> A.. is old than A. Or maybe the time stamps of commits are not in the
> right order, but the order in git log A.. should be the order we apply
> patches.
This is because A..HEAD is not all commits newer than A, it is all
commits which became included in HEAD since A.
X ... Y ... Z ... A ... B ... C
R ... S ....../
So for example B here merges in R and S which are older than A, but
which were not in the tree at A but are at C.
Note that this also implies that given a merge ridden source there may
actually not be any linear order that they will correctly apply. Any
linear order that git log offers you is a mearly an approximation of the
correct order and a known to work order does not exist.
> > to me git format-patch A.. if run from your branch, will list all the
> > commits which are in our OMAP4 branch but not in ubuntu master.
> >
>
> Oh, really, so weird. on my side.
[...]
Hard to see from those what is and is not expected without the tree
itself to play with. Will try and look at that and see what the best
way out of this is.
-apw
More information about the kernel-team
mailing list