On Fri, Nov 20, 2020 at 12:59 PM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > > On Fri, Nov 20 2020, Orgad Shaneh wrote: > > > Can you suggest an alternative way to determine if I can accept user > > input from the console or not? > > Like Eric noted in his reply I can't think of a way to do that > particular thing reliably either, and agree with his comments that if > such a way is found / some aspect of this change is kept having this > explanation in the patch/commit message is really helpful. I'll reword. > I think what you're trying to do here isn't a good fit for most git > workflows. Instead of trying to interactively compose a commit message > why not change the commit template to start with e.g.: > > # You must replace XXX with an issue number here!: > Issue #XXX: > > That gives the user the same thing to fill out, but in their editor > instead of via some terminal/GUI prompt. They need to write the rest of > the commit message anyway in the editor, so even if you could why open > up two UIs? We do have a template. The hook pops a listbox with all the open issues assigned to the user, which he/she can easily pick from, instead of searching for them in the browser and copying the issue id. This is only done if the user doesn't write an issue in the commit message. > Projects that have these conventions also typically settle on just not > trying to solve this problem on the client-side, but e.g. having a > pre-receive hook that does the validation, or do it via CI / before a > merge to master happens etc. We have validation on the server too. The hook is there for convenience. - Orgad
