Re: [git-users] Re: Question: git merge origin/master

[Konstantin Kivi]

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 >
>
>> 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" > 
>> 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 

> 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_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 

Re: [git-users] restrict history/messages on push?

[Tom Roche]

https://groups.google.com/forum/#!topic/git-users/nzwVr5li3cM
> Tom Roche
> How to restrict the commit history or messages that get pushed to a remote 
> repository?

...

> Gergely Polonkai
...
> git rebase -i[.] Before pushing, rebase on the last public commit, and 
> edit/squash the unnecessary commits.

...

> Peter J Weisberg
...
> Keep in mind that Fred's own private history will [then] also have only the 
> "sanitized" commits.

Thanks for the tips! I had not previously understood why one would want to use 
`git rebase` instead of `git merge`, when the latter seems more 
straightforward. I should have read to the end of the page:

http://git-scm.com/book/en/Git-Branching-Rebasing
>> treat rebasing as a way to clean up and work with commits before you push 
>> them,
>> and [only] rebase commits that have never been available publicly

Fortunately I have not needed this, but I'll recommend it to more 
commit-challenged colleagues.

thanks again, Tom Roche 

-- 
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] restrict history/messages on push?

[PJ Weisberg]

On Sep 26, 2013 12:05 AM, "Gergely Polonkai"  wrote:
>
> Hello,
>
> first of all, Fred should stop using such commit messages :-)
>
> Seriously speaking, I think that's where git rebase -i comes in. Before
pushing, rebase on the last public commit, and edit/squash the unnecessary
commits.

This is exactly what I would recommend for Fred.  Keep in mind that Fred's
own private history will also have only the "sanitized" commits.  That
might be a good thing.

-- 
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

[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 

> 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"  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 
>>>
 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_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 messag

Re: [git-users] Git Pro: PDF versions in English and other languages

[Florian Loch]

Hi Martin,
were you able to create the German pdf file yet? You told automatix to send 
a pm to you, then you would mail him the German version. I would really 
catch at the offer, but actually I do not use Google Groups regulary and 
therefore didn't find a way to send a pm...

Would be great, if you could send me the file!

Cheers
Florian

Am Dienstag, 29. Januar 2013 00:58:10 UTC+1 schrieb Martin Møller 
Skarbiniks Pedersen:
>
> On 29 January 2013 00:54, automatix > 
> wrote: 
> > Not for me. I find bottomposting not so good readable. IMHO the main 
> > information should be placed directly on the top. The replied message 
> just 
> > supplies additional information. 
>
> OK. Then I will not continue to reply to your emails. 
>
> /Martin 
>

-- 
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

[Gergely Polonkai]

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"  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 
>>
>>> 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_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] restrict history/messages on push?

[Gergely Polonkai]

Hello,

first of all, Fred should stop using such commit messages :-)

Seriously speaking, I think that's where git rebase -i comes in. Before
pushing, rebase on the last public commit, and edit/squash the unnecessary
commits.

Cheers,
Gergely
On 26 Sep 2013 04:19, "Tom Roche"  wrote:

>
> [caution: contains ASCII table, best viewed in monospace]
>
> How to restrict the commit history or messages that get pushed to a remote
> repository? What I mean:
>
> Suppose a group wants to have a remote public repository (e.g., on
> github), but its developers do not want their commit behavior and messages
> to be fully publicly visible. (Paranoid, I know, but these are real
> people.) Is there a way such a group could show only (for want of a better
> term) "push events" on the public remote? For example:
>
> Suppose developer Fred makes the following commits to his private repo:
>
> --commit-
> ID   date/time  message
> ---  -  -
> 23rw4kf  23 Sep 2013 09:39  Foo?
> 98bjttr  24 Sep 2013 12:34  Rollback! Bar.
> 07657ab  25 Sep 2013 10:11  Arrggg! Baz.
> 1495fcc  25 Sep 2013 23:45  Self-serving explanation.
>
> Fred wants to push 1495fcc to the public repo, but doesn't want manager
> Ethel (or anyone else) to see commits=[23rw4kf, 98bjttr, 07657ab], much
> less those commit messages. Fred wants one of two options:
>
> 1. That only commit ID=1495fcc and its message to be visible on the public
> remote post-push.
>
> 2. For the code from commit ID=1495fcc to show on the public remote as a
> separate event, with a separate message.
>
> As a git beginner, the only option that seems feasible to me is a
> variation on option 2. Fred would maintain 2 private repos: one for "normal
> development," and one reserved for use with the public remote. When he
> wanted to push to public, Fred would
>
> 2.1. copy code from his "real" dev repo to the second,
> public-remote-linked repo
> 2.2. make a separate, aggregate commit (with a separate message) to that
> second repo
> 2.3. push from the second repo to the public remote
>
> This seems painful, and maybe that's what Fred deserves. But I'm
> wondering, is there a way to accomplish Fred's objective more easily?
>
> TIA, Tom Roche 
>
> --
> 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.