Re: [git-users] Empty Commit?
Hi Vicki, You're trying to amend your commit (which was previously pushed to Gerrit) but your new commit (the amend) would have the exact same tree as its parent commit (see --allow-empty item in git help commit). In this case, you do NOT need to amend your commit, you just need to abandon the original one by clicking in the *Abandon Change* button in Gerrit UI. -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/10/22 William Seiti Mizuta william.miz...@gmail.com Yes, that might be the cause. Then, you can discard the last commit with git reset --hard HEAD^ or create an empty commit with git commit --allow-empty William Seiti Mizuta @williammizuta Caelum | Ensino e Inovação www.caelum.com.br On Tue, Oct 22, 2013 at 2:55 PM, Vicki Kozel vickiko...@gmail.com wrote: Also, my file on the branch that I am amending looks exactly like the file in master. I checked their SHA1 signatures with git hash-object command - they are identical. Maybe that what is causing the problem? On Tuesday, October 22, 2013 11:53:25 AM UTC-7, Vicki Kozel wrote: Thank you William, I just tried that - same outcome. Vicki On Tuesday, October 22, 2013 11:24:29 AM UTC-7, William Seiti Mizuta wrote: On Tue, Oct 22, 2013 at 2:20 PM, Vicki Kozel vicki...@gmail.comwrote: git commit COMMON/pom.xml --amend You don't need to pass the file in commit command. You just need to use git commit --amend William Seiti Mizuta @williammizuta Caelum | Ensino e Inovação www.caelum.com.br -- 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] Empty Commit?
But in this special case the amended commit you are planning to push to Gerrit is equal to the original commit you have based in to make your previous commit. You do not need to make the same commit again to fix your change, just abandon it on Gerrit. -- Marcelo Ávila de Oliveira mav...@cpqd.com.br Em 22/10/2013 18:55, Vicki Kozel vickiko...@gmail.com escreveu: Hi Marcelo, I do not want to abandon this change, I want to keep it and the commit unchanged. I think this is a good practice in Gerrit to keep adding patches to the same change - to the same commit - which allows for better change tracking and tighter code gating. On Tuesday, October 22, 2013 12:22:07 PM UTC-7, Marcelo Avila wrote: Hi Vicki, You're trying to amend your commit (which was previously pushed to Gerrit) but your new commit (the amend) would have the exact same tree as its parent commit (see --allow-empty item in git help commit). In this case, you do NOT need to amend your commit, you just need to abandon the original one by clicking in the *Abandon Change* button in Gerrit UI. -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/10/22 William Seiti Mizuta william...@gmail.com Yes, that might be the cause. Then, you can discard the last commit with git reset --hard HEAD^ or create an empty commit with git commit --allow-empty William Seiti Mizuta @williammizuta Caelum | Ensino e Inovação www.caelum.com.br On Tue, Oct 22, 2013 at 2:55 PM, Vicki Kozel vicki...@gmail.com wrote: Also, my file on the branch that I am amending looks exactly like the file in master. I checked their SHA1 signatures with git hash-object command - they are identical. Maybe that what is causing the problem? On Tuesday, October 22, 2013 11:53:25 AM UTC-7, Vicki Kozel wrote: Thank you William, I just tried that - same outcome. Vicki On Tuesday, October 22, 2013 11:24:29 AM UTC-7, William Seiti Mizuta wrote: On Tue, Oct 22, 2013 at 2:20 PM, Vicki Kozel vicki...@gmail.comwrote: git commit COMMON/pom.xml --amend You don't need to pass the file in commit command. You just need to use git commit --amend William Seiti Mizuta @williammizuta Caelum | Ensino e Inovação www.caelum.com.br -- 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. 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
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
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
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.
