#x27; to the allowed values for the pull.rebase config setting.
Signed-off-by: Stephen Haberman
---
Hi,
This is v5 of my --rebase=preserve patch, the last discussion of which
was here:
http://thread.gmane.org/gmane.comp.version-control.git/232156
This update has two small changes:
* Chang
> 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
#x27; to the allowed values for the pull.rebase config setting.
Signed-off-by: Stephen Haberman
---
Hi,
This is v4 of my pull.rebase=preserve patch, previously discussed here:
http://thread.gmane.org/gmane.comp.version-control.git/232140
This version addresses feedback from Andreas about us
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
> 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
#x27; to the allowed values for the pull.rebase config setting.
Signed-off-by: Stephen Haberman
---
Hi,
This is v3 of my previous pull.rebase=preserve patch, previously discussed here:
http://thread.gmane.org/gmane.comp.version-control.git/232061
http://thread.gmane.org/gmane.comp.version-con
#x27; to the allowed values for the pull.rebase config setting.
Signed-off-by: Stephen Haberman
---
Hey,
This is version 2 of my previous patch--I changed over to the --rebase=preserve
syntax as suggested by Johannes and Junio.
I also updated the documentation.
I believe it is ready for seriou
> 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 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
> 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--
able this behavior as
the default.
Signed-off-by: Stephen Haberman
---
git-pull.sh | 11 +--
t/t5520-pull.sh | 15 +++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index f0df41c..61d1efb 100755
--- a/git-pull.sh
+++ b/git-pull.sh
config setting before doing that.
Thanks!
- Stephen
Stephen Haberman (1):
pull: Allow pull to preserve merges when rebasing.
git-pull.sh | 11 +--
t/t5520-pull.sh | 15 +++
2 files changed, 24 insertions(+), 2 deletions(-)
--
1.8.1.2
--
To unsubscribe from this list
13 matches
Mail list logo
