From: "Konstantin Khomoutov" <flatw...@users.sourceforge.net>
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.

I think Darragh is looking for the mechanism that the other commands use to determine if a rebase is in progress, which I think is that certain of the special refs and special files for the rebase are present in their known locations (and are cleared upon completion), though it would require a bit of digging to see exactly which ones are used e.g. maybe the 'todo' insn sheet.

If Darragh could say which are the commands that best detect the REBASE state, that it should be too hard to point him at the code that does the checking.

Darragh?


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.

--
Philip
--
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