Permalink
Browse files

Annotated the code with some TODO-notes.

  • Loading branch information...
1 parent 5fa4758 commit d29e315f87185cf96287078a59bc9552ed04781c @nvie committed Feb 8, 2010
Showing with 5 additions and 0 deletions.
  1. +2 −0 git-flow-hotfix
  2. +3 −0 git-flow-release
View
@@ -201,6 +201,8 @@ cmd_finish() {
git checkout $DEVELOP_BRANCH || \
die "Could not check out $DEVELOP_BRANCH."
+ # TODO: Actually, accounting for 'git describe' pays, so we should
+ # ideally git merge --no-ff $tagname here, instead!
git merge --no-ff $BRANCH || \
die "There were merge conflicts."
# TODO: What do we do now?
View
@@ -206,6 +206,9 @@ cmd_finish() {
if ! gitflow_is_branch_merged_into $BRANCH $DEVELOP_BRANCH; then
git checkout $DEVELOP_BRANCH || \
die "Could not check out $DEVELOP_BRANCH."
+
+ # TODO: Actually, accounting for 'git describe' pays, so we should
+ # ideally git merge --no-ff $tagname here, instead!
@snaewe

snaewe Apr 9, 2010

Is there any reason why you don't do 'git merge -no-ff $tagname' here ?

@nvie

nvie Apr 9, 2010

Owner

Mostly to keep it in line with the original model blog post for now. Maybe in the future I will make a version 2 of the model that uses this strategy, and some other improvements. The only thing keeping me from doing it right now is (lack of) time, really.

@bloveridge

bloveridge Dec 7, 2010

Contributor

So, aside from matching it up with the model in the original blog post, did you discover any real tricky problems, or other reasons not to do this?

I'm strongly considering making this change in a fork of my own so we can use it at my org, but thought I'd ask if there were some stumbling blocks you already came across that would sway me from doing so.

git merge --no-ff $BRANCH || \
die "There were merge conflicts."
# TODO: What do we do now?

0 comments on commit d29e315

Please sign in to comment.