From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: "Galan Rémi" <remi.galan-alfonso@ensimag.grenoble-inp.fr>
Cc: Git List <git@vger.kernel.org>,
Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>,
Guillaume Pages <guillaume.pages@ensimag.grenoble-inp.fr>,
Louis-Alexandre Stuber
<louis--alexandre.stuber@ensimag.grenoble-inp.fr>,
Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr>,
Junio C Hamano <gitster@pobox.com>,
Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH/RFCv3 2/2] git rebase -i: warn about removed commits
Date: Tue, 02 Jun 2015 16:56:01 +0200 [thread overview]
Message-ID: <vpqzj4ignwe.fsf@anie.imag.fr> (raw)
In-Reply-To: <1433252180-25591-2-git-send-email-remi.galan-alfonso@ensimag.grenoble-inp.fr> ("Galan \=\?iso-8859-1\?Q\?R\=E9mi\=22's\?\= message of "Tue, 2 Jun 2015 15:36:20 +0200")
Galan Rémi <remi.galan-alfonso@ensimag.grenoble-inp.fr> writes:
> Check if commits were removed (i.e. a line was deleted) and print
> warnings or abort git rebase according to the value of the
s/according to/depending on/
(although both translate to the same "selon" in french ;-))
> configuration variable rebase.missingCommitsCheckLevel.
Now I'm wondering whether rebase.missingCommits would be sufficient. The
full config would be
[rebase]
missingCommits = warn
which reads like "in rebase, on missing commit, warn me".
> Add the configuration variable rebase.missingCommitsCheckLevel.
> - When unset or set to "ignore", no checking is done.
> - When set to "warn", the commits are checked, warnings are
> displayed but git rebase still proceeds.
> - When set to "error", the commits are checked, warnings are
> displayed and the rebase is aborted.
>
> rebase.missingCommitsCheckLevel defaults to "ignore".
This all describes well *what* the commit is doing (which is essentially
rendundant with the documentation actually), but fails to really explain
*why*, which is the most important question to adress in a commit
message.
I'm convinced that this is a good idea (partly because I'm the one who
suggested ^^), but not everybody is.
> +rebase.missingCommitsCheckLevel::
> + If set to "warn", git rebase -i will print a warning if some
> + commits are removed (i.e. a line was deleted), however the
> + rebase will still proceed. If set to "error", it will print
> + the previous warning and abort the rebase. If set to
> + "ignore", no checking is done. Defaults to "ignore".
I think the relationship with 'drop' should be clarified here.
"To drop a commit without warning or error, use the `drop` command in the
todo-list."
?
> +# Print the list of the SHA-1 of the commits
> +# from a todo list in a file.
> +# $1: todo-file, $2: outfile
> +todo_list_to_sha_list () {
> + todo_list=$(git stripspace --strip-comments <"$1")
> + temp_file=$(mktemp)
c5770f7 (contrib/diffall: create tmp dirs without mktemp, 2012-03-14)
says "mktemp is not available on all platforms." ...
> + echo "$todo_list" >$temp_file
Don't use echo on user-supplied data. It's not portable (think what
happens if $todo_list starts with a -).
printf '%s' "$todo_list"
You don't need all these intermediate variables/files. It looks like you
want
git stripspace --strip-comments | while read -r command sha1 rest
do
...
> +# Transforms SHA-1 list in argument
> +# to a list of commits (in place)
> +# Doesn't check if the SHA-1 are commits.
s/if/whether/
> +# $1: file with long SHA-1 list
> +long_sha_to_commit_list () {
> + short_missing=""
> + git_command="git show --oneline"
> + get_line_command="head -n 1"
> + temp_file=$(mktemp)
> + while read -r sha
> + do
> + if test -n "$sha"
> + then
> + commit=$($git_command $sha | $get_line_command)
Why not git show --oneline $sha without using this $git_command?
To me
git show --oneline $sha | head -n 1
says all that has to be said, while
$git_command $sha | $get_line_command
does not say anything (although it uses more characters).
But actually, computing the diff with `git show` and eliminating it with
`head` seems backwards.
I guess you want something like:
git rev-list --pretty=oneline -1 $sha
And the whole long_sha_to_commit_list is more or less equivalent to
git rev-list --stdin --no-walk --format=oneline --abbrev-commit
(Yes, git was _meant_ to be scriptable, and it really is)
> +# Use warn for each line of a file
> +# $1: file to warn
I don't parse "file to warn". I'd rather warn the user than a file ;-).
> +# Check if the user dropped some commits by mistake
> +# Behaviour determined by .gitconfig.
not necessarily .gitconfig, there are other names. Say
rebase.missingCommitsCheckLevel if you want to be technically accurate.
> +check_commits () {
> + checkLevel=$(git config --get rebase.missingCommitsCheckLevel)
> + checkLevel=${checkLevel:-ignore}
> + # To lowercase
> + checkLevel=$(echo "$checkLevel" | tr 'A-Z' 'a-z')
Good comments insist on _why_ not _what_. I'd write:
# Don't be case sensitive
checkLevel=$(echo "$checkLevel" | tr 'A-Z' 'a-z')
> + case "$checkLevel" in
> + warn|error)
> + # Get the SHA-1 of the commits
> + todo_list_to_sha_list "$todo".backup "$todo".oldsha1
> + todo_list_to_sha_list "$todo" "$todo".newsha1
> +
> + # Sort the SHA-1 and compare them
> + echo "$(sort -u "$todo".oldsha1)" >"$todo".oldsha1
> + echo "$(sort -u "$todo".newsha1)" >"$todo".newsha1
Useless uses of echo.
echo $(foo) -> foo
> + warn "Warning : some commits may have been dropped" \
No space before : in english (hmm, didn't I already notice this one?)
> + warn "Use git --config rebase.missingCommitsCheckLevel to change" \
> + "the level of warnings (ignore,warn,error)."
Spaces after commas, or (ignore/warn/error).
> + warn "Unrecognized setting $checkLevel for option" \
> + "rebase.missingCommitsCheckLevel in git rebase -i."
I'd drop the "in git rebase -i" part. The user may have run "git rebase
--interactive" and not know -i, and normally already knows which command
is executed.
> +test_expect_success 'rebase -i respects rebase.missingCommitsCheckLevel=error' '
> + test_config rebase.missingCommitsCheckLevel error &&
> + test_when_finished "git checkout master &&
> + git branch -D tmp2" &&
> + git checkout -b tmp2 master &&
> + set_fake_editor &&
> + test_must_fail env FAKE_LINES="1 2 3 4" \
> + git rebase -i --root &&
> + test E = $(git cat-file commit HEAD | sed -ne \$p)
> +'
You should test also that
git rebase --edit-todo # playing with $EDITOR to restore the original lines.
git rebase --continue
actually continues. You did have problems with this in early
implementations, so it's not straightforward, so it deserves a test.
You should check the output of git rebase -i too.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
next prev parent reply other threads:[~2015-06-02 14:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-02 13:36 [PATCH/RFCv3 1/2] git-rebase -i: add command "drop" to remove a commit Galan Rémi
2015-06-02 13:36 ` [PATCH/RFCv3 2/2] git rebase -i: warn about removed commits Galan Rémi
2015-06-02 14:56 ` Matthieu Moy [this message]
2015-06-02 16:32 ` Remi Galan Alfonso
2015-06-02 18:22 ` Junio C Hamano
2015-06-03 6:42 ` Matthieu Moy
2015-06-03 7:33 ` Remi Galan Alfonso
2015-06-03 8:25 ` Remi Galan Alfonso
2015-06-02 14:17 ` [PATCH/RFCv3 1/2] git-rebase -i: add command "drop" to remove a commit Matthieu Moy
2015-06-02 14:32 ` Remi Galan Alfonso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vpqzj4ignwe.fsf@anie.imag.fr \
--to=matthieu.moy@grenoble-inp.fr \
--cc=antoine.delaite@ensimag.grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=guillaume.pages@ensimag.grenoble-inp.fr \
--cc=louis--alexandre.stuber@ensimag.grenoble-inp.fr \
--cc=remi.galan-alfonso@ensimag.grenoble-inp.fr \
--cc=remi.lespinet@ensimag.grenoble-inp.fr \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.