Nico Williams writes:
> On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov wrote:
>> Nico Williams writes:
>>> Local merge commits mean that you either didn't rebase to keep all
>>> your local commits on top of the upstream, or that you have multiple
>>> upstreams (the example exception I gave).
>
On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov wrote:
> Nico Williams writes:
>> Local merge commits mean that you either didn't rebase to keep all
>> your local commits on top of the upstream, or that you have multiple
>> upstreams (the example exception I gave).
>
> I rather have multiple (rel
Nico Williams writes:
> On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov wrote:
>> Nico Williams writes:
>>> That exception aside, keeping all local commits "on top" by always
>>> rebasing them onto the upstream is extremely useful: a) in simplifying
>>> conflict resolution, b) making it easy to
On Tue, Jul 29, 2014 at 4:38 PM, Philip Oakley wrote:
> From: "Nico Williams"
>> That workflow works just fine with git.
>
> I'm not saying that it isn't a good technique and can work well. Rather I'm
> saying we should be tolerant of the rules and techniques of others who do
> [...]
Sure. I wa
From: "Nico Williams"
On Tue, Jul 29, 2014 at 2:29 PM, Philip Oakley
wrote:
From: "Nico Williams"
Local merge commits mean that you either didn't rebase to keep all
your local commits on top of the upstream, or that you have multiple
upstreams (the example exception I gave).
Conversely, if
On Tue, Jul 29, 2014 at 2:29 PM, Philip Oakley wrote:
> From: "Nico Williams"
>> Local merge commits mean that you either didn't rebase to keep all
>> your local commits on top of the upstream, or that you have multiple
>> upstreams (the example exception I gave).
>>
>> Conversely, if you always
From: "Nico Williams"
On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov wrote:
Nico Williams writes:
That exception aside, keeping all local commits "on top" by always
rebasing them onto the upstream is extremely useful: a) in
simplifying
conflict resolution, b) making it easy to identify
as
On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov wrote:
> Nico Williams writes:
>> That exception aside, keeping all local commits "on top" by always
>> rebasing them onto the upstream is extremely useful: a) in simplifying
>> conflict resolution, b) making it easy to identify as-yet-unintegrated
Nico Williams writes:
> On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder wrote:
>> Sergei Organov wrote:
>>
>>> Is there any scenario at all where pull --rebase=true wins over
>>> preserve?
>>
>> Basically always in my book. ;-)
>>
>> When people turn on 'pull --rebase', they are asking for a cl
On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder wrote:
> Sergei Organov wrote:
>
>> Is there any scenario at all where pull --rebase=true wins over
>> preserve?
>
> Basically always in my book. ;-)
>
> When people turn on 'pull --rebase', they are asking for a clean,
> simplified history where th
Jonathan Nieder writes:
> Sergei Organov wrote:
>
>> Is there any scenario at all where pull --rebase=true wins over
>> preserve?
>
> Basically always in my book. ;-)
>
> When people turn on 'pull --rebase', they are asking for a clean,
> simplified history where their changes are small discrete
Sergei Organov wrote:
> Is there any scenario at all where pull --rebase=true wins over
> preserve?
Basically always in my book. ;-)
When people turn on 'pull --rebase', they are asking for a clean,
simplified history where their changes are small discrete patches in a
clump on top of upstream.
Jonathan Nieder writes:
> David Besen wrote:
>> Jonathan Nieder wrote:
>
>>> This is how pull --rebase works. It turns your single-parent commits
>>> into a sequence of patches on top of upstream and completely ignores
>>> your merge commits.
>>>
>>> There is a --rebase=preserve option that make
David Besen wrote:
> Jonathan Nieder wrote:
>> This is how pull --rebase works. It turns your single-parent commits
>> into a sequence of patches on top of upstream and completely ignores
>> your merge commits.
>>
>> There is a --rebase=preserve option that makes a halfhearted attempt
>> to prese
Ah thanks, I'll RTFM better in the future.
- Dave
-Original Message-
From: Jonathan Nieder [mailto:jrnie...@gmail.com]
Sent: Friday, July 25, 2014 4:19 PM
To: Besen, David
Cc: git@vger.kernel.org
Subject: Re: Amending merge commits?
Besen, David wrote:
> I think one of my c
Besen, David wrote:
> I think one of my coworkers has stumbled on a git bug -- if you
> amend a merge commit, and then pull, your amends are lost.
This is how pull --rebase works. It turns your single-parent commits
into a sequence of patches on top of upstream and completely ignores
your merge
Besen, David hp.com> writes:
>
>
> Hi folks,
>
> I think one of my coworkers has stumbled on a git bug -- if you amend a
merge commit, and then pull, your amends
> are lost.
>
> Is this expected behavior?
>
> I've reproduced the problem in a script (attached). I ran it against a
couple of
Hi folks,
I think one of my coworkers has stumbled on a git bug -- if you amend a merge
commit, and then pull, your amends are lost.
Is this expected behavior?
I've reproduced the problem in a script (attached). I ran it against a couple
of versions of git (1.7.1, 1.7.9, 1.8.4, 2.0.0) and in
18 matches
Mail list logo
