I've assumed maintainership for a given project on github. I've done so by cloning the repository of the original authors and pushing my own changes and developments. This was done in accord with the original authors, so they do not expect to work on this in the future. Nevertheless, my repository is marked as a fork of theirs, which makes it appear less official. Is there some way to denote a given repository as official? To swap the relation between my repository and that of the original developers?
I guess I could delete my repository, then ask the original devs to transfer theirs to mine, then let the original devs fork from that, then push my own changes from my local repo. But somehow this feels wrong. It would rely on my local copy. Migration of e.g. the pages branch might be causing extra trouble. I hope there is a cleaner solution.
There doesn't seem to be a clean way to do this.
It seems your best option is to ask GitHub support to convert your repository to "normal mode" as opposed to "forked from" mode.
Another solution is to delete and recreate the repository. However, this can be dangerous, as the wiki and issues data will also be deleted in this process.
If you have further questions about this then let me know in comments and I can amend my answer.
Related
I am studying how to use GitHub to collaborate with other people.
I have already set up Collaborators for one of my project and they have been able to download it.
But I don't know how to go for the next step. In other words, after they make their contribution; how are they supposed to upoad the result of their work, so that I can get it?
Yes indeed, by following the guides I have been able to make an update to a test project.
But everything is not quite clear yet.
I follow the process of creating-a-branch -> editing-something -> creating-a-pull-request -> merging-the-branch.
Then I delete the branch since it is no more needed. Apparently it works, but I can still see the deleted branch after, so it doesn't seem to be really deleted.
Starting July 2019, using GitHub Desktop, as part of its epic "branch pruning" and its 2.1.0 release, will prune those remote tracking branches for you.
Branches that have been merged and deleted on GitHub.com will now be pruned after two weeks.
See desktop/desktop issue 750:
We decided in taking a very conservative posture that we would only delete branches that aren't actively in use (hence the 14 days requirement) and don't have anything on them that's ahead of the default branch on GitHub. This combination, in addition to the branch being deleted on GitHub.com, seems relatively uncontroversial, but we're definitely going to listen to feedback we receive in the weeks and months after this ships to make sure it aligns with people's expectations and isn't overly aggressive.
Because we've taken an extremely conservative approach here, we don't intend to provide the ability to toggle it as a setting.
If you use a particularly branch frequently, this will never prune that branch, and it's restricted only to branches where there is no additional work that hasn't been merged into the default branch on GitHub.
In other words, we set this up intentionally such that users should never lose any work, which is our primary concern when deleting things. Hope that makes sense, and appreciate the feedback.
I am newbie in GitHub. I wonder why the option "Fork" is there when I have the option of cloning others' project and make my own repository on GitHub to extend it?
I guess the best answer I can think of is you might want to bring the fork back into the original branch, hence keeping it in the same repository.
I believe Forks were designed for playing with ideas or for suggesting changes to the owner of the repository, heres a link about it:
Github Forks
Yes, you are right, you can clone another repo and do any desired stuff.
But after that you need merge your updates into original repo (share your improvements with whole world) - and exactly for this purposes you need fork.
As far as I know, only this is the most flexible way manage your updates with original repo. And only this way can avoid undesired commit into original repo (repo owner able manage all propositions about any changes).
I just found the Mottie/tablesorter repository after implementing the –what I thought to be– original repository from Chrisitian Back.
The description of Mottie's repo says:
Github fork of Christian Bach's tablesorter plugin + awesomeness
Now when reading this, three questions come up:
Why is this one not marked as fork on github (usually if this is a little hint below the repository name if it's a fork - that's missing on this repo)
Is "+ awesomeness" in the repository description something specific (e.g. a JS lib) or is this just some kind of "marketing term" for this repo?
What are the major differences between this repository and the original one from Christian Bach?
Can I easily migrate to Mottie's repo (as it is much more vivid according to its Pulse)? What do I have to watch at when doing so?
As I mentioned in the issue that was opened:
Christian Bach added his GitHub repository on May 20, 2014, whereas my fork was created somewhere around June 2011. So there really isn't a way for me to fork from his repo now. Nothing is missing, except for a few documented changes to the options; but a lot has been added.
"+ awesomeness" was just added to distinguish this fork from the original; especially because most of the widgets available for this fork will not work with the original. I have tried different methods to help distinguish this difference... "+ awesomeness" is just one way. Now the main document page has "unoffical fork" at the top to try to make it more obvious. Eventually, I plan to rename this fork to Abelt (which has lots of breaking changes) to avoid further confusion.
I have some documented differences on the summary wiki page. Sadly, I haven't had the time nor the inclination to update it since version 2.7 (currently we're on v2.18.3). That should at least get you started. Other than that, I feel like the documentation is pretty extensive, so you can always fall back on it if you have questions.
If you have a basic set up working with the original tablesorter, then there is shouldn't be any major changes needed to just swap out the original with the forked version. With a more complex set up, you might have to tweak a few things. Post some code, I'll try to help. It won't be as bad as you think.
I forked a repository (blog theme) on github, I want to make some changes to it and use it as my site, but I don't want to push those changes to the genuine repo, since the creator probably will not be interested, is that OK?, I mean will this brake any rules?, of course in my readme file I will give credits to the owner etc.
Should I just fork it or is better to clone it locally and then push it on Github as my own project, with credits to the legal owner.
Thank you
Unless they added you as a Collaborator on their repo, you wouldn't be able to push changes to the original (although you could submit Pull Requests).
It's probably more of an "informal rule" that you should fork, but you wouldn't be breaking any rules if you just made a new repo - unless you were violating the license or copyright of the original work.
A benefit of forking would be that you can more easily incorporate future changes to the original author's theme back into your fork (ex. if they fix something that you didn't notice was broken, future new standards compatibility, etc.)
Other benefits of forking include: let the original author know that their work really was useful to someone and let others see that it has been forked, thus validating the usefulness of the work if they're considering using the original work, etc.
So, while the original author might not be interested in your work specifically, there are benefits to you and the community to forking.
I'm fairly new to Mercurial, but one of the advantages I see using Mercurial is that while writing a feature you can be more free to experiment, check in changes, share them, etc, while still maintaining a "clean" repo for the finished feature.
The issue is one of history. If I tried 6 different ways to get something to work, now I'm stuck with all of the history for all my mistakes. What I'd like to do is go through and clean up my changes and "collapse" them into one changeset that can be pushed into a shared repository. This is complicated by the fact that I might pull in new changesets from the shared repository, and have those changesets intermingled with my own.
The best way I know of to do that is to use hg export to create a patch of my changes since cloning, clone a fresh repository, and apply the patch to the fresh repository.
Those steps seems a little bit cumbersome and easy to mess up, particularly if this methodology is rolled out to the whole dev team, some of whom are a little resistant to change (don't get me started). TortoiseHg makes the process slightly better since you can highlight the changesets you want to be included in an export.
My question is this: Am I making this more complex than it needs to be? Is there a better workflow I can use to ease my troubles? Is it too much to expect a clean history where entire (small-ish) features are included in one changeset?
Or maybe my whole question could be summed up this way:
Is there an equivalent for this in mercurial? Collapsing a git repository's history
Although I think you should reconsider your use of branches in Mercurial (as per my comment on your post), using named branches doesn't really help with your concern of maintaining useless or unnecessary history - it just organizes them a bit.
I would recommend a combination of these tools:
mercurial queues
histedit (not distributed with Hg)
the mq changeset strip feature
to rework a messy history before pushing to a blessed or master repo. The easiest thing would be to use strip to permanently remove any changeset with no children. Once you've done that you can use mq or histedit to combine, relocate, or modify existing commits. Histedit will even let you redo the comment associated with a changeset.
Some pitfalls:
In your opening paragraph you mention sharing changesets during feature development. Please understand that once you've shared a changeset it's not a good idea to modify using mq or histedit, or strip. Using these extensions can result in a change to the revision hash, which will make them look like a new changeset to everyone else.
Also, I agree with Paul Nathan's comment that mq (and histedit) are power features and can easily destroy a history. It's a good idea to make a safety clone before using these extensions.
Named branches are the simplest solution. Each experimental approach gets its own branch.This retains the history of the experiments.
The next solution is to have a fresh clone for each experiment. The working one gets pushed back to the main repo.
The next solution - and probably what you are really looking for - is the mq extension, which can "squash" a series of patches into a single commit. I consider mq to be "advanced", and "subject to accidently shooting yourself in the foot". I also don't care to squash my commits - I like having my version history present for reference.