From: Robin Burchell <hidden> Date: 2016-06-15 22:45:26
Hi,
This is my first mail to this list, so I hope I'm not breaking any
form of ettiquette, etc. If I do step on any toes, feel free to bop me
on the head with a rubber mallet, or steer me in the right direction.
That over, I have a suggestion for `git rebase', from the perspective
of a newcomer.
I've been using git instead of svn (and various other VCS) now for
about a month, and am finding it quite a refreshing change.
I have also recently started a collaborative project exclusively with
git (well, pulling changes from a git-svn repo I don't control) which
has been a valuable ..learning experience.
With this in mind, I'd like to mention exactly what I did.
Upstream had issued a new commit, so I, not knowing the possible
dangers used git-svn rebase to pull in the new changes to our tree.
This "appeared" to work fine, but alarm bells were already going off
in my head before I typed the command (I didn't know at the time I
could merge svn trees like I could normal git branches) as I knew that
rebase rewrote history, and I saw it do this to about 300 commits.
It promptly made merging absolute hell with the other few members of
my team, as it would.
Granted - this is a mistake on my part, and probably a common newbie
one, but something that came to mind when thinking about it later:
would it perhaps be an idea to have a way to mark a tree 'public', and
disallow rebase *unless* --force was passed, or it was a public tree?
(Then again, the alternative might be more 'intelligent' for new
users: start off with branches defaulting to private, and marking them
public, disallowing use of rebase, etc).
Thoughts, feedback, etc are welcome.
--
Robin Burchell
Documentation/git-rebase.txt talks about pre-rebase hook, but
it appears that Documentation/git-hooks.txt does not have corresponding
entry for it.
Signed-off-by: Nanako Shiraishi <redacted>
---
"Robin Burchell" [off-list ref] writes:
> would it perhaps be an idea to have a way to mark a tree 'public', and
> disallow rebase *unless* --force was passed, or it was a public tree?
Documentation/githooks.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
@@ -130,6 +130,13 @@ parameter, and is invoked after a commit is made. This hook is meant primarily for notification, and cannot affect the outcome of 'git-commit'.+pre-rebase+----------++This hook is called by 'git-rebase' and can be used to prevent a branch+from getting rebased.++ post-checkout -----------
The original git-rebase honored pre-rebase hook so that public branches
can be protected from getting rebased, but rebase --interactive ignored
the hook entirely. This fixes it.
Signed-off-by: Nanako Shiraishi <redacted>
---
git-rebase--interactive.sh | 11 ++++
git-rebase.sh | 18 ++++---
t/t3409-rebase-hook.sh | 126 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 148 insertions(+), 7 deletions(-)
create mode 100755 t/t3409-rebase-hook.sh
@@ -65,6 +65,16 @@ output () {esac}+run_pre_rebase_hook(){+iftest-x"$GIT_DIR/hooks/pre-rebase"+then+"$GIT_DIR/hooks/pre-rebase"${1+"$@"}||{+echo>&2"The pre-rebase hook refused to rebase."+exit1+}+fi+}+ require_clean_work_tree(){# test if working tree is dirtygitrev-parse--verifyHEAD>/dev/null&&
@@ -507,6 +517,7 @@ first and then run 'git rebase --continue' again.";;--)shift+run_pre_rebase_hook${1+"$@"}test$#-eq1-o$#-eq2||usagetest-d"$DOTEST"&&die"Interactive rebase already started"
@@ -144,6 +144,16 @@ is_interactive () {done&&test-n"$1"}+run_pre_rebase_hook(){+iftest-x"$GIT_DIR/hooks/pre-rebase"+then+"$GIT_DIR/hooks/pre-rebase"${1+"$@"}||{+echo>&2"The pre-rebase hook refused to rebase."+exit1+}+fi+}+test-f"$GIT_DIR"/rebase-apply/applying&&die'It looks like git-am is in progress. Cannot rebase.'
@@ -320,13 +330,7 @@ onto_name=${newbase-"$upstream_name"}onto=$(gitrev-parse--verify"${onto_name}^0")||exit# If a hook exists, give it a chance to interrupt-iftest-x"$GIT_DIR/hooks/pre-rebase"-then-"$GIT_DIR/hooks/pre-rebase"${1+"$@"}||{-echo>&2"The pre-rebase hook refused to rebase."-exit1-}-fi+run_pre_rebase_hook${1+"$@"}# If the branch to rebase is given, that is the branch we will rebase# $branch_name -- branch being rebased, or HEAD (already detached)
It is sometimes desirable to disable the safety net of pre-rebase hook
when the user knows what he is doing (for example, when the original
changes on the branch have not been shown to the public yet).
This teaches --no-verify option to git-rebase, which is similar to the way
pre-commit hook is bypassed by git-commit.
Signed-off-by: Nanako Shiraishi <redacted>
---
It probably is better to fix "rebase -i" to share more code with the main
"rebase" script to avoid duplicated run-pre-rebase-hook function, but it
is beyond what I can do right now. Perhaps people more smart and
beautiful than me can help (^_^;)
git-rebase--interactive.sh | 10 +++++++++-
git-rebase.sh | 7 ++++++-
t/t3409-rebase-hook.sh | 16 ++++++++++++++++
3 files changed, 31 insertions(+), 2 deletions(-)
@@ -170,6 +172,9 @@ fiwhiletest$#!=0docase"$1"in+--no-verify)+OK_TO_SKIP_PRE_REBASE=yes+;;--continue)test-d"$dotest"-o-d"$GIT_DIR"/rebase-apply||die"No rebase in progress?"
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:27
Nanako Shiraishi [off-list ref] wrote:
It is sometimes desirable to disable the safety net of pre-rebase hook
when the user knows what he is doing (for example, when the original
changes on the branch have not been shown to the public yet).
This teaches --no-verify option to git-rebase, which is similar to the way
pre-commit hook is bypassed by git-commit.
Looks good.
It probably is better to fix "rebase -i" to share more code with the main
"rebase" script to avoid duplicated run-pre-rebase-hook function, but it
is beyond what I can do right now. Perhaps people more smart and
beautiful than me can help (^_^;)
True. But its already a mess. git-sequencer is probably the
right approach to merge it all together.
From: Stephan Beyer <hidden> Date: 2016-06-15 22:45:27
Hi,
Shawn O. Pearce wrote:
quoted
It probably is better to fix "rebase -i" to share more code with the main
"rebase" script to avoid duplicated run-pre-rebase-hook function, but it
is beyond what I can do right now. Perhaps people more smart and
beautiful than me can help (^_^;)
True. But its already a mess. git-sequencer is probably the
right approach to merge it all together.
Hmm, I don't think I like the pre-rebase hook in sequencer. The user
scripts (git-rebase--interactive.sh and git-rebase.sh) should run them;
that's ok.
I think, for the moment it is ok to have the code duplicated. After
sequencer has merged into master[1], I will probably take a look at
merging git-rebase.sh and git-rebase--interactive.sh if somebody
else is interested in it and if there is a good way to achieve that.
Regards,
Stephan
Footnotes:
1. For the *very* interested ones of you,
http://repo.or.cz/w/git/sbeyer.git
is the way to go. seq-builtin-dev is the active development branch
and git's master is frequently merged into it. seq-builtin-rfc^ is
an approach to possible patchsets (for review).
--
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:27
Stephan Beyer [off-list ref] wrote:
Shawn O. Pearce wrote:
quoted
quoted
It probably is better to fix "rebase -i" to share more code with the main
"rebase" script to avoid duplicated run-pre-rebase-hook function, but it
is beyond what I can do right now. Perhaps people more smart and
beautiful than me can help (^_^;)
True. But its already a mess. git-sequencer is probably the
right approach to merge it all together.
Hmm, I don't think I like the pre-rebase hook in sequencer. The user
scripts (git-rebase--interactive.sh and git-rebase.sh) should run them;
that's ok.
Sorry, my remark wasn't about the rebase hook as much as it was
that there is a good chunk of code duplicated between the two
rebase implementations and all of them were implemented through
git-sequencer its likely they could all collapse into a single
common "git rebase" wrapper script which just sets up the call
to git-sequencer.
So yea, I do agree, the pre-rebase hook should be in rebase, not
git-sequencer, but git-sequencer probably offers a great way to
get the different rebase implementations combined together.
I think, for the moment it is ok to have the code duplicated. After
sequencer has merged into master[1], I will probably take a look at
merging git-rebase.sh and git-rebase--interactive.sh if somebody
else is interested in it and if there is a good way to achieve that.
Yup, exactly my thoughts. I just didn't express them well.
--
Shawn.