[Qt-creator] prepare-commit-msg and commit-msg hooks

[Seth Raymond]

With the current Qt Creator git plugin implementation, it is difficult (and
perhaps impossible?) to use the prepare-commit-msg and commit-msg hooks to
check if a commit message is stylistically valid. This is because Qt
Creator does not run `git commit` until after the message has been written
in the "Description" box and the "Commit" button has been pressed. The
current sequence is as follows:

-User types commit message into blank Description box
-User presses "Commit"
-Description is written to temp/commit/msg
-prepare-commit-msg hook is run on path/to/repo/.git/EDIT-COMMITMSG
-Data from temp/commit/msg is pseudo-appended to
path/to/repo/.git/EDIT-COMMITMSG
-commit-msg hook is run on path/to/repo/.git/EDIT-COMMITMSG

My temporary workaround is to use a static template, but the template
cannot dynamically insert text into the commit (such as the current branch
name). I could "fix" the commit message after the user is done, but that is
not ideal. Suggestions?

[Tobias Hunger]

Hi Seth!

You are almost correct AFAICT.

- User types commit message into blank Description box

Actually GitClient::getCommitData retrieves the text for the commit
message that is shown in the description box. That can be blank or
some of the different templates used by git. Creator does not run any
hooks at that point though.

- User presses "Commit"

... and creator runs "git commit", triggering all the magic git does
with the user-provided commit message as input.

Hooks do get run at this point, but it is admittedly a bit late for
the pre-commit or the prepare-commit-msg hook. Do you have any idea
how we can improve this -- without reimplementing all the logic built
into git?

Best Regards,
Tobias

With the current Qt Creator git plugin implementation, it is difficult (and
perhaps impossible?) to use the prepare-commit-msg and commit-msg hooks to
check if a commit message is stylistically valid. This is because Qt Creator
does not run `git commit` until after the message has been written in the
"Description" box and the "Commit" button has been pressed. The current
-User types commit message into blank Description box
-User presses "Commit"
-Description is written to temp/commit/msg
-prepare-commit-msg hook is run on path/to/repo/.git/EDIT-COMMITMSG
-Data from temp/commit/msg is pseudo-appended to
path/to/repo/.git/EDIT-COMMITMSG
-commit-msg hook is run on path/to/repo/.git/EDIT-COMMITMSG
My temporary workaround is to use a static template, but the template cannot
dynamically insert text into the commit (such as the current branch name). I
could "fix" the commit message after the user is done, but that is not
ideal. Suggestions?
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Oswald Buddenhagen]

Post by Tobias Hunger
Hooks do get run at this point, but it is admittedly a bit late for
the pre-commit or the prepare-commit-msg hook. Do you have any idea
how we can improve this -- without reimplementing all the logic built
into git?

by providing a stub editor and running git commit with $EDITOR pointing
to that stub as soon as the dialog is opened. from there it's just a bit
of ipc, which can be mostly ripped off from the debugger stub.

[Orgad Shaneh]

Post by Oswald Buddenhagen

Post by Tobias Hunger
Hooks do get run at this point, but it is admittedly a bit late for
the pre-commit or the prepare-commit-msg hook. Do you have any idea
how we can improve this -- without reimplementing all the logic built
into git?

by providing a stub editor and running git commit with $EDITOR pointing
to that stub as soon as the dialog is opened. from there it's just a bit
of ipc, which can be mostly ripped off from the debugger stub.

What if there are no staged files? git commit will not execute any hook on
this case,
and this is the typical state when the Git Commit dialog is opened.

- Orgad

[Oswald Buddenhagen]

Post by Orgad Shaneh
What if there are no staged files? git commit will not execute any hook on
this case,

it can be forced with --allow-empty.

Post by Orgad Shaneh
and this is the typical state when the Git Commit dialog is opened.

well, yes, and the hook's output can depend on what has been staged.
so this is really an inherent problem of the fact that the dialog
parallelizes a workflow that is meant to be sequential. git gui has the
same problem, and it's even worse at dealing with it.

as a workaround, i can imagine canceling and re-starting the commit
whenever the index changes (after a small delay). if the generated
commit message differs but the user has already edited it, a warning is
shown (maybe make an exception for the gerrit change-id, otherwise it
gets annoying; preferentially, the latest generated id should be used to
minimize the risk of collisions).

[Seth Raymond]

Post by Oswald Buddenhagen
so this is really an inherent problem of the fact that the dialog
parallelizes a workflow that is meant to be sequential.

This is the underlying problem. I'm sure there are plenty of inelegant
workarounds, but they're exactly that - inelegant. Furthermore, these
workarounds can't be done at the user-level, they must be a
(relatively) significant change to Creator/the git plugin.

I think the solution boils down to two options: either overhaul how
the git plugin handles the flow or circumvent a portion of git's
back-end and recreate it in the plugin. Is there a strong reason to
keep the process in its current, parallelized state?

On Tue, Jan 9, 2018 at 7:05 AM, Oswald Buddenhagen

Post by Oswald Buddenhagen

Post by Orgad Shaneh
What if there are no staged files? git commit will not execute any hook on
this case,

it can be forced with --allow-empty.

Post by Orgad Shaneh
and this is the typical state when the Git Commit dialog is opened.

well, yes, and the hook's output can depend on what has been staged.
so this is really an inherent problem of the fact that the dialog
parallelizes a workflow that is meant to be sequential. git gui has the
same problem, and it's even worse at dealing with it.
as a workaround, i can imagine canceling and re-starting the commit
whenever the index changes (after a small delay). if the generated
commit message differs but the user has already edited it, a warning is
shown (maybe make an exception for the gerrit change-id, otherwise it
gets annoying; preferentially, the latest generated id should be used to
minimize the risk of collisions).
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Oswald Buddenhagen]

Is there a strong reason to keep the process in its current,
parallelized state?

yes. for example, a conscientious committer will want to revise the file
list when during writing the commit message they notice that the commit
is non-atomic. happens to me all the time.

fwiw, qtc is imo still inferior to git gui regarding fine-grained
commits - the diff view and chunk-level staging are kinda hidden, and
line-wise staging apparently isn't there at all.
in fact, the selective staging context menu is outright broken in 4.5 -
there is no indication which actions make sense, and there are
duplicated actions.

[Seth Raymond]

Post by Oswald Buddenhagen
yes. for example, a conscientious committer will want to revise the file
list when during writing the commit message they notice that the commit
is non-atomic. happens to me all the time.

Would a "back"/"cancel" button at the commit message window that
returns you to the file selection window be sufficient? I'm not
particularly familiar with git gui, I've only ever used git out of the
terminal (and am now learning Qt Creator's git plugin). Invoking git
via the terminal is a series process, so obviously the process in the
GUI could be done in series. You lose an aspect of convenience for the
sake of "proper" functionality. But I'm not the one who makes those
decisions; I just wanted to report a deficiency I saw and see if there
were any known workarounds.

Our team is just skipping the Creator git plugin altogether and will
be using git via the terminal/preferred GUI that works with the hooks
we've written.

Post by Oswald Buddenhagen
fwiw, qtc is imo still inferior to git gui regarding fine-grained
commits - the diff view and chunk-level staging are kinda hidden, and
line-wise staging apparently isn't there at all.
in fact, the selective staging context menu is outright broken in 4.5 -
there is no indication which actions make sense, and there are
duplicated actions.

Sounds to me like I'm not the only person having problems with the
plugin. Hopefully some extra functionality will be added in the future
to make the plugin line up better with git tools already in place
elsewhere. Creator is an *integrated* development environment, after
all...

On Tue, Jan 9, 2018 at 9:56 AM, Oswald Buddenhagen

Post by Oswald Buddenhagen

Is there a strong reason to keep the process in its current,
parallelized state?

yes. for example, a conscientious committer will want to revise the file
list when during writing the commit message they notice that the commit
is non-atomic. happens to me all the time.
fwiw, qtc is imo still inferior to git gui regarding fine-grained
commits - the diff view and chunk-level staging are kinda hidden, and
line-wise staging apparently isn't there at all.
in fact, the selective staging context menu is outright broken in 4.5 -
there is no indication which actions make sense, and there are
duplicated actions.
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Vidhya Arun]

Hello All

I have a plugin written to update the kit and auto add the target devices
which is working fine

I would like to know how can I set the “Additional startup commands” and
“Additional attach commands” from Tools->Options->Debugger.

I found some options in Debugger plugin but nothing seems to be a writable
option.

Would help if any of you can share details if you know.

Regards

Vidhya

[André Hartmann]

Post by Seth Raymond

Post by Oswald Buddenhagen
yes. for example, a conscientious committer will want to revise the file
list when during writing the commit message they notice that the commit
is non-atomic. happens to me all the time.

Would a "back"/"cancel" button at the commit message window that
returns you to the file selection window be sufficient?

I'm quite sure that would break my workflow. And in all the yars I'm
working with Creator, you're the first one that had such a requirement.

Post by Seth Raymond
I'm not particularly familiar with git gui, I've only ever used git > out of the terminal (and am now learning Qt Creator's git plugin).
Invoking git via the terminal is a series process, so obviously
the process in the GUI could be done in series.

I don't think so. Well, you can stage files also in Creator before
commiting; but I think most people will just open the commit dialog
and work from there. But if you have a suggestion how this "new way of
commiting in series" could look like, you're welcome to present.

Post by Seth Raymond
You lose an aspect of convenience for the
sake of "proper" functionality. But I'm not the one who makes those
decisions; I just wanted to report a deficiency I saw and see if there
were any known workarounds.
Our team is just skipping the Creator git plugin altogether and will
be using git via the terminal/preferred GUI that works with the hooks
we've written.

Would you tell us which "preferred GUI" allows you to do that?

Post by Seth Raymond

Post by Oswald Buddenhagen
fwiw, qtc is imo still inferior to git gui regarding fine-grained
commits - the diff view and chunk-level staging are kinda hidden, and
line-wise staging apparently isn't there at all.
in fact, the selective staging context menu is outright broken in 4.5 -
there is no indication which actions make sense, and there are
duplicated actions.

Sounds to me like I'm not the only person having problems with the
plugin. Hopefully some extra functionality will be added in the future
to make the plugin line up better with git tools already in place
elsewhere. Creator is an *integrated* development environment, after
all...

Come on, Creators Git integration is the best I have seen so far. The
only thing I miss, is an integrated Merge tool...

Regards,
André

Post by Seth Raymond
On Tue, Jan 9, 2018 at 9:56 AM, Oswald Buddenhagen

Post by Oswald Buddenhagen

Is there a strong reason to keep the process in its current,
parallelized state?

yes. for example, a conscientious committer will want to revise the file
list when during writing the commit message they notice that the commit
is non-atomic. happens to me all the time.
fwiw, qtc is imo still inferior to git gui regarding fine-grained
commits - the diff view and chunk-level staging are kinda hidden, and
line-wise staging apparently isn't there at all.
in fact, the selective staging context menu is outright broken in 4.5 -
there is no indication which actions make sense, and there are
duplicated actions.
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator

_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator

--
Dipl.-Ing. (FH) André Hartmann
Softwareentwicklung / Software Development

E-Mail: ***@iseg-hv.de | Tel: [phone] | Fax: +49
351 26996-21

iseg Spezialelektronik GmbH - HIGH VOLTAGE. EXACTLY.
iseg-hv.de | iseg-hv.com | download.iseg-hv.com

Bautzner Landstr. 23, 01454 Radeberg / Rossendorf, Germany
Geschäftsführer / Managing directors: Dr. Frank Gleisberg, Dr. Joachim
Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Umsatzsteuer-Id: / VAT-ID: DE812508942

News / Information
https://iseg-hv.com/en/products/control#isegControl2 isegControl2 -
Unified Control Software
https://iseg-hv.com/en/products/detail/EHS EHS FLEX - Customize and keep
the price
https://iseg-hv.com/en/products/detail/EHS EHS STACK - Perfect for GEM
Detectors
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf NEW!
Product catalog 2017 / 2018 released
https://iseg-hv.com/en/products/detail/NHR NHR - NIM HV-Supply with
reversible polarity

Links
https://www.linkedin.com/company/12726924 iseg on LINKEDIN | Let's stay
connected!
https://www.youtube.com/channel/UC5AL-ZgOqSim_1gYNnndyzQ iseg on YOUTUBE
| Tutorials and more ...
https://www.twitter.com/iseg_hv iseg on TWITTER | please follow!
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf iseg
CATALOG | download product catalog as PDF
http://download.iseg-hv.com/ iseg DOWNLOADS | manuals, software,
firmware and more...

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren
Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht
gestattet.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient
(or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.

[André Hartmann]

Post by Oswald Buddenhagen

Is there a strong reason to keep the process in its current,
parallelized state?

yes. for example, a conscientious committer will want to revise the file
list when during writing the commit message they notice that the commit
is non-atomic. happens to me all the time.

Me too.

Post by Oswald Buddenhagen
fwiw, qtc is imo still inferior to git gui regarding fine-grained
commits - the diff view and chunk-level staging are kinda hidden,

But once you know it is there, it's no problem. There is also
https://bugreports.qt.io/browse/QTCREATORBUG-18482 as suggestion to
improve this.

Post by Oswald Buddenhagen
and line-wise staging apparently isn't there at all.

Line-wise staging is in my pipeline:
https://codereview.qt-project.org/#/c/213165

Regards,
André

Post by Oswald Buddenhagen
in fact, the selective staging context menu is outright broken in 4.5 -
there is no indication which actions make sense, and there are
duplicated actions.
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Konstantin Tokarev]

Post by Oswald Buddenhagen

Is there a strong reason to keep the process in its current,
parallelized state?

yes. for example, a conscientious committer will want to revise the file
list when during writing the commit message they notice that the commit
is non-atomic. happens to me all the time.
fwiw, qtc is imo still inferior to git gui regarding fine-grained
commits - the diff view and chunk-level staging are kinda hidden, and
line-wise staging apparently isn't there at all.

FWIW, one can just press Ctrl-K and type "! git gui" to get it

Post by Oswald Buddenhagen
in fact, the selective staging context menu is outright broken in 4.5 -
there is no indication which actions make sense, and there are
duplicated actions.
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator