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.
Related
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.
hope you are having a good day.
I want to know a small thing about pull/push in git repo.
Below is the representation of my code/project.
Blue: This is my code which is worked on and without commit i pulled the red code from git.
Red: This is the older version of blue code.
Yellow: this is the code which i have now
So i have worked on blue code but without commit or push i pulled red code, so it over writes my blue updated code and merged as yellow code. So now i want to get back my blue code, is it possible? i searched in my project folder but i cant find it. i search on my git branch code too but it wasn't there too.
Thanks for the read, if you know how to revert that pull request it will save my couple of hours. Thanks again
And by the way this is an android project and code is in bitbucket.
[UPDATE] - Solved-
Thanks for the response. I got my blue code back using Android Studio Local History tool. Reverted all the changes that i have made.
Try git lola9 (if you've set up the alias, or whatever way you prefer to view your commit history), and you should see the commits you pulled. Alternatively, the console output of the git pull should also include the commits you pulled.
Once you have that, what I would do is:
Note the number of commits you want to git rid of
git stash your changes,
git reset head~n, where n is the number of commits we figured out earlier. This will 'un-commit' the changes you pulled
git co . & git reset as needed to 'lose' all those now un-commit-ed changes that you've pulled down
git stash apply to retrieve your changes (rather than pop in case somethings gone wrong, you don't want to dirty your changes)
This might be a trivial question but I dont know the answer to it. Looking for android gurus.
My task is to compile android kernel and run on a pandaboard. I cannot just take the uImages there are drivers which I need to modify..
Now one way is to download every thing from AOSP by repo init... and downloading 3-4 Gb of git from day 1 of android git init.
Is there a way to just get the source files for ICS. It is easy for linux just go to git.kernel.org and get the snapshot of the tag like 3.0 , is there a same git snapshot available in android ?
Any help is welcome....
TLDR: Not likely. Don't bother and simply repo sync to the branch you need.
Longer explanation:
If somebody has created snapshot of your particular tree, then you might be able to do that.
However, I don't think anybody will bother to do so, because having this git-less snapshot is pretty much useless from developer's standpoint, and space/traffic savings over repo sync are miniscule.
Note that git is extremely efficient at packing historic metadata in object store (provided it was packed by git gc recently). It is relatively rare situation when compressed git metadata takes more space than simple checkout of the top of the tree. Since repo sync only downloads compressed metadata, this process is very efficient.
So speed this up even further and avoid handling small objects, Android projects creates single-file compressed bundles for most repositories included in standard manifest, and modern repo script understands how to get these bundles first for efficiency, and then get small deltas afterwards. This allows to perform first repo sync much faster than otherwise. Basically, you are only limited by the speed of your internet connection.
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 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