Sebastian Moeller <moell...@gmx.de> writes: > Hi All, > > >> On Nov 28, 2017, at 23:37, Dave Taht <d...@taht.net> wrote: >> >> >> A flag day here is feasible. I will fiddle along the lines you describe. >> >> As for other flag days... >> >> I'm toying with the idea of fixing xstats in a separate branch. I really >> hate the idea of breaking backward compatability here, but I do suspect >> it will be a barrier to upstreaming, and it is, quite inefficient. > > > So if we go and change the statistics could we rename max_len to > maxpacket so that fq_codel and cake report the same information under the same > name. Sure the qdisc statistics are not terribly well coordinated naming-wise, > but maybe cake could show to be a good citizen here?
The justification for that change was that it's 7 characters. I really do want to open up the discussion of other stuff worth breaking along the way. > > Best Regards >> >> >> Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> writes: >> >>>> On 28 Nov 2017, at 18:48, Dave Taht <d...@taht.net> wrote: >>>> >>>> >>>> >>>> It sounds like your git-foo is stronger than ours! I'm not even trying >>>> to get head to work, tho my intent would be to promote cobalt to it. >>> >>> git checkout master >>> git pull (does the equivalent of git fetch origin; git merge >>> origin/master) >>> git merge cobalt (this will produce a minor merge conflict in sch_cake.c) >>> >>> fix merge conflict >>> >>> git add sch_cake.c >>> git commit (complete the merge - and create a merge commit in process) >>> >>> git diff cobalt - should return nothing…content of master & cobalt are the >>> same. >>> >>> git push (send this to github assuming above is true!) >>> >>> If it were me I’d now restart the cobalt ‘feature’ branch from this new >>> ‘master’ point. >>> >>> git checkout cobalt >>> git reset —hard master (resets ‘cobalts’ commit pointer and the current >>> tree on disc to where master is) >>> git push -f (send that to github -f means force) >>> >>> You’ve just created a ‘new’ history for the ‘cobalt’ feature branch, so all >>> ‘clients’ of that branch will see a ‘forced update’ message….you’ve broken >>> the >>> linear git history for that branch, so they’d have to do something like ‘git >>> checkout cobalt; git reset —hard origin/cobalt’ >>> >>> I used to be terrified of ‘git reset’ until I read >>> https://git-scm.com/blog/2011/07/11/reset.html - at that point I realised >>> all it (and the whole of git) is about moving pointers contained in branch >>> names. >>> >>> Of course I’d advise checking things carefully before doing force >>> pushes….but then I’d imagine many on this list have forks and hence clones >>> of the git repo in various places so it’s all recoverable. >>> >>> >>>> >>>> I didn't know about the cherry-pick option til now, either. I was doing >>>> a git format-patch thenewcommit, then a git am on my other branch. >>> I’ve just sped up your workflow then :-) >>>> >>>> For example, with this config, git fetch --all doesn't do anything. >>> git fetch —all goes and gets all the branches/commits etc from all >>> configured >>> remotes. You’ve only 1 remote (origin…which points at github) and it’s >>> likely >>> that since it’s not very active that you’ve all the commits etc already in >>> your >>> local git database. >>> >>> I have several remotes e.g. >>> >>> [remote "origin"] >>> url = g...@github.com:ldir-EDB0/sch_cake.git >>> fetch = +refs/heads/*:refs/remotes/origin/* >>> [remote "upstream"] >>> url = g...@github.com:dtaht/sch_cake.git >>> fetch = +refs/heads/*:refs/remotes/upstream/* >>> [remote "teg"] >>> url = g...@github.com:tegularius/sch_cake.git >>> fetch = +refs/heads/*:refs/remotes/teg/* >>> [remote "rmounce"] >>> url = g...@github.com:rmounce/sch_cake.git >>> fetch = +refs/heads/*:refs/remotes/rmounce/* >>> >>> so my ‘git fetch —all’ will go and look in all those places for things I’m >>> missing. Origin is my own github base cake repo (a clone/fork of yours), >>> ‘upstream’ is a pointer directly to your github repo, ‘teg’ & ‘rmounce’ are >>> pointers to their forks/clones. >>> >>> So to bring my master up to date with yours: >>> >>> git checkout master >>> git fetch —all >>> git merge upstream/master. (which should do a ‘fast-forward’ to where you >>> are since I intentionally don’t do any of my own work in master) >>> git push (update my own fork with all the latest stuff) >>> >>> >>> My own stuff (not that there is any anymore ‘cos it’s all in cobalt) would >>> then be rebased on top of the stable (but moving) master e.g: >>> >>> git checkout worldpeace (my WIP mega solution branch) >>> edit edit edit, commit commit commit >>> git rebase master. - replay all of my stuff on top of the updated master >>> edit - fixup any conflicts >>> git push -f (force update my worldpeace branch on github) >>> >>> >>> I like git, but I’m by no means a guru on it….and it took me about 2 years >>> to go from ‘I hate it’ to ‘ahhh I get it - sort of’. The git reset article >>> helped. Also having ‘git prompt’ enabled was a godsend. >>> >>>> >>>> [core] >>>> repositoryformatversion = 0 >>>> filemode = true >>>> bare = false >>>> logallrefupdates = true >>>> [remote "origin"] >>>> url = g...@github.com:dtaht/sch_cake.git >>>> fetch = +refs/heads/*:refs/remotes/origin/* >>>> [branch "master"] >>>> remote = origin >>>> merge = refs/heads/master >>>> [branch "for_upstream_4.16"] >>>> remote = origin >>>> merge = refs/heads/for_upstream_4.16 >>>> [branch "cobalt"] >>>> remote = origin >>>> merge = refs/heads/cobalt >>>> >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
