Jump to content

Difficulties differing with "diff"!


Unkle Nuke

Recommended Posts

After the great and thorough help I've received here in learning the basics of Git, I'm back with a question regarding the use of Git's diff command to generate patches. I'm using msysgit 1.6.5.1 preview20091022 for Windows 32-bit XP SP2

Lately, my issue has been with attempting to create diff files from patches that come from repositories where the revision is either older than my own Git master or much newer. Currently, my master is set to mangos-0.16-dev1 revision 9310 so I can maintain compatibility with my database version.

I'll use Naicisum's work on AuctionHouseBot as an example. First, let me trace my steps in setting up my repo:

git init
git remote add -f -t master origin git://github.com/mangos/mangos.git
git branch master --track origin/master

Then I revert my master branch to 9310 using git reset.

Next, I add Naicisum's ahbot repository to my local branch

git remote add -f -t ahbot ahbot git://github.com/Naicisum/mangos.git
git branch ahbot --track ahbot/ahbot

Now, I try using diff to create a patch, in an attempt to obtain a clean file with only the ahbot code:

git diff master ahbot>ahbot.patch

This is where I run into trouble. Every time I do this, I get the AHBot patch with quite a lot of other code from the MaNGOS core mixed in with it. I've even tried creating the patch without reverting my master, thinking that diff might be too literal in it's execution and adding any code that differs from my master.

Using git rebase master on my 'ahbot' branch does not seem to make any difference. I still see a lot of extra code in my diff files, that has nothing to do with the actual patch, when using git diff master.

git rebase master ahbot
git diff master ahbot>ahbot.patch

Does git rebase master work like I think or am I using rebase incorrectly?

I have similar difficulties when generating a patch from a repository that is older than my master, such as using kaxias' branch for the nameannounce patch, labeled simply as announce, which is still at MaNGOS revision 9126.

This makes me wonder if git merge isn't also adding in the other MaNGOS source code when it's adding in the patch, such as having parts of MaNGOS 9439 added into my 9310 source when using git merge to apply ahbot 94xx to my 9310 source.

Would using git reset on my local 'ahbot' branch work for reverting it to 9310 as well or must I revert only to the revisions of ahbot where there's been a merge/commit for it at the remote repo, in order to actually have the patched source?

Should I try to do a merge first and then run git diff? For merging, I set up a branch, called working, add my master to it, and then execute my merges on that branch. This way, it is a simple matter for me to use reset or even delete the branch if I mess up too badly. I know there's better ways to do it but my Git-fu is still weak and I'm learning as I go here.

Any thoughts? My patches turn out to be much larger than they need to be, with lots of "trash" code from the mangos core instead of only the code from the desired patch.

Link to comment
Share on other sites

Phew...i am not 100% sure what you are trying to do...

You keep your master deliberately behind origin/master for database reasons?

I'll try to explainas good as i can, with my also limited git knowledge.

At least right now, the ahbot repo/branch you mention was last merged with [9400], so if you diff your master with ahbot without telling git specific revisions, it will assume current HEAD for both. That means, it includes all ahbot specific commits aswell as everything from master [9310]-[9400], because all that is present in your ahbot branch, but not in your master branch.

If you want a diff that only contains ahbot specific code, you need to look at the history of the ahbot branch and pick suitable commits (e.g. by the SHA hash). Suitable commits means, take an ahbot commit, and diff against the last "joint" with origin master, so the last point it synced code.

Ideal place to see the apropriate commits is a merge itself, either there is already one in the ahbot branch, or you can merge the branches.

For example take this merge commit:

http://github.com/Naicisum/mangos/commit/09969c4c6d0a68ca429d61effd1abc365d02451d

Take a look at the right side of the blue box, this commit has two parents:

http://github.com/Naicisum/mangos/commit/e2a8db20e8310f6226bc919c5fc45d49b55b9723

This is the last commit to ahbot, it apparently resolved merge conflicts

http://github.com/Naicisum/mangos/commit/10847c9fc562bb94d55fa66cbac699521530453e

This is the mangos commit that was merged with, [9400] in this case.

If you tell git to diff from this commit to its mangos parent:

git diff 10847c9fc562bb94d55fa66cbac699521530453e 09969c4c6d0a68ca429d61effd1abc365d02451d > ahbot.patch

you should get a patch with everything from ahbot that will definitely apply to clean mangos [9400].

However, it will not necessarily apply to [9310], it might, or might not.

If it does not, you really have to look at the history and find a common point between the branches as close to [9310] as possible. You could for example try above procedure with e9f2db1016acb6d8eeabd4cd70c88cef8d3d25ef which merges ahbot with [9342].

But in general you cannot expect code written after newer merges to to magically apply to your old mangos, in this case, you either have to live with older ahbot code, or backport new code yourself where necessary.

Link to comment
Share on other sites

Thank you for clarifying the workings of git diff, Lynx3d, and for your input as well, freghar. :)

I made diffs with using the nearest common ancestors between master and the respective branches, looking for where a merge was done with master for each of my branches.

The result? Clean patches for each and every one! :D

Now I can make a build from mangos-0.16-dev1 (9310) with confidence that no code from later revisions will creep in. :cool:

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use