I'm using github for students to submit a programming assignment. And I have a strict deadline for submission and I would like to be able to check the time that their release was submitted.
Unfortunately, github only reports how many days ago a release or commit was made. Is there any (quick) way to get the exact time?
If you move your mouse over the xx minutes|hours\... ago label, a tooltip will be displayed showing the UTC time the commit was created at.
Keep in mind that Git history can be rewritten (see git commit --amend or git filter-branch commands for instance) and that this displayed time shouldn't be considered as solid proof.
Well I'm jumping into this WAAAYY late, but I wanted to add a note about this particular use case.
nulltoken is absolutely right about the possibility of the times being modified. To circumvent this, I would make use of tags. Slap together a simple script that would pull the branch at the cutoff point, tag it (using an annotated tag), and then push the tag up to github. This gives you a snapshot of the branch at that particular time, stamped the time that the tag was cut AND the name of the tagger. That last part is particularly useful for students who think they are crafty.
https://git-scm.com/book/en/v2/Git-Basics-Tagging
Cheers!
Related
I'm working on a project that has a large number of json files that are never reviewed in pull requests but occasionally need to be changed. Recently we had to make minor changes to them, and github isn't allowing me to create a pull request with those changes. Instead it gives me:
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
I checked the diff locally and the actual code changes are pretty minor (maybe 200 lines changed), but there are millions of changed lines in these json files. Is there any way to tell Github to ignore them? Right now I am unable to make a PR so the changes can't go through our normal company review process.
I've tried using the .gitattributes file with *.json linguist-generated=true unfortunately that had no effect.
Edit: As suggested in the accepted answer, I contacted github support about this case. Their suggestion was to create a new branch with a small commit, create the PR, and then merge the actual branch that I want to deploy into it. This will update the PR, and while the diff still won't display, it will let me create a PR.
I have just been able to solve this problem via the gh command line tool!
gh pr create
Maybe this option did not exist when the original question was posted, but I'll definitely be doing this in future.
When you compare two branches on GitHub, GitHub has to go compute the diff for those changes using Git and then render it for you. In your case, you have millions of lines of changes, and Git doesn't perform very well in this case because the algorithm that's used to compute diffs is O((N + M)D). Thus, if you have a number of differences proportional to the number of lines, the algorithm is essentially O(N²). Having a large N makes that even worse.
GitHub has a limit on long a request can take, so your large number of changes are just not going to render in the interface. It may be possible to choose the branches you want even though the diff won't render and still open the pull request. If not, you may need to resort to using the API, which won't generate the diff for rendering and therefore is likely to work a little better.
I would encourage you to let GitHub Support know about this, if you haven't been able to find a way to do it through the UI, since they can notify someone to make sure the interface is usable to create a PR even if the diff can't render. You probably aren't the first person to encounter this.
You may also want to store these files outside of Git on some sort of artifact server and pull them down to your repository based on hash, in which case you wouldn't have this pathological case.
I using GitKraken as Git client. Here I see that, in file history it shows 1 hour ago, yesterday, 4 days ago,etc. Is there a way that I can see date time instead? I can see that in sourceTree.
GitKraken:
SourceTree:
Is there a way that I can see date time instead?
tl;dr: No, since it does not fit GitKrakens slim visual approach.
There is no feature to switch to absolute times, as far as I know. And it wouldn't really meet the purpose here: in SourceTree, you have a list (more like a table) of commits, each with id, author, message and time stamp shown.
GitKraken, following a more visual approach, focuses on the graph and the commit messages, but groups the commits in the graph by time period. There would be no point in showing a concrete date, since it would only show the date for a single commit, but not group commits by time periods. It would have to be shown for every commit separately, leading to a more table-like view, as it is in SourceTree.
In your example, You would have four timestamps cluttering your graphical repository view instead of a single 3 hours ago, roughly pinning down when the four commits where created.
You can, of course, click a commit in the graph to view its details in the top right, also showing author and commit date times.
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
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.