A user proposed a localization to an open source project; however, they proposed a localization for an old version. I'd like to point them at the changes that were made between the two.
I know that I can show the difference between branches by providing the following link:
https://github.com/<user or organization>/<project>/master...master:<branch name>
Is there a similar interface for comparing certain commits? (and, ideally, only versions of a certain file) I'd like not to bother the potential contributor with learning git and doing the diff locally in the first place (although that I'll suggest that in the future).
I've tried
https://github.com/<user or organization>/<project>/master...master:<hash>
but that didn't work which is kinda expected; and I haven't found any reference on this matter either.
You can compare the difference between two commits on GitHub by using the below URL
https://github.com/{user}/{repo}/compare/{commit-1-hash}..{commit-2-hash}
For eg, to compare the diff between commits c3a414e and faf7c6f for the linguist repo of github, use the below
https://github.com/github/linguist/compare/c3a414e..faf7c6f
The above will show the diff like this:
You can go through the GitHub reference for more information.
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.
When creating a GitHub Pull Request, it is often that a file (script, lib, etc.) may be completely replaced (or introduced) with one from another repo. Sometimes, the file requires small changes. I'm trying to establish a standard for my team for how to communicate where the file came from and what changed. In the same way that you can craft a URL to highlight a specific change in a single repo, I'd like to be able to highlight a change across repos.
The reality may very well be that GitHub does not offer this. (I do a lot of research before asking questions. Consequently, the answer is often, "you couldn't find an answer because it is impossible.") In which case an alternative will be needed. One possibility might be to generate a diff in markdown and add it as a comment. (Notice I improved that answer back in 2016.)
One possibility might be to generate a diff in markdown and add it as a comment.
Good idea.
One alternative which would not depend on a PR comment would be to use git notes. They are not supported/displayed by GitHub since 2014 and they are criticised, but they would remain in your case possible way to leave... well a note describing where some of the PR files are coming from.
In github, is it possible to show the diff of a single file between two commits?
One can readily diff two commits, and it is possible to link to the anchor for a specific file in those two commits, but all files are included in that view. For example, https://github.com/adamginsburg/APEX_CMZ_H2CO/compare/a94a962db51e0f4e73ec3ba4170a0ca8269548da...adamginsburg:master#diff-22
I would like a similar view, but without the other files.
(I know how to do this on the command line with git, but I want to share this link with collaborators, so the command line approach is not relevant for this question)
I think your question can be consider a duplicate of this one :
How can I generate a diff for a single file between two branches in github
Unfortunately, the accepted answer doens't answer your expected behavior.
I really tried to exclude the other files without success, and since there not seems to have other means to filter it out but html anchor pointer, I guess what you already have is what best available with Github to pin point the change you want to talk about with your peers.
I can recommend you to use Vscode with the Git History, I know is not the same as having in Github but it allows you to see the changes of the code according to an specific file or the entire project, comparing with the actual code, see all the changes of specific file through the commits, I work with this tool and this is helpful for me, hopefully it will be helpful for you.
Git History Example Usage
You can use the GitHub File Diff extension available for Chrome and Firefox.
Disclaimer: I made this extension.
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'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.