Is there a way to either scroll faster through the commit history OR go to the very beginning?
I don’t see an option, not even on desktop site.
I’m trying to figure out why a certain branch was made but that info is not in the README section because the README is not customized per branch.
I don't think github has this built in but there are a couple of ways using URLs.
With some trial and error using page? gets you to the beginning of the history fast: https://github.com/micropython/micropython/commits/master?page=242
This is less trial and error because you can enter nearly exact values: you know the current latest commit's hash and github says there's about 8450 commits so this one gets you to the first page: https://github.com/micropython/micropython/commits/master?after=cada971113e6db0cf9e0751e95dbe9217dd707b5+8420
There used to be a tool for it but the site is dead now so only the code is left.
But anyway, I'm fairly sure you'd achieve your actual goal way (examining log searching for something) faster without github, by using git itself. Github is fine for hosting but it's not exactly a complete git user interface. On th other hand git log/blame/rev-list commands are built for that. E.g. first commit hash: git rev-list --max-parents=0 HEAD
Related
Recently, we have started a group project and decided to use GitHub to share the code among ourselves.
For example, if I created a login page and my friend created a home page, how can I get it on my local machine.
I mean, whenever a change is made to the repo, do we need to download it all again?
The beauty of GitHub is that you can always go back whenever you feel like.
Whenever a changed is made by any of the teammate, it's a really good practice that you push that change. Even when it's a small one. After you've pushed your changes, your teammates would need to pull that change.
The best sequence for this is;
- git commit
- git pull
- git push
You'll have to pull the changes first as it would help you avoid getting merge conflicts. If you get any merge conflicts on any line, or any function, you'll resolve that conflict and follow the same sequence once again.
So, to conclude, GitHub is so easy to use and you won't have to necessary 'Download' all the changes once again. I would recommend you to setup via Visual Studio 2019 so that it becomes easier for you to just "pull" the changes whenever a new change has been made.
I added a small section to my portfolio, Skill Set, and after I made a commit sync and published it I can't find it on my laptop and it's not on the repository on github.com but it's still on my site which is hosted by github pages. Is there anything I could do to recover this really small section of my portfolio?
www.keithcarrillo.com . At the bottom of the one page portfolio is my skill set section.
First, do check your git reflog to see if you find a commit with a message regarding skill set: you might get it back that way (with git cherry-pick).
If that is not working, you can at least create a new commit with the content you can still scrap form your website.
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 am working with the GitHub GUI on Windows.
I did some work on my project which was successfully committed about a month ago going forward. Unfortunately other person who also works on this project recently committed the files I changed without realizing that he removed a huge portion of my work.
Now my question would be: is there an easy way of restoring my commits. This is not one commit. For the past month I made several very important commits to the project which got killed by the other party error.
I really don't want to go thru each file individually and re-aaply the changes manually, especially since I already got paid for that work.
How can I get my commits back?
IF you don't see your commit anymore in the history of the repo, that would mean the other developer has done a forced push (git push --force).
In that case, use git reflog (as in this answer) to find your commits back.
If yo do see your commits, then you could revert (git revert) the commits introduced by the other developers in order to cancel them, which should leave your branch in a state reflecting your work.
In both cases, this is a communication issue: you need to coordinate with the other developer in order for both of you to agree on a state from which to move forward.
I'm trying to set up version control for a programming-related tutorial. It's proving problematic because there are two different kinds of history:
There's the history of the project being built by the tutorial, which is available for each chapter and is what the reader will see. If I never planned to change already-written chapters of the tutorial again, I could just store each chapter as a tag in the history of the project.
Then there's also the history of the tutorial itself (not only the text, but my working on the pretend history of the project). If I find a bug I need to go back and fix in chapter 1, adding a new commit to the end doesn't work because I want to change how the project "appeared" at that stage, i.e. insert a commit in the project history and move the chapter's tag forward.
So far I've thought about a few possibilities- using git branches where each chapter is a branch that gets rebased to the front of the previous chapter whenever I make a change, a mercurial patch queue that I insert patches into, or structuring the tutorial around a set of modules that I could put in subrepositories.
I thought I'd ask if anyone has experience with this kind of thing and what solutions worked and didn't.
Rather than rewriting the history of the all project because of a late fix to an early chapter, I would rather isolate each chapter in its own branch, have each HEAD representing the current state for each chapter.
Assembling the all tutorial is then more a release management issue (deploying your tutorial by extracting the relevant informations from the Git Repo).
You can then develop your tutorial to achieve something similar to git immersion.
(Note: If this was more an ebook you were after, then git-scribe would have been a more interesting way to version it.)
The OP rusky adds in the comments:
I'm trying to version the sample code for the chapters, where each chapter's code is based on the previous chapter's code
That means any bugfix you add needs to be reported to the other branches representing the other chapters, in which case see:
In Git, how do you apply a commit of bug fix to the other newer branches? (avoiding cherry-picking, which is generally a bad idea)
using a topic branch
rebase --onto solution
git rebase --interactive is probably the most straightforward solution here. That will let you choose a specific commit to edit, then reapply all the subsequent commits on top of it. Shouldn't be much more difficult than a regular merge, depending on how extensive your change is, of course. Check out the part of the git rebase man page on splitting commits. That will let you keep your original version for historical reasons, then add a new commit just after it in the history where you can move your tag.
The great thing about CLI-based version control is you can use shell scripts to build up tutorial examples, something like:
#!/bin/bash
mkdir example_repo
cd example_repo
git init .
touch file1
git add file1
git commit -m "Added file 1"
git checkout -b branch2
echo "New line" > file1
git commit -am "Added new line to file 1"
You get the idea. It lets you build up a new repo from scratch to whatever point you like, and mistakes in the middle are easy to fix because you start from a blank slate every time. You can put the shell script itself under version control, or just comment out parts you don't need for different examples.
This is what tags are for. Tag your "snapshot" points, and go from there. If you need to go back and change something, do so and update the tag. And if you don't want people to see the in-between stages, simply create a second repository and incrementally check in your commits one tag at a time.