Tqdm2

[casperdcl]

local branch migrated from #34

[hadim]

@lrq3000 are you doing the modif and do you want me to take care of it ?

[casperdcl]

pandoc basically rules my life, I was going to use it to convert everything to rst and then manually tweak anything that was broken. Personally I prefer md, though... but since pypi doesn't support it we don't really have a choice.

[lrq3000]

You can do the stuff about version, I can do the rest :)

[hadim]

Well I am currently writing my PhD thesis with pandoc @casperdcl :-)

What do we do with version finally ?

[lrq3000]

@kmike is against reading from a file, so I guess we will use the AST.

[lrq3000]

Ehm... guys, could someone tell me how I can contribute to this branch? I cannot use my credentials...

[hadim]

git co tqdm2 then you can commit and push to it

[lrq3000]

Yes I checked out but I cannot push directly on tqdm/tqdm, my usual credentials are refused.

[hadim]

that should work now (I modified your right in the org settings)

[lrq3000]

Ok all good, I had to use my private key password, which is a bit weird but ok.

[lrq3000]

Ah ok great, that's why it worked :) Thank's!

[lrq3000]

I'm working on converting the Markdown Readme to ReStructured Text

[hadim]

I guess we can live with that but be carefull next time and overall never force push on master !!!

[lrq3000]

@casperdcl rebased it to clean history. You can try to git pull --rebase to fix your issue, or else delete and reclone the whole project :/ Anyway, the 2.0.0 tag is still referencing the correct commit, so it should be OK.

[lrq3000]

Arg no you're right, it messed up the repo:

"lrq3000 released this an hour ago · 52 commits to master since this release"

Not cool... @casperdcl, do you think this is fixable?

[casperdcl]

yeah didn't realise you'd released already.

[hadim]

Well unless I am missing something git tag is for 4d7aac9 and this commit never shows in the master branch...

[lrq3000]

Yes @hadim, you're right, it points to a non existent reference now. We can still guess what was the history state because we still have the correct commit message, but the commit hash is pretty much useless now...

[casperdcl]

would clearing all tags and then tagging the last commit v2.0.0 work?

[hadim]

@casperdcl seems to be the only solution... please never force push in master again :-D

[hadim]

I let you do it ( @lrq3000 or @casperdcl )

[lrq3000]

Yes, I'm doing that since I have the builds

[lrq3000]

AH! well I have another solution: I can force push the entire history back since I still have it on my computer. But I don't know what is the most messy option between the two lol.

[hadim]

If you still have the correct history, please force push it !

[casperdcl]

Was really meant to be rebase (bviously incl force-push) on the tqdm2 branch. really was surprised that you merged it in.

[hadim]

Be sure the v2 tag hash is in your history

[hadim]

@casperdcl yeah its not only your fault here, I also totally forgot that you were rebasing... sorry for that

[hadim]

Next time we should first merge the PR, create the git tag and then upload to pypi (in that order).

[casperdcl]

nvm. i don't mind re-rebasing if you still have old history. obviously this time i'll leave in the appropriate commit... or we could just leave the messy history as is? idk.

I would think just re-tagging is best since it keeps the clean history?

[hadim]

Well I don't what's best, I let you decide with @lrq3000

[lrq3000]

Yes the old hash is in my history so normally I can recover the whole old history.

Seriously guys I don't know lol, I just have a bad feeling about the new history being rebased after releasing stuff and all, but I don't know, we can technically keep it.

[hadim]

Well seems weird to me too so let just not rebasing this time and keep the old and correct history no ?

[lrq3000]

I follow my intuition, I push back the old history and @casperdcl you push your new changes on top. We will be careful next time to rebase and do all git maintenance before releasing.

[hadim]

he cant rebase without re writing the history...

[lrq3000]

OK, old history restored. The release tag seems to be restored OK

[lrq3000]

Yes but he did some additional changes to RELEASE and some other stuff, that's what I meant

[hadim]

Ok it will go in the next release i guess

[lrq3000]

Yes anyway we can always make things better :) So we would never release if we waited the project to be perfect ;)

[kmike]

We will be careful next time to rebase and do all git maintenance before releasing

Even better to do rebasing only before merging PRs. It seems this time we just had a really bad luck (quick rebase of merged PR), it wasn't anyone's error.

[casperdcl]

I'd rather say it was everyone's fault (incl. mine). I think we were all too eager having finally managed to contribute to the project proper. anyway nice work.

[lrq3000]

Yes we'll do better next time :) The release is good enough, it will be better next time, but I'm already quite glad the project reached this stage of maturity.