I have successfully been able to "diff" two files using the stash git API, however, each time you have to specify the full hashes of the commits, like so:
rest/api/latest/projects/{project}/diff/{path to file}?since={hash}&until={hash}
What I would like to do is something like this:
rest/api/latest/projects/{project}/diff/{path to file}?since=HEAD^^&until=HEAD
To resemble:
git diff HEAD^^ HEAD {my_file} (So diff between the HEAD and previous commits on that file.)
The only way I have been able to get a list of historical commits from the API is using the following from their docs:
https://stash.atlassian.com/rest/api/1.0/projects/JIRA/repos/jira/commits
which will: "the latest commits to the jira repository in the JIRA project" but not for a specific file.
From what I have been able to find it seems as though the API does not support this functionality.
I have been able to solve this, thanks to my Firfox console. The UI makes use of a history drop down showing the last 25 commits to the file with the following URL:
rest/api/latest/projects/{project}/commits?path={path_to_file}&until=refs%2Fheads%2Fmaster&start=0&limit=25
Related
Ok so we are trying to move from SVN (VisualSVN Server in house) to GitHub and we want to keep version numbers, all the posts so far I have tried to follow don't seem to find the version numbers. And I end up getting this 'Unable to determine upstream SVN information from HEAD history'
So we used the GitHub import utility to bring over the SVN repository but everything I have tried after that doesn't seem to work to allow us to access version numbering from SVN.
If anyone can help me please, I am not really great in either SVN or GitHub and all advice would be very welcome.
What do you mean by "we want to keep version numbers"? - The version info from SVN (revision numbers I think they call it) we need for historic records (we are getting rid of SVN) it would be great to see them as a message in the commit comments for historic SVN items. I may be using the wrong terms sorry.
I am not really great in either SVN or GitHub
Hire anybody proficient in at least one theme: SVN or Git (Github is service on top of Git and it's irrelevant to task "repository migration")
Another way is:
read and understand git-svn topic from Git Book
convert SVN-repository to local Git-repo
using fresh Git, discover and use find-rev subcommand in git-svn for your task:
When given an SVN revision number of the form rN, returns the
corresponding Git commit hash (this can optionally be followed by a
tree-ish to specify which branch should be searched). When given a
tree-ish, returns the corresponding SVN revision number.
We recently moved to git from svn (both using Eclipse). I am in the (perhaps bad) habit of writing my Java code first, getting everything to work and then going back and adding comments. In SVN this was easy. I would just create a Fisheye review with my Jira task. The review would have a list of all the files I changed and methods I added or modified. I would note it and abandon the review. Then I would edit all the files listed and add the comments.
However, Fisheye does not (I believe) work with git. I could do a git status to see the files I changed but the local branch is already updated so it will not list any files. And all it does is tell me I am something like one commit ahead of the remote branch but does not list any files.
Is there some way to see a lit of the files I have changed with git so I can add comments? And when I say I wait for my comments I really mean mostly for added classes and methods. If I do something like add a line or two to a method I will generally add the comment too.
changing comments on git commits is not that easy. Each git commit has a sha-checksum which also includes the previous git commit. If you change a commit you change the current commits sha-checksum. therefore you create a new commit. All following commits of your branch must now be rebased on top of this new commit.
The command line provides the git rebase -i [commitid] where you can do lots of modifications including changing comments on commits. I never did this with a GUI but egit might support that too. Just refer documentation on egits rebase feature.
I found out how to do this.
The "Synchronize Workspace" in eclipse appears to show all the changed files not yet pushed remotely. I have not done any pushes, so this showed me what files changed.
I'm transitioning from using Subversion in Eclipse for code management to GitHub in RStudio. It's starting to make sense, but I can't seem to figure out how to pull effectively.
Specifically, if I use the Pull arrow in RStudio, every file change in the repository automatically updates my local files without warning. I can see how many files were updated, but not what changed!
Here are the questions I'm hoping to get help with:
1) Can I preview the repository file changes in RStudio before I pull them locally? With SVN in Eclipse, there was an indicator showing files with a difference, and the option to view side by side.
2) If multiple files have been changed on the repository, is it possible to pull just 1 locally?
3) How can I revert a local file to a previous version?
Right now I've been trying to do this all within RStudio for simplicity. I haven't used things like the GitHub desktop client.
I appreciate the help!
I would suggest you better get used to the git's own tools to stay informed about your repository.
For example you could do following.
Before you pull, check your current commit logs
git log
This should show you how your current commits stack up. Note the latest commit id (first 4-5 letters would usually do)
Now after pulling you can see the difference using following command
git diff --color your_previous_commit_id..HEAD
If you don't like the changes and want to go back,
you can just reset to your favorite commit with following command. BTW run "git stash save" to keep a copy of your uncommitted changes.
git reset --hard you_favorite_commit_id
Note: that this will delete all your uncommitted changes unless you stashed them and put your local branch behind the remote repo branch you are tracking again.
Wondering where to put these commands? Check https://git-scm.com/downloads.
What's good about using these git tools is that if you switch between IDEs you don't need to search for same functionalities you had in your earlier IDEs.
Let's say I have a branch named feature/1. And also issue #1. I want to link that branch to that issue.
Is there a way to link that branch to that issue from the issue? Without making a commit.
Directly from GitHub:
References
Certain references are auto-linked:
SHA: be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
User#SHA ref: mojombo#be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
User/Project#SHA: mojombo/god#be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
#Num: #1
User/#Num: mojombo#1
User/Project#Num: mojombo/god#1
It seems that directly (as in user/repo/branch) is not possible, but maybe by using the id of the tree?
As mentioned in another answer, GitHub automatically makes links to various things, including other GH repositories, but not to branches within those repositories. When I want to do this, I manually make the link like this:
[a link to a branch](/_user_/_project_/tree/_branch_)
Where _user_, _project_, and _branch_ should be replaced with the parts of the branch's URL. For example, a branch in GitHub's "linguist" project:
[api-changes branch in github/linguist](/github/linguist/tree/api-changes)
Important:
GitHub's Markdown processor creates links using the exact URL value enclosed within parentheses. You must specify the URL considering how a browser would handle that link. If the URL specified is only the path portion (as in this example), browsers will treat the path as relative to the current page's URL. If that relative path begins with a slash ("/", also as in this example), then it will be relative to the root of the server of the current page's URL. Otherwise, paths that don't begin with slash will be treated as relative to the parent of the current page's URL. (This is basic HTML link specification.)
Do not forget to include the tree part of the URL when referring to specific branches of projects.
Since Sept. 2022, you can link a branch from an issue.
Nov. 2022, since gh 2.19.0 and the gh issue develop command:
$ gh issue develop 123 --name "my-branch" --base my-feature # create a branch for issue 123 based on the my-feature branch
$ gh issue develop 123 --checkout # fetch and checkout the branch for issue 123 after creating it
$ gh issue develop --list 123 # list branches for issue 123
$ gh issue develop --list --issue-repo "github/cli" 123 # list branches for issue 123 in repo "github/cli"
$ gh issue develop --list https://github.com/github/cli/issues/123 # list branches for issue 123 in repo "github/cli"
But, as noted by NotX in the comments (in Dec. 2022):
The new linking feature won't work for branches in other repos though.
So if you have a dedicated issues repo holding the issues from all the other repos, you've still go via mentioning.
Note that from April 2013 ("Branch and Tag Labels For Commit Pages"):
Any commit can mention the branch it is part of:
If the commit is not on the default branch, the indicator will show the branches which contain the commit. If the commit is part of an unmerged pull request, a link will be shown.
That means referencing a commit from the issue will allow the user to see the branch (by looking at the commit), and even to see a link back to the issue (still by looking at the commit).
You can't reference the branch directly.
But you can make a reference to a branch compared to another branch. If you enter this:
https://github.com/user1/repo/compare/branch1...branch2
it will render as
branch1...branch2
Also, you can compare branches across forks. If user2 has forked repo, this works:
https://github.com/user1/repo/compare/branch1...user2:branch2
I was looking for the same possibility in Git, but nothing was available so I decided to directly refer the brach with a markdown link by using the Hash reference.
# Issue02
## Commit Hash _<hash_number>_
...Rest of comments in the issue...
So, now in my organization we always do that reference when opening or closing an issue. It must be refered to a certain Hash and indirectly it is refered to the corresponding branch.
I guess you already now, but if not, to get the hash you will use git log
Note: It is not referencing to a certaing branch but a commit,
With some hours of work I think it is possible to automatically do this and create a command line tool,
Once a directory is renamed, "git log" no longer shows its history, unless you force it to, by using "git log --follow".
Is there a way to force the "history" function on the GitHub web UI to use "--follow"?
Alternatively - is there any way to see pre-rename history on GitHub?
Update June 2022: GitHub now supports viewing commit history across file renames and moves!
.
2011: This was requested in 2009 (Request 129), and then in 2010 (Request 897), and then in 2021 (github/feedback discussion 6964):
I like this.
There could be other issues preventing us from plopping the --follow argument in.
I'll take a look and let you know.
... and then nothing for now.
Note: Git 2.6+ (Q3 2015) will propose that in command line: see "Why does git log not default to git log --follow?"
Note: Git 2.6.0 has been released and includes this feature. Following path changes in the log command can be enabled by setting the log.follow config option to true as in:
git config log.follow true
I wrote a chrome extension to enable this. Source on github.
I've sent a mail to support#github.com (salutations removed):
Will "git --follow" functionality ever be implemented on Github? If yes, where can I track its progress?
(By "git --follow", I mean a way to easily see the object revisions before a rename. Currently, when an item is renamed, Github doesn't offer an easy way to display the directory / file history.)
Response:
> Will "git --follow" functionality ever be implemented on Github? If yes,
where can I track its progress?
This is something a few other users have requested as well -- we might add it in the future. We currently don't have a public issue tracker, but I'll put another +1 next to it on the Feature Request List™ for the team to see.
So, "git --follow" is unfortunately not supported yet.
To get such functionality in the meantime, I guess you could write a user script that looks up the hash of the parent object, (recursively) look up its history and render the result.