As stated in this answer (suggested as a duplicate) : you can see a “both deleted” when branchA has a git mv oldfile newstandard commit, and branchB has a git mv oldfile newcustom commit. In that case, when trying to merge customBranch into standardBranch, git will report a conflict on three files : both deleted: … Read more
git stash is perfectly legitimate, though as Greg said, for some reason fixing the conflicts can get strange. But they are still fixable, you won’t actually fubar anything. The command as I know to re-apply the stash is git stash apply, though pop may be an alternative that I’m not aware of (or it could … Read more
You can do this with git filter-branch. The idea is that you have to change the encoding of the files in every commit, rewriting each commit as you go. First, write a script that changes the encoding of every file in the repository. It could look like this: #!/bin/sh find . -type f -print | … Read more
I ran into this problem when I had identically-named subdirectories within branches or tags. For example, I had tags candidates/1.0.0 and releases/1.0.0, and this caused the documented error because subdirectory 1.0.0 appears within both candidates and releases. Per git-svn docs: When using multiple –branches or –tags, git svn does not automatically handle name collisions (for … Read more
What you have here (with the Temporary merge branch 1 and same with 2) is due to git’s “recursive merge” method: o->branch1 = “Temporary merge branch 1”; o->branch2 = “Temporary merge branch 2”; merge_recursive(o, merged_common_ancestors, iter->item, NULL, &merged_common_ancestors); (merge-recursive.c, around line 1940). Git will do a recursive merge when the commit graph has multiple candidates … Read more
I used git-jira-hook and modified it to my needs, which should also work for you. For your needs, just remove the parts where it logs into Jira to check if the jira issue number regexed from the commit message is valid. If you don’t like python (git-jira-hook is written in python) and prefer bash, you … Read more
You could remove the secret keys using the git-filter-repo tool, see this explanation in the GitHub documentation. git-filter-repo is much preferable to the older git filter-branch. My old, now somewhat out-of-date answer: You could remove the secret keys from the repository using a hammer like git filter-branch. There is a nice explanation on GitHub’s help … Read more
Today there’s a better way of doing this: git subtree See this answer.
The reason that Git behaves like this is explained well in the answers to this question: https://softwareengineering.stackexchange.com/questions/194788/why-doesnt-git-merge-adjacent-lines-without-conflict/378258#378258 Essentially, because you need the neighboring lines to provide context to the change (you can’t just use line numbers, because something may have been added or deleted above), if the lines around it have changed you usually don’t … Read more
After a long walk on the internet, I found out that you can achieve what you want by writing directly in the git index and create the “gitlink” file type. git update-index [–add] –cacheinfo 160000 <subrepo commit hash> <submod path> Also do not forget to write the subrepo in .gitmodules (declare the external path, mostly).