Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add stage_fixed flag for hooks #109

Closed

Conversation

rbUUbr
Copy link
Contributor

@rbUUbr rbUUbr commented Feb 2, 2020

Hey, I like to do contributions in this repo, It helped me to practice a lot about Go with it. Thanks! So, I made this feature, it should work on Windows platform(I hope so, I don't have possibility to figure it out). Also, I've added processError function to output all errors and set pipe as broken but didn't make any refactoring, I hope it will be useful in the future.

@rbUUbr rbUUbr requested a review from Arkweid February 3, 2020 09:23
@Arkweid
Copy link
Collaborator

Arkweid commented Feb 3, 2020

Could you explain about a little more? What problem does this PR solve?

@rbUUbr
Copy link
Contributor Author

rbUUbr commented Feb 3, 2020

sorry, I haven't provided issue :) It's closes #64

@Arkweid
Copy link
Collaborator

Arkweid commented Feb 3, 2020

Awesome! I will check it soon.

// io.Copy(os.Stdout, ptyOut) // win specific
if command.Wait() == nil {
okList = append(okList, commandName)
context.ExecGitCommand(fmt.Sprintf("git add %v", strings.Replace(string(fileNames), "\r\n", " ", -1)))

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like output logging is inconsistent with bash command.

@lionskape
Copy link

lionskape commented Feb 17, 2020

Can you describe what is the difference between your approach and "git add {staged_files}", please?

How do you achieve the passing of partially staged content to the linter-formatter, and how do you grab the result of it?
How do you solve the merging problem for applying unstaged changes to the working tree?

I can explain some important cases for "stage_fixed" feature, as I understood it:

  1. formatter can reorder lines, for example - key order, import order
  2. formatter can split line (for example to solve "too long line" rule)
  3. one line can be both reordered and split while the formatting process.
  4. after the hook - you have to get a working tree with unstaged changes and fixes, but with committed fixes.

@rbUUbr
Copy link
Contributor Author

rbUUbr commented Feb 22, 2020

Can you describe what is the difference between your approach and "git add {staged_files}", please?

How do you achieve the passing of partially staged content to the linter-formatter, and how do you grab the result of it?
How do you solve the merging problem for applying unstaged changes to the working tree?

I can explain some important cases for "stage_fixed" feature, as I understood it:

  1. formatter can reorder lines, for example - key order, import order
  2. formatter can split line (for example to solve "too long line" rule)
  3. one line can be both reordered and split while the formatting process.
  4. after the hook - you have to get a working tree with unstaged changes and fixes, but with committed fixes.

hey there, thanks for your review. There is no diff between this approach and git add {files}. Only one key difference: this feature automize staging of fixed files, that helps you to not write bash script with xargs for it. Also, this feature does not passes parts of files, because it can be the reason of chaos :)

@rbUUbr
Copy link
Contributor Author

rbUUbr commented Mar 16, 2020

@Arkweid any updates?

@Arkweid
Copy link
Collaborator

Arkweid commented Mar 17, 2020

Going to merge it at weekend. Sorry for so long!

@Arkweid
Copy link
Collaborator

Arkweid commented Mar 22, 2020

@rbUUbr Again sorry for so long. I have tested it on discourse example:
https://github.com/discourse/discourse/blob/master/lefthook.yml
And everything goes down:

$ git commit -m "test"
Lefthook v0.7.0
RUNNING HOOKS GROUP: pre-commit

  EXECUTE > eslint-assets
read /dev/ptmx: input/output error

  EXECUTE > eslint-plugins-assets
read /dev/ptmx: input/output error

  EXECUTE > eslint-plugins-test
read /dev/ptmx: input/output error

  EXECUTE > prettier
read /dev/ptmx: input/output error

  EXECUTE > eslint-assets-tests
read /dev/ptmx: input/output error

  EXECUTE > eslint-test
read /dev/ptmx: input/output error

SUMMARY: (done in 10.00 seconds)
🥊  eslint-assets
🥊  eslint-plugins-assets
🥊  eslint-plugins-test
🥊  prettier
🥊  eslint-assets-tests
🥊  eslint-test

Could you recheck it?

@rbUUbr
Copy link
Contributor Author

rbUUbr commented Mar 23, 2020

O_o will recheck it, thanks!

@rbUUbr
Copy link
Contributor Author

rbUUbr commented Apr 12, 2020

Hi, sorry for long response time :( @Arkweid I can't reproduce it, but I found this issue creack/pty#21
I can't reproduce it on my version of left hook with next config:

pre-commit:
  parallel: true
  commands:
    govet:
      tags: backend style
      run: go vet ./...
      stage_fixed: true
    golint:
      tags: backend style
      run: golint ./...
      stage_fixed: true
    gofmt:
      tags: backend style
      run: go fmt ./...
      stage_fixed: true
    terraformfmt:
      tags: backend style
      glob: '**/*.tf'
      run: terraform fmt
      stage_fixed: true
pre-push:
  parallel: true
  scripts:
    "coverage.sh":
      runner: bash

@shin-sforzando
Copy link

shin-sforzando commented Mar 3, 2022

I came across this PR because I was wondering how to include the results of automated documentation generation tools (like sphinx) and automated tests (like Coverage.py) in pre-commit.
There are times when newly generated files have not been staged in the past, but they are obviously harmless and we want to add them to the stage immediately.
In this case, I can't do git add {staged_files}, so I write the following every time.

pre-commit:
  commands:
    format:
      glob: "*.py"
      run: black {staged_files}
    test:
      glob: "*.py"
      run: pytest {files} && git add {files}
    doc:
      run: sphinx-build -a docs docs/_build/ && git add {files}

A little messy looking with && git add {files} all over the place.
And this way, files that may not be harmless, generated by other commands, will be mixed into the stage.
So I want to add only the results generated by each command to the stage.

I would be very happy if you could tell me how you all do it so well.

@elliotwestlake
Copy link

@Arkweid Is there any update on this? Would be good to get this merged in. Thanks!

@elliotwestlake
Copy link

@mrexox Maybe you'll be able to help out?

@mrexox
Copy link
Member

mrexox commented Aug 15, 2022

This feature is a good idea, but I see some nuances:

Imagine we have staged a file partially:

$ git status
AM file1
A  file2
A  file3

If we just git add it, we would commit changes that weren't expected to be committed. Anyway, I like the idea of auto-stage files that were changed during the lefthook execution, but I want to add an extra step:

  1. Hide changes that weren't staged before running lefthook (e.g. in stash).
  2. Run lefthook command.
  3. Some files changed? -> Stage those files. (q: should them be all files in a project or just those that were staged initially?)
  4. "Unhide" the unstaged changes.
  5. Proceed with git commit.

This feature is applicable only to pre-commit hook, isn't it? Do you agree that we should ignore it on other hooks?

@elliotwestlake
Copy link

This feature is a good idea, but I see some nuances:

Imagine we have staged a file partially:

$ git status
AM file1
A  file2
A  file3

If we just git add it, we would commit changes that weren't expected to be committed. Anyway, I like the idea of auto-stage files that were changed during the lefthook execution, but I want to add an extra step:

  1. Hide changes that weren't staged before running lefthook (e.g. in stash).
  2. Run lefthook command.
  3. Some files changed? -> Stage those files. (q: should them be all files in a project or just those that were staged initially?)
  4. "Unhide" the unstaged changes.
  5. Proceed with git commit.

This feature is applicable only to pre-commit hook, isn't it? Do you agree that we should ignore it on other hooks?

Agreed, all makes sense to me. Yes this should only exist on pre-commit

@rbUUbr are you happy to work on this? If not I'm happy to pick up.

@mrexox
Copy link
Member

mrexox commented Mar 15, 2023

Closing this in favor of #445. Please, feel free to open an issue if something doesn't work as expected.

@mrexox mrexox closed this Mar 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants