• Following thru as described in https://stackoverflow.com/questions/1726­8394/change-fork-name-for-github would have solved your issue / let you keep the old fork and let the local - your clone(s) and checked out branch(es) - on your local still in working condition (re-connected).

    A a fork is actually not that much different than a plain repository. The only difference is that the fork has an origin where as the repos is the origin, and therefore a change(s) in the fork that should go to the origin has(have) have to go thru process of merge request (MR). A MR can have as much you put into it. The owner of the origin then can either accept the MR as is, apply modifications to the changes to some parts before accepting, accepting a part - called cherry picking or reject the MR all together.

    Since the origin itself changes too and the MR when merged changed or partially is also a change versus what the fork 'knows', the fork has to be updated. I promised earlier to post about it... and it has to still stay a promise for now.

    To get some understanding of the guts, take a look at this book... http://shop.oreilly.com/product/06369200­22862.do - there are other good - and may be even free - books and tutorials out there... beyond the 10-day free Safari - read online - trial for this Oreilly book.

    I found this git - the simple guide, introduced as (sorry for the wording, it is the author's subtitle):

    just a simple guide for getting started with git. no deep shit ;)

    It lacks some graphics to visualize 'the flow of things' and some basic text or reasoning for why this particular flow.

    You can get that though together in you head with the simple fact about how edition id-ing works in git / gitlab / and the like - all based on Linus Thorwald's 'suggestion': the id of a new edition is construed from the previous id / parent id(s) and the new content - ids are also called commits or hashes - the latter hints how the id is constructed: it is actually calculated with an algorithm. I get it, you will say: every child knows the parent(s), and any parent was once a child (except it was the first of something... the empty repository. The ramifications show the ingenuity of this setup... in many aspects, for example:

    1. If you and i have the same id, we know that you and I have the very same content.
    2. There is nothing that can come out of thin air (except the first edition): everything is a very well trackable change to a previous edition (in case of the first thing, the empty repos is that previous thing).
    3. Confidence - I do not need to got a check... and miss a thing because of my imperfectness
    4. Performance - performance - performance... Since same hash means same content, no need for compare, which saves me time... not just for the compare, but I do not need to ship around and waste band with in order to know that it is the same or different and I need only what is different to have a complete pic of a new hash...

    Btw, until recently there was only one content and id that together create one and only one, unique hash. You can also say just content and define the content to include the id... just like a data record in a reasonable (indexed) setup of a database, where the id is a part of that record. The existing uniqueness is though more than sufficient for source code - that is verbose, has syntax and berars semantic... A content that would result in the same hash but would be different would be absolutely different in regard of those aspects.

  • Sun 2018.11.11

    'Following thru as described in . . . . would have solved your issue'

    Nope. That stackoverflow link has the same content as at:

    https://help.github.com/articles/renamin­g-a-repository/

    Maybe on a local copy but remember I had a public online repo fork.

    If you re-read 'Interesting note' above, you'll see that I attempted what is described. When attempting to get a new forked instance,
    GitHub knew the origins of the renamed forked copy, and just created the new fork as a copy over the renamed one. Did this twice.

    Reading the 'git - the simple guide' . . . .

About

Avatar for Robin @Robin started