Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

2014-08-19 Thread Sergey Organov
Junio C Hamano gits...@pobox.com writes:

 Sergey Organov sorga...@gmail.com writes:

 A sentence --force has no effect under --preserve-merges mode does
 not tell the readers very much, either and leaves them wondering if
 it means --preserve-merges mode always rebases every time it is
 asked, never noticing 'ah, the history is already in a good shape
 and there is no need to do anything further' or --preserve-merges
 mode ignores --force and refuses to recreate the history if the
 history is in the shape the mode deems is already desirable.

 In fact there is no way to force rebase when --preserve-merges is given.
 Neither --force nor --no-ff has any effect.

 Maybe some clarification could be given in --preserve-merges
 description, provided it's not clear that has no effect for --force
 means that one can't force the rebase in this case.

 I am not sure if that is an intended behaviour or simply a bug (I
 rarely use preserve-merges myself, so I offhand do not know for
 certain).

It seems that there is some problem there anyway. Probably a slight
misfeature rather than a bug, as --preserve-merges always pretends it
does something, even when it does not:

$ git log --oneline --graph --decorate
*   6f25bd5 (HEAD, topic) M
|\  
| * c5a4a43 C
* | 3c6ab7a (master) N
* | 99ff328 B
|/  
* 130ae2d A
$ git rebase --preserve-merges master
Successfully rebased and updated refs/heads/topic.
$ git log --oneline --graph --decorate
*   6f25bd5 (HEAD, topic) M
|\  
| * c5a4a43 C
* | 3c6ab7a (master) N
* | 99ff328 B
|/  
* 130ae2d A
$

git reflog topic doesn't show any changes either.

-- 
Sergey.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

2014-08-19 Thread Sergey Organov
Junio C Hamano gits...@pobox.com writes:
 Junio C Hamano gits...@pobox.com writes:
[...]
 How about doing it this way, perhaps?

Could you please apply this your suggestion, as we seem not to agree
on anything better?

 -- 8 --
 From: Sergey Organov sorga...@gmail.com
 Date: Tue, 12 Aug 2014 00:22:48 +0400
 Subject: [PATCH] Documentation/git-rebase.txt: -f forces a rebase that would 
 otherwise be a no-op

 Current branch is a descendant of the commit you are rebasing onto
 does not necessarily mean rebase requires --force.  For a plain
 vanilla history flattening rebase, the rebase can be done without
 forcing if there is a merge between the tip of the branch being
 rebased and the commit you are rebasing onto, even if the tip is
 descendant of the other.

 [jc: reworded both the text and the log description]

 Signed-off-by: Sergey Organov sorga...@gmail.com
 Signed-off-by: Junio C Hamano gits...@pobox.com
 ---
  Documentation/git-rebase.txt | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

 diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
 index 2a93c64..f14100a 100644
 --- a/Documentation/git-rebase.txt
 +++ b/Documentation/git-rebase.txt
 @@ -316,11 +316,8 @@ which makes little sense.
  
  -f::
  --force-rebase::
 - Force the rebase even if the current branch is a descendant
 - of the commit you are rebasing onto.  Normally non-interactive rebase 
 will
 - exit with the message Current branch is up to date in such a
 - situation.
 - Incompatible with the --interactive option.
 + Force a rebase even if the current branch is up-to-date and
 + the command without `--force` would return without doing anything.
  +
  You may find this (or --no-ff with an interactive rebase) helpful after
  reverting a topic branch merge, as this option recreates the topic branch 
 with

--  
Sergey.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

2014-08-18 Thread Sergey Organov
Junio C Hamano gits...@pobox.com writes:

 Sergey Organov sorga...@gmail.com writes:

 A sentence --force has no effect under --preserve-merges mode does
 not tell the readers very much, either and leaves them wondering if
 it means --preserve-merges mode always rebases every time it is
 asked, never noticing 'ah, the history is already in a good shape
 and there is no need to do anything further' or --preserve-merges
 mode ignores --force and refuses to recreate the history if the
 history is in the shape the mode deems is already desirable.

 In fact there is no way to force rebase when --preserve-merges is given.
 Neither --force nor --no-ff has any effect.

 Maybe some clarification could be given in --preserve-merges
 description, provided it's not clear that has no effect for --force
 means that one can't force the rebase in this case.

 I am not sure if that is an intended behaviour or simply a bug

I think nobody actually ever needed to make it work, even though
fundamentally it could have the same usage as in the case of flattening
rebase. Once again, it seems that most uses of rebase handle already
flat history and thus are served by vanilla invocation.

 (I rarely use preserve-merges myself, so I offhand do not know for
 certain).

I wonder, don't you yourself use preserve-merges because you don't care
and just use the default, or because you actually use vanilla
history-flattening feature?

-- 
Sergey.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

2014-08-18 Thread Sergey Organov
Junio C Hamano gits...@pobox.com writes:

 Sergey Organov sorga...@gmail.com writes:

 ... I.e., git must not rebase anything
 when Current branch is a descendant of the commit you are rebasing
 onto, unless -f is given. Simple, reasonable, straightforward.

 It may be simple and straightforward, but breaks the use case the
 plain vanilla rebase is used for, doesn't it?

I hope it does not. I don't think plain vanilla rebase's flattening
feature is usually used, as those who care about flat history mostly
don't merge. Either not at all, or do merges temporarily and undo them
later. At least that's the impression I've got from recent conversations
about the issue.

Moreover, I'm afraid rare person would correctly predict the result of
history flattening he will get from git rebase of even remotely complex
graph.

That said, I'm still to hear from somebody who would actually suffer. I
mean I see some use-case(s), but they: 1) are unlikely to be used in
practice. 2) are better handled by other means. 3) abuse bug/feature
that contradicts documentation. 4) won't be broken that hard anyway.

 You seem to ignore, or perhaps you don't realize the existence of, the
 need of those who want to flatten the history on top of the tip from
 the other side;

No, I do realize and I don't ignore the possibility. Please recall that
I didn't suggest to get rid of any functionality that is already there.

I didn't want to get into lengthy discussion about it, but here we are.

In fact there are 2 issues here (please notice that I don't cut any
existing functionality):

1. Better design of interface to git rebase features.

2. How far we are currently from those better, is it worth the trouble
   to move in the direction of better at all, and how far and how fast
   we are going to move, considering backward compatibility issues.

If we don't agree on (1), i.e., where is point B, there is no reason to
discuss (2), i.e., the way from point A to point B. I'm trying to
discuss (1), and you are mostly objecting by pointing me to the fact
that changes could break some workflow, i.e., by discussing (2).

What about those better design? Here is my bet:

1. git rebase with no options takes a set of commits and rebases them
   on top of another commit, preserving precious history as much as
   possible.

   Reason: most common operation: rebase my work on top of different
   commit. Nothing more, nothing less. That's what --preserve mode does
   right now. I.e., the result should be as close as possible to the
   case where I had started to do all the work on top of the new base
   commit from the beginning.

2. git rebase onto the same base should be no-op, unless --force
   option is given.

   Reason: if command changes base, it's natural to do nothing when base
   is not changed. Alternatively, rebase would have to be performed
   always, and commit dates etc. would be changed as a result. This
   would be just annoying most of times.

3. git rebase may have an option to flatten the history instead of
   preserving its shape (--flatten or some such). This mode may imply
   some relaxing of (2) by always performing the rebase when there are
   merge commits among those to be rebased.

   Reason: somebody somewhere could probably find a real use for such a
   feature. BTW, there could be different modes of flattening, so this
   option may take corresponding values (e.g., squash every merged set
   of commits to a single commit). Please also notice that function of
   (3) could be achieved by other means, so it's not a requirement,
   rather a convenience (that's why I said may have an option).

We can discuss this if somebody interested. If not, let's just fix
documentation to match current historical design, please.

 your statements in the pull --rebase[=preserve] thread may be
 coming from the same place, I suspect.

Yes, it's the same place. It's all started from a big trouble I ran into
by simply following current git documentation for git pull and git
rebase and from assumption that defaults are usually safe (and sane,
yes, in my understanding of sane ;-) ).

And yes, they share the same reasoning. That is, by default a command
must perform its primary job, and only it. Everything else should be an
option. For git pull it'd mean to fetch the changes from upstream, and
then either merge or rebase to integrate with them. For git pull, my
plan would be to introduce new pull.rebase=flatten value and deprecate
pull.rebase=true. Bare pull --rebase should be deprecated as well
in favor of explicit pull --rebase=flatten, then later pull
--rebase could be given saner and safer meaning of pull
--rebase=preserve, or rather removed.

 For the flatten the history on top of that commit use case, two
 conditions must be satisfied before the command can say the history
 is already in the desired shape and nothing needs to be done to
 allow it to make a short-cut.  It is not sufficient for the current
 tip to be merely descendant of the tip 

Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

2014-08-18 Thread Junio C Hamano
Sergey Organov sorga...@gmail.com writes:

 (I rarely use preserve-merges myself, so I offhand do not know for
 certain).

 I wonder, don't you yourself use preserve-merges because you don't care
 and just use the default, or because you actually use vanilla
 history-flattening feature?

The latter.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

2014-08-15 Thread Sergey Organov
Junio C Hamano gits...@pobox.com writes:

 Junio C Hamano gits...@pobox.com writes:

 So I think the reasoning (i.e. is a descendant is not quite right)
 is correct, but the updated text is not quite right.  Changing it
 further to only the committer timestamps and identities would
 change is probably not an improvement, either.  Force the rebase
 that would otherwise be a no-op may be a better phrasing that does
 not risk going stale even if we update what are preserved and what
 are modified in the future.

 Also I notice the sentence Normally non-interactive...in such a
 situation is not helping the reader in this description very much.
 I wonder if we should keep it if we are rewriting this paragraph.

 How about doing it this way, perhaps?

 -- 8 --
 From: Sergey Organov sorga...@gmail.com
 Date: Tue, 12 Aug 2014 00:22:48 +0400
 Subject: [PATCH] Documentation/git-rebase.txt: -f forces a rebase that would 
 otherwise be a no-op

 Current branch is a descendant of the commit you are rebasing onto
 does not necessarily mean rebase requires --force.  For a plain
 vanilla history flattening rebase, the rebase can be done without
 forcing if there is a merge between the tip of the branch being
 rebased and the commit you are rebasing onto, even if the tip is
 descendant of the other.

 [jc: reworded both the text and the log description]

 Signed-off-by: Sergey Organov sorga...@gmail.com
 Signed-off-by: Junio C Hamano gits...@pobox.com
 ---
  Documentation/git-rebase.txt | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

 diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
 index 2a93c64..f14100a 100644
 --- a/Documentation/git-rebase.txt
 +++ b/Documentation/git-rebase.txt
 @@ -316,11 +316,8 @@ which makes little sense.
  
  -f::
  --force-rebase::
 - Force the rebase even if the current branch is a descendant
 - of the commit you are rebasing onto.  Normally non-interactive rebase 
 will
 - exit with the message Current branch is up to date in such a
 - situation.
 - Incompatible with the --interactive option.
 + Force a rebase even if the current branch is up-to-date and
 + the command without `--force` would return without doing anything.
  +
  You may find this (or --no-ff with an interactive rebase) helpful after
  reverting a topic branch merge, as this option recreates the topic branch 
 with


Junio C Hamano gits...@pobox.com writes:

 Junio C Hamano gits...@pobox.com writes:

 So I think the reasoning (i.e. is a descendant is not quite right)
 is correct, but the updated text is not quite right.  Changing it
 further to only the committer timestamps and identities would
 change is probably not an improvement, either.  Force the rebase
 that would otherwise be a no-op may be a better phrasing that does
 not risk going stale even if we update what are preserved and what
 are modified in the future.

 Also I notice the sentence Normally non-interactive...in such a
 situation is not helping the reader in this description very much.
 I wonder if we should keep it if we are rewriting this paragraph.

 How about doing it this way, perhaps?

 -- 8 --
 From: Sergey Organov sorga...@gmail.com
 Date: Tue, 12 Aug 2014 00:22:48 +0400
 Subject: [PATCH] Documentation/git-rebase.txt: -f forces a rebase that would 
 otherwise be a no-op

 Current branch is a descendant of the commit you are rebasing onto
 does not necessarily mean rebase requires --force.  For a plain
 vanilla history flattening rebase, the rebase can be done without
 forcing if there is a merge between the tip of the branch being
 rebased and the commit you are rebasing onto, even if the tip is
 descendant of the other.

 [jc: reworded both the text and the log description]

 Signed-off-by: Sergey Organov sorga...@gmail.com
 Signed-off-by: Junio C Hamano gits...@pobox.com
 ---
  Documentation/git-rebase.txt | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

 diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
 index 2a93c64..f14100a 100644
 --- a/Documentation/git-rebase.txt
 +++ b/Documentation/git-rebase.txt
 @@ -316,11 +316,8 @@ which makes little sense.
  
  -f::
  --force-rebase::
 - Force the rebase even if the current branch is a descendant
 - of the commit you are rebasing onto.  Normally non-interactive rebase 
 will
 - exit with the message Current branch is up to date in such a
 - situation.
 - Incompatible with the --interactive option.
 + Force a rebase even if the current branch is up-to-date and
 + the command without `--force` would return without doing anything.
  +
  You may find this (or --no-ff with an interactive rebase) helpful after
  reverting a topic branch merge, as this option recreates the topic branch 
 with

I dig more into it, and that's what I came up with, using some of your
suggestions as well.

Please notice new text on essential interaction with --preserve-merges.

I also thought about 

Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

2014-08-15 Thread Junio C Hamano
Sergey Organov sorga...@gmail.com writes:

 ...
 diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
 index 2a93c64..f14100a 100644
 --- a/Documentation/git-rebase.txt
 +++ b/Documentation/git-rebase.txt
 @@ -316,11 +316,8 @@ which makes little sense.
  
  -f::
  --force-rebase::
 -Force the rebase even if the current branch is a descendant
 -of the commit you are rebasing onto.  Normally non-interactive rebase 
 will
 -exit with the message Current branch is up to date in such a
 -situation.
 -Incompatible with the --interactive option.
 +Force a rebase even if the current branch is up-to-date and
 +the command without `--force` would return without doing anything.
  +
  You may find this (or --no-ff with an interactive rebase) helpful after
  reverting a topic branch merge, as this option recreates the topic branch 
 with

 I dig more into it, and that's what I came up with, using some of your
 suggestions as well.

 Please notice new text on essential interaction with --preserve-merges.

 I also thought about Force the rebase that would otherwise be a no-op,
 and while it is future-changes-agnostic indeed, it doesn't actually
 explain anything, so I put some explanation back.

A sentence --force has no effect under --preserve-merges mode does
not tell the readers very much, either and leaves them wondering if
it means --preserve-merges mode always rebases every time it is
asked, never noticing 'ah, the history is already in a good shape
and there is no need to do anything further' or --preserve-merges
mode ignores --force and refuses to recreate the history if the
history is in the shape the mode deems is already desirable.

I think the root cause of the issue we share in this thread, when
trying to come up with an improvement of this part, is that we are
trying to put more explanation to the description of --force, but if
we step back a bit, it may be that the explanation does not belong
there.  As far as the readers are concerned, --force is about
forcing a rebase that would not otherwise be a no-op, but the real
issue is that the condition under which a requested rebase becomes a
no-op, iow, the history is already in the desired shape, nothing to
do, is different from mode to mode, because the desired shape is
what distinguishes the modes.  Preserve-merge rebase may think that
a history that is descendant of the onto commit is already in the
desired shape while plain-vanilla rebase does not if it has a merge
in between, for example.

The sentence that follows Otherwise in this version encourages the
readers to be in a wrong mind-set that rebase is only about making
the branch a descendant of the 'onto' commit, which isn't the case.

The desired outcome depends on the mode (and that is why there are
modes), and not saying that explicitly will only help spread the
confusion, I am afraid.  Isn't it a better solution to explain what
that no-op condition is for the mode at the place in the document
where we describe each mode?

E.g. under --preserve-merges heading, we may say make sure the
history is a descendant of the 'onto' commit; if it already is,
nothing is done because there is no need to do anything or
something along that line.  The description for the plain-vanilla
rebase may say flatten the history on top of the 'onto' commit by
replaying the changes in each non-merge commit; if the history is
already a descendant of the 'onto' commit without any merge in
between, nothing is done because there is no need to.

That would make description of the modes more understandable, too.
The users can read what kind of resulting history they can get out
of by using each mode in one place.

Hmm?

 -- 8 --

 From: Sergey Organov sorga...@gmail.com
 Date: Tue, 12 Aug 2014 00:10:19 +0400
 Subject: [PATCH] Documentation/git-rebase.txt: fix -f description to match

 Current branch is a descendant of the commit you are rebasing onto
 does not necessarily mean rebase requires --force. Presence of
 merge commit(s) makes rebase perform its default flattening actions
 anyway.

 Signed-off-by: Sergey Organov sorga...@gmail.com
 ---
  Documentation/git-rebase.txt | 9 -
  1 file changed, 4 insertions(+), 5 deletions(-)

 diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
 index 2a93c64..9153369 100644
 --- a/Documentation/git-rebase.txt
 +++ b/Documentation/git-rebase.txt
 @@ -316,11 +316,10 @@ which makes little sense.
  
  -f::
  --force-rebase::
 - Force the rebase even if the current branch is a descendant
 - of the commit you are rebasing onto.  Normally non-interactive rebase 
 will
 - exit with the message Current branch is up to date in such a
 - situation.
 - Incompatible with the --interactive option.
 + If --preserve-merges is given, has no effect. Otherwise forces
 + rebase even if the current branch is a descendant of the commit
 + you are rebasing onto and there are no merge commits among
 + 

Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

2014-08-15 Thread Sergey Organov
Junio C Hamano gits...@pobox.com writes:

 Sergey Organov sorga...@gmail.com writes:

 ...
 diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
 index 2a93c64..f14100a 100644
 --- a/Documentation/git-rebase.txt
 +++ b/Documentation/git-rebase.txt
 @@ -316,11 +316,8 @@ which makes little sense.
  
  -f::
  --force-rebase::
 -   Force the rebase even if the current branch is a descendant
 -   of the commit you are rebasing onto.  Normally non-interactive rebase 
 will
 -   exit with the message Current branch is up to date in such a
 -   situation.
 -   Incompatible with the --interactive option.
 +   Force a rebase even if the current branch is up-to-date and
 +   the command without `--force` would return without doing anything.
  +
  You may find this (or --no-ff with an interactive rebase) helpful after
  reverting a topic branch merge, as this option recreates the topic branch 
 with

 I dig more into it, and that's what I came up with, using some of your
 suggestions as well.

 Please notice new text on essential interaction with --preserve-merges.

 I also thought about Force the rebase that would otherwise be a no-op,
 and while it is future-changes-agnostic indeed, it doesn't actually
 explain anything, so I put some explanation back.

 A sentence --force has no effect under --preserve-merges mode does
 not tell the readers very much, either and leaves them wondering if
 it means --preserve-merges mode always rebases every time it is
 asked, never noticing 'ah, the history is already in a good shape
 and there is no need to do anything further' or --preserve-merges
 mode ignores --force and refuses to recreate the history if the
 history is in the shape the mode deems is already desirable.

In fact there is no way to force rebase when --preserve-merges is given.
Neither --force nor --no-ff has any effect.

Maybe some clarification could be given in --preserve-merges
description, provided it's not clear that has no effect for --force
means that one can't force the rebase in this case.

 I think the root cause of the issue we share in this thread, when
 trying to come up with an improvement of this part, is that we are
 trying to put more explanation to the description of --force, but if
 we step back a bit, it may be that the explanation does not belong
 there.  As far as the readers are concerned, --force is about
 forcing a rebase that would not otherwise be a no-op, but the real
 issue is that the condition under which a requested rebase becomes a
 no-op, iow, the history is already in the desired shape, nothing to
 do, is different from mode to mode, because the desired shape is
 what distinguishes the modes.  Preserve-merge rebase may think that
 a history that is descendant of the onto commit is already in the
 desired shape while plain-vanilla rebase does not if it has a merge
 in between, for example.

I think the root cause is even deeper, in the current design of the
rebase interface, but those my opinion you already know and I'll leave
discussion for another post that I currently try to formulate.

 The sentence that follows Otherwise in this version encourages the
 readers to be in a wrong mind-set that rebase is only about making
 the branch a descendant of the 'onto' commit, which isn't the case.

I'm not happy with the wording myself either.

 The desired outcome depends on the mode (and that is why there are
 modes), and not saying that explicitly will only help spread the
 confusion, I am afraid.  Isn't it a better solution to explain what
 that no-op condition is for the mode at the place in the document
 where we describe each mode?

 E.g. under --preserve-merges heading, we may say make sure the
 history is a descendant of the 'onto' commit; if it already is,
 nothing is done because there is no need to do anything or
 something along that line.  The description for the plain-vanilla
 rebase may say flatten the history on top of the 'onto' commit by
 replaying the changes in each non-merge commit; if the history is
 already a descendant of the 'onto' commit without any merge in
 between, nothing is done because there is no need to.

 That would make description of the modes more understandable, too.
 The users can read what kind of resulting history they can get out
 of by using each mode in one place.

I think you've lost me here, though I think that all the suggested
variants are still better than what is there right now.

-- 
Sergey.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

2014-08-15 Thread Junio C Hamano
Sergey Organov sorga...@gmail.com writes:

 A sentence --force has no effect under --preserve-merges mode does
 not tell the readers very much, either and leaves them wondering if
 it means --preserve-merges mode always rebases every time it is
 asked, never noticing 'ah, the history is already in a good shape
 and there is no need to do anything further' or --preserve-merges
 mode ignores --force and refuses to recreate the history if the
 history is in the shape the mode deems is already desirable.

 In fact there is no way to force rebase when --preserve-merges is given.
 Neither --force nor --no-ff has any effect.

 Maybe some clarification could be given in --preserve-merges
 description, provided it's not clear that has no effect for --force
 means that one can't force the rebase in this case.

I am not sure if that is an intended behaviour or simply a bug (I
rarely use preserve-merges myself, so I offhand do not know for
certain).

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

2014-08-13 Thread Sergey Organov
Junio C Hamano gits...@pobox.com writes:

 Junio C Hamano gits...@pobox.com writes:

 So I think the reasoning (i.e. is a descendant is not quite right)
 is correct, but the updated text is not quite right.  Changing it
 further to only the committer timestamps and identities would
 change is probably not an improvement, either.  Force the rebase
 that would otherwise be a no-op may be a better phrasing that does
 not risk going stale even if we update what are preserved and what
 are modified in the future.

 Also I notice the sentence Normally non-interactive...in such a
 situation is not helping the reader in this description very much.
 I wonder if we should keep it if we are rewriting this paragraph.

 How about doing it this way, perhaps?

[...]

  -f::
  --force-rebase::
 - Force the rebase even if the current branch is a descendant
 - of the commit you are rebasing onto.  Normally non-interactive rebase 
 will
 - exit with the message Current branch is up to date in such a
 - situation.
 - Incompatible with the --interactive option.
 + Force a rebase even if the current branch is up-to-date and
 + the command without `--force` would return without doing anything.
  +
  You may find this (or --no-ff with an interactive rebase) helpful after
  reverting a topic branch merge, as this option recreates the topic branch 
 with

It's OK with me, as in fact I think that there is no good explanation
for current git behavior, and thus it's git behavior that should have
been changed, not the documentation. I.e., git must not rebase anything
when Current branch is a descendant of the commit you are rebasing
onto, unless -f is given. Simple, reasonable, straightforward.

The version you propose at least does not lie, so it's definiteley an
improvement. However,

Force the rebase when the command exits with Current branch is up to
date message.

reads even more simple and clear for me.

-- 
Sergey.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

2014-08-13 Thread Junio C Hamano
Sergey Organov sorga...@gmail.com writes:

 ... I.e., git must not rebase anything
 when Current branch is a descendant of the commit you are rebasing
 onto, unless -f is given. Simple, reasonable, straightforward.

It may be simple and straightforward, but breaks the use case the
plain vanilla rebase is used for, doesn't it?  You seem to ignore,
or perhaps you don't realize the existence of, the need of those who
want to flatten the history on top of the tip from the other side;
your statements in the pull --rebase[=preserve] thread may be
coming from the same place, I suspect.

For the flatten the history on top of that commit use case, two
conditions must be satisfied before the command can say the history
is already in the desired shape and nothing needs to be done to
allow it to make a short-cut.  It is not sufficient for the current
tip to be merely descendant of the tip from the other side (which is
the documentation bug we are fixing here).  The history between the
two commits need also to be linear, or it would not be flattening.

Punting when when only one of the two conditions is met and
requiring --force to perform what the user wanted to ask the
command to do does not fall into the reasonable category.

If your workflow does not involve the flattening plain vanilla
rebase, not using it is perfectly fine.  But please do not break
it for other people only because you do not use it yourself.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

2014-08-12 Thread Junio C Hamano
Sergey Organov sorga...@gmail.com writes:

 Previous description of -f option was wrong as git rebase does not
 require -f to perform rebase when current branch is a descendant of
 the commit you are rebasing onto, provided commit(s) to be rebased
 contain merge(s).

Both the above and the updated documentation are a bit hard to read
for me, so let me disect what you are and you are not saying to see
if I understood them correctly:

 - The plain-vanilla git rebase that flattens the history will be
   a no-op *only* when the current tip is a linear descendant of the
   onto commit without any merge in between.

 - Merge-preserving form of git rebase -m/-p is a no-op when the
   current tip is a descendant of the onto commit.

 - rebase -f is a way to force rebase when it would otherwise be a
   no-op.

 - When you force a rebase that would otherwise be a no-op, only the
   timestamps would change.

I think you are right that 'current branch is a descendant of the
onto commit' is not necessarily equal to 'rebase that would
otherwise be a no-op'.  I am not sure if a 'rebase that would
otherwise be a no-op' is equal to 'only timestamp would change',
though.  What happens if you do this, for example?

$ GIT_COMMITTER_NAME='Somebody Else' git commit
$ git rebase --force --onto HEAD^ HEAD^ HEAD^0

So I think the reasoning (i.e. is a descendant is not quite right)
is correct, but the updated text is not quite right.  Changing it
further to only the committer timestamps and identities would
change is probably not an improvement, either.  Force the rebase
that would otherwise be a no-op may be a better phrasing that does
not risk going stale even if we update what are preserved and what
are modified in the future.

Also I notice the sentence Normally non-interactive...in such a
situation is not helping the reader in this description very much.
I wonder if we should keep it if we are rewriting this paragraph.

Thanks.

 Signed-off-by: Sergey Organov sorga...@gmail.com
 ---
  Documentation/git-rebase.txt | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

 diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
 index 2a93c64..62dac31 100644
 --- a/Documentation/git-rebase.txt
 +++ b/Documentation/git-rebase.txt
 @@ -316,10 +316,9 @@ which makes little sense.
  
  -f::
  --force-rebase::
 - Force the rebase even if the current branch is a descendant
 - of the commit you are rebasing onto.  Normally non-interactive rebase 
 will
 - exit with the message Current branch is up to date in such a
 - situation.
 + Force the rebase even if the result will only change commit
 + timestamps. Normally non-interactive rebase will exit with the
 + message Current branch is up to date in such a situation.
   Incompatible with the --interactive option.
  +
  You may find this (or --no-ff with an interactive rebase) helpful after
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

2014-08-12 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes:

 So I think the reasoning (i.e. is a descendant is not quite right)
 is correct, but the updated text is not quite right.  Changing it
 further to only the committer timestamps and identities would
 change is probably not an improvement, either.  Force the rebase
 that would otherwise be a no-op may be a better phrasing that does
 not risk going stale even if we update what are preserved and what
 are modified in the future.

 Also I notice the sentence Normally non-interactive...in such a
 situation is not helping the reader in this description very much.
 I wonder if we should keep it if we are rewriting this paragraph.

How about doing it this way, perhaps?

-- 8 --
From: Sergey Organov sorga...@gmail.com
Date: Tue, 12 Aug 2014 00:22:48 +0400
Subject: [PATCH] Documentation/git-rebase.txt: -f forces a rebase that would 
otherwise be a no-op

Current branch is a descendant of the commit you are rebasing onto
does not necessarily mean rebase requires --force.  For a plain
vanilla history flattening rebase, the rebase can be done without
forcing if there is a merge between the tip of the branch being
rebased and the commit you are rebasing onto, even if the tip is
descendant of the other.

[jc: reworded both the text and the log description]

Signed-off-by: Sergey Organov sorga...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
 Documentation/git-rebase.txt | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2a93c64..f14100a 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -316,11 +316,8 @@ which makes little sense.
 
 -f::
 --force-rebase::
-   Force the rebase even if the current branch is a descendant
-   of the commit you are rebasing onto.  Normally non-interactive rebase 
will
-   exit with the message Current branch is up to date in such a
-   situation.
-   Incompatible with the --interactive option.
+   Force a rebase even if the current branch is up-to-date and
+   the command without `--force` would return without doing anything.
 +
 You may find this (or --no-ff with an interactive rebase) helpful after
 reverting a topic branch merge, as this option recreates the topic branch with
-- 
2.1.0-rc2-238-g2566d2d

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html