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: send the line
.
Signed-off-by: Stephen Haberman step...@exigencecorp.com
---
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
@@ -40,7
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
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 to
for the pull.rebase config setting.
Signed-off-by: Stephen Haberman step...@exigencecorp.com
---
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 serious consideration
for the pull.rebase config setting.
Signed-off-by: Stephen Haberman step...@exigencecorp.com
---
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-control.git/231909
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 rebase
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
somearg, we accept somearg only if it's true, false, or
for the pull.rebase config setting.
Signed-off-by: Stephen Haberman step...@exigencecorp.com
---
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 using case statements
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 like:
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,
for the pull.rebase config setting.
Signed-off-by: Stephen Haberman step...@exigencecorp.com
---
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:
* Change the usage output
12 matches
Mail list logo
