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 not know about rebase's preserve
merges flag, which would avoid thi
> 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
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 not know about rebase's preserve
merges flag, which would avoid thi
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
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 not know about rebase's preserve
merges flag, which would avoid thi
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
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 not know about rebase's preserve
merges flag, which would avoid thi
> 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--
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 not know about rebase's preserve
merges flag, which would this beha
23 matches
Mail list logo
