On Tue, 20 Sep 2016 10:14:30 -0700 (PDT)
Darragh Bailey <daragh.bai...@gmail.com> wrote:

> I've been working on a workflow tool to help with automating syncing
> with upstream open source projects (mainly openstack), where it
> allows for the patch queue to be automatically pruned of anything
> that landed upstream (even when it no longer matches on patch-id as
> each patch contains a Change-Id in the commit message), see 
> https://pypi.python.org/pypi/git-upstream.
> 
> One of things that has bugged me for a while is that it makes use of 
> git-rebase to not only since it is doing something similar but also
> because all the other git tools are aware of when the repository is
> in the middle of a rebase. This has the nice effect of if using the
> tool manually, you switch away and come back, and have forgotten that
> it was stopped in the middle of the patch series, most git commands
> will point out that it's unsafe to perform certain actions until
> completing the rebase or aborting. Which means that you get a warning
> about it being in an unclean state.
> 
> It would be really useful if it was possible to use a standard
> mechanism to identify that the repo is in an unclean state instead of
> needing to hijack git-rebase and rely on the various other tools
> having been scripted to be aware of when it's in the middle of
> applying patches, to point users at the workflow scripts to
> continue/abort.
> 
> Anything kind of workflow hook point like that exist? Or is being 
> considered for the future?

It's not clean what exactly you're after.

My take: you want a way to explicitly mark a Git repo as being in some
certain state (let's call it "unclean") and somehow make all the stock
Git tools be automagically aware of it so that they fail whatever their
task and warn you about that state.  Am I correct?

If yes, I, for one, is not aware of anything like this (at least, I see
no hook supported by Git which would resemble something like this).

But it may appear that you're fixated on pushing this _into_ Git for no
good reason: since you appear to use Git in an unusual way anyway
(somehow I've got a feeling that you intend to use it in an automated
way) merely have a wrapper which would eventually "forward" a call to
Git but first do the necessary checks.

I mean, have a script named, say, "git-foo" which would perform the
necessary actions and they either fail or call "git" with the arguments
supplied.  "The state" would just be a custom file under ".git".

Another approach (though it smells IMO) would be overriding the `git`
command in the shell: just stick something like this in
~/.whatevershellrc:

  git() {
    # Do checks, fail if needed
    builtin git "$@"
  }

and now when you execute git commands in your "whatevershell",
your function will get called.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to