Bring receptor-fixes up to date with master

airr-community / airr-standards

AIRR Community Data Standards

https://docs.airr-community.org

Creative Commons Attribution 4.0 International

35 stars 23 forks source link

Bring receptor-fixes up to date with master #729

Closed bcorrie closed 8 months ago

bcorrie commented 9 months ago

I think we want to have our receptor fixes up to date with the master branch and the v1.5 release

@bussec do you want to have look at this? I think this is a good thing to do...

javh commented 9 months ago

@bcorrie, what's going on with this? Why merge from master into a branch?

bussec commented 9 months ago

@bcorrie #705 does currently not report any conflicts for a "rebase and merge" strategy, therefore the reverse merge from master is not necessary. If we want to do a rebase onto v1.5, then we should IMO do it on #705 directly.

bcorrie commented 9 months ago

@javh this branch is on v1.4 so when you pull it an try and use the python code you get airr v1.4 python. I need a version that has the new Receptor and is v1.5.

bcorrie commented 9 months ago

@bussec I don't object, but we don't use rebase and merge on our github so I am "nervous" about doing this. If you wouldn't mind rebasing receptor-fixes on #705 so it is synced with the master changes, I think that would be good...We can then close this without merging...

javh commented 9 months ago

That create confusing PRs. And there's already a force-push in #705 we'll need to worry about.

bussec commented 9 months ago

@bcorrie You can also do the rebase locally, on a copy of the receptor-fixes branch:

(On your local repo, we you are on master and master is at v1.5.0)
git branch -c receptor-fixes receptor-fixes-v1.5
git checkout receptor-fixes-v1.5
git rebase master

This way, we don't have to do the rebase on Github (although I think that it is not problematic per se, just a pain if you don't notice it).

javh commented 8 months ago

Doesn't seem necessary. #705 is conflict free.