All of lore.kernel.org
 help / color / mirror / Atom feed
* determine a linux kernel version of a patch file
@ 2015-05-14 17:08 Pawel Por
  2015-05-14 17:25 ` Johannes Schindelin
  2015-05-15 12:08 ` Matthieu Moy
  0 siblings, 2 replies; 6+ messages in thread
From: Pawel Por @ 2015-05-14 17:08 UTC (permalink / raw)
  To: git

Hi,

At the beginning I'm sorry if this post is completely unrelated to
this mailing list.
I'm trying to find the base linux kernel version from which a patch
has been created and posted to LKML.
Most patches contain the index line. Is it the well known git index
(staging area) ?
Can I use the index to find the exact kernel version from which a
patch was created.
Please look at an example patch sent to LKML:
https://lkml.org/lkml/2015/5/14/497

It contains the following index line:
index 8dd1e55..9b0c81e 100644

I tried to find it using "git log" but I couldn't.

Please help me to determine the exact kernel version.

thanks in advance

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: determine a linux kernel version of a patch file
  2015-05-14 17:08 determine a linux kernel version of a patch file Pawel Por
@ 2015-05-14 17:25 ` Johannes Schindelin
  2015-05-15 12:08 ` Matthieu Moy
  1 sibling, 0 replies; 6+ messages in thread
From: Johannes Schindelin @ 2015-05-14 17:25 UTC (permalink / raw)
  To: Pawel Por; +Cc: git

Hi Pawel,

On 2015-05-14 19:08, Pawel Por wrote:

> Most patches contain the index line. Is it the well known git index
> (staging area) ?
> Can I use the index to find the exact kernel version from which a
> patch was created.
> Please look at an example patch sent to LKML:
> https://lkml.org/lkml/2015/5/14/497
> 
> It contains the following index line:
> index 8dd1e55..9b0c81e 100644
> 
> I tried to find it using "git log" but I couldn't.

If you call `git log --raw` (possibly adding --all) and then search for 8dd1e55, you should at least get to the revision when this file was changed to the revision that served as base for the patch. To make it faster, you could call `git log --raw -- <filename>`. That would also have the advantage that you could scroll up again to see which revision, if any, modified the file again, giving you kind of a commit range from which to pick.

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: determine a linux kernel version of a patch file
  2015-05-14 17:08 determine a linux kernel version of a patch file Pawel Por
  2015-05-14 17:25 ` Johannes Schindelin
@ 2015-05-15 12:08 ` Matthieu Moy
  2015-05-15 17:03   ` Kelvin Li
  1 sibling, 1 reply; 6+ messages in thread
From: Matthieu Moy @ 2015-05-15 12:08 UTC (permalink / raw)
  To: Pawel Por; +Cc: git

Pawel Por <porparek@gmail.com> writes:

> Hi,
>
> At the beginning I'm sorry if this post is completely unrelated to
> this mailing list.
> I'm trying to find the base linux kernel version from which a patch
> has been created and posted to LKML.
> Most patches contain the index line. Is it the well known git index
> (staging area) ?

This is the id of the blob object corresponding to the _file_ being
patched (index <from>..<to> <mode>). That's why you don't see it in git
log: git log shows you ids for commit objects (which point to trees,
which in turn points to blob).

See Johannes' answer for how you can get some possible commits.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: determine a linux kernel version of a patch file
  2015-05-15 12:08 ` Matthieu Moy
@ 2015-05-15 17:03   ` Kelvin Li
  2015-05-15 17:41     ` Johannes Schindelin
  0 siblings, 1 reply; 6+ messages in thread
From: Kelvin Li @ 2015-05-15 17:03 UTC (permalink / raw)
  To: Matthieu Moy; +Cc: Pawel Por, git

On Fri, 2015-05-15 at 14:08 +0200, Matthieu Moy wrote:
> Pawel Por <porparek@gmail.com> writes:
> 
> > Hi,
> >
> > At the beginning I'm sorry if this post is completely unrelated to
> > this mailing list.
> > I'm trying to find the base linux kernel version from which a patch
> > has been created and posted to LKML.
> > Most patches contain the index line. Is it the well known git index
> > (staging area) ?
> 
> This is the id of the blob object corresponding to the _file_ being
> patched (index <from>..<to> <mode>). That's why you don't see it in git
> log: git log shows you ids for commit objects (which point to trees,
> which in turn points to blob).
> 
> See Johannes' answer for how you can get some possible commits.
> 

Come to think of it, why is that line named "index"? Conceptually, this
"diff header index" seems distinct from the "staging area index", but
calling both "index" is confusing, in my opinion.

Is there already a note about this in the docs somewhere? At the very
least, "git help diff" seems to happily use both senses of the word
without any acknowledgement that we're overloading it.

Thanks,
Kelvin

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: determine a linux kernel version of a patch file
  2015-05-15 17:03   ` Kelvin Li
@ 2015-05-15 17:41     ` Johannes Schindelin
  2015-05-15 20:16       ` Junio C Hamano
  0 siblings, 1 reply; 6+ messages in thread
From: Johannes Schindelin @ 2015-05-15 17:41 UTC (permalink / raw)
  To: Kelvin Li; +Cc: Matthieu Moy, Pawel Por, git

Hi,

On 2015-05-15 19:03, Kelvin Li wrote:
> On Fri, 2015-05-15 at 14:08 +0200, Matthieu Moy wrote:
>> Pawel Por <porparek@gmail.com> writes:
>>
>> > At the beginning I'm sorry if this post is completely unrelated to
>> > this mailing list.
>> > I'm trying to find the base linux kernel version from which a patch
>> > has been created and posted to LKML.
>> > Most patches contain the index line. Is it the well known git index
>> > (staging area) ?
>>
>> This is the id of the blob object corresponding to the _file_ being
>> patched (index <from>..<to> <mode>). That's why you don't see it in git
>> log: git log shows you ids for commit objects (which point to trees,
>> which in turn points to blob).
>>
>> See Johannes' answer for how you can get some possible commits.
>>
> 
> Come to think of it, why is that line named "index"? Conceptually, this
> "diff header index" seems distinct from the "staging area index", but
> calling both "index" is confusing, in my opinion.
> 
> Is there already a note about this in the docs somewhere? At the very
> least, "git help diff" seems to happily use both senses of the word
> without any acknowledgement that we're overloading it.

By default, `git diff` works on the index, unless you force it to compare revisions or the working directory to a revision. I guess that is where the wording comes from.

In any case, it is too late to change it now...

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: determine a linux kernel version of a patch file
  2015-05-15 17:41     ` Johannes Schindelin
@ 2015-05-15 20:16       ` Junio C Hamano
  0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2015-05-15 20:16 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Kelvin Li, Matthieu Moy, Pawel Por, git

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> By default, `git diff` works on the index, unless you force it to
> compare revisions or the working directory to a revision. I guess that
> is where the wording comes from.
>
> In any case, it is too late to change it now...

Those who are interested in the full answer can look at this thread.

  http://thread.gmane.org/gmane.comp.version-control.git/9694/focus=9795

;-)

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-05-15 20:16 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-14 17:08 determine a linux kernel version of a patch file Pawel Por
2015-05-14 17:25 ` Johannes Schindelin
2015-05-15 12:08 ` Matthieu Moy
2015-05-15 17:03   ` Kelvin Li
2015-05-15 17:41     ` Johannes Schindelin
2015-05-15 20:16       ` Junio C Hamano

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.