On Monday 24 November 2008, Andrei Pelinescu-Onciul wrote: wrote: Hi Andrei, i'm still trying to wrap my head around this git. ;-) Aparently this merged the content from the henning/trie branch into the trunk, the operation i wanted to do. But i don't understand the log message, 'my_branch' is a local branch on my machine, not sure why this show up, and it should be also the other way round. And the diff for the revision is also the other way round. Perhaps i just did it the wrong way. :-/ henning@ca:~/projects/openser/sip-router$ git config --get merge.log true Perhaps it make sense to revert this commit? Cheers, Henning

On Nov 24, 2008 at 20:30, Henning Westerholt <henning.westerholt(a)1und1.de> wrote: git diff 7e69be0 origin/master shows me only lib/trie addition, and 2 mem/mem.h macros (PKG_MEM_ERROR and SHM_MEM_ERROR). 7e69be0 is the shor form of 7e69be0441a98653ea0d94c831f64a2947aa4fff which is the previous commit on master branch (git log or git log -2). Did you updated from the repo before trying git diff (or else you don't have the latest version)? (git fetch origin) The problem was with git merge. Anyway the best way is that before git push-ing you should look at the branch tree (gitk) and/or at the log (git log). If it looks ok then git push .... (that's because is much easier to revert changes locally) They didn't show anything because it was ok (the code is ok), only the merge message is wrong. Maybe I've got you wrong: do you want to revert the mem.h changes? the merge log commit message? the whole merge? Andrei

On Nov 25, 2008 at 13:54, Henning Westerholt <henning.westerholt(a)1und1.de> wrote: Your configuration is ok. I was wrong recommending git revert for this, I think it can't work, because it tries to merge, sees that trie was merged in the past and then it tries to merge only what's new on trie since the past merge... Sorry, I think git revert is not good for undoing a merge commit. It does undo the code changes, but it leaves the merge in the history and so future merges with the same branch think the branch was already merged. I don't know if this can be done in another way, but for now I'm going to reset master to the commit just before the merge (7e69be). I'll send a message on sr-dev after I do it and then you could retry the merge from the beginning. Andrei [...]

On Nov 24, 2008 at 19:46, Henning Westerholt <henning.westerholt(a)1und1.de> wrote: No, the commit is ok, only the last log message is broken. You probably where on "my_branch" and you did a git pull ssh://git.sip-router.org/sip-router master and then git push origin my_branch:master So what you did was to merge the remote version of master into "my_branch" and then update master with my_branch version. What you should have done is to merge trie or "my_branch" into master: git fetch origin # to get up-to-date origin/ branches, including master git checkout -b master origin/master # local branch following # origin/master # now you are on branch master (local version) git merge trie git log or gitk to see if everything looks ok git push origin master:master If you already have a local master branch tracking origin/master you could do instead: git checkout master # switch to master git pull origin master # equiv. with git fetch origin; git merge master git merge trie # git log or gitk to see if everything looks ok git push origin master:master Note that some of this commands have shorter forms (if not specified some parameters take some default values and some of this values can be configured in the git config on a per branch basis, e.g. the default branch to push into or to pull form). Note2: you don't have to specify the whole reop name path (ssh://git.sip-router.org/sip-router), origin is set by default to the repo from where you cloned, so you could always use origin. To revert the commit (it's not needed since we have only a strange merge message, but the rest is ok, but it might be good practice), there are 2 possibilities: 1. you could use git revert (it will create a new commit reverting the old one): checkout the master branch: - if you don't have a local master: git fetch origin; git checkout -b master origin/master - if you already have a master tracking origin/master (created in a similar way some time ago): git checkout master # switch to master git pull origin master revert the commit git revert -m X commit_id where comit_id is the commit you want reversed (in this case 8d41196809f014e00346785b6517bd2c4051901a) and X is the merge parent number that should be the mainline (in this case I think it's 2) You could try git revert --no-commit -m 2 8d41196809f014e00346785b6517bd2c4051901a and see if it look ok (and if it does remove --no-commit and retry). After this and after making sure the log looks ok (gitk, or git log) you can git push origin master:master, or maybe git push origin master:tmp/test just to have an extra check. WARNING: do not push if it doesn't look ok (if you use the wrong -m value you might end up reverting master into your branch :-)). 2. we could revert it the hard way without leaving "commit" traces (by directly editing the master branch on sip-router.org and making it point to the previous comit). The problem with this is that if people have already checked out the current master version they will have problems updating, but since I don't expect to have more then 2 or 3 people who do this at this point we could try it as an experiment (in the future we might have to revert a commit the hard way so we might try it now when this will not cause any serious problems). So do you want it reverted and if so what method do you prefer to try? Andrei

On Monday 24 November 2008, Andrei Pelinescu-Onciul wrote: Hi Andrei, yes, correct. I read on some git docs that this is needed in order to merge the branches. This were apparently wrong. Ah, ok, understand. Ok I'll try this the next time, perhaps in the test branch. Ah, good to know! I'll try the first method. Thanks for your help and explanations, Henning