Skip to contentSkip to conversation

obtain commit list

DISCUSSION Arend Van Spriel 3 participants 3 messages Feb 17, 2016 – Feb 22, 2016

lore
Share & tools
lore
#0 lore raw

Hi Bob,

With the old wireless testing I used to provide a list of commits that were merged from wireless-testing into our internal repo. I am trying to determine the strategy to produce that list with the new wireless-testing using rebase stategy. Do you have a good suggestion for that?

Regards,
Arend

#1 lore raw
Quoted 7 lines · Arend Van Spriel

Hi Bob,

With the old wireless testing I used to provide a list of commits that were merged from wireless-testing into our internal repo. I am trying to determine the strategy to produce that list with the new wireless-testing using rebase stategy. Do you have a good suggestion for that?

Hi Arend,

So I suppose it depends somewhat on how you are using the tree, whether you are merging w-t still or rebasing your own tree, but here's a couple of barely tested ideas. [Corrections welcome, I just tried a few things that looked "close enough", but I suppose some cases where the downstream trees rebase could muck up the result somewhat.]

Suppose I want to see which commits have been added between two wireless-testing tags, I can do, for example:

    git log wt-2016-02-17 ^wt-2016-02-15 -- net drivers/net/wireless | \
        git shortlog

You'll see a handful of merge commits from me that don't end up in the upstream, but otherwise should see a reasonable set of commits that got merged, in this case a few iwlwifi patches.

Now suppose you're rebasing your internal tree on top of w-t/master periodically, e.g., you have:

    wt-oldbase -- A -- B -- C -- D

And rebase onto a new w-t tag to get (suppose A is merged upstream):

    wt-newbase -- B' -- C' -- D'

wt-oldbase and wt-newbase actually have dated tags associated with them, but perhaps it is too much work to look them up and you just use "wireless-testing/master" in your rebase script.

Then you could do the same thing but first get the base of the tree:

    wt_oldbase=$(git merge-base --fork-point wireless-testing/master D)
    wt_newbase=$(git merge-base --fork-point wireless-testing/master D')
    git log $wt_newbase ^$wt_oldbase

Hope that helps,
Bob

Signature · 1 line
Bob Copeland %% http://bobcopeland.com/
#2 lore raw
Quoted 9 lines · Bob Copeland
Quoted 7 lines · Arend Van Spriel

Hi Bob,

With the old wireless testing I used to provide a list of commits that were merged from wireless-testing into our internal repo. I am trying to determine the strategy to produce that list with the new wireless-testing using rebase stategy. Do you have a good suggestion for that?

Quoted 7 lines

Hi Arend,

So I suppose it depends somewhat on how you are using the tree, whether you are merging w-t still or rebasing your own tree, but here's a couple of barely tested ideas. [Corrections welcome, I just tried a few things that looked "close enough", but I suppose some cases where the downstream trees rebase could muck up the result somewhat.]

I am actually doing a rebase of our internal tree on new w-t.

Quoted 15 lines

Suppose I want to see which commits have been added between two wireless-testing tags, I can do, for example:

    git log wt-2016-02-17 ^wt-2016-02-15 -- net drivers/net/wireless | \
        git shortlog

You'll see a handful of merge commits from me that don't end up in the upstream, but otherwise should see a reasonable set of commits that got merged, in this case a few iwlwifi patches.

Now suppose you're rebasing your internal tree on top of w-t/master periodically, e.g., you have:

    wt-oldbase -- A -- B -- C -- D
Quoted 7 lines

And rebase onto a new w-t tag to get (suppose A is merged upstream):

    wt-newbase -- B' -- C' -- D'

wt-oldbase and wt-newbase actually have dated tags associated with them, but perhaps it is too much work to look them up and you just use "wireless-testing/master" in your rebase script.

Instead of doing 'git pull --rebase' I always start with 'git fetch' so I get:

+ cdf56a8...34bbd49 master -> wl-testing/master (forced update)

which give me wt-oldbase vs wt-newbase.

Quoted 5 lines

Then you could do the same thing but first get the base of the tree:

    wt_oldbase=$(git merge-base --fork-point wireless-testing/master D)
    wt_newbase=$(git merge-base --fork-point wireless-testing/master D')
    git log $wt_newbase ^$wt_oldbase

This time it only gave me the merge commits as there were no patches on our drivers (I submitted ours a bit late). Still it seems this could work for me so for that: Thanks!

Regards,
Arend