* obtain commit list
@ 2016-02-17 10:40 Arend Van Spriel
2016-02-17 14:07 ` Bob Copeland
0 siblings, 1 reply; 3+ messages in thread
From: Arend Van Spriel @ 2016-02-17 10:40 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: obtain commit list
2016-02-17 10:40 obtain commit list Arend Van Spriel
@ 2016-02-17 14:07 ` Bob Copeland
2016-02-22 13:12 ` Arend Van Spriel
0 siblings, 1 reply; 3+ messages in thread
From: Bob Copeland @ 2016-02-17 14:07 UTC (permalink / raw)
To: arend; +Cc: linux-wireless
On Wed, Feb 17, 2016 at 11:40:26AM +0100, Arend Van Spriel wrote:
> 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
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: obtain commit list
2016-02-17 14:07 ` Bob Copeland
@ 2016-02-22 13:12 ` Arend Van Spriel
0 siblings, 0 replies; 3+ messages in thread
From: Arend Van Spriel @ 2016-02-22 13:12 UTC (permalink / raw)
To: Bob Copeland, arend; +Cc: linux-wireless
On 17-2-2016 15:07, Bob Copeland wrote:
> On Wed, Feb 17, 2016 at 11:40:26AM +0100, Arend Van Spriel wrote:
>> 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.]
I am actually doing a rebase of our internal tree on new w-t.
> 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.
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.
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-02-22 13:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-17 10:40 obtain commit list Arend Van Spriel
2016-02-17 14:07 ` Bob Copeland
2016-02-22 13:12 ` Arend Van Spriel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).