> How should this interact with 949e0d8e (pull: require choice between
> rebase/merge on non-fast-forward pull, 2013-06-27)
I believe there should not be any conflicts in functionality, other
than just tweaking the docs to mention --rebase=preserve as an option.
Personally, I would assert that,
Hi Junio,
> "-r", even though it happens to be accepted, is not a good idea
> here, as there are other --r* commands that are not --rebase.
>
> [--[no-]rebase|--rebase=preserve]
Cool, I will change that.
> You would want "bool or string" helper function to parse it
> correctly, something
Junio C Hamano writes:
> Andres Perera writes:
>
>> i just realized that there are ambiguities:
>>
>> pull -r (true|false|preserve) foo
>>
>> there are 2 ways to interpret this:
>>
>> pull --rebase=(true|false|preserve) foo # pull from remote named foo
>>
>> pull --rebase (true|false|preserve) f
Stephen Haberman writes:
> I assume I'm doing the right thing by just posting another version of
> this patch to the git list; let me know if I'm missing something.
Thanks. Writing the "story so far..." summary like you did after
the three-dash line was very helpful.
> diff --git a/git-pull.sh
Andres Perera writes:
> i just realized that there are ambiguities:
>
> pull -r (true|false|preserve) foo
>
> there are 2 ways to interpret this:
>
> pull --rebase=(true|false|preserve) foo # pull from remote named foo
>
> pull --rebase (true|false|preserve) foo # pull from remote named
> (true|f
Hi Andres,
> i just realized that there are ambiguities:
> pull --rebase (true|false|preserve) foo # pull from remote named
> (true|false|preserve), branch foo
Yeah.
Right now, I did the latter. Around line 125, when parsing "--rebase
", we accept only if it's true, false, or preserve,
and shi
On Sun, Aug 11, 2013 at 6:39 PM, Stephen Haberman
wrote:
>
>> 1. i'm not sure why you are testing $3 == preserve. it looks like a
>> typo
>
> Yes, good catch. I've added a test that fails, and will fix that.
>
>> 2. clearer than a string of yoda conditions:
>>
>> case $2 in
>> true|false|preserve)
> 1. i'm not sure why you are testing $3 == preserve. it looks like a
> typo
Yes, good catch. I've added a test that fails, and will fix that.
> 2. clearer than a string of yoda conditions:
>
> case $2 in
> true|false|preserve)
Makes sense, will change.
> 1. in the error message you say that
hello, comments inline
On Sun, Aug 11, 2013 at 4:56 PM, Stephen Haberman
wrote:
> If a user is working on master, and has merged in their feature branch, but
> now
> has to "git pull" because master moved, with pull.rebase their feature branch
> will be flattened into master.
>
> This is because
On Sun, Aug 11, 2013 at 2:16 AM, Eric Sunshine wrote:
> Also, it's not clear from the documentation how one would override
> pull.rebase=preserve in order to do a normal non-preserving rebase.
> From reading the code, one can see that --preserve=true (or
s/--preserve=true/--rebase=true/
> --no-r
On Sat, Aug 10, 2013 at 12:58 AM, Stephen Haberman
wrote:
> If a user is working on master, and has merged in their feature branch, but
> now
> has to "git pull" because master moved, with pull.rebase their feature branch
> will be flattened into master.
>
> This is because "git pull" currently d
> We have a patch in Git for Windows allowing rebase = interactive
> which I did not have time to send upstream.
Cool, so, would rebase=preserve and rebase=interactive be completely
orthogonal?
E.g. do we have to worry about the user wanting to do both, like with
something ugly like rebase=prese
Hi,
On Thu, 8 Aug 2013, Junio C Hamano wrote:
> Stephen Haberman writes:
>
> > Hi Johannes,
> >
> >> This should probably be added to config.txt and
> >> Documentation/git-pull.txt, too, right?
> >
> > Yep, I meant to note that I'd do that after getting an initial
> > confirmation that the pull
Stephen Haberman writes:
> Hi Johannes,
>
>> This should probably be added to config.txt and
>> Documentation/git-pull.txt, too, right?
>
> Yep, I meant to note that I'd do that after getting an initial
> confirmation that the pull.preserve-merges was the preferred approach.
If you were to go th
From: "Stephen Haberman"
Hi Johannes,
This should probably be added to config.txt and
Documentation/git-pull.txt, too, right?
Yep, I meant to note that I'd do that after getting an initial
confirmation that the pull.preserve-merges was the preferred approach.
(I was being lazy and didn't wa
Hi Johannes,
> This should probably be added to config.txt and
> Documentation/git-pull.txt, too, right?
Yep, I meant to note that I'd do that after getting an initial
confirmation that the pull.preserve-merges was the preferred approach.
(I was being lazy and didn't want to write up docs only t
Hi Stephen,
On Thu, 8 Aug 2013, Stephen Haberman wrote:
> If a user is working on master, and has merged in their feature branch,
> but now has to "git pull" because master moved, with pull.rebase their
> feature branch will be flattened into master.
>
> This is because "git pull" currently does
> This is because "git pull" currently does not know about rebase's
> preserve merges flag, which would this behavior, and instead replay
> on the merge commit of the feature branch onto the new master, and
> not the entire feature branch itself.
Ack, sorry, I was doing this too late last night--
18 matches
Mail list logo
