Sourcetree - is there an equivalent of tortoise's Repo browser - atlassian-sourcetree

I'm investigating the features of sourcetree and it looks like it has everything I need, however I am looking for an equivalent of TortoiseSVN's Repo Browser.
This allows me to view a directory and see the date author, and commit id and for every file. This can be really handy so I was wondering how I can get the same view in SourceTree. I can use the "All Files" option on the File status tab to see all files, but this isn't quite the same.

I think tortoise git is exactly what you're looking for. There is a built in repo browser with it.

Related

How to get permanent link to a file with BitBucket server?

Sometimes I want to provide a link to some source code in the comment to an issue.
If I open repository in browser and find the fileI need, the link refers to master branch by default. It means that over time the code referred by the link will change, because the master will move together with commits history.
In GitHub and GitLab when you want to get a permanent link on a file you just opened, it is enough to press y on the keyboard and the link will switch from referring the master branch to particular commit hash it points to.
I.e. https://github.com/octocat/Hello-World/blob/master/README -> https://github.com/octocat/Hello-World/blob/7fd1a60b01f91b314f59955a4e4d4e80d8edf11d/README
At work I use BitBucket server (v7.10.1, if it matters) and unfortunately the y does not work, and I also do not see any button on UI to get permanent link. How can I achieve the same result (get permanent link) on BitBucket server?
I know a couple of tricks I am not satisfied with:
using Bitbucket Linky plugin for Intellij, but I want a more light-weight way
pressing History button on a file, and choosing the most recent one (but it does not give you the master hash, it gives the hash of the last change of the file. And also this button won't work if the file has a single version and never changed after the 1st commit)
Got to the version you want, and then click 'Raw file' (top right hand side of screen)
The path in the address bar should now be a permanent link. It will be the raw version of the file unfortunately, but it is a permanent link.

Egit missing compare with HEAD option when committing

When trying to commit changes to git from eclipse, I often want to look, what exactly changed in the file. For some reason egit doesn't give me that option.
It only offers to compare with working tree, which makes no sense to me, since it will show no differences.
For example TortoiseGit has the option compare with base. But it is inconvinient to use external tool for making commit. Is there any solution with egit for this issue?
Double clicking on the file should open the compare view between the central repository version and local work space version of that file. Hope that helps you

Github and Dropbox conflict risk?

I have a dev folder with all my projects. Some of these are on github and some are not. I also use Dropbox (with symlinks) to keep my data synchronised across several computers.
For example if I add something to my Documents folder on one PC I can then see it in the corresponding folder on another PC.
My question is: If I do the same with my dev folder (so the dev folder is synced by Dropbox on both PCs) will it cause problems with my pushing to github?
You don't ever want to mix code versioning strategies. Either all of your code lives in git (which is a good idea), or it all lives in Dropbox (which doesn't give you any history, hence a very bad idea).
When you add a source file to git, you should be forced to push it to Github so it can be pulled at a later date.
I get the feeling that you will run into issues when pushing the code - you'll be adding new files in through one source, but pulling through another - it'd turn into a headache more than a benefit.
I'm not sure exactly how you could "prove" that is ok. But, I have used exactly this development model with no issues. I personally, don't use symlinks in my dropbox but that shouldn't affect anything. All of my git repos are on my Dropbox. I've been working this way for over a year across OXS, Windows, and Ubuntu. All of my commits and pushes have worked just fine.
Also, this may be a repeat of this question: Using Git and Dropbox together effectively?
[edit:]
Actually one thing was recently brought to my attention is that you might run into an issue with line endings across systems. This post from GitHub (with a link back to an SO question) explains how to deal with line endings.
I had the same question and now my answer is "simply move your repository out of Dropbox".
As you can see, Using Git and Dropbox together effectively? is not the same question, but if you just search the key word "GitHub", you will see the debate about your confusing. And maybe you will make your own desition.

Way to see the whole commit history of a repo in Egit/TortoiseGit?

I'm looking for a way to see, though egit, to the whole history of my current git repo. From what it looks like, egit's "Show in History" will only show commits up to the current commit. With this I mean that if I do commit1 and commit2 and then decide to do checkout of the first, running "Show in History" of the project will not show up commit2.
Is there any way that allows me to see the whole history of the repo? I guess that'll be somehting on the lines of the git log master console command.
In other words, if you do checkout at any time your initial commit, how are you supposed to later be able to checkout the newer commits if your history won't show them?
I've been checking out, and it seems TortoiseGit "suffers" from the same problem. Is it indeed a problem or is just me that's not doing thing as we're supposed to?
Thanks
There is actually a button Show all Branches and Tags in the Eclipse history view to show all commits. See screenshot for more detail:
(It was already mentioned by L2G, but i did not had enough reputation to post a comment there.)
I would just open up gitk --all and look at the top. This will show you the entire history. I haven't worked with the other tools but if they don't have an --all switch, use gitk.
Hope this helps.
If you look at the toolbar under the History tab, there's a little icon of a path forking into two downward arrows. Its tooltip says "Show All Branches and Tags." I think that will do what you want.
I was having this problem too.
There is a 'Git Reflog' view available on the latest versions (eclipse Luna Service Release 1 [4.4.1] with eGit 3.5.1).
For background see: http://aniszczyk.org/2011/06/26/git-reflog-and-eclipse/
I like to use the context menu when right clicking on the repo folder. Go to TortoiseGit -> Show Log

Subversive: can't commit files inside a tags folder

I'm using Zend Studio 6.1 for Eclipse, which comes bundled with the Subversive plug-in.
My repo layout is:
/trunk/
/branches/
/tags/
My application code is in:
/trunk/application
I'm trying to add some view templates in:
/trunk/application/views/tags/index.tpl
BUT Subversive won't let me commit any of the files in that folder.
The message it gives me is:
"You are going to modify the tag on
the repository. Do you want to
continue?"
So I say "no".
It seems to be confusing my 'tags' folder with SVN's concept of tags.
I can't rename the folder because the framework I'm using enforces strict naming conventions between controller & view. I have a tagsController, so my views must be in /views/tags
I could rename the controller to something other than 'tags', but that sucks, because a tag is a tag, not a schmag ;)
Any ideas on how to get around this?
It's actually fine to say "Yes" to this warning.
A common layout for version control is to have 3 root folders:
/trunk
/tags
/branches
Once a trunk build has been released, the current contents of trunk are copied into a folder (e.g. "April 2008 version 1.3" or something) in tags. Generally speaking this folder should not then be modified, as it represents a specific build at a specific point in time, so Subversion will warn you if you attempt to change files in it.
However, in your case you have a folder which just happens to be called "tags", and contains trunk code, rather than tagged code, so it is perfectly right to say "Yes" to this warning and continue with the commit.
For more info, read the SVN Book, particularly Tags and Recommended Repository Layout
Maybe change tho another plugin? "tags" and "branches" are exactly the same thing inside svn, it is only the logical view that we, as users, have of both that makes them different. You should be able -- even though it is not a good idea IMO -- to commit here.
It is one of my gripes with svn BTW, branches and tags are different things.
Subversion's just trying to warn you that you might be accidentally committing to a tag - that is, a labeled version of code - which in normal usage you would never do.
In your case I believe you've just got a folder called tags where you're working on taglib type stuff. You might want to call it something different to prevent the warning, but it sounds like it's spurious in your case.
The trunk should usually represent the current working copy of your application, branches are there to support working on a previous version of an application (like they do with Firefox for example, they still release bug fixes to version 2.0 while the last version is in the trunk. Tags are just used to mark a specific release of your application, this makes it handy to check how code was at a specific release.
Why are you trying to change the tagged files?
I finally got it working.
I can only assume it's a bug in the Zend Studio for Eclipse's Subversive plugin.
If I try to commit by right clicking on the files in "PHP Explorer", it fails.
If I "Override and Commit" via "Team -> Synchronize with Repository", it works fine.
See this post for a slightly longer explanation of why the warning pops up :-)