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 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/**grou**ps/opt_out<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. >>>>> For more options, visit >>>>> https://groups.google.com/**groups/opt_out<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. >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<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 a topic in the > Google Groups "Git for human beings" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/git-users/xVlvW4GPtIY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- Sincerely yours, Konstantin Kivi C уважением, Константин Киви -- 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.
