Re: [git-users] Re: Question: git merge origin/master
however, such command works as expected (doesn't show merges) git log -p -10 HEAD --not origin/master I have to figure out how to force double --not to work On Mon, Sep 30, 2013 at 7:30 AM, Konstantin Kivi konstantin.k...@gmail.comwrote: according to documentation, this command should work, but it doesn't. It still shows commits resulted from merges On Fri, Sep 27, 2013 at 6:30 PM, Marcelo Avila mav...@cpqd.com.br wrote: The use of .. or ... will depend if you want to include the commit G (in my example) or not. With this command you get something next you want: git log --no-merges -p commi1..commit2 --not master -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/27 Konstantin Kivi konstantin.k...@gmail.com This will work (if use 3 dots instead off 2), but only on entire branch, ( I will see ALL my changes on this branch) If, on the other hand, I want to see changes for, say, last 2 days, I will also get all changes introduced by merge commits that happend in this period. What I want is to see something like git diff A B MINUS origin/master That was my question On Fri, Sep 27, 2013 at 3:48 PM, Marcelo Avila mav...@cpqd.com.brwrote: Sorry, I think I lost the focus here... Suppose you have something like this: B---E---F---H topic / / A---C---D---G master I think that what you want is: git diff master..topic Which will show differences introduced by commits B, E, F and H I hope this helps... -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/27 Konstantin Kivi konstantin.k...@gmail.com If we get back to my question - there is no way to see difference between between two arbitrary commits in my task branch excluding diffs resulted from merges, right ? четверг, 26 сентября 2013 г., 16:21:46 UTC+4 пользователь Marcelo Avila написал: Yes, if somebody do any commit based on your commits you can not use rebase, but this must only happen when your task is done and you do not want to use rebase anymore. In other words, work in you tasks rebasing when needed, you can share your commits to someone but nobody can make commits based in your commits until your work is done and submitted to the main line, when this happens it's time to start working in another task... Recompilations: I can't see any difference in using rebase or merge in this specific topic, I think that the number of recompilations will be exactly the same using one method or the other. -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/26 Gergely Polonkai ger...@polonkai.eu Hello, The point is to rebase before pushing, thus, only rearrange/edit only the commits that haven't gone public yet. Rebasing is only a bad idea if you do it with already pushed commits. The other use case is rebase on pull. If your upstream changes while you develop your own code, do a git pull --rebase instead of a plain git pull. This will rebase your changes on the fresh state of upstream. Cheers, Gergely On 26 Sep 2013 05:57, Konstantin Kivi konstan...@gmail.com wrote: Honestly, I right now I don't have to publish (make public ) branches, as for current progects I use git locally, and use svn as main repository. But new projects use git only, so I have to return to right track. All documenation says that rebasing a branch that was made public is a bad idea, as people who used my branch will have numerous conflicts after I do rebase. As to recompilations, it of course depend on the nature of changes in master branch and in my task branch. If in my task I have heavy header file changes (C++) then switching to master ( which is requiried to do svn up or git pull ) will cause timestamp changes of that header and thus recompliations. Updates of master branch can also change header files, so sometimes it doesn't matter. The main reason of not useing rebase is that it is not recommended by books. среда, 25 сентября 2013 г., 15:37:30 UTC+4 пользователь Marcelo Avila написал: Yes, the solution is to switch back to the rebase approach... I didn't understand some points: Why you could not publish your task branch? Why the rebase approach leads to massive recompilations? -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/25 Konstantin Kivi konstan...@gmail.com Hello All. First I must apologize for asking a question in other people's thread (which I don't like myself) , but you are talking about the approach that I am going to use, so decided that this will be appropriate in this case. Here is the question. I recently decided to switch from 'task branch rebase' aproach
Re: [git-users] Re: Question: git merge origin/master
according to documentation, this command should work, but it doesn't. It still shows commits resulted from merges On Fri, Sep 27, 2013 at 6:30 PM, Marcelo Avila mav...@cpqd.com.br wrote: The use of .. or ... will depend if you want to include the commit G (in my example) or not. With this command you get something next you want: git log --no-merges -p commi1..commit2 --not master -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/27 Konstantin Kivi konstantin.k...@gmail.com This will work (if use 3 dots instead off 2), but only on entire branch, ( I will see ALL my changes on this branch) If, on the other hand, I want to see changes for, say, last 2 days, I will also get all changes introduced by merge commits that happend in this period. What I want is to see something like git diff A B MINUS origin/master That was my question On Fri, Sep 27, 2013 at 3:48 PM, Marcelo Avila mav...@cpqd.com.brwrote: Sorry, I think I lost the focus here... Suppose you have something like this: B---E---F---H topic / / A---C---D---G master I think that what you want is: git diff master..topic Which will show differences introduced by commits B, E, F and H I hope this helps... -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/27 Konstantin Kivi konstantin.k...@gmail.com If we get back to my question - there is no way to see difference between between two arbitrary commits in my task branch excluding diffs resulted from merges, right ? четверг, 26 сентября 2013 г., 16:21:46 UTC+4 пользователь Marcelo Avila написал: Yes, if somebody do any commit based on your commits you can not use rebase, but this must only happen when your task is done and you do not want to use rebase anymore. In other words, work in you tasks rebasing when needed, you can share your commits to someone but nobody can make commits based in your commits until your work is done and submitted to the main line, when this happens it's time to start working in another task... Recompilations: I can't see any difference in using rebase or merge in this specific topic, I think that the number of recompilations will be exactly the same using one method or the other. -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/26 Gergely Polonkai ger...@polonkai.eu Hello, The point is to rebase before pushing, thus, only rearrange/edit only the commits that haven't gone public yet. Rebasing is only a bad idea if you do it with already pushed commits. The other use case is rebase on pull. If your upstream changes while you develop your own code, do a git pull --rebase instead of a plain git pull. This will rebase your changes on the fresh state of upstream. Cheers, Gergely On 26 Sep 2013 05:57, Konstantin Kivi konstan...@gmail.com wrote: Honestly, I right now I don't have to publish (make public ) branches, as for current progects I use git locally, and use svn as main repository. But new projects use git only, so I have to return to right track. All documenation says that rebasing a branch that was made public is a bad idea, as people who used my branch will have numerous conflicts after I do rebase. As to recompilations, it of course depend on the nature of changes in master branch and in my task branch. If in my task I have heavy header file changes (C++) then switching to master ( which is requiried to do svn up or git pull ) will cause timestamp changes of that header and thus recompliations. Updates of master branch can also change header files, so sometimes it doesn't matter. The main reason of not useing rebase is that it is not recommended by books. среда, 25 сентября 2013 г., 15:37:30 UTC+4 пользователь Marcelo Avila написал: Yes, the solution is to switch back to the rebase approach... I didn't understand some points: Why you could not publish your task branch? Why the rebase approach leads to massive recompilations? -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/25 Konstantin Kivi konstan...@gmail.com Hello All. First I must apologize for asking a question in other people's thread (which I don't like myself) , but you are talking about the approach that I am going to use, so decided that this will be appropriate in this case. Here is the question. I recently decided to switch from 'task branch rebase' aproach to 'merge' approach. I used to work in the task branch, periodically switching to master, making pull and rebasing task branch. This worked fine, except I could not publish my task branch. And it also leads to massive recompilations, since I
Re: [git-users] Re: Question: git merge origin/master
This will work (if use 3 dots instead off 2), but only on entire branch, ( I will see ALL my changes on this branch) If, on the other hand, I want to see changes for, say, last 2 days, I will also get all changes introduced by merge commits that happend in this period. What I want is to see something like git diff A B MINUS origin/master That was my question On Fri, Sep 27, 2013 at 3:48 PM, Marcelo Avila mav...@cpqd.com.br wrote: Sorry, I think I lost the focus here... Suppose you have something like this: B---E---F---H topic / / A---C---D---G master I think that what you want is: git diff master..topic Which will show differences introduced by commits B, E, F and H I hope this helps... -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/27 Konstantin Kivi konstantin.k...@gmail.com If we get back to my question - there is no way to see difference between between two arbitrary commits in my task branch excluding diffs resulted from merges, right ? четверг, 26 сентября 2013 г., 16:21:46 UTC+4 пользователь Marcelo Avila написал: Yes, if somebody do any commit based on your commits you can not use rebase, but this must only happen when your task is done and you do not want to use rebase anymore. In other words, work in you tasks rebasing when needed, you can share your commits to someone but nobody can make commits based in your commits until your work is done and submitted to the main line, when this happens it's time to start working in another task... Recompilations: I can't see any difference in using rebase or merge in this specific topic, I think that the number of recompilations will be exactly the same using one method or the other. -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/26 Gergely Polonkai ger...@polonkai.eu Hello, The point is to rebase before pushing, thus, only rearrange/edit only the commits that haven't gone public yet. Rebasing is only a bad idea if you do it with already pushed commits. The other use case is rebase on pull. If your upstream changes while you develop your own code, do a git pull --rebase instead of a plain git pull. This will rebase your changes on the fresh state of upstream. Cheers, Gergely On 26 Sep 2013 05:57, Konstantin Kivi konstan...@gmail.com wrote: Honestly, I right now I don't have to publish (make public ) branches, as for current progects I use git locally, and use svn as main repository. But new projects use git only, so I have to return to right track. All documenation says that rebasing a branch that was made public is a bad idea, as people who used my branch will have numerous conflicts after I do rebase. As to recompilations, it of course depend on the nature of changes in master branch and in my task branch. If in my task I have heavy header file changes (C++) then switching to master ( which is requiried to do svn up or git pull ) will cause timestamp changes of that header and thus recompliations. Updates of master branch can also change header files, so sometimes it doesn't matter. The main reason of not useing rebase is that it is not recommended by books. среда, 25 сентября 2013 г., 15:37:30 UTC+4 пользователь Marcelo Avila написал: Yes, the solution is to switch back to the rebase approach... I didn't understand some points: Why you could not publish your task branch? Why the rebase approach leads to massive recompilations? -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/25 Konstantin Kivi konstan...@gmail.com Hello All. First I must apologize for asking a question in other people's thread (which I don't like myself) , but you are talking about the approach that I am going to use, so decided that this will be appropriate in this case. Here is the question. I recently decided to switch from 'task branch rebase' aproach to 'merge' approach. I used to work in the task branch, periodically switching to master, making pull and rebasing task branch. This worked fine, except I could not publish my task branch. And it also leads to massive recompilations, since I have to switch to master and then back. I decided to switch to merge apporoach, that is do fetch periodically, and then merge 'origin/master' to my task branch. The problem now is how to check what I have done. I always can find what I have done in my branch from the start, by 'git diff origin/master...task_b' but I cannot find my changes between two given commits or by several last commits, as it always shows any merges that have been done in-between. Is there any remedy for this problem ? Regards, Konstantin -- You received this message because you are subscribed to
Re: [git-users] Re: Question: git merge origin/master
The use of .. or ... will depend if you want to include the commit G (in my example) or not. With this command you get something next you want: git log --no-merges -p commi1..commit2 --not master -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/27 Konstantin Kivi konstantin.k...@gmail.com This will work (if use 3 dots instead off 2), but only on entire branch, ( I will see ALL my changes on this branch) If, on the other hand, I want to see changes for, say, last 2 days, I will also get all changes introduced by merge commits that happend in this period. What I want is to see something like git diff A B MINUS origin/master That was my question On Fri, Sep 27, 2013 at 3:48 PM, Marcelo Avila mav...@cpqd.com.br wrote: Sorry, I think I lost the focus here... Suppose you have something like this: B---E---F---H topic / / A---C---D---G master I think that what you want is: git diff master..topic Which will show differences introduced by commits B, E, F and H I hope this helps... -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/27 Konstantin Kivi konstantin.k...@gmail.com If we get back to my question - there is no way to see difference between between two arbitrary commits in my task branch excluding diffs resulted from merges, right ? четверг, 26 сентября 2013 г., 16:21:46 UTC+4 пользователь Marcelo Avila написал: Yes, if somebody do any commit based on your commits you can not use rebase, but this must only happen when your task is done and you do not want to use rebase anymore. In other words, work in you tasks rebasing when needed, you can share your commits to someone but nobody can make commits based in your commits until your work is done and submitted to the main line, when this happens it's time to start working in another task... Recompilations: I can't see any difference in using rebase or merge in this specific topic, I think that the number of recompilations will be exactly the same using one method or the other. -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/26 Gergely Polonkai ger...@polonkai.eu Hello, The point is to rebase before pushing, thus, only rearrange/edit only the commits that haven't gone public yet. Rebasing is only a bad idea if you do it with already pushed commits. The other use case is rebase on pull. If your upstream changes while you develop your own code, do a git pull --rebase instead of a plain git pull. This will rebase your changes on the fresh state of upstream. Cheers, Gergely On 26 Sep 2013 05:57, Konstantin Kivi konstan...@gmail.com wrote: Honestly, I right now I don't have to publish (make public ) branches, as for current progects I use git locally, and use svn as main repository. But new projects use git only, so I have to return to right track. All documenation says that rebasing a branch that was made public is a bad idea, as people who used my branch will have numerous conflicts after I do rebase. As to recompilations, it of course depend on the nature of changes in master branch and in my task branch. If in my task I have heavy header file changes (C++) then switching to master ( which is requiried to do svn up or git pull ) will cause timestamp changes of that header and thus recompliations. Updates of master branch can also change header files, so sometimes it doesn't matter. The main reason of not useing rebase is that it is not recommended by books. среда, 25 сентября 2013 г., 15:37:30 UTC+4 пользователь Marcelo Avila написал: Yes, the solution is to switch back to the rebase approach... I didn't understand some points: Why you could not publish your task branch? Why the rebase approach leads to massive recompilations? -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/25 Konstantin Kivi konstan...@gmail.com Hello All. First I must apologize for asking a question in other people's thread (which I don't like myself) , but you are talking about the approach that I am going to use, so decided that this will be appropriate in this case. Here is the question. I recently decided to switch from 'task branch rebase' aproach to 'merge' approach. I used to work in the task branch, periodically switching to master, making pull and rebasing task branch. This worked fine, except I could not publish my task branch. And it also leads to massive recompilations, since I have to switch to master and then back. I decided to switch to merge apporoach, that is do fetch periodically, and then merge 'origin/master' to my task branch. The problem now is how to check what I
Re: [git-users] Re: Question: git merge origin/master
Hello, The point is to rebase before pushing, thus, only rearrange/edit only the commits that haven't gone public yet. Rebasing is only a bad idea if you do it with already pushed commits. The other use case is rebase on pull. If your upstream changes while you develop your own code, do a git pull --rebase instead of a plain git pull. This will rebase your changes on the fresh state of upstream. Cheers, Gergely On 26 Sep 2013 05:57, Konstantin Kivi konstantin.k...@gmail.com wrote: Honestly, I right now I don't have to publish (make public ) branches, as for current progects I use git locally, and use svn as main repository. But new projects use git only, so I have to return to right track. All documenation says that rebasing a branch that was made public is a bad idea, as people who used my branch will have numerous conflicts after I do rebase. As to recompilations, it of course depend on the nature of changes in master branch and in my task branch. If in my task I have heavy header file changes (C++) then switching to master ( which is requiried to do svn up or git pull ) will cause timestamp changes of that header and thus recompliations. Updates of master branch can also change header files, so sometimes it doesn't matter. The main reason of not useing rebase is that it is not recommended by books. среда, 25 сентября 2013 г., 15:37:30 UTC+4 пользователь Marcelo Avila написал: Yes, the solution is to switch back to the rebase approach... I didn't understand some points: Why you could not publish your task branch? Why the rebase approach leads to massive recompilations? -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/25 Konstantin Kivi konstan...@gmail.com Hello All. First I must apologize for asking a question in other people's thread (which I don't like myself) , but you are talking about the approach that I am going to use, so decided that this will be appropriate in this case. Here is the question. I recently decided to switch from 'task branch rebase' aproach to 'merge' approach. I used to work in the task branch, periodically switching to master, making pull and rebasing task branch. This worked fine, except I could not publish my task branch. And it also leads to massive recompilations, since I have to switch to master and then back. I decided to switch to merge apporoach, that is do fetch periodically, and then merge 'origin/master' to my task branch. The problem now is how to check what I have done. I always can find what I have done in my branch from the start, by 'git diff origin/master...task_b' but I cannot find my changes between two given commits or by several last commits, as it always shows any merges that have been done in-between. Is there any remedy for this problem ? Regards, Konstantin -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Question: git merge origin/master
Yes, if somebody do any commit based on your commits you can not use rebase, but this must only happen when your task is done and you do not want to use rebase anymore. In other words, work in you tasks rebasing when needed, you can share your commits to someone but nobody can make commits based in your commits until your work is done and submitted to the main line, when this happens it's time to start working in another task... Recompilations: I can't see any difference in using rebase or merge in this specific topic, I think that the number of recompilations will be exactly the same using one method or the other. -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/26 Gergely Polonkai gerg...@polonkai.eu Hello, The point is to rebase before pushing, thus, only rearrange/edit only the commits that haven't gone public yet. Rebasing is only a bad idea if you do it with already pushed commits. The other use case is rebase on pull. If your upstream changes while you develop your own code, do a git pull --rebase instead of a plain git pull. This will rebase your changes on the fresh state of upstream. Cheers, Gergely On 26 Sep 2013 05:57, Konstantin Kivi konstantin.k...@gmail.com wrote: Honestly, I right now I don't have to publish (make public ) branches, as for current progects I use git locally, and use svn as main repository. But new projects use git only, so I have to return to right track. All documenation says that rebasing a branch that was made public is a bad idea, as people who used my branch will have numerous conflicts after I do rebase. As to recompilations, it of course depend on the nature of changes in master branch and in my task branch. If in my task I have heavy header file changes (C++) then switching to master ( which is requiried to do svn up or git pull ) will cause timestamp changes of that header and thus recompliations. Updates of master branch can also change header files, so sometimes it doesn't matter. The main reason of not useing rebase is that it is not recommended by books. среда, 25 сентября 2013 г., 15:37:30 UTC+4 пользователь Marcelo Avila написал: Yes, the solution is to switch back to the rebase approach... I didn't understand some points: Why you could not publish your task branch? Why the rebase approach leads to massive recompilations? -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/25 Konstantin Kivi konstan...@gmail.com Hello All. First I must apologize for asking a question in other people's thread (which I don't like myself) , but you are talking about the approach that I am going to use, so decided that this will be appropriate in this case. Here is the question. I recently decided to switch from 'task branch rebase' aproach to 'merge' approach. I used to work in the task branch, periodically switching to master, making pull and rebasing task branch. This worked fine, except I could not publish my task branch. And it also leads to massive recompilations, since I have to switch to master and then back. I decided to switch to merge apporoach, that is do fetch periodically, and then merge 'origin/master' to my task branch. The problem now is how to check what I have done. I always can find what I have done in my branch from the start, by 'git diff origin/master...task_b' but I cannot find my changes between two given commits or by several last commits, as it always shows any merges that have been done in-between. Is there any remedy for this problem ? Regards, Konstantin -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Question: git merge origin/master
If we get back to my question - there is no way to see difference between between two arbitrary commits in my task branch excluding diffs resulted from merges, right ? четверг, 26 сентября 2013 г., 16:21:46 UTC+4 пользователь Marcelo Avila написал: Yes, if somebody do any commit based on your commits you can not use rebase, but this must only happen when your task is done and you do not want to use rebase anymore. In other words, work in you tasks rebasing when needed, you can share your commits to someone but nobody can make commits based in your commits until your work is done and submitted to the main line, when this happens it's time to start working in another task... Recompilations: I can't see any difference in using rebase or merge in this specific topic, I think that the number of recompilations will be exactly the same using one method or the other. -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br javascript: www.cpqd.com.br 2013/9/26 Gergely Polonkai ger...@polonkai.eu javascript: Hello, The point is to rebase before pushing, thus, only rearrange/edit only the commits that haven't gone public yet. Rebasing is only a bad idea if you do it with already pushed commits. The other use case is rebase on pull. If your upstream changes while you develop your own code, do a git pull --rebase instead of a plain git pull. This will rebase your changes on the fresh state of upstream. Cheers, Gergely On 26 Sep 2013 05:57, Konstantin Kivi konstan...@gmail.comjavascript: wrote: Honestly, I right now I don't have to publish (make public ) branches, as for current progects I use git locally, and use svn as main repository. But new projects use git only, so I have to return to right track. All documenation says that rebasing a branch that was made public is a bad idea, as people who used my branch will have numerous conflicts after I do rebase. As to recompilations, it of course depend on the nature of changes in master branch and in my task branch. If in my task I have heavy header file changes (C++) then switching to master ( which is requiried to do svn up or git pull ) will cause timestamp changes of that header and thus recompliations. Updates of master branch can also change header files, so sometimes it doesn't matter. The main reason of not useing rebase is that it is not recommended by books. среда, 25 сентября 2013 г., 15:37:30 UTC+4 пользователь Marcelo Avila написал: Yes, the solution is to switch back to the rebase approach... I didn't understand some points: Why you could not publish your task branch? Why the rebase approach leads to massive recompilations? -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/25 Konstantin Kivi konstan...@gmail.com Hello All. First I must apologize for asking a question in other people's thread (which I don't like myself) , but you are talking about the approach that I am going to use, so decided that this will be appropriate in this case. Here is the question. I recently decided to switch from 'task branch rebase' aproach to 'merge' approach. I used to work in the task branch, periodically switching to master, making pull and rebasing task branch. This worked fine, except I could not publish my task branch. And it also leads to massive recompilations, since I have to switch to master and then back. I decided to switch to merge apporoach, that is do fetch periodically, and then merge 'origin/master' to my task branch. The problem now is how to check what I have done. I always can find what I have done in my branch from the start, by 'git diff origin/master...task_b' but I cannot find my changes between two given commits or by several last commits, as it always shows any merges that have been done in-between. Is there any remedy for this problem ? Regards, Konstantin -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@googlegroups.com javascript:. For more
Re: [git-users] Re: Question: git merge origin/master
Yes, the solution is to switch back to the rebase approach... I didn't understand some points: Why you could not publish your task branch? Why the rebase approach leads to massive recompilations? -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/25 Konstantin Kivi konstantin.k...@gmail.com Hello All. First I must apologize for asking a question in other people's thread (which I don't like myself) , but you are talking about the approach that I am going to use, so decided that this will be appropriate in this case. Here is the question. I recently decided to switch from 'task branch rebase' aproach to 'merge' approach. I used to work in the task branch, periodically switching to master, making pull and rebasing task branch. This worked fine, except I could not publish my task branch. And it also leads to massive recompilations, since I have to switch to master and then back. I decided to switch to merge apporoach, that is do fetch periodically, and then merge 'origin/master' to my task branch. The problem now is how to check what I have done. I always can find what I have done in my branch from the start, by 'git diff origin/master...task_b' but I cannot find my changes between two given commits or by several last commits, as it always shows any merges that have been done in-between. Is there any remedy for this problem ? Regards, Konstantin -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Question: git merge origin/master
Honestly, I right now I don't have to publish (make public ) branches, as for current progects I use git locally, and use svn as main repository. But new projects use git only, so I have to return to right track. All documenation says that rebasing a branch that was made public is a bad idea, as people who used my branch will have numerous conflicts after I do rebase. As to recompilations, it of course depend on the nature of changes in master branch and in my task branch. If in my task I have heavy header file changes (C++) then switching to master ( which is requiried to do svn up or git pull ) will cause timestamp changes of that header and thus recompliations. Updates of master branch can also change header files, so sometimes it doesn't matter. The main reason of not useing rebase is that it is not recommended by books. среда, 25 сентября 2013 г., 15:37:30 UTC+4 пользователь Marcelo Avila написал: Yes, the solution is to switch back to the rebase approach... I didn't understand some points: Why you could not publish your task branch? Why the rebase approach leads to massive recompilations? -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br javascript: www.cpqd.com.br 2013/9/25 Konstantin Kivi konstan...@gmail.com javascript: Hello All. First I must apologize for asking a question in other people's thread (which I don't like myself) , but you are talking about the approach that I am going to use, so decided that this will be appropriate in this case. Here is the question. I recently decided to switch from 'task branch rebase' aproach to 'merge' approach. I used to work in the task branch, periodically switching to master, making pull and rebasing task branch. This worked fine, except I could not publish my task branch. And it also leads to massive recompilations, since I have to switch to master and then back. I decided to switch to merge apporoach, that is do fetch periodically, and then merge 'origin/master' to my task branch. The problem now is how to check what I have done. I always can find what I have done in my branch from the start, by 'git diff origin/master...task_b' but I cannot find my changes between two given commits or by several last commits, as it always shows any merges that have been done in-between. Is there any remedy for this problem ? Regards, Konstantin -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
