* 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).