PS is that correct that the upstream name is purely a convention and git doesn't do anything different with regard to it, technically?
среда, 24 января 2018 г., 16:05:17 UTC+3 пользователь Yakov написал: > > Hi Mario, > > thanks, I've almost came up with the same workflow, but the issue with > merging on github side was an unexpected one. For now I'll be using this > workflow, although may be I'll add rebasing and also I have to admit that > merging updates of master to each branch is somewhat annoying, I'll > probably do something about it. > > Now, yesterday I've done some debugging and found the real problem that > broke those tests. It's not formatter was created too late, rather it > wasn't created at all because startup process (main) crashes. The cause > is QUnit overwrites window.isLocal as a boolean while TW defines it and > main tries to call it as a function. Commenting out QUnit.isLocal = > !!(location.protocol === 'file:'); (which is later is set to window using > extend(window, > QUnit);) in test/qunit/qunit.js fixes all tests (but LoadingSaving and > slices) and removes the error messages. I wonder if this may break > something, but from what I see, no error messages are shown in console and > looking through the whole tests.html source (search for isLocal and in > QUnit, in window) makes me think it's ok to remove (comment out) that > line – as far as I can see, this property isn't really used anywhere. I'll > probably comment this out in the next PR. > > Best regards, > Yakov. > > понедельник, 22 января 2018 г., 16:48:10 UTC+3 пользователь PMario написал: >> >> Hi Yakov, >> >> Along with fixing tests and issues I'll probably be learning using git >>> rebase: looks like it is an exact tool to deal with this mess >>> <https://github.com/YakovL/tiddlywiki/network>. If there are any >>> suggestions regarding this, let me know (as well as suggestions of how to >>> merge on GitHub in a proper way or other things regarding git/github >>> workflow). >> >> >> I do use the following workflow (for TiddlyWiki5), which never caused >> merge conflicts for me. >> >> I'm using 2 aliases for my local git repos: >> >> - origin ... points to my github account, where I do have write access. >> - upstream ... points to the "main project" account ... which only >> merges to master with pull requestes, even if I have write access! >> >> The most important rule for me is: >> >> - Never, ever *commit and push* to *origin remote master *branch! >> >> Except for >> >> - git status ... if working tree is clean I can go on. If not I need to >> commit to a "feature-branch" or I simply do a "git stash" >> - git checkout master >> - git pull upstream master >> - git push origin master .... to update origin repo. >> >> >> *My local workflow looks like this: * >> >> - git status ... if working tree is clean I can go on. If not I need to >> commit to a "feature-branch" or I simply do a "git stash" >> - git checkout master >> - git pull upstream master >> - git checkout -b new-feature-branch >> - git add . >> - git commit -m "detailed info" >> - git push origin new-feature-branch >> >> - Create a PR with github web UI. >> - Once the PR is merged start over with git status ... >> >> have fun! >> mario >> >> >> >> >> -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywikidev@googlegroups.com. Visit this group at https://groups.google.com/group/tiddlywikidev. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/e57a1588-1c99-47e5-a3a6-77d056499fa4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
