Jesse Phillips Wrote:
> On Sat, 05 Nov 2011 15:15:37 -0700, Jonathan M Davis wrote:
>
> > So, I should probably add the question more explicitly, what exactly
> > does using --rebase gain other than not having the extra commit message?
> > Why is it better?
> >
> > - Jonathan M Davis
>
> My qui
On 11/5/2011 5:38 PM, Alex Rønne Petersen wrote:
Hi folks!
This is a friendly request for D core devs to use 'git pull --rebase'
instead of just plain 'git pull' when pulling remote changes into local
repositories. The reason for this is that it takes any outstanding
commits in your local tree,
On Sun, 06 Nov 2011 22:28:58 +0100, Jonathan M Davis
wrote:
On Sunday, November 06, 2011 20:40:12 Alex Rønne Petersen wrote:
I should clarify that this entire post was directed at *normal git pull
operations*. Not merging of pull requests. Those will (and should!)
result in a merge commit to
On Sunday, November 06, 2011 20:40:12 Alex Rønne Petersen wrote:
> I should clarify that this entire post was directed at *normal git pull
> operations*. Not merging of pull requests. Those will (and should!)
> result in a merge commit to make it easier to see when in history a pull
> request was m
On 06-11-2011 19:41, Jesse Phillips wrote:
On Sat, 05 Nov 2011 19:16:01 -0700, Jonathan M Davis wrote:
Rebasing, I understand. Rebasing happens often enough in pull requests.
It affects branches that way, not master, so I don't think that it's
really all that big a deal - particularly when such
On Sat, 05 Nov 2011 19:16:01 -0700, Jonathan M Davis wrote:
> Rebasing, I understand. Rebasing happens often enough in pull requests.
> It affects branches that way, not master, so I don't think that it's
> really all that big a deal - particularly when such branchs frequently
> created just for t
On 06-11-2011 16:01, Michel Fortin wrote:
On 2011-11-06 12:16:41 +, Alex Rønne Petersen
said:
Rewriting history in forks is perfectly fine. In fact, many people
generally consider it polite for contributors to clean up their
history using rebase before sending changes upstream.
Rewriting
On 2011-11-06 12:16:41 +, Alex Rønne Petersen said:
Rewriting history in forks is perfectly fine. In fact, many people
generally consider it polite for contributors to clean up their history
using rebase before sending changes upstream.
Rewriting history in private forks is perfectly fin
On 06-11-2011 05:40, Steve Teale wrote:
On Sat, 05 Nov 2011 22:38:03 +0100, Alex Rønne Petersen wrote:
Hi folks!
This is a friendly request for D core devs to use 'git pull --rebase'
instead of just plain 'git pull' when pulling remote changes into local
repositories. The reason for this is th
On 06-11-2011 02:37, Jesse Phillips wrote:
On Sat, 05 Nov 2011 15:15:37 -0700, Jonathan M Davis wrote:
So, I should probably add the question more explicitly, what exactly
does using --rebase gain other than not having the extra commit message?
Why is it better?
- Jonathan M Davis
My quick s
"Steve Teale" wrote in message
news:j9533f$7oc$2...@digitalmars.com...
> On Sat, 05 Nov 2011 22:38:03 +0100, Alex Rønne Petersen wrote:
>
>> Hi folks!
>>
>> This is a friendly request for D core devs to use 'git pull --rebase'
>> instead of just plain 'git pull' when pulling remote changes into l
On Sat, 05 Nov 2011 22:38:03 +0100, Alex Rønne Petersen wrote:
> Hi folks!
>
> This is a friendly request for D core devs to use 'git pull --rebase'
> instead of just plain 'git pull' when pulling remote changes into local
> repositories. The reason for this is that it takes any outstanding
> com
On Sun, 06 Nov 2011 04:16:01 +0200, Jonathan M Davis
wrote:
The commits lose their original date and are no longer interspersed,
which could be good or bad, depending on what you're looking for.
It's a bit more involved than that (in a good way). Each commit has an
author date and a comm
On Sunday, November 06, 2011 01:37:52 Jesse Phillips wrote:
> On Sat, 05 Nov 2011 15:15:37 -0700, Jonathan M Davis wrote:
> > So, I should probably add the question more explicitly, what exactly
> > does using --rebase gain other than not having the extra commit message?
> > Why is it better?
> >
On Sat, 05 Nov 2011 15:15:37 -0700, Jonathan M Davis wrote:
> So, I should probably add the question more explicitly, what exactly
> does using --rebase gain other than not having the extra commit message?
> Why is it better?
>
> - Jonathan M Davis
My quick search:
http://book.git-scm.com/4_reb
On Sun, 06 Nov 2011 00:15:37 +0200, Jonathan M Davis
wrote:
So, I should probably add the question more explicitly, what exactly does
using --rebase gain other than not having the extra commit message? Why
is it better?
It also makes the history easier to follow (less branching in the DAG
On Saturday, November 05, 2011 15:10:52 Jonathan M Davis wrote:
> On Saturday, November 05, 2011 22:38:03 Alex Rønne Petersen wrote:
> > Hi folks!
> >
> > This is a friendly request for D core devs to use 'git pull --rebase'
> > instead of just plain 'git pull' when pulling remote changes into loc
On Saturday, November 05, 2011 22:38:03 Alex Rønne Petersen wrote:
> Hi folks!
>
> This is a friendly request for D core devs to use 'git pull --rebase'
> instead of just plain 'git pull' when pulling remote changes into local
> repositories. The reason for this is that it takes any outstanding
>
Hi folks!
This is a friendly request for D core devs to use 'git pull --rebase'
instead of just plain 'git pull' when pulling remote changes into local
repositories. The reason for this is that it takes any outstanding
commits in your local tree, unrolls them, pulls in the remote changes,
and
19 matches
Mail list logo
