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?
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
