This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Commit procedure question: One commit, or multiple commits.


On Wed, Apr 18, 2012 at 3:32 PM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On Wed, Apr 18, 2012 at 4:23 PM, Ryan S. Arnold <ryan.arnold@gmail.com> wrote:
>> On Wed, Apr 18, 2012 at 2:59 PM, Carlos O'Donell
>> <carlos@systemhalted.org> wrote:
>>> On Wed, Apr 18, 2012 at 3:04 PM, Ryan S. Arnold <ryan.arnold@gmail.com> wrote:
>>>> This should have said "I'll use option 1."
>>>>
>>>> I just realized a problem with my suggestion about pushing more than a
>>>> single commit. ÂOnce the patches are committed locally it precludes
>>>> the ability to git pull --rebase to bring the patch set up to the
>>>> current head to avoid the merge.
>>>
>>> I don't understand that use case. Could you elaborate a bit more?
>>
>> As an example, I was working with Will's memmove patch set and I
>> committed each patch individually onto a local branch. ÂSo my local
>> branch was three commits ahead of master. ÂI then updated my remote
>> branches and noticed that Dave had checked in a patch in the meantime.
>>
>> I wasn't able to rebase my three commits on top of Dave's change... or
>> at least I don't know how. ÂThe directions to use git stash on the
>> committers page didn't do as I'd hoped.
>
> Stashing is only useful for uncommitted changes.
>
> I would have expected that rebasing would have just worked in that case.
>
> What broke?

I think it was user error.  I've verified that rebasing does indeed
work on commited changes.

Ryan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]