I have a severe problem with my mercurial repository and I do not know what I have done wrong.
I am using the MercurialEclipse Addon for Java development on a local repository. Some time ago, I created some branches for better organization.
When I then looked at the graph in TortoiseHg, it looked kind of wrong to me.
As I know, the graph of the main branch should always be at the left side. But in my case, it is shown somewhere else.
What have I done wrong? Commit error? Or do I understand the graph wrong and everything is correct?
The left side are the parents of your current revision, with everything being in commit order (kind of sorted by date).
Well, if this isn't the standard, it's pretty common.
The default branch is not the main branch for everyone, as there is many ways to organize the code.
Related
I admit that I have very little experience with source control and git, however, in my past projects it has been useful to make commitments as backups. During this project, I decided to test out making a new branch. After working in it I decided to click 'checkout' master not knowing what it really did, now all my commits 2 weeks prior have been deleted, it's like I traveled back in time and all those commits I made never existed. All the files I had been working on are now gone and nowhere to be seen. I searched trash, I searched the project folder. They vanished. Did I screw up? Is there any way to recover this files? I searched all the branches without any luck. Thanks.
I don't know how Xcode's UI spells it, but the git command is git checkout #{1}. Look up reflogs and revisions, #{1} is how git spells "what I had checked out just before I did whatever just changed it".
Did I screw up?
Not necessarily! If you made commits on the new branch, everything is still there, on the new branch you created and worked on. So just checkout that branch again, and it will return!
now all my commits 2 weeks prior have been deleted
Ah, so you did make commits. In that case, be assured, nothing is lost.
But if you did not commit on the new branch — if you checked out master without committing your work from the new branch you were working on — then yes, you screwed up and it is all gone. The substance of git is commits, and whatever is not committed is not in the purview of git and is subject to unexpected loss. Loss due to checkout is a classic git trap; you would think it would warn you of the danger, but it doesn’t always do that.
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.
Sorry for this novice question.
What a want to do: I forked a website (superman.github.io) to write upon it and making it my website (batman.github.io).
Someone can help me with, How can I do this?
As a novice I have only changed the name, what's the next step?
Make changes..test.. then commit and push it(only when you are sure that you have done one significant change or corrected something or added feature). If accepted your changes will be accepted.
This is the general cycle. You can try to learn why we use github?
The sole purpose is to version control. So after you forked it you work on your local copy (by cloning of course) and commit multiple times but when you think you have added a feature or corrected something on the code then you will push it to the original repository. Then make a pull request to remote original repository. If accepted then you be happy.. you have contributed something significant.
I have a project with a single branch, default. I have been iterating on this single named branch for some time now and I have been using tags to mark version number milestones.
The project's source code changed quite a bit between tags 1.0.7 and 1.1.0 (current). However, there are some users on 1.0.7 that need a bug fix. So I checked out the source, updated to tag 1.0.7, implemented a fix and committed. That was tagged 1.0.8, and will probably be the last commit on the 1.0.x line.
I now have two heads on the default branch. I expected that. But when I tried to push to our BitBucket account, I received a warning from hg: "push creates new remote head". Reading up on this message, I get a lot of answers explaining why the message is there and for most people the answer is just to merge. However, I don't think I want that in this case. The two branches aren't compatible.
It looks like I can just use the -f option to force push the new head to the remote repository, however this seems to be discouraged both by hg help and various posts on the web without much explanation as to why. So what is the downside to doing this? It seems as though I can still update to whatever tags/revisions I want to continue working on. If I push that head to the BitBucket account, will I be shooting myself in the foot in some way?
Having multiple heads is perfectly fine.
If there are several heads and there's little indication as to their purpose, it may be difficult for others to see where they should continue and what is the head which contains the newest developments, e.g. which gains new features.
However by using the tags on the branch with clear versioning like you do, that problem doesn't exist either.
There's one small catch though: Mercurial will, upon clone, update to the newest commit in the default branch - e.g. the head which received the last commit. If that's the 1.0.x head of yours, that might be unfortunate. However you can fix this, by attaching the special '#' bookmark to the mainline or development head. Mercurial will always update to the head which bears that bookmark, if it is present - irrespective which head has the newest commit.
I have a few CVS WCs and, today, I took a look at one to make sure such-and-such code was present, but before I tell my colleague that it's okay, I need to make sure I'm looking at the right branch.
Somewhere I read that cvs log is the right way to go, so I cvs log [filename] and it listed all the branches in the project, but I wasn't sure how to see which branch I was using at the moment.
You want to do a cvs status and look at the Sticky Tag: line. there should be a branch listed in parentheses.
Sorry, I can't capture the output for you, thankfully it's been almost a decade since I touched CVS.