On Fri, Jun 28, 2013 at 5:41 PM, Junio C Hamano wrote:
> John Keeping writes:
>> I don't think "git pull remote branch" falls into the same category as
>> plain "git pull" so I'm not convinced that defaulting to merge there is
>> unreasonable. The original message about this [1] did talk about
Andreas Schwab writes:
> John Keeping writes:
>
>> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
>>> diff --git a/git-pull.sh b/git-pull.sh
>>> index 638aabb..4a6a863 100755
>>> --- a/git-pull.sh
>>> +++ b/git-pull.sh
>>> @@ -264,6 +274,30 @@ case "$merge_head" in
>>>
John Keeping writes:
> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
>> diff --git a/git-pull.sh b/git-pull.sh
>> index 638aabb..4a6a863 100755
>> --- a/git-pull.sh
>> +++ b/git-pull.sh
>> @@ -264,6 +274,30 @@ case "$merge_head" in
>> die "$(gettext "Cannot rebase o
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
> diff --git a/git-pull.sh b/git-pull.sh
> index 638aabb..4a6a863 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -264,6 +274,30 @@ case "$merge_head" in
> die "$(gettext "Cannot rebase onto multiple branches")"
>
On Fri, Jun 28, 2013 at 03:41:34PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> >> Here, "git pull . branch1" is merely saying "I want to integrate
> >> the work on my current branch with that of branch1" without saying
> >> how that integration wants to happen.
> >
> > The change that
John Keeping writes:
>> Here, "git pull . branch1" is merely saying "I want to integrate
>> the work on my current branch with that of branch1" without saying
>> how that integration wants to happen.
>
> The change that I think is important is that the "bring my branch
> up-to-date" operation sho
On Fri, Jun 28, 2013 at 10:22:57AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> >> test_expect_success \
> >> 'merge-setup part 3' \
> >> -'git pull . branch1'
> >> +'git pull --merge . branch1'
> >
> > I think the "--merge" should be implied here because the suer has
> >
John Keeping writes:
>> test_expect_success \
>> 'merge-setup part 3' \
>> -'git pull . branch1'
>> +'git pull --merge . branch1'
>
> I think the "--merge" should be implied here because the suer has
> specified an explicit remote and branch.
The whole point of the topic is "It use
On Fri, Jun 28, 2013 at 01:52:38PM +0200, Matthieu Moy wrote:
> "W. Trevor King" writes:
> > I want the warning that they had not made the required config choice
> > between rebase/merge needed to handle a non-ff case, not the default
> > merge (or rebase) behavior. The warning gives them a chanc
"W. Trevor King" writes:
> On Fri, Jun 28, 2013 at 08:34:53AM +0200, Matthieu Moy wrote:
>> "W. Trevor King" writes:
>>
>> > Or they may not even realize that they've just merged an unrelated
>> > branch at all, dragging in a thousand unrelated commits which they
>> > accidentally push to a cent
On Fri, Jun 28, 2013 at 08:34:53AM +0200, Matthieu Moy wrote:
> "W. Trevor King" writes:
> > On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
> >> Because letting a trivial merge automatically handled by Git is so
> >> easy with "git pull", a person who is new to Git may not realize
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
> Because letting a trivial merge automatically handled by Git is so
> easy with "git pull", a person who is new to Git may not realize
> that the project s/he is interacting with may prefer "rebase"
> workflow. Add a safety valve to
"W. Trevor King" writes:
> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
>> Because letting a trivial merge automatically handled by Git is so
>> easy with "git pull", a person who is new to Git may not realize
>> that the project s/he is interacting with may prefer "rebase"
>>
On Fri, Jun 28, 2013 at 12:16:53AM +0200, Matthieu Moy wrote:
> IMHO, that would be terrible for beginners.
>
> My experience with many beginners/students is: they run "git pull" to
> get changes from their co-workers, don't read the messages.
I admit that I'd be happy with a config option that j
On Thu, Jun 27, 2013 at 02:20:42PM -0700, Junio C Hamano wrote:
> Your "accident user" could have just been on a 'maint' branch,
> [snip]
By the time I talk people into using a 'maint' branch, we'll probably
have already passed the 'accidental pull and push' stage ;). This
will certainly reduce t
Junio C Hamano writes:
> Because letting a trivial merge automatically handled by Git is so
> easy with "git pull", a person who is new to Git may not realize
> that the project s/he is interacting with may prefer "rebase"
> workflow. Add a safety valve to fail "git pull" that is not a
> fast-fo
"W. Trevor King" writes:
> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
>> Because letting a trivial merge automatically handled by Git is so
>> easy with "git pull", a person who is new to Git may not realize
>> that the project s/he is interacting with may prefer "rebase"
>>
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
> Because letting a trivial merge automatically handled by Git is so
> easy with "git pull", a person who is new to Git may not realize
> that the project s/he is interacting with may prefer "rebase"
> workflow.
Or they may not even r
"W. Trevor King" writes:
> Assorted minor edits:
>
> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
>> Because letting a trivial merge automatically handled by Git is so
>
> Maybe:
>
> Because letting Git handle a trivial merge automatically is so…
>
>> that the project s/he is
Fredrik Gustafsson writes:
> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
>
>> +# See if we are configured to rebase by default.
>> +# The value $rebase is, throughout the main part of the code:
>> +#(empty) - the user did not have any preference
>> +#true- the use
Assorted minor edits:
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
> Because letting a trivial merge automatically handled by Git is so
Maybe:
Because letting Git handle a trivial merge automatically is so…
> that the project s/he is interacting with may prefer "rebase"
> w
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
> +# See if we are configured to rebase by default.
> +# The value $rebase is, throughout the main part of the code:
> +#(empty) - the user did not have any preference
> +#true- the user told us to integrate by rebasing
>
Because letting a trivial merge automatically handled by Git is so
easy with "git pull", a person who is new to Git may not realize
that the project s/he is interacting with may prefer "rebase"
workflow. Add a safety valve to fail "git pull" that is not a
fast-forward until/unless the user express
23 matches
Mail list logo
