I got the problem with resolving merge conflicts within sql files.
MenkeTTA#909086 MINGW64 //FILE0019 (master)
$ git pull
remote: Microsoft (R) Visual Studio (R) Team Services
remote: Found 5 objects to send. (5 ms)
Unpacking objects: 100% (5/5), done.
From https://***
d58a69b..4830c58 master -> origin/master
warning: Cannot merge binary files: example_StoredProcedure.sql (HEAD vs. 4830c5886d3e1eac5ac76d1d49496afb43f444c3)
Auto-merging WRR - example_StoredProcedure.sql
CONFLICT (content): Merge conflict in example_StoredProcedure.sql
Automatic merge failed; fix conflicts and then commit the result.
When the merge conflict is created git isn't creating a pre-merged file with the competing changes as in the usual structure:
/SQL-File/
<<<<<<< HEAD
competing change A
=======
competing change B
>>>>>>> branch-a
Git is treating both files as binaries – but only for the merge-conflict operations (normal merge without conflict works properly). I can choose my own version of the file or the pulled competing file from the remote as the new head for the next push.
I reproduced this conflict with a normal .txt file. Git is treating the merge conflict then as expected with creating one pre-merged file with both competing changes/commits where I can manually fix the code how I want to.
To make git recognize the sql files as text I added
.sql diff
to the .gitattributes file like it's described here. Does anyone know how I can make git to create a ordinary pre-merged file with both versions of the competing commits when working with sql files?
First, a quick note:
To make git recognize the sql files as text I added
.sql diff
to the .gitattributes file ...
The .gitattributes line should read *.sql diff (I've fixed the linked answer, which is on a question about getting git diff to treat the file as text). However, if the file really is text, you may want, or even need, *.sql text. Note: this will not help at all if the file is not text. If the file's content is UTF-16, it is not text to Git, at least.
Consider marking the file as example_StoredProcedure.sql text, i.e., not all .sql files, just this one particular file. I'm also curious to see whether just marking it diff suffices! Update, Nov 2019: apparently marking the file as diff is not sufficient, though I have not verified this myself.
(The difference is that the diff attribute tells Git how to show the file in git diff output,1 while the text tells Git that instead of using its built in guessing algorithm, it should, for all purposes, use the setting to decide whether the file is text. The guessing algorithm consists of scanning an initial chunk of the file's contents to see how many "text-like" characters there are vs "non-text-like" characters. Probably there should be a special allowance for UTF-8 Byte Order Markers at the top, but there isn't. Curiously, during filtering, there are explicit checks.)
1Well, it's actually more involved than just showing, but I think this is a good way to start thinking about the issues. Note that you can augment the diff setting with a driver. It's not clear to me how the low level file merge interacts with a diff driver and I do not have time to experiment with it right now.
Longer explanation
warning: Cannot merge binary files: example_StoredProcedure.sql (... vs ...)
tells us that you are correct, that Git is treating the three versions of example_StoredProcedure.sql as binary. (I see you added this output after the initial question; good thing, since it's the key!)
But why did I say three versions, when the line goes on to say:
HEAD vs. 4830c5886d3e1eac5ac76d1d49496afb43f444c3
Git is being a little lazy here: all merges involve three inputs, not just two. One of these is the one you supply explicitly—or, as in this case, git pull ran git merge and git pull itself supplied the big ugly hash ID 4830c5886d3e1eac5ac76d1d49496afb43f444c3.
The second input to a merge is always the current commit, aka HEAD. You normally get this by being on the branch in the first place: HEAD names the branch-name, the branch-name identifies the commit, and this is where you want the final merge commit to go, so it all fits together.
The third input—or internally, first; internally the "theirs" version is the third input—is one that Git computes for you, based on the HEAD and other or --theirs commits: Git walks through enough of the commit graph to find the best common ancestor commit.1 It's this common ancestor commit that determines which files need merging, and if a file does need merging, the built in merge driver needs to use diffs to get textual changes to merge. For both this and for git diff, Git has a differencing engine built in to it (modified from LibXDiff).
Hence Git can, in effect, run:
git diff --find-renames <merge base commit> HEAD
to see what we did to each of our files, and:
git diff --find-renames <merge base commit> <other commit>
to see what they did to each of our files. Then:
If we changed a file and they did not touch it at all, the merge is easy: take ours.
If they changed a file and we did not touch it at all, the merge is easy: take theirs.
If we both changed a file but made the new file exactly the same, the merge is easy: take either one (ours, really, since it's in place).
Otherwise, attempt to combine the changes.
For speed reasons, Git uses the hash IDs ("blob" hashes, for the file's content) to accomplish the first three bullet points without ever having to fire up the file-level diff. This can, and does, merge unconflicted binary-file changes. It's only the final stage, where all three blob hashes differ, that requires a textual diff so as to combine changes.
Obviously, if Git can't diff the file, it cannot merge the two diff outputs. But does just marking the file as text-diff-able (pattern diff in .gitattributes) make the merge proceed? What happens if you set a diff driver, does the low-level file merge code use that driver? It "wants" to use the xdiff internal interface to find hunks; that's a lot easier than interpreting text output from a driver; you probably have to define a merge driver to get a detected-as-binary file to be merged, even if you have marked it as diff.
Additional note, Nov 2019: Since Git 2.18, Git has the ability to convert between committed UTF-8 data and in-work-tree other-format data. To use this, set the working-tree-encoding attribute. For instance, [the gitattributes documentation] shows an example line:
*.ps1 text working-tree-encoding=UTF-16LE eol=CRLF
that would keep all *.ps1 files in UTF-8 internally (in the frozen, committed files inside each commit) but keep the useful-format versions of those files in your work-tree in UTF-16-LE. I have no data as to whether this would work with these SQL files.
1In all cases, but especially in problem cases where there's more than one best common ancestor, git merge's behavior actually depends on the strategy you chose. The usual recursive strategy will merge the merge bases, commit the result, and then use that commit as the merge base! Other merge strategies work differently.
Is there a way to find the list of unstaged files during merge?
That is, when we merge from branch A to branch B, few files get merged (staged) if there are no conflicts. Suppose if I discard some of them (unstaging/discarding), How will I get the list of those files?
Assume I have merged couple of months ago, I wouldn't remember the unstaged files.
Agreed: the merge commit would only reflect staged files (automatically merged or resolved after merge conflict)
And don't forget that you could also unstaged part of one file, and merging the trest of that same file.
What if I want to merge those files now again?
You could, for testing, reset your HEAD to one commit before the last merge commit, effectively cancelling that merge.
Then merge again (the same source commit to your moved HEAD) and list the files being merged: git diff --name-only
You can compare that list to the one of the previous merge commit:
git diff-tree --no-commit-id --name-only -r <commit-ish>
The difference between the two lists would be the list of files that were unstaged during the initial merge.
I'm not terribly familiar with Mercurial, and I have no idea how I managed to do this in the first place...
https://bitbucket.org/agent154/controlsfx/branch/wizard-before_advance?head=d6dda855fd9885d3413121068e73c0fa73e3cc2e
See above link. My branch "wizard-before_advance" has multiple heads. I've been doing development using IntelliJ IDEA, but I have TortoiseHG installed. How might I fix this?
What you probably did was make two separate commits with revision 22ec847 as the parent. This might have occurred in two separate clones, where you committed and pushed both of them to bitbucket (expect you'd have needed a -f on the second one). It could also have occurred in a single clone because you updated to an old version and committed there.
Regardless, it's not a problem. All you have to do is merge them. The message tells you which two revisions to work with.
d6dda85
2d5a883
So we update to one of these, and merge the other.
% hg update -r 2d5a883
% hg merge -r d6dda85
<Run checks, resolve conflicts, and basically make sure everything is good>
% hg commit -m 'Merging divergent heads'
This will leave you with a graph like this:
o---o---o---------M---
\ /
\-o---o---o
Where M is the merge change-set. Simple
I am complete Noobie in Liquibase (and jenkins) deployments.
We have a SQL table which can be modified by 2 separate git repositories. We have one liquibase based deployment for this table for each of the git repos.
ISSUE:
Liquibase will try to update the DATAGBASECHANGELOG after each deployment. Thus breaking the cycle of continuity between 2 commits in the same git repo.
E.g.
We have a table A, the script for which is A.sql and it is in two repos X and Y. The table script can be modified in either of the two repos X or Y. Now if I do the first deployment using the repo X, second using repo Y and then change the file A.sql in repo X, then next repo X deployment with fail because of mismatched changesets.
What we think can solve this is that we need to have 2 different DATABASECHANGELOG tables for each repository deployment?
Any help or pointers will be of great help.
Mercurial - Is it possible to merge changes from the trunk to a branch, within the same repository?
If yes, is it possible with TortoiseHg?
There are two things you can do, merge or transplant. These answers assume the command line, you may have to search through your menus in tortoise to find similar functionality.
You can merge all the changes from one branch to another. The procedure for this is:
hg update mybranch
hg merge default
hg commit -m "Merging with default"
This will bring all commits from default into your branch, but not the other way around. Later you can reintegrate your branch with default by doing the opposite
hg update default
hg merge mybranch
hg commit -m "Bringing in changes from mybranch"
If you want to bring in one or more specific commits that were committed in another branch, you can do that with 'transplant', which is a mercurial extension.
# reqiured in ~/.hgrc
[extensions]
transplant =
These are the commands you can use to use transplant:
hg log | less
# (find revision number, the part after the colon, i.e. "88660cca467d")
hg update mybranch
hg transplant 88660cca467d
# (no commit required)
As #Jerub said, you can use merge and transplant to get change sets from one branch to another. With TortoiseHg you can do a merge by opening the "repository explorer", then select the first revision to merge, and afterwards right click on the second revision to merge. Chose the "Merge with..." menu item to do the merge.