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
Related
According to the Directus documenentation, https://docs.directus.io/guides/upgrading.html
the correct procedure to upgrade a current version 7 to newer version (7.x) is by pulling the new version from git:
git pull origin
However, this results in an error stating that the local changes e.g. in the files for migrations located in: migrations/db/schemas/
and some more locations will be overwritten thus the operation will not be performed (ending with an error).
Are the instructions on the linked page incorrect or am I doing something wrong here?
Any help is appreciated
/Chris
The issue appears to be that you've manually modified files within Directus, therefore your local Git is expecting the changes to be committed before updating, you may need to update by force, but any changes you've made will be overwritten.
Your config.php and uploads should remain untouched.
I would like to find solution for problem very well described here - in short, this problem can be solved with git branch -d $(git branch --merged) when commandline used - question is, is there possibility to do the same in TortoiseGit?
As of version 2.3 TortoiseGit only helps you for automatically cleaning up remote tracking branches.
You can do this automatically when you use the Pull/Fetch-dialog an check "Prune". Then all remote-tracking references which are not there on the remote are automatically removed. On Sync dialog select "Clean up stale remote branches" in the pull/fetch menu button.
Starting with version 2.3.2 you can open the Browse References dialog and filter for merged/unmerged branches. Using that filter you, then, can delete unneeded branches/tags.
I am trying to connect Xcode with Git (Bitbucket).
I read this question/"tutorial":
In XCode 4 how do I add a remote GitHub repository to an existing local project?
I follow all steps but I have a problem.
In Xcode 4.6.1 I always obtain this error:
"fatal "my_Repo" does not appear to be a git repository fatal: Could not read from remote repository."
What can I do? I am very noob with XCode.
Thanks!
This is usually linked to the Bitbucket url you are using for your remote repo.
I prefer using at first an https url (not a git one, or an ssh one), as listed in this BitBucket doc page:
https://accountname#bitbucket.org/accountname/reponame.git
Make sure your repo name and user name are correct, including their case.
The problem is on Xcode, at the moment to make the "Push". Xcode always shows: "Commit or discard the changes and try again." And isn´t true, there aren´t changes
As in this answer, you need to add and commit at least one change in order to be able to push.
The OP Kaisser mentions this tutorial "12 steps to using GitHub with XCode 4".
What he did was:
create an empty project and make the commit and the push, all OK.
Then, I copied my current project and renamed it
I am seeing a similar issue, starting today. I haven't made any commits or pushes to my BitBucket repo in about 2 months, but I never had issues before. XCode is now telling me that the repository "could not be reached" and to "Please verify that the repository is online and reachable and try again". I can commit from the command line. I wonder if this is an XCode 4.6.1 bug?
PS - not sure if I put this in the right place. I've never posted on SO. Correct me if I did this wrong!
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'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.