If you do a rollback in Heroku it will checkout a previous commit on the Heroku side. We know that. However, how do you restore it to the HEAD commit?
It seems that you actually have to modify your local HEAD, and then push to the repository. Otherwise,
$ git push git#heroku.com:appname.git HEAD:master
Everything up-to-date
and nothing happens, i.e. no new release is created.
The easy solution is just to do some innocuous change like a bundle install, commit, and push. But I was hoping to find someway to bring apps up to the HEAD if they weren't before. Any insight? Am I missing something?
When you do a rollback, you're creating a new deployment to an older change #. The other version is still out there in git. So to go "forward" to the newer change, you'd roll back again, this time to the deployment at that hash number.
Related
I'm totally new with Mercurial.
When commiting and pushing my changes through IntelliJ Idea, I've accidently pushed the Commit and Create MQ patch button.
The commit went through, but push didn't. I force pushed my changes successfully (not a very good thing to do), but I cannot commit anything now.
I get this error:
1 file failed to commit: tip fix. abort: cannot commit over an applied mq patch
The fix was very simple:
I had to type these two commands in IntelliJ Idea terminal:
1. hg commit (with your message commit)
2. hg push
Now everything is back to normal.
A couple of days ago we did a long due migration from Redmine 0.9.3 to 2.2.0. Everything migrated perfectly and seemed to work right away.
But we just found one function that no longer works. Redmine no longer seems to listen to the repository keyword. They are still found under Administration -> Repositories and it's still possible to browse the repositorie and see the changes. But Redmine will no longer associate revisions to redmine ids.
I already tried to remove the keywords, save the changes and readd them. No succes.
I told Redmine to re-read all the changesets using the command "rails runner "Repository.fetch_changesets" -e production"
But nothing seems to work.
Any ideas?
Have You changed subversion system or commits numbering?
Link to a changeset with a *non-numeric* hash: commit:c6f4d0fd (displays c6f4d0fd).
Or, this can be bug in Redmine
http://www.redmine.org/issues/13000
When you change the reference keywords they only work for new committs. If you want them work for old commits you have to delete the repository inside yor redmineproject and readd ir there. On the next fetch of changesets (if you have fetch changesets automatically activated yust openthe repository tab in your project) the keywords are used for all commits, including old onea.
For example you have a commit with "#1234" as commitmessage and the default keywords (ref, reference issue [as far as I remember]) rhe ticked 1234 would not be connected to the commit. Now changing the keywords to just * (single star means every issuenumber is bind without keyword) it would still be not connected. When now delete, readd and refetch changesets the issue 1234 would be connected to the commit
In my company we have a subversion server and everyone is using subversion on their machines.
However I'd like to use git, committing changes locally and then "push" them when I'm ready.
However, I can't understand what happens in the following situation.
Let's say that I made 3 git commits locally and now I'm ready to "push" everything on the subversion server. If I understand correctly, git svn dcommit should basically make 3 commits sequentially on the server, right? But what happens if in the meantime (let's say between the second and the third commit) another colleague of mine issues a commit?
The scenarios I can think of are:
1) git kind of "locks" (is that even possible?) the subversion server during commits so that my commits are doing atomically and my colleague's one is done after mine
2) The commit history on the server becomes mine1-mine2-other-mine3 (even if 'other' should fail since my colleague doesn't have an updated working copy at that point).
I think it's #2, but perhaps the committing speed is so high that this seldom becomes an issue. So which one is, #1 or #2?
No locks are not supported in Git, it's not a Git way (Git way is branching and merginig).
With git-svn you'll get mine1-mine2-other-mine3 history. If you need atomicity, have a look at SubGit project (it is installed into the SVN server and creates a pure Git interface for the SVN repository).
There was a similar question recently that might be interesting for you.
If you are lucky then number 2 but most of the time you aren't that lucky. In my experience when I dcommit a lot of commits and someone else commits while doing that usually 2 things happen:
It stops with dcommitting your other changes.
You lose the commits not-yet dcommitted.
Number 2 is really really annoying. The main problem is that you need to be totally up-to date to use git svn dcommit. This is because git-svn doesn't let the server merge revisions on the fly. (Because it would require both committers to have a working tree with both changes).
The only way to solve this are the following steps which I found here
Open .git/logs/HEAD
Look for your most recent commit (note that these commits are sorted
by “unix time”, although you can also find the latest one by reading
the shortlog there
Confirm that the commit you found is the right one: git show
git reset --hard hash from log
git svn rebase
git svn dcommit
Following this procedure allows you to take off from where it failed. I hope they fix this soon but they said this isn't priority for them yet.
Ofcourse if you commmit small groups and have a fast connection to the server it shouldn't happen that often. (I only got it 2-3 times when actively working and committing every day for 6 months).
I just downloaded the free trial of Bamboo continuous integration server, and created the first plan with nothing but downloading the source code from the git. I have a local git repository on the bamboo machine so the git URL is pointing to a local path.
The problem is that when I run the job, it never finishes even after waiting for an hour. This is the last lines of the activity log:
07-Apr-2011 20:03:23 Checking out revision f9dc82500914333ed4bbdae5ed038771fd658c3c.
07-Apr-2011 20:03:23 Creating local git repository in '/home/bob/bamboo-home/xml-data/build-dir/DEV-DEV-1/.git'.
From the shell I can go to the directory shown in the log and see that the source code were cloned correctly to the bamboo working directory. But the job will never finish and the log will not have any more update from here. I have to manually terminate the job. Any ideas? Do I miss something?
Just a guess, since the Bamboo instance we have at work pulls from Accurev and not Git, and I've never run into this problem myself - but it may be hung because there isn't a builder defined for that plan. You might try defining a builder (even if it's one that you know will fail) just to see if it makes it to that next step.
I had very similar problem.
It's not very original solution but I just uninstalled bamboo and installed it again.. Now it works now
I'm trying to do git svn dcommit, however, one directory continues to fail on me and therefore stops my commit and continue to get this error:
Filesystem has no item: File not found: transaction '43999-6', path '/path/to/folder' at /usr/local/git/libexec/git-core/git-svn line 572
I tried adding the folder back in but i continue to get that error. can I remove a commit from the tree to bypass this? Not sure what else to do here.
edit
some of the following don't fully answer my question, but they seem to be in the right direction:
issue about tracking and not detaching the HEAD
issue about rebasing
issue about recovering commits
The last issue seems to be what I wanted, but with the size of my repo (last time, took me around a whole work day to checkout the entire thing), and the little amount of work I would have lost by just doing a hard reset (which ultimately seemed to do the trick), I went for the hard reset option.
svn reset --hard didn't work for me
the reason of this is that when doing a dcommit to svn, it seems like the commit that deleted the file appears to be done in both git and svn at the same time but the link is lost.
The solution that worked for me was to reset master to the commit before the problem, then merge all sucessive commit back to master (except the faulty one), then redo the file deletion.
there may be a more elegant solution...
side note:
git svn DOES svn rename/move files correctly.
It (either tortoisegit+mysgit or jgit/egit) does it automagically all the time ;)
I don't think git-svn actually supports renaming files. I get this error every time I try to rename something. I always end up having to rename it with svn and then rebase with git-svn.
Update
This is likely due to the fact that git-svn doesn't play nicely with spaces in URLs. I often have to rename project paths in order to get them to work with git-svn. Of course, this isn't an acceptable solution for projects that actually have other people working on them. For those I simply have to resort to using svn to move files. It's a huge hassle.
I was able to work around the problem of git svn not working for repositories with spaces in them by patching git-svn.
I updated the url_path function to:
sub url_path {
my ($self, $path) = #_;
my $url = $self->{url} . '/' . $self->repo_path($path);
if ($self->{url} =~ m#^https?://#) {
$url =~ s!([^~a-zA-Z0-9_./-])!uc sprintf("%%%02x",ord($1))!eg;
$url =~ s!^(https?)%3A//!$1://!;
}
$url
}
This ensures that the spaces in the url are encoded correctly.
It seems to work for me, but hasn't been tested thoroughly.
I believe the problem should be fixed in Git >= 1.8.0
You should consider to upgrade it.
Home page: https://github.com/git/git
I know this is an old question but I had this exact issue recently and wanted to share how I fixed the problem. Admittedly this is not a nice solution but it allowed me to complete my commit. I did the following:
Added the folder/file under complaint back into svn using svn.
Committed my original code from git to svn (git svn dcommit --rmdir)
Deleted the folder/file in git and committed this to svn.
This meant I had an extra 2 small commits, one to add and then another to remove the offending folder/file but after this everything worked as expected again. I know this isn't a nice solution and it doesn't address the root of the problem but at least it allowed me to commit my code. Hopefully this can help someone else in this situation needing a quick fix.