Re: Merge or Cherry-Pick?
On 23/02/2011, Hugo Pereira Da Costa h...@oxygen-icons.org wrote: Hi All, For the record, it appears (unless I am doing something wrong), that git merge of KDE 4.6 into trunk (while trying to fix and forward-port a bug) for kde- workspace is broken again. I end up with: # both modified: ../../khotkeys/data/kde32b1.khotkeys # both modified: ../../kwin/effects/configs_builtins.cpp # both modified: ../../kwin/effects/highlightwindow/highlightwindow.cpp # both modified: ../../kwin/tabbox/tabboxhandler.cpp # both modified: ../../plasma/generic/applets/icon/icon.cpp This is *mainly* because kwin reformatted the whole code in master but not in 4.6, so any attempt to merge gives conflicts in those files. I just merged 4.6 into master again. I checked the 16 commits pending merge and they were all was already backported or forward-ported manually (via cherry-pick); so I could just resolve all conflicts to the code in master. -- Nicolas
Re: Merge or Cherry-Pick?
On Thu, Feb 10, 2011 at 04:31, Johannes Sixt j.s...@viscovery.net wrote: Am 2/10/2011 10:40, schrieb Ben Cooksley: On Thu, Feb 10, 2011 at 9:35 PM, Johannes Sixt j.s...@viscovery.net wrote: git push origin KDE/4.6 This is wrong, as it would try to push the content of HEAD (the merge of origin/KDE/4.6 into a checkout of origin/master) into KDE/4.6. Now you made me think about it. But, no, it is correct: git push remote branch is always a shorthand for git push remote branch:branch regardless of the push.default configuration setting. Therefore, the command I gave pushes the local KDE/4.6 branch to the remote KDE/4.6 branch, regardless what you have checked out. Which is why I think these shorthands are just really confusing and urge folks to just be explicit in everything. Certainly it isn't obvious that git push remote branch doesn't does the same thing regardless of what branch you have checked out. But if you did git push origin KDE/4.6:KDE/4.6 you know exactly what you are doing. But shorthand commands like `git pull --rebase` remain popular, and everyone confused. Ian
Re: Merge or Cherry-Pick?
On 03/02/2011, Johannes Sixt j.s...@viscovery.net wrote: Am 2/3/2011 12:15, schrieb Hugo Pereira Da Costa: So I git cloned KDE/4.6 into some local branch (git checkout KDE/4.6; git checkout -b toolbuttons), then fix, then test. Now I want to merge to the KDE/4.6 branch; thats easy. Then I want to merge to master (or to some local branch cloned from master and then from there to master). As already announced in this thread, this results in tons of conflicts (notably many .desktop files). Before anybody begins to work in this way, someone with sufficient knowlege must introduce the first real merge of the 4.6 branch into the master branch. The conflicts must be resolved; or it is possible to punt by using -s ours. As long as this merge did not happen, anyone who wants to use the merge workflow is at a loss, unfortunately. Or should I give up and cherry-pick ? (I'd really like not to). My recommendation: Keep the fix in 4.6 only for the moment. Just wait until the initial merge has happened - and lets hope (HOPE BIG TIME) that the person doing that merge knows what s/he is doing! I have now merged 4.6 into master in kde-workspace. -- Nicolas
Re: Merge or Cherry-Pick?
2011/2/8 Nicolás Alvarez nicolas.alva...@gmail.com: On 03/02/2011, Johannes Sixt j.s...@viscovery.net wrote: Am 2/3/2011 12:15, schrieb Hugo Pereira Da Costa: Before anybody begins to work in this way, someone with sufficient knowlege must introduce the first real merge of the 4.6 branch into the master branch. The conflicts must be resolved; or it is possible to punt by using -s ours. As long as this merge did not happen, anyone who wants to use the merge workflow is at a loss, unfortunately. Or should I give up and cherry-pick ? (I'd really like not to). My recommendation: Keep the fix in 4.6 only for the moment. Just wait until the initial merge has happened - and lets hope (HOPE BIG TIME) that the person doing that merge knows what s/he is doing! I have now merged 4.6 into master in kde-workspace. Great Nicolás. This will be much easier with the 4.7 branch! Ian
Re: Merge or Cherry-Pick?
On Wednesday, February 02, 2011 18:36:28 Alexander Neundorf wrote: I don't really care how it will be, but I really think we should agree on one common recommended and documented workflow to use. I agree of having a recommended way of doing, but I do not agree forcing a predefined workflow on the contributors. As the thread cleary shows, some use master as base and work there (and used to do it in the past X years), others work on stable. Forcing a way onto the developers just becase the tool's result is nicer in that way will not make me happy. Andras
Re: Merge or Cherry-Pick?
On Monday 07 February 2011, Andras Mantia wrote: On Wednesday, February 02, 2011 18:36:28 Alexander Neundorf wrote: I don't really care how it will be, but I really think we should agree on one common recommended and documented workflow to use. I agree of having a recommended way of doing, but I do not agree forcing a predefined workflow on the contributors. As the thread cleary shows, some use master as base and work there (and used to do it in the past X years), others work on stable. Forcing a way onto the developers just becase the tool's result is nicer in that way will not make me happy. Well, I think a recommendation for those who are not git-masters is important, so a workflow which leads to few conflicts and makes people happy when followed (like a nice history etc.) would be a good thing to have. I don't think it has to be forced on people who know what they are doing. Alex
Re: Merge or Cherry-Pick?
On Saturday, 5 de February de 2011 00:16:03 Tom Albers wrote: - Original Message - this will get us used to the merge workflow which starts with fix it in the stable branch first. So, in conclusion, we did not pick a tool which fits our workflow, instead we are now adjusting our workflow to the tool. The tool supports either workflow. We are adjusting the workflow to improve the way we want to work. The upside is that the adjusted workflow works better in Git. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Initial merge (was: Re: Merge or Cherry-Pick?)
On Friday, 4 de February de 2011 08:47:08 Johannes Sixt wrote: I can offer a set of git bundles that contain the merge results. (I don't have push access yet.) Anyone interested? Send to me. By the way, for the KDE readers here: git mergetool running kdiff3 is very useful too. Select the Local side usually. (that's C I think) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Initial merge (was: Re: Merge or Cherry-Pick?)
On 04.02.11 08:47:08, Johannes Sixt wrote: Am 2/3/2011 13:04, schrieb Johannes Sixt: Before anybody begins to work in this way, someone with sufficient knowlege must introduce the first real merge of the 4.6 branch into the master branch. The conflicts must be resolved; or it is possible to punt by using -s ours. As long as this merge did not happen, anyone who wants to use the merge workflow is at a loss, unfortunately. I tried to do the initial merges in kdelibs, kde-runtime, kde-baseapps, and kde-workspace yesterday, and they turned out to be rather simple with a surprisingly trivial result. Fast-forward to 5. below if you want to know what it is. The simplicity results from two assumptions: (1) All back- and forward-porting was complete when SVN went read-only. I'm not sure that assumption is safe. (2) *.desktop and similar files are generated files, i.e., their content is dictated from outside the repository. And that one is certainly not safe, unless you're solely talking about the translated parts in them. Not everything in a .desktop file is generated. I'm sure you know that already, just wanted to point that out in case somebody stumbles over this in the future. Andreas -- Make a wish, it might come true.
Re: Initial merge (was: Re: Merge or Cherry-Pick?)
On Fri, Feb 04, 2011 at 08:47:08AM +0100, Johannes Sixt wrote: (e) There is no (e). as far as i'm concerned, there isn't even an (a). i said about a year ago and repeated it later that *if* we wanted a forward-merge based process, we would have to do the git migration *before* branching off the next stable branch. that ship has sailed - we are in our old cherry-picking process now, and merging will just make the history an utter mess (but then, i'm sure everybody loves seeing every commit twice - right?). and i'm strongly opposed to merging any previous branches back to master with -s ours, as this will effectively rewrite history (we did *not* merge back, and claiming that now will possibly hide actual omissions).
Re: Initial merge (was: Re: Merge or Cherry-Pick?)
Em sexta-feira, 4 de fevereiro de 2011, às 15:27:49, Oswald Buddenhagen escreveu: and i'm strongly opposed to merging any previous branches back to master with -s ours, as this will effectively rewrite history (we did *not* merge back, and claiming that now will possibly hide actual omissions). I don't think that's the message here. The message of the -s ours merge is that no forward-porting of fixes is necessary, so it's easy to find out what changes need to be forward-merged. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
Can somone please clarify the proper rule to follow for committing bug fixes as it relates to the KDE 4.6 branch ? The conclusion from the discussion here is rather confusing as to what should be done going forward. Should we still commit new bug fixes to the 4.6 branch first and merge into master which, from all indications here, seems not to be possibe with the current state of the KDE 4.6 branch ? Or it does not matter now so we can go ahead and commit to master and backport to the branch if we so choose ?
Re: Merge or Cherry-Pick?
On Tue, Feb 1, 2011 at 06:29, Johannes Sixt wrote: Am 2/1/2011 10:31, schrieb David Jarvie: On Mon, January 31, 2011 11:27 pm, Thiago Macieira wrote: On Monday, 31 de January de 2011 23:34:39 Arno Rehn wrote: I guess that won't quite work when there are commits specific to 4.6 in the 4.6 branch that shouldn't end up in master. And it clutters history with tons of merges. Then let's solve the problem by not having anything specific to 4.6. If it belongs in the stable release, it belongs in the next stable release too. That's not always true. Some changes *will* be specific to 4.6, because sections of code in master can get rewritten, features added or removed, so the changes won't be applicable there. In such a situation, you make the merge anyway, but you resolve the ensuing conflicts by taking master's state (i.e., it amounts to a merge --ours). You should write in the message of the merge commit that the change made to 4.6 is not relevant on master anymore (and why it is not relevant anymore). Another special and unavoidable case of this will be applications bumping their stable version numbers. It seems weird to have a Updated version to 4.6.2 commit in a 4.7 master, for example, but I guess that the (small) price one pays for mergeable stable branches. Parker
Re: Initial merge (was: Re: Merge or Cherry-Pick?)
Thiago Macieira wrote: On Friday, 4 de February de 2011 15:18:58 Nicolas Alvarez wrote: Johannes Sixt wrote: (1) All back- and forward-porting was complete when SVN went read-only. IMHO this is not a safe assumption. As I said before, I found a missing forward-port in kdeplasma-addons, which is a 'small' repository. I see a higher chance of a missing forward port among the 200+ 4.6 revisions in kdelibs. Those missing forward-ports need to be forward-ported anyway. The merging doesn't change that. Whoever forgot to do forward-ports should be doing it *yesterday*. I know forward-ports should be done anyway and asap. But until they aren't done, we can't do the 4.6 merge. -- Nicolas
Re: Initial merge (was: Re: Merge or Cherry-Pick?)
On Friday, 4 de February de 2011 17:13:31 Nicolas Alvarez wrote: Whoever forgot to do forward-ports should be doing it *yesterday*. I know forward-ports should be done anyway and asap. But until they aren't done, we can't do the 4.6 merge. Sure we can. It doesn't influence in anyway. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Friday, 4 de February de 2011 14:58:52 Parker Coates wrote: Another special and unavoidable case of this will be applications bumping their stable version numbers. It seems weird to have a Updated version to 4.6.2 commit in a 4.7 master, for example, but I guess that the (small) price one pays for mergeable stable branches. That is the type of commit that *will* conflict when you try to merge. Then you should be undumb and choose the side that says the correct version for the branch. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Friday, February 04, 2011 19:16:03 Tom Albers wrote: - Original Message - this will get us used to the merge workflow which starts with fix it in the stable branch first. So, in conclusion, we did not pick a tool which fits our workflow, instead we are now adjusting our workflow to the tool. Adjusting the workflow is not bad per se though. It is bad if the new workflow is inferior or hinders development. I haven't been using any of the git modules long enough to see if that's the case, but I don't see any reason why the proposed new workflow shouldn't actually be an improvement... Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Mittwoch 02 Februar 2011, Thiago Macieira wrote: if I continue developing the app in master and fix some bugs on the way, the fixes will be in master first. I would not always want to put them into 4.6 at once because testing in master is much easier and comes at much less cost while development goes on. So I might even want to wait some days or even weeks until backporting fixes. Laziness is not an argument -- it's just an excuse. If you find a bug that applies to 4.6, why will you not fix it there? sometimes because 4.6 is already frozen, so I wait until I can commit for 4.6.1. In general I see first testing in master as an additional level of testing - after backporting to 4.6 I can still test that again as needed. and - how often did you test something only to find out later that the user does things differently and finds different bugs? using the bug-fixed master for development did already help me to avoid backporting bugs. In my experience, testing the stable releases is easier. Testing the development versions usually cause trouble because of unfinished features and untested new code. for Kajongg I am practically the only developer so I normally know what is going on but I like Felix's idea - create a new branch in master for every bug fix I expect to backport. I will definitely have to learn more about git... -- Wolfgang
Re: Merge or Cherry-Pick?
please ignore this - I should have first read the rest of the thread - others already had the same arguments On Donnerstag 03 Februar 2011, Wolfgang Rohdewald wrote: On Mittwoch 02 Februar 2011, Thiago Macieira wrote: if I continue developing the app in master and fix some bugs on the way, the fixes will be in master first. I would not always want to put them into 4.6 at once because testing in master is much easier and comes at much less cost while development goes on. So I might even want to wait some days or even weeks until backporting fixes. Laziness is not an argument -- it's just an excuse. If you find a bug that applies to 4.6, why will you not fix it there? sometimes because 4.6 is already frozen, so I wait until I can commit for 4.6.1. In general I see first testing in master as an additional level of testing - after backporting to 4.6 I can still test that again as needed. and - how often did you test something only to find out later that the user does things differently and finds different bugs? using the bug-fixed master for development did already help me to avoid backporting bugs. In my experience, testing the stable releases is easier. Testing the development versions usually cause trouble because of unfinished features and untested new code. for Kajongg I am practically the only developer so I normally know what is going on but I like Felix's idea - create a new branch in master for every bug fix I expect to backport. I will definitely have to learn more about git... -- Wolfgang
Re: Merge or Cherry-Pick?
On Thu, Feb 3, 2011 at 6:21 AM, Dawit A ada...@kde.org wrote: git config --global push.default tracking and use the -t or --track option when creating your branches (branch or checkout -b). This way you can 'git push' (no arguments) in the current tracked branch without accidentally pushing your changes in other branches. I think this is the default. When I do git checkout -b somework origin/somework here, it automatically sets up somework to track origin/somework. Push by default only operates on the tracking branch, i.e. push --all needs to be specified manually. Greetings Stefan
Re: Merge or Cherry-Pick?
Am 2/3/2011 12:15, schrieb Hugo Pereira Da Costa: So I git cloned KDE/4.6 into some local branch (git checkout KDE/4.6; git checkout -b toolbuttons), then fix, then test. Now I want to merge to the KDE/4.6 branch; thats easy. Then I want to merge to master (or to some local branch cloned from master and then from there to master). As already announced in this thread, this results in tons of conflicts (notably many .desktop files). Before anybody begins to work in this way, someone with sufficient knowlege must introduce the first real merge of the 4.6 branch into the master branch. The conflicts must be resolved; or it is possible to punt by using -s ours. As long as this merge did not happen, anyone who wants to use the merge workflow is at a loss, unfortunately. I do: git merge -X ours toolbuttons Is that the correct action to take ? No. Perhaps you meant 'git merge -s ours toolbuttons', but even that would be wrong because it would ignore your changes that you made in the 4.6 branch - but this defeats the purpose of the merge. Or should I give up and cherry-pick ? (I'd really like not to). My recommendation: Keep the fix in 4.6 only for the moment. Just wait until the initial merge has happened - and lets hope (HOPE BIG TIME) that the person doing that merge knows what s/he is doing! Hannes -- Atomic objects are neither active nor radioactive. -- Programming Languages -- C++, Final Committee Draft (Doc.N3092)
Re: Merge or Cherry-Pick?
On Thursday 03 February 2011 13:04:18 Johannes Sixt wrote: Am 2/3/2011 12:15, schrieb Hugo Pereira Da Costa: So I git cloned KDE/4.6 into some local branch (git checkout KDE/4.6; git checkout -b toolbuttons), then fix, then test. Now I want to merge to the KDE/4.6 branch; thats easy. Then I want to merge to master (or to some local branch cloned from master and then from there to master). As already announced in this thread, this results in tons of conflicts (notably many .desktop files). Before anybody begins to work in this way, someone with sufficient knowlege must introduce the first real merge of the 4.6 branch into the master branch. The conflicts must be resolved; or it is possible to punt by using -s ours. As long as this merge did not happen, anyone who wants to use the merge workflow is at a loss, unfortunately. I do: git merge -X ours toolbuttons Is that the correct action to take ? No. Perhaps you meant 'git merge -s ours toolbuttons', No, I really meant git merge -X ours toolbuttons which I believe, is equivalent to git merge -s recursive -X ours toolbuttons and which, according to the documentation (and confirmed by my test), would pick my changes if there is no conflict, and keep the master branch source, in case of conflict. Which, in my case, is exactly what I need (since there is no conflict with oxygenstyle.cpp). Anyway, I agree with you, I'm not that confident with the merge part itself, and will follow your advice, by just waiting. My understanding is also that people should refrain from cherry-picking before this original merge happens, cause that would only make it more painful. Correct ? but even that would be wrong because it would ignore your changes that you made in the 4.6 branch - but this defeats the purpose of the merge. Or should I give up and cherry-pick ? (I'd really like not to). My recommendation: Keep the fix in 4.6 only for the moment. Just wait until the initial merge has happened - and lets hope (HOPE BIG TIME) that the person doing that merge knows what s/he is doing! Hannes
Re: Merge or Cherry-Pick?
On Thursday 03 February 2011 08:57:00 Johannes Sixt wrote: Am 2/3/2011 6:10, schrieb Dawit A: What happens if I tested a bug fix and wanted it to push it upstream so that it can receive even wider testing, but it just so happens the time to tag the next bug fix release is right around the corner ? The original intent is to at least leave the bug fix in the trunk for several days to see if it causes any unforeseen regression. It is an impossible task for any developer, specially one working on the plumbing libraries, to test every possible combination or use case. If the push is done into a stable branch, then there is a real possibility that users are going to get exposed to unintended regressions. I'll assume you meant to say push is done into a stable branch *too early*... (otherwise, the last sentence in this paragraph is incompatible with the first part of the paragraph). You do it this way: 1. You fork off a topic branch from stable, and place your fix there. 2. Compile-test the fix. (Bonus points, if you can test the fix in action with the stable version.) 3. Merge that topic into master. Compile and test. 4. Publish the merge. Let it cook for a week in master. 5. Looks OK? Good. Merge the topic into the stable branch as well. (The stable branch might have progressed in the past week, hence, you don't necessarily fast-forward, but get a real merge.) 6. Merge stable into master and publish both. However, if you cannot test your fix with the stable version yourself, you should ask someone to do Step 5, additionally Step 5b test with stable version, and Step 6 for you. This seems to be, except for the origin of the merge into stable which is irrelevant to the actual code in the repository, what Dawit and I want. AFAIU simple bug fixes like null pointer checks go into stable first and then immediately into master with that approach, as suggested earlier in this thread. As long as I can test fixes in master in some way I'm (for now) fine with trying any approach - it will probably work about equally well for everyone, so if it won't work for me it won't work for others and we can think again.
Re: Merge or Cherry-Pick?
Em terça-feira, 1 de fevereiro de 2011, às 09:31:40, David Jarvie escreveu: On Mon, January 31, 2011 11:27 pm, Thiago Macieira wrote: On Monday, 31 de January de 2011 23:34:39 Arno Rehn wrote: I guess that won't quite work when there are commits specific to 4.6 in the 4.6 branch that shouldn't end up in master. And it clutters history with tons of merges. Then let's solve the problem by not having anything specific to 4.6. If it belongs in the stable release, it belongs in the next stable release too. That's not always true. Some changes *will* be specific to 4.6, because sections of code in master can get rewritten, features added or removed, so the changes won't be applicable there. That's not a problem or an excuse. Make the change in 4.6, merge to master, fix the conflicts and then push both branches. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Wed, Feb 02, 2011 at 01:21:44AM -0500, Dawit Alemayehu wrote: On Wed, Feb 2, 2011 at 12:58 AM, John Tapsell johnf...@gmail.com wrote: But how would a similar work flow except there are multiple fixes Does that make sense? Yes. Great. IMHO that type of documentation is what is needed in techbase. in fact, that's exactly the type that does *not* belong there. there is enough generic git documentation out there, and bloating techbase by duplicating it all won't make it simpler to use. the right way is stating the desired goals, mentioning a few key phrases (interactive rebase in this case) and linking to some external source. and remember that following receipes does *not* work if you don't actually understand what you are doing - there may always be some circumstances that make it a receipe for disaster. and from experience i can tell that some people are astonishingly stubborn with ignoring signs of disaster ...
Re: Merge or Cherry-Pick?
On Dienstag 01 Februar 2011, Thiago Macieira wrote: That's not always true. Some changes will be specific to 4.6, because sections of code in master can get rewritten, features added or removed, so the changes won't be applicable there. That's not a problem or an excuse. Make the change in 4.6, merge to master, fix the conflicts and then push both branches. if I continue developing the app in master and fix some bugs on the way, the fixes will be in master first. I would not always want to put them into 4.6 at once because testing in master is much easier and comes at much less cost while development goes on. So I might even want to wait some days or even weeks until backporting fixes. -- Wolfgang
Re: Merge or Cherry-Pick?
Quoting Oswald Buddenhagen o...@kde.org: and remember that following receipes does *not* work if you don't actually understand what you are doing - there may always be some circumstances that make it a receipe for disaster. and from experience i can tell that some people are astonishingly stubborn with ignoring signs of disaster ... A good tip if all went wrong is that git saves all the states for you. Just type: git reflog and you will see a log of every operation you did. If you messed up, try doing: git reset --hard SHA1 where SHA1 is the sha1 of the last successful operation you did. but just use reflog in emergencies and try to not make it an habit! Cheers, Artur ---
Re: Merge or Cherry-Pick?
On Wed, February 2, 2011 11:38 am, John Tapsell wrote: On 2 February 2011 07:27, Dawit A ada...@kde.org wrote: Ahh... I see. It is push everything upto that commit, not just push that commit. Ouch! That is almost as much a hassle as the convoluted method I am following now. Do not commit anything that is not ready to be pushed into my own local branch. Use git stash to save the uncommited changes before doing the pull --rebase and apply the stashed changes after doing the push... And then one day you do git checkout . by mistake and lose all your local uncommitted changes that you just spent a week working on .. I'd recommend maintaining a local 'master' branch which always mirrors the remote repository. Never do development in your local 'master' branch - always do your work in other local branches, and only merge/cherry-pick changes from them into the local 'master' once you are ready to push to the remote. That way, your local master always mirrors the remote, and you can choose exactly when and which commits to push. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Merge or Cherry-Pick?
On Wed, Feb 2, 2011 at 08:25, David Jarvie wrote: I'd recommend maintaining a local 'master' branch which always mirrors the remote repository. Never do development in your local 'master' branch - always do your work in other local branches, and only merge/cherry-pick changes from them into the local 'master' once you are ready to push to the remote. That way, your local master always mirrors the remote, and you can choose exactly when and which commits to push. Note to self: Always check that there are no new messages in the thread before pressing Send. Parker
Re: Merge or Cherry-Pick?
On Wednesday 02 February 2011 07:27:01 Dawit A wrote: Ahh... I see. It is push everything upto that commit, not just push that commit. Ouch! That is almost as much a hassle as the convoluted method I am following now. Do not commit anything that is not ready to be pushed into my own local branch. Use git stash to save the uncommited changes before doing the pull --rebase and apply the stashed changes after doing the push... Never have uncommitted changes, git is designed around frequent local commits as checkpoints in your development which you can later clean-up by collapsing them into fewer commits and re-writing the commit message just before pushing to the main repo. John.
Re: Merge or Cherry-Pick?
On Wed, Feb 2, 2011 at 09:05, John Layt wrote: On Wednesday 02 February 2011 13:43:04 Parker Coates wrote: My preferred workflow is to put all local commits intended for master in a single, local, long-lived workmaster branch instead of putting them in master directly. Since the changes are local, you can just keep rebasing it onto master every time master is updated. Then if you want to push a single commit from the work branch: * pull master * you interactively rebase the workmaster branch onto master to put the desired commit first * merge the SHA you want to commit into master * push master I find that by keeping my commits out of master itself allows me to update without worries, to commit high priority fixes without messing up my local work, and to commit early and often locally while still having the option to clean things up later with some rebasing. Personally, I found this ability to keep my local commit queue out of the way was the biggest advantage of switching to Git. Parker Personally, I think you should NEVER have commits in master, you should only ever work in and push from branches, they're so cheap to do. That way your master is always a clean pure copy of the main repo to branch off. If I needed to extract a single commit out of a branch to push, rather than merging it to master I'd create a new branch from master and cherry-pick the commit to that, build and test it knowing it's clean, then push from there. Then pull master and rebase the original branch on master again. Hmm. You're probably right. The majority of my Git experience has been with git-svn where it's pretty much mandatory to commit via master. In a pure Git environment, I guess it should be possible to keep master 100% clean. Parker
Re: Merge or Cherry-Pick?
On 2 February 2011 14:23, Parker Coates parker.coa...@kdemail.net wrote: On Wed, Feb 2, 2011 at 09:05, John Layt wrote: On Wednesday 02 February 2011 13:43:04 Parker Coates wrote: My preferred workflow is to put all local commits intended for master in a single, local, long-lived workmaster branch instead of putting them in master directly. Since the changes are local, you can just keep rebasing it onto master every time master is updated. Then if you want to push a single commit from the work branch: * pull master * you interactively rebase the workmaster branch onto master to put the desired commit first * merge the SHA you want to commit into master * push master I find that by keeping my commits out of master itself allows me to update without worries, to commit high priority fixes without messing up my local work, and to commit early and often locally while still having the option to clean things up later with some rebasing. Personally, I found this ability to keep my local commit queue out of the way was the biggest advantage of switching to Git. Parker Personally, I think you should NEVER have commits in master, you should only ever work in and push from branches, they're so cheap to do. That way your master is always a clean pure copy of the main repo to branch off. If I needed to extract a single commit out of a branch to push, rather than merging it to master I'd create a new branch from master and cherry-pick the commit to that, build and test it knowing it's clean, then push from there. Then pull master and rebase the original branch on master again. Hmm. You're probably right. The majority of my Git experience has been with git-svn where it's pretty much mandatory to commit via master. In a pure Git environment, I guess it should be possible to keep master 100% clean. It seems that I go against the grain, and always develop in master. You already have origin/master as a pristine version of upstream master, and you don't have to worry about it getting out of sync. E.g: git log #find SHA1 of commit I want to push upstream git checkout origin/master #we are now on an unnamed branch git cherry-pick SHA # still on an 'unnamed branch' #compile, test, fix, etc. git push origin HEAD:master git checkout master git pull --rebase #rebase on top of remote, which now has our change John
Re: Merge or Cherry-Pick?
Em quarta-feira, 2 de fevereiro de 2011, às 11:46:20, Wolfgang Rohdewald escreveu: On Dienstag 01 Februar 2011, Thiago Macieira wrote: That's not always true. Some changes will be specific to 4.6, because sections of code in master can get rewritten, features added or removed, so the changes won't be applicable there. That's not a problem or an excuse. Make the change in 4.6, merge to master, fix the conflicts and then push both branches. if I continue developing the app in master and fix some bugs on the way, the fixes will be in master first. I would not always want to put them into 4.6 at once because testing in master is much easier and comes at much less cost while development goes on. So I might even want to wait some days or even weeks until backporting fixes. Laziness is not an argument -- it's just an excuse. If you find a bug that applies to 4.6, why will you not fix it there? In my experience, testing the *stable* releases is easier. Testing the development versions usually cause trouble because of unfinished features and untested new code. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
Em quarta-feira, 2 de fevereiro de 2011, às 09:23:43, Parker Coates escreveu: Hmm. You're probably right. The majority of my Git experience has been with git-svn where it's pretty much mandatory to commit via master. In No, it isn't :-) You can commit from anywhere with git-svn. It chooses the SVN target based on the last SVN commit it finds in the history. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Wednesday 02 February 2011, Oswald Buddenhagen wrote: On Wed, Feb 02, 2011 at 01:21:44AM -0500, Dawit Alemayehu wrote: On Wed, Feb 2, 2011 at 12:58 AM, John Tapsell johnf...@gmail.com wrote: But how would a similar work flow except there are multiple fixes Does that make sense? Yes. Great. IMHO that type of documentation is what is needed in techbase. in fact, that's exactly the type that does *not* belong there. there is enough generic git documentation out there, and bloating techbase by duplicating it all won't make it simpler to use. the right way is stating the desired goals, mentioning a few key phrases (interactive rebase in this case) and linking to some external source. I very much disagree with this. We need the basic recipes there. With short statements I then start searching around in the web, find some blogs, some man pages, mess around, and in the end just take a local diff, get a fresh clone because everything is messed up, and apply the local diff in one step. At least that's the experience I had when trying to merge with conflicts and short remarks like do a interactive rebase or something like that, which lead me into an editor window which showed strange things where I didn't understand what I should do and when I did something things just got worse. Alex
Re: Merge or Cherry-Pick?
On Wednesday 02 February 2011, John Layt wrote: On Wednesday 02 February 2011 13:43:04 Parker Coates wrote: My preferred workflow is to put all local commits intended for master in a single, local, long-lived workmaster branch instead of putting them in master directly. Since the changes are local, you can just keep rebasing it onto master every time master is updated. Then if you want to push a single commit from the work branch: * pull master * you interactively rebase the workmaster branch onto master to put the desired commit first * merge the SHA you want to commit into master * push master I find that by keeping my commits out of master itself allows me to update without worries, to commit high priority fixes without messing up my local work, and to commit early and often locally while still having the option to clean things up later with some rebasing. Personally, I found this ability to keep my local commit queue out of the way was the biggest advantage of switching to Git. Parker Personally, I think you should NEVER have commits in master, you should only ever work in and push from branches, they're so cheap to do. That way your master is always a clean pure copy of the main repo to branch off. I don't really care how it will be, but I really think we should agree on one common recommended and documented workflow to use. Alex
Re: Merge or Cherry-Pick?
On Wednesday, 2 de February de 2011 18:28:38 Alexander Neundorf wrote: If you find a bug that applies to 4.6, why will you not fix it there? In my experience, testing the *stable* releases is easier. Testing the development versions usually cause trouble because of unfinished features and untested new code. The code may already differ. The developer may not have both branches installed in a recent and runnable state. Fair enough. Then fix only master. If you don't have the time or ability to test the stable release, do not apply commits there. If you can't test it, then you can't be sure to be doing worse. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
Would someone be so kind to tell me how to undo accidentally pushed commits to trunk ? By accident I pushed the following commits to trunk when I only meant to push backported fixes in 4.6 branch: http://quickgit.kde.org/?p=kdelibs.gita=commith=e6f00fdd71328b26e57ef09e97e4aca569c4199c http://quickgit.kde.org/?p=kdelibs.gita=commith=65ac813c955c97798b53cd3f45854c40bdd2feaa http://quickgit.kde.org/?p=kdelibs.gita=commith=449d49908ce610d9af4e8e3da89466f168f66bc3
Re: Merge or Cherry-Pick?
On Wednesday, February 2, 2011, Alexander Neundorf wrote: On Wednesday 02 February 2011, Oswald Buddenhagen wrote: in fact, that's exactly the type that does *not* belong there. there is enough generic git documentation out there, and bloating techbase by duplicating it all won't make it simpler to use. the right way is stating the desired goals, mentioning a few key phrases (interactive rebase in this case) and linking to some external source. I very much disagree with this. We need the basic recipes there. imho, you're both right :) simple recipes for the common tasks that are done in a KDE way will be of critical value; we can not expect everyone to learn on their own and then expect them to all be proficient or to do things consistently without some basic guidance. so yes, we're going to need to document a few basic things and that will probably involve some very simple illustrative examples. but we also can not get involved in writing a New and Improved Book On Git, either. we ought to rely on external sources for that, as Ossi points out. it's the difference between documenting the KDE best practices and teaching people how to use git, right? and it's one of the things that i found CMake's git documentation pages does very well. they don't make too much sense if you don't have a basic understanding of git, and you'll still run into all kinds of issues in practice that aren't covered on those pages, but they give you enough information to get pointed in the right direction and using the right kinds of commands for the different parts of their development workflow. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Wednesday, February 2, 2011, Thiago Macieira wrote: I still think the current procedure is wrong. You're not testing the stable release, there's no guarantee that you're solving the problem at all, or worse, that you're not making it worse. and, imho, the stable branch is the more important thing to test: if it goes wrong in master due to a bad or unecessary merge from stable, you usually have months to notice and fix it. certain you or your teammates that also track master will notice it faster than if it sits in the stable branch where primary devel isn't happening anymore. with our monthly x.y.z releases, you have at most a few weeks with fewer people tracking the stable branch to catch a bad merge from master. so, again at least imho, the risk is higher when backporting compared to forward porting. and finally we have a tool that makes it reasonably painless to do it. :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Wednesday 19 January 2011, Ian Monroe wrote: Can somebody please add a simple step-by-step howto, what I have to do with identity.kde.org, projects.kde.org and git.kde.org, how the git push/merge/branching policy is for KDE, etc. If there are existing blog articles about this, please add links to them in a good visible place. There is no push/merge/branching policy for KDE. Different projects will likely do their own thing. For the time being its just the SVN-style development translated to Git. This looks to me like do what you want, there is no policy. FWIW I thought the question was regarding branch policies (eg the release schedule with code freezes), not the technicalities of how to do merges between branches. I suppose the answer would be the same, but I was confused why you thought the release schedule system needed to be shaken up post-haste. :) Ian
Re: Merge or Cherry-Pick?
On Wednesday 02 February 2011 21:15:31 Aaron J. Seigo wrote: On Wednesday, February 2, 2011, Thiago Macieira wrote: I still think the current procedure is wrong. You're not testing the stable release, there's no guarantee that you're solving the problem at all, or worse, that you're not making it worse. and, imho, the stable branch is the more important thing to test: if it goes wrong in master due to a bad or unecessary merge from stable, you usually have months to notice and fix it. certain you or your teammates that also track master will notice it faster than if it sits in the stable branch where primary devel isn't happening anymore. with our monthly x.y.z releases, you have at most a few weeks with fewer people tracking the stable branch to catch a bad merge from master. so, again at least imho, the risk is higher when backporting compared to forward porting. and finally we have a tool that makes it reasonably painless to do it. :) I have two reasons to test in master: - I run master myself all the time. - If a fix really is dangerous I don't want it to appear in a bugfix release by accident. If nobody was running master who'd make sure its quality was even remotely decent? Somehow I don't buy that we should all be testing the latest stable branch while developing against master. Switching environments all the time is a major hassle and not as effective at finding and making people care about bugs in master.
Re: Merge or Cherry-Pick?
On Wed, Feb 2, 2011 at 1:03 PM, Dawit A ada...@kde.org wrote: Would someone be so kind to tell me how to undo accidentally pushed commits to trunk ? By accident I pushed the following commits to trunk when I only meant to push backported fixes in 4.6 branch: http://quickgit.kde.org/?p=kdelibs.gita=commith=e6f00fdd71328b26e57ef09e97e4aca569c4199c http://quickgit.kde.org/?p=kdelibs.gita=commith=65ac813c955c97798b53cd3f45854c40bdd2feaa http://quickgit.kde.org/?p=kdelibs.gita=commith=449d49908ce610d9af4e8e3da89466f168f66bc3 For those like me who made a mistake like this one there is an easy solution... Do git config --global push.default tracking and use the -t or --track option when creating your branches (branch or checkout -b). This way you can 'git push' (no arguments) in the current tracked branch without accidentally pushing your changes in other branches.
Re: Merge or Cherry-Pick?
Am 2/3/2011 6:10, schrieb Dawit A: What happens if I tested a bug fix and wanted it to push it upstream so that it can receive even wider testing, but it just so happens the time to tag the next bug fix release is right around the corner ? The original intent is to at least leave the bug fix in the trunk for several days to see if it causes any unforeseen regression. It is an impossible task for any developer, specially one working on the plumbing libraries, to test every possible combination or use case. If the push is done into a stable branch, then there is a real possibility that users are going to get exposed to unintended regressions. I'll assume you meant to say push is done into a stable branch *too early*... (otherwise, the last sentence in this paragraph is incompatible with the first part of the paragraph). You do it this way: 1. You fork off a topic branch from stable, and place your fix there. 2. Compile-test the fix. (Bonus points, if you can test the fix in action with the stable version.) 3. Merge that topic into master. Compile and test. 4. Publish the merge. Let it cook for a week in master. 5. Looks OK? Good. Merge the topic into the stable branch as well. (The stable branch might have progressed in the past week, hence, you don't necessarily fast-forward, but get a real merge.) 6. Merge stable into master and publish both. However, if you cannot test your fix with the stable version yourself, you should ask someone to do Step 5, additionally Step 5b test with stable version, and Step 6 for you. Hannes -- Atomic objects are neither active nor radioactive. -- Programming Languages -- C++, Final Committee Draft (Doc.N3092)
Re: Merge or Cherry-Pick?
On Tue, Feb 01, 2011 at 08:18:10AM +0100, Thiago Macieira wrote: On Tuesday, 1 de February de 2011 01:23:01 Oswald Buddenhagen wrote: just face it, git's merging concept makes most sense for longer-lived feature branches, but not so much for bugfix branches. not even linux itself uses a forward-merge strategy for bugfix branches. How does the kernel work then? As far as I know, everything is merged. not bugfix branches, e.g. what will become 2.6.37.1. it is in fact maintained by a different person and linus doesn't care much for it. it just works better if the stability of a patch is proven in someone higher up the hierarchy's master. fwiw, even in linux' history you'll find merged cherry-picks, but that's presumably because less critical bugfixes often take so long to propagate in the hierarchy. having said that, i do think a clean forward-merging strategy is worthwhile and feasible, given the proper infrastructure and mindsets - e.g. what i envision for qt's opengov. but this is so utterly incompatible with kde's resources and low quality standards^W^Wbarrier to entry culture.
Re: Merge or Cherry-Pick?
On Tue, Feb 01, 2011 at 01:43:17AM +0100, Andreas Pakulat wrote: I'm constantly doing the tag --contains and branch --contains thing to find out when a certain fix was done at work to double-check wether a reported bug is already contained in a released version. Or which branches are affected by a bug introduced by a specific commit. this could be implemented by a secondary merge tracking mechanism which works like svn's. git somewhat recently got the notes feature which allows attaching pretty much any textual metadata to commits without altering them. it's just that somebody would have to write that code ...
Re: Merge or Cherry-Pick?
On Mon, January 31, 2011 11:27 pm, Thiago Macieira wrote: On Monday, 31 de January de 2011 23:34:39 Arno Rehn wrote: I guess that won't quite work when there are commits specific to 4.6 in the 4.6 branch that shouldn't end up in master. And it clutters history with tons of merges. Then let's solve the problem by not having anything specific to 4.6. If it belongs in the stable release, it belongs in the next stable release too. That's not always true. Some changes *will* be specific to 4.6, because sections of code in master can get rewritten, features added or removed, so the changes won't be applicable there. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Merge or Cherry-Pick?
On Tuesday, February 1, 2011, Alexander Neundorf wrote: On Monday 31 January 2011, Andreas Pakulat wrote: Hi, something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? Andreas Not replying to any particular response in this thread... I don't know whether I missed something, if so, please let me know. no, you didn't miss anything. right now i think everyone is very busy getting up to speed with the basics. for instance, i spent a good portion of the day today struggling with git.reviewboard.kde.org (sysadmin was very helpful, but things are still rough in places ..) there's also the issue that it appears that the 4.6 branch is unmergable with master, complicating things for the time being. in fact, it encourages cherry- picks when probably it should be merges. then i learned today to be extra vigilant about doing `git pull --rebase` and not just `git pull` so i don't accidentally throw merge commits in there while preping for a push. and so yes, it's all a bit hap-hazzard at the moment and many of us are learning at a brisk pace. ;) those that may have much of this information are busy with supporting the migration itself. so ... how do we go from where we are now to where we need to be with documentation? well .. .. i think we need to stop hoping for someone else to do the work. :) there's an email coming in a new thread to get that moving. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Tue, Feb 1, 2011 at 10:22 PM, Aaron J. Seigo ase...@kde.org wrote: then i learned today to be extra vigilant about doing `git pull --rebase` and not just `git pull` so i don't accidentally throw merge commits in there while preping for a push. Look in man git-config for branch.autosetuprebase. I think this should go into the Git manual after someone has checked this (did not actually try it). Greetings Stefan
Re: Merge or Cherry-Pick?
On Tuesday, February 1, 2011, Stefan Majewsky wrote: On Tue, Feb 1, 2011 at 10:22 PM, Aaron J. Seigo ase...@kde.org wrote: then i learned today to be extra vigilant about doing `git pull --rebase` and not just `git pull` so i don't accidentally throw merge commits in there while preping for a push. Look in man git-config for branch.autosetuprebase. I think this should go into the Git manual after someone has checked this (did not actually try it). ooh, very cool. ok, i'm going to try running with this and see how it rolls. we _really_ need to start a page to collect all these tidbits together. i'm not sure where yet and i'm afraid i've run out of time for today. an etherpad that we can all edit might be a good place to start collecting these gems, and then we can grab the best bits and put them on a page on techbase... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On 01.02.11 14:06:47, Aaron J. Seigo wrote: On Tuesday, February 1, 2011, Stefan Majewsky wrote: On Tue, Feb 1, 2011 at 10:22 PM, Aaron J. Seigo ase...@kde.org wrote: then i learned today to be extra vigilant about doing `git pull --rebase` and not just `git pull` so i don't accidentally throw merge commits in there while preping for a push. Look in man git-config for branch.autosetuprebase. I think this should go into the Git manual after someone has checked this (did not actually try it). ooh, very cool. ok, i'm going to try running with this and see how it rolls. In addition to that you probably also want to do git config branch.yourbranchname.rebase true for any branches you already created locally (thats what autosetuprebase does when creating a new local branch from a remote one) We're using that since 1+ year at work now and so far haven't had a single case where it broke something. Andreas -- You love peace.
Re: Merge or Cherry-Pick?
On Tue, Feb 1, 2011 at 4:22 PM, Aaron J. Seigo ase...@kde.org wrote: On Tuesday, February 1, 2011, Alexander Neundorf wrote: On Monday 31 January 2011, Andreas Pakulat wrote: Hi, something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? Andreas Not replying to any particular response in this thread... I don't know whether I missed something, if so, please let me know. no, you didn't miss anything. right now i think everyone is very busy getting up to speed with the basics. for instance, i spent a good portion of the day today struggling with git.reviewboard.kde.org (sysadmin was very helpful, but things are still rough in places ..) there's also the issue that it appears that the 4.6 branch is unmergable with master, complicating things for the time being. in fact, it encourages cherry- picks when probably it should be merges. then i learned today to be extra vigilant about doing `git pull --rebase` and not just `git pull` so i don't accidentally throw merge commits in there while preping for a push. I learned this the hard way, but it is even more problematic, at least for me, when you attempt to learn how to adapt or re-learn how to do a particular workflow with git. For example, let us take one of the things Alexander mentioned in his email: * for committing a trivial change to master/trunk If you only had a single change that is already committed into your local repo, then I guess it is simple enough and can be pushed to the origin master branch by doing: git pull --rebase git push But how would a similar work flow except there are multiple fixes present in the local repo ? How would you push only a single fix in such case ? It does not seem possible to me to do that... If that is the case, does it mean we have to create separate branches for each and every fix we work on since branches are cheap to create in git ? Or simply wait until we are ready to push all the changes and do them at once ? What if that is not desirable, i.e. an urgent fix that needs to be committed ? There is probably easier way to do things in git, but despite reading several articles and documentation on git, it is not easy to figure out the uses of git for own work flow for first time users like myself. Perhaps compiling answers for the easiest way to handle the most common work flows being discussed here would be a good starting point for a guide that can be put on techbase... Regards, Dawit A.
Re: Merge or Cherry-Pick?
On Wed, Feb 2, 2011 at 12:58 AM, John Tapsell johnf...@gmail.com wrote: But how would a similar work flow except there are multiple fixes present in the local repo ? How would you push only a single fix in such case ? git rebase -i origin #Bring up a list of your changes. Reorder them in the editor so that the commit you want to push is at the top of the list, save Fix any conflicts that might have arisen because you reordered the commits git pull --rebase #make sure we are up to date git log #copy the SHA of the commit you want to push up to git push origin SHA:head #paste the SHA that you just copied where I wrote SHA Does that make sense? There are other ways to do it, but this way avoids most of the common problems. Yes. Great. IMHO that type of documentation is what is needed in techbase. One question though... why would i need to do git rebase -i origin if I always do git pull --rebase in the first place ? Wouldn't simply following the steps you mentioned after git pull --rebase suffice since I am going to be using the commit SHA to do the push ?
Re: Merge or Cherry-Pick?
On Wed, Feb 2, 2011 at 2:02 AM, Kevin Ottens er...@kde.org wrote: On Wednesday 2 February 2011 07:21:44 Dawit A wrote: On Wed, Feb 2, 2011 at 12:58 AM, John Tapsell johnf...@gmail.com wrote: But how would a similar work flow except there are multiple fixes present in the local repo ? How would you push only a single fix in such case ? git rebase -i origin #Bring up a list of your changes. Reorder them in the editor so that the commit you want to push is at the top of the list, save Fix any conflicts that might have arisen because you reordered the commits git pull --rebase #make sure we are up to date git log #copy the SHA of the commit you want to push up to git push origin SHA:head #paste the SHA that you just copied where I wrote SHA Does that make sense? There are other ways to do it, but this way avoids most of the common problems. Yes. Great. IMHO that type of documentation is what is needed in techbase. One question though... why would i need to do git rebase -i origin if I always do git pull --rebase in the first place ? Wouldn't simply following the steps you mentioned after git pull --rebase suffice since I am going to be using the commit SHA to do the push ? Because the order matters. git will push everything up to the commit with the SHA1 passed as parameter. git rebase -i allows you to reorder your commits first. Ahh... I see. It is push everything upto that commit, not just push that commit. Ouch! That is almost as much a hassle as the convoluted method I am following now. Do not commit anything that is not ready to be pushed into my own local branch. Use git stash to save the uncommited changes before doing the pull --rebase and apply the stashed changes after doing the push...
Re: Merge or Cherry-Pick?
On Wednesday, 2 de February de 2011 05:58:35 John Tapsell wrote:
git rebase -i origin #Bring up a list of your changes.
Reorder them in the editor so that the commit you want to push is at
the top of the list, save
Fix any conflicts that might have arisen because you reordered the commits
git pull --rebase #make sure we are up to date
git log #copy the SHA of the commit you want to push up to
Hint:
git log @{upstream}..
(the two dots included)
git push origin SHA:head #paste the SHA that you just copied where I
wrote SHA
I think head here is supposed to be the branch you want to push to. Please
avoid using head, as it easily is confused with HEAD.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
Merge or Cherry-Pick?
Hi, something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? Andreas -- You learn to write as if to someone else because NEXT YEAR YOU WILL BE SOMEONE ELSE.
Re: Merge or Cherry-Pick?
On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote: Hi, something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? Commit to 4.6, merge 4.6 into master. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Monday 31 January 2011 23:27:15 Thiago Macieira wrote: On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote: Hi, something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? Commit to 4.6, merge 4.6 into master. I guess that won't quite work when there are commits specific to 4.6 in the 4.6 branch that shouldn't end up in master. And it clutters history with tons of merges. Personally I'd go with 'Commit to master, cherry-pick in 4.6'. (Feature branches are a different thing). -- Arno Rehn a...@arnorehn.de
Re: Merge or Cherry-Pick?
On Mon, Jan 31, 2011 at 11:34 PM, Arno Rehn kde-de...@arnorehn.de wrote: (Feature branches are a different thing). Am I right that these should be rebased instead of merged?
Re: Merge or Cherry-Pick?
On Monday, January 31, 2011, Andreas Pakulat wrote: something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? what i've started doing for bugfixes is to apply the fix to the stable branch (e.g. 4.6) and then cherry-pick that into master. when i tried to merge the 4.6 branch into master, i just got a ton of conflicts, so i stopped trying that :) my git fu is not strong, however, so i'm near certain there must be better ways ... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Monday, 31 de January de 2011 23:50:49 Oswald Buddenhagen wrote: On Mon, Jan 31, 2011 at 11:27:15PM +0100, Thiago Macieira wrote: On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote: something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? Commit to 4.6, merge 4.6 into master. that's hard enough in qt, and there is totally no way that kde's discipline would be sufficient to make forward-merging feasible (as in actually helpful and producing an even remotely readable history). Only because in Qt we do it in batches, so we get lots of changes. And the Qt repository is way bigger than anything KDE has. If people merge after they've applied a change to the previous version, only their change needs merging. If it conflicts, it's your change. therefore i'm for cherry-picking, preferably with a mandated -x flag. of course that means no merge tracking whatsover, which is about as much as we used from svn when it comes to bugfix backports. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Monday, 31 de January de 2011 14:44:38 Aaron J. Seigo wrote: On Monday, January 31, 2011, Andreas Pakulat wrote: something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? what i've started doing for bugfixes is to apply the fix to the stable branch (e.g. 4.6) and then cherry-pick that into master. when i tried to merge the 4.6 branch into master, i just got a ton of conflicts, so i stopped trying that :) Because of the cherry-picks. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Mon, Jan 31, 2011 at 5:27 PM, Thiago Macieira thi...@kde.org wrote: On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote: Hi, something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? Commit to 4.6, merge 4.6 into master. Doesn't that conflict the true and tried workflow of never back porting fixes that have not received some testing into a stable branch ? To me this seems to do things in reverse. Perhaps the workflow is supposed to be different in git ?
Re: Merge or Cherry-Pick?
On Monday, January 31, 2011, Thiago Macieira wrote: On Monday, 31 de January de 2011 14:44:38 Aaron J. Seigo wrote: On Monday, January 31, 2011, Andreas Pakulat wrote: something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? what i've started doing for bugfixes is to apply the fix to the stable branch (e.g. 4.6) and then cherry-pick that into master. when i tried to merge the 4.6 branch into master, i just got a ton of conflicts, so i stopped trying that :) Because of the cherry-picks. this was before i did any cherry-picks myself, but perhaps others had already beat me to it. in any case, is there a way to fix it so that the 4.6 branch would become mergeable with master, or do we now basically just have to wait for a 4.7 branch? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Tue, Feb 01, 2011 at 12:29:12AM +0100, Thiago Macieira wrote: On Monday, 31 de January de 2011 23:50:49 Oswald Buddenhagen wrote: On Mon, Jan 31, 2011 at 11:27:15PM +0100, Thiago Macieira wrote: Commit to 4.6, merge 4.6 into master. that's hard enough in qt, and there is totally no way that kde's discipline would be sufficient to make forward-merging feasible (as in actually helpful and producing an even remotely readable history). Only because in Qt we do it in batches, so we get lots of changes. And the Qt repository is way bigger than anything KDE has. that's part of the problem, but not what i aimed at. people are just too short-minded and often too lazy (and sometimes don't have the disk space or cpu/time) to do things in the proper branch to start with. the result is a lot of cherry-picks even when using forward merging, which makes for a rather terrible history and a somewhat limited benefit. just look at qt's history - kde's will be three times worse. just face it, git's merging concept makes most sense for longer-lived feature branches, but not so much for bugfix branches. not even linux itself uses a forward-merge strategy for bugfix branches.
Re: Merge or Cherry-Pick?
On 31.01.11 16:05:43, Aaron J. Seigo wrote: On Monday, January 31, 2011, Thiago Macieira wrote: On Monday, 31 de January de 2011 14:44:38 Aaron J. Seigo wrote: On Monday, January 31, 2011, Andreas Pakulat wrote: something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? what i've started doing for bugfixes is to apply the fix to the stable branch (e.g. 4.6) and then cherry-pick that into master. when i tried to merge the 4.6 branch into master, i just got a ton of conflicts, so i stopped trying that :) Because of the cherry-picks. this was before i did any cherry-picks myself, but perhaps others had already beat me to it. in any case, is there a way to fix it so that the 4.6 branch would become mergeable with master, or do we now basically just have to wait for a 4.7 branch? One could do a git merge --ours KDE/4.6 if its certain that all changes from 4.6 have been cherry-picked into master. That'll do the merge, but ignore any changes in 4.6 and simply always use the master version of all files. Having had a quick look at the result of a normal git merge KDE/4.6 into master, however I think that this is not desirable. Even some .desktop files seem to need manual merging (or at least another scripty run, I can see fr-translations in 4.6 that are not in master). Other things may be fine, dunno and am not willing to take this on my head by doing the merge :) For now I've cherry-picked my change as well (otherwise I might even forget all about it), but I think trying to do forward-merges at least when 4.7 branches off would be very useful. I'm constantly doing the tag --contains and branch --contains thing to find out when a certain fix was done at work to double-check wether a reported bug is already contained in a released version. Or which branches are affected by a bug introduced by a specific commit. Having this info available for kdelibs is quite important IMHO and hence worth the extra merge commits in the history. Once you're used to them, you don't even see them anymore :) Andreas -- Give him an evasive answer.
Re: Merge or Cherry-Pick?
On Tuesday, 1 de February de 2011 01:23:01 Oswald Buddenhagen wrote: just face it, git's merging concept makes most sense for longer-lived feature branches, but not so much for bugfix branches. not even linux itself uses a forward-merge strategy for bugfix branches. How does the kernel work then? As far as I know, everything is merged. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Monday, 31 de January de 2011 18:37:32 Dawit A wrote: On Mon, Jan 31, 2011 at 5:27 PM, Thiago Macieira thi...@kde.org wrote: On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote: Hi, something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? Commit to 4.6, merge 4.6 into master. Doesn't that conflict the true and tried workflow of never back porting fixes that have not received some testing into a stable branch ? To me this seems to do things in reverse. Perhaps the workflow is supposed to be different in git ? The workflow is supposed to be different. You're supposed to test the 4.6 branch first. If the fix is not good enough for 4.6, why would you put it in the repository at all? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Monday, 31 de January de 2011 16:05:43 Aaron J. Seigo wrote: this was before i did any cherry-picks myself, but perhaps others had already beat me to it. in any case, is there a way to fix it so that the 4.6 branch would become mergeable with master, or do we now basically just have to wait for a 4.7 branch? Fix all the conflicts. After that, merging should work. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
