TortoiseSVN has a nice feature where I can quickly go back to older versions in the log in my working directory, in order to quickly determine where something went wrong. It is called "Update to revision." I can't find the equivalent in TortoiseGit. Is there such an option?
Go to the log dialog an switch to a different commit.
For that use the contect menu on a comit and select "Switch/checkout to this..." (cf. https://tortoisegit.org/docs/tortoisegit/tgit-dug-showlog.html). This, by default, will create a new branch wich can be deleted afterwards.
If you are searching a revision where a bug got introduced, you should have a look at git bisect, which does a binary search on the revisions in order to find a faulty commit (cf. https://tortoisegit.org/docs/tortoisegit/tgit-dug-bisect.html).
Related
When I choose "update from master", it creates a merge commit. I'd rather just have it re-base. Is this possible?
It does not appear that feature is currently included in GitHub desktop. What I normally do is click on the repository name in the drop-down menu in the top left and then click on "open in terminal". Then just follow the instructions here.
Update:
If you add this to your .gitconfig, GitHub desktop should rebase according to here.
[pull]
rebase = true
Second Update:
GitHub desktop 2.0 now supports rebasing built in! It is under the branch section of the top menu or you can use the shortcut ⇧⌘E
As #Taraz commented on the question, GitHub Desktop now has the option built in.
Branch > Rebase current branch
It's below the Update from master option
Using rebase instead of merging branches results in an easier to follow but less exact history of commits. Your team should agree under what circumstances you should rebase a branch. You should still always merge branches into the main branch through a pull request.
A suggested approach is to allow rebasing local changes that you have made but haven't shared with others, but to merge once you are sharing changes with others. This avoids trouble with rewriting history while still letting you easily catch up with changes as you develop your code locally.
Ref & Source:
https://learn.microsoft.com/en-us/vsts/git/tutorial/rebase?tabs=visual-studio#when-to-rebase-vs-merge
https://learn.microsoft.com/en-us/vsts/git/tutorial/pulling?tabs=visual-studio#update-your-branch-with-the-latest-changes-from-master
No. There was a feature request on their GitHub issue tracker for exactly this option a year ago, for which the response was
This idea is interesting for the future, but this is beyond the scope of our current roadmap.
Since then, another feature request, which is still open, has also been posted.
This might be a bug but I've never seen a bug in Git before, and I can't find any mention of this issue on the intertubes, so for now I'll assume user stupidity.
I use Git a great deal so I've set up an alias to bring up a birds-eye view of the git log: alias gl='git log --pretty=oneline --abbrev-commit'. So when I'm juggling between different branches, I'll frequently type gl to pull up the log, then q to exit. I find this super convenient.
But today I've noticed something strange: it looks like the most recent two commits are excluded from this view. Here's sample output from gl for one of my active projects:
b6e802d Location autocomplete; major refactoring and cleanup
d0cecdf Admin can download CSV of all users
0149ea2 Changed some verbiage on terms, privacy and profile page
5c0bdff Changed the link for find coach to go to the coaches page
But if I output gl to a file like gl > gitlog.txt, the first few lines are:
5e57f97 City autocomplete supported in mobile navbar search
df43a02 Add firstname & lastname to admin's users CSV download
b6e802d Location autocomplete; major refactoring and cleanup
d0cecdf Admin can download CSV of all users
0149ea2 Changed some verbiage on terms, privacy and profile page
5c0bdff Changed the link for find coach to go to the coaches page
Note that the top 2 lines in the latter are not present in the former.
If I open up the normal git log, all commits are visible as expected.
EDIT: I just discovered that I can work around this for now by piping (redundantly, I think) to less: gl | less shows all commits as expected.
I never noticed this happening before now (ie. the past couple weeks); I've recently updated to a newer Git version, could that be related? Has anyone else seen this happen? What should I do to figure out what's going on here? I don't even know where to start. Does this look like a bug?
Numbers:
Mac OSX 10.9.5
Git 2.2.1
Are any other numbers relevant?
Thanks for reading!
This isn't a complete answer, but I just made a couple observations:
This is only happening with one particular repository. The git log works fine on other projects.
I've added several more commits in the last day or two, and all of those commits are excluded. So it's not that the latest 2 commits are hidden so much as that every commit after a certain one are being excluded.
The earliest commit being hidden begins with the following line:
Add firstname & lastname to admin's users CSV download
Given the behavior of the error, I think there's a bug with Git's log printout that causes some commits to be hidden if a commit message contains &. So the lesson for me, for now, is to not use & in Git commit messages.
Just reproduced this behaviour happening with an old git version (2.6.x), but I updated it (2.19.1) and it was then fixed.
I am learning git and SVN in Xcode 5.
My question:
How should I revert back my previous commit when I commit my code?
Is there a way on a branch to revert back to previous commits?
For example, I commit a state, call it GOODSPOT, then I commit, a few times as my code progresses. Can I easily revert back to GOODSPOT, in a single click ? Or do i have to go through line by line. Similar to going back to an old snap shot ?
https://developer.apple.com/library/ios/documentation/cocoa/conceptual/ProgrammingWithObjectiveC/Conventions/Conventions.html
Here is what you can do
$ git push origin (branch)
You can go back to any commit you want to. Use the command-line interface (also known as Terminal).
As far as I'm concerned every time i try Source Control. It depends on whether you are working with people. I would just go back to the terminal and recommend it.
For versioning in Xcode, I do this:
- in my Developer directory I set up a project folder
- then Duplicate the Outer initial folder Xcode sets up and append its name with a number and two word description of where it's at
- this also duplicates development art, research notes etc
- the inner folder is all XCode cares about, so that one gets untouched
- when the finished app ships, I illustrate its development for proving copyright originality
I have an iOS project under Subversion source control and I am using Cornerstone as my SVN client. (I have also tried using XCode for this as well)
I've had numerous problems merging branches, and hope someone can help!
In the simplest test I have done, I have:
Created a new branch from the trunk
Made one small text change in one file in the new branch
Immediately attempted to merge the change back into the trunk from the branch.
When Cornerstone analyses the merge contents, it reports lots of tree conflicts and newly added files.
Other (potentially) relevant info:
I am the only person working on the project at present, so there are no other changes being made.
I have tried merging from branch-branch, trunk-branch, branch-trunk all with the same result
The server is using SVN v1.4.2, my client is v1.6.17. I am suspecting that this may be the cause, but am looking to get this confirmed if possible.
Thanks!
It appears that the problem is due to the server being v1.4.2.
I deleted my existing working copy and checked out a fresh copy, ensuring that the SVN version was set in the check-out dialog box to 1.4.
Now, when I attempt a merge, I only get the options to "Cherry Pick Changes" or "Advanced Merge". The "Synchronise a branch" or "Reintegrate a branch" options no longer appear, so these must be options not supported on 1.4.2 and be the cause of the conflict explosion I was seeing.
In summary, to merge between my branches it appears that I have to select the specific revisions that I wish to merge.
Using TortoiseGit (I'm trying to avoid command line usage) how does one delete all commits that accended from a certain commit, and "get back in the past" (example usage: continued doing something, figured I didn't like where it was going, and decided to go "back" disregarding all in between).
In short I wish to go 5 commits "back", and delete them afterwards.
Go to TortoiseGit -> Show log. Select the most recent commit you want to keep, everything above will be erased. Then right click on it and select "Reset "master" to this" and choose Hard. Be careful though because once you do this all the commits after it will be forever lost unless they are stored off in another branch somewhere.
I've never used Tortoise anything (unless you count the electronica group), but I'll give you this info in case you don't find a way to do it with the GUI or you end up deciding to go CLI after all.
As #Tuxified mentions, you can accomplish this with git reset --hard <COMMIT>. You need to specify a commit, which can be done in any of an intimidating panoply of possible ways; the most common have forms like HEAD~4, which specifies a commit 4 commits before the head of the current branch, and deadbeef42, which specifies a commit whose SHA1 starts with 0xdeadbeef42. If you're running linux or OSX, you can get the full details on commit specifiers via man git-rev-parse, under "SPECIFYING REVISIONS".
You can also rename the current branch (git branch -m new_branch_name) and then create a new branch with its head at the place you want to revert to. The advantage is that if you end up wanting to use all or some of the stuff you did there, you can still readily access it; and if you typo the commit, you're saved from a big holycrap moment. Plus git branches are super lightweight so the only real downside is that there will be another branch listed. To make the new master branch you would use git branch master <COMMIT>, and then you check it out. So the net effect here is the same as the first option, except that you still have your old changes saved in the branch new_branch_name. You can even merge those changes back in later, after new commits to master, if you feel like it.
Note that either of these techniques are considered "rewriting history" and will cause issues if you're sharing your repo with others. If you're being smart and pushing to a backup repo in cloud city or another pc, you will have to fix things on that end before you can push to it again.
This is probably way more info than you need right now, but if you end up using git a lot you'll probably want to learn this stuff at some point. Sorry I don't know how to use Tortoise...