I have very confusing issue with conflicts during pull request at bitbucket. I have 137 conflicts like those below. How to fix it and prevent this from happening in the future? It's Android Studio's project on macOs.
As you can see I've just added some lines, but git treats it as conflicts.
Below you can find conflicts with merge.conflictStyle=diff3.
I still have no idea why it's conflict instead of edition.
Your diff3 screenshots provide the answer. (Aside: don't use screenshots here. Cut-and-paste the text directly. In this case that should drop the gutter information with the line numbers, but that's OK. See How do I ask a good question.)
Remember that in Git, a merge is about combining work. There are three commits involved:
You, on your branch, started with some commit. Git calls this the merge base commit.
They, on their branch, started with this very same commit.
So Git first runs two git diff commands (or the internal equivalent anyway). One compares this merge base to your version of the code, and the second git diff compares this merge base to their version of the code.
I'll start with the middle conflict.
The diff3 style diff includes the merge base code (from commit ce442625), where we can read—I have retyped this, so I may have added some typos1—that the original line said:
chage_lang.setOnClickListener { openDialogToSelectLang() }
This is clearly defective: it should read change_lang rather than chage_lang.
In your commit, in HEAD, you kept this line but added one more blank line after it. This is one "diff hunk".
In their commit, in feature/dark_mode, they fixed the spelling and replaced the single blank line with a non-blank line, to get:
change_lang.setOnClickListener { openDialogToSelectLang() }
change_theme.setOnClickListener { openDialogToSelectTheme() }
Here, Git does not know whether to keep your added blank line, or keep their removal-and-replacement of a blank line; it does not know whether to keep the wrong spelling, chage_lang, or use the corrected spelling, change_lang. So it produces a conflict: you must select the correct resolution.
Just below this, the last conflict is similar: the merge base version says:
android:layout_marginTop="#dimen/standard_margin"
android:background="#color/white"
In your version, you *changed the first line" to read "8dp" and kept the second line intact, but in their version they kept the first line intact and deleted the second line. Once again, Git does not know whether to take your version, their version, some combination of both, or what. You must choose the correct resolution here.
The first diff is the most confusing: here, the set of lines taken from the merge base version is empty. The change on your side is that you added one blank line, while they added one non-blank line reading:
setBackgroundColor(ContextCompat.getColor(context, ...
As in both other cases, Git does not know whether it should add your blank line, or their line, or both, or neither, or what. You must choose.
Edit the file in question to have the correct combination (and to no longer contain the conflict markers), or use a merge tool to achieve the same effect. Then use git add on the resulting file, or use a merge tool—probably the same merge tool, all as one thing—to run git add for you. The git add updates the copies of the files in Git's staging area so that Git knows the correct resolution.
(Git assumes that whatever you told it is correct, is correct, so be sure you tell it the right thing here! In other words, make sure the entire file is correct. Usually that means you should test your merge resolution before giving it to Git. That's one reason I don't like git mergetool: you do the merge, and then git mergetool immediately tells Git it's right, and if it's not right, you have to start over.2)
1This risk-of-typos is why the "ask" page suggests using cut-and-paste.
2You can start over with just this one file, and/or edit-and-debug it without re-creating the conflict, but it's now harder to see the original three input files. Using git checkout -m to re-create the conflict works, but that loses your resolution. Once you know exactly what you and Git are doing, there are workarounds for all of this, but overall this whole user-experience seems like a bad one, to me.
Related
I would like to rename all of my java classes and layouts that starts with the prefix tranp_ to event_. I can do that one by one using the combination Shift+F6 but it is taking too much time (there are more than 20 files). Is there a quicker way to do that in bulk?
Although is an old question, I feel it's worth answering as there is a valid solution.
Open the project with AndroidStudio, then right click on the main project's folder, select "replace in path" and enjoy it. I just replaced 400 occurrences in less than 40 seconds, just make sure you really need to replace all statements!
There seems to be no feature implemented to rename multiple files at once through refactoring provided within the Android Studio.
I also feel the need to have such feature as I keep changing my decision to name elements of certain category to some specific manner and thus have to tediously do it one by one. Which in many cases causes the bug.
I hope the future version will have it but till then what I am doing best at the moment is use the 'ctrl+r' feature to search all the occurrences of the item and replace it with what I want to rename to. And then do it again on all places where the element has been referenced. And then at last to make sure that there are no errors caused by the recent renaming I just run it. If any errors like "resources not found" then the Android Studio does point me to the location of the error, which generally is the place I left to rename.
Although this is not a sure way but it has helped me quite a lot when you have to rename lots of elements instead of 'shift+f6'.
So since I have tried the reply before me and it didn't help, I actually did find useful to open the direct path of the files I want to change, selected all of them and just pressed on rename(On MAC). It gave me the option to replace specific letters in all of the files. Made my life much easier after changing about 30 files, and noticing I have another 250 to change at least.
I have an android project, and mistakenly added bin folder to stage and committed it. Now how can I ignore this bin folder and ignore it for ever?
I added bin/ to the .gitignore file, but nothing changes and I see all files in this folder in working copy in SourceTree.
I am using SourceTree as the git client.
Along with ignoring the folder, you need to git rm it. Git only ignores files that aren't already under its control.
Be aware, though: doing so will cause git to remove that folder for anyone else who pulls those changes. You'd better be sure that folder is just the output from building, or can otherwise be easily reconstructed.
If you haven't published the changes yet (that is, if you've never pushed them to anywhere and no one's pulled them from you), then you have the option of rewriting the history. You can simply say git reset --soft the_commit_before_you_added_bin (of course, you'll need the actual commit ID, or another name for it, like HEAD~3 etc) to basically "uncommit" to right before you added it. Your working copy will still have the latest versions of the files, but Git will all but forget you committed them. (This also means you lose intermediate changes.) You can then redo your commit(s), being careful to avoid bin this time.
Git has a filter-branch command that can allegedly help with automating all that, and can even preserve intermediate changes. I've never used it, though, and couldn't tell you how to use it.
Obligatory Big Bold Warning:
Don't rewrite history that has already been published.
Only undo/rewrite commits that have never been pushed or pulled. Otherwise, wackiness ensues.
So I'm not sure if this is possible but I'm hoping it is. Basically, we just moved to SVN from Sourcesafe (I know a lot of you almost threw up in your mouth just now ;)) and I'm setting up eclipse to work with it. I installed Subversive and have a repo set up with my project. Just FYI, I'm working on an Android project written in Java. Here's what I want:
As I'm working on each Java file making changes, I want to write the SVN Commit Messages right their in code just as I add javadoc comments. This is because I have to change a ton of files before I commit and I want to remember each thing I changed (client requirement). But I don't want to have to remember all of that (especially as I'm deleting a lot of code) and them add the comments when I commit all my changes from all my files. Ideally, I simply add some tag and then the commit message that SVN understands and as I commit the file, I don't have to manually add the comments but it gets done automatically based on the commit messages tagged in my source file?
As an example, say I deleted a function foo in footest.java, I would simply type in the following in footest.java:
// __ (hopefully some tag here) deleted foo
Now when footest.java is commmitted, I don't have to type anything, the commit message 'deleted foo' gets added to it.
Finally, ideally, this is done automatically per revision. That is, once I make another change in footest.java, say, added function newfoo(), I could tag it like before with comment "added newfoo()" and when I commit only "added newfoo" comment gets put on the revision and not the one for the previous version "deleted foo".
Is this possible? Any issue anyone sees here?
Thanks,
-Vivek
Generally speaking, mixing your commit messages & your code is discouraged.
Subversion (or any client I'm aware of) has nothing of the kind built in, because it would require knowledge of the code itself and your custom markup.
You would need to write a wrapper around svn commit (or your client's equivalent) to process your files.
But have you considered that to do this right, you'd also have to remove those comments from your code once you've committed the changes? Now you're into your wrapper script messing with your code - and a bug there could break your code, either introducing subtle, hard-to-find bugs or rendering it impossible to compile.
Why not just keep a text file on your desktop with your notes? Or make smaller self-contained commits instead of delaying until the point where you've forgotten why you made some of the changes?
I have some raw open-source code for a modified version of the linux kernel. Ideally I would have a patch so that I could apply it to a newer version of the kernel, but instead I just have the source code, so I'm trying to create that patch myself.
What I'm finding is that when I create a patch and apply it to the newer kernel, I end up reverting a lot of changes. Is there a feature in git that can tell if local changes are reverting previous commits? Or is there some other tool that can find the commit with the least amount of changes (even if it's time consuming and has to be run on my own machine)?
I've been manually narrowing down what commit the source branched from, but it's very time consuming. I found a branch that fairly closely matched and now am trying to figure out what the latest commit was before changes were made to it.
I'll check out a commit A, copy the changed files, do a log on any file that has a lot of stuff taken out to find out if those exact changes were added from commit B, then checkout the commit before commit B, etc, etc...
EDIT: Since this is all pertaining to open source code, I don't see any reason why I can't share links to it here.
The source code released by LGE can be found here. Search for LS970 under Mobile.
The different branches of the MSM kernel can be found here. So far the ics_strawberry head seems to be the closest. It's one of the few that has a chromeos folder, which seems like it would be an odd thing to add specifically for a cell phone that wouldn't be running Chrome OS.
Unfortunately, you cannot use git bisect here because you cannot tell at any commit whether it was bad or good.
Your goal is to find commit that matches best to your target source. I think that best metric of what is "matching best" is the size (in lines) of unified diff/patch.
With this in mind, you can write a script according to following pseudo-code (sorry, weird mix of shell, Perl and C):
min_diff_size = 10000000000
best_commit = none
git branch tmp original_branch # branch to scan
git checkout tmp
for (;;) {
diff_size = `diff -burN -x.git my_git_subtree my_src_subtree | wc -l`;
if (diff_size < min_diff_size) {
min_diff_size = diff_size;
best_commit = `git log --oneline -1`;
}
git reset --hard HEAD~; # rewind back by 1 commit
if (git reset did not work) break;
}
git checkout original_branch
git branch -d tmp
print "best commit $best_commit, diff size $min_diff_size"
You may also want to cycle through kernel branches as well to find best matching branch.
This probably will work slow and take a lot of time (could be hours), but it will find best matching commit.
You can use git blame to find out which commit each line of code was introduced in. For example,
git blame main.c
Check out the man page for the various options you can use to fine-tune blame's output and other cool tricks.
I use eclipse to build an android app, and git running locally for version control. Currently I have a value in strings.xml that represents the version number. If i change that number, the very next thing I do is a code commit in git using the same version number in the comment, so that I can tie a specific build to the matching code that generates it. Very manual process.
Larsks comment helped in pointing me in a direction of defining things better. I think what I want is some type of git hook. Something where, if I change a particular version variable, it will automatically add a corresponding tag. Or, if I issue a tag of a specific format "v3.1.4", it will update the version number in code.
I think prior to reading about hooks, I was hoping for something where I could put "ReplaceWithVersion", or some other special code, and on commit git would know automatically to replace that with the current tag/version.
Am I hoping for too much? Is there a feasible way to get that the versions/tags in sync?
This sounds like the precut use for git tags. After you update strings.xml and commit the change, tag the commit with the version number:
git tag 3.14.15
You can then use this tag in other git commands to refer to this specific commit. For example, too see any change you've made since a release:
git diff 3.14.15