Hi Philip, Konstantin,

Apologies for being slow getting back after you're quick replies, was away 
for a few days shortly after I set the email.

On Tuesday, September 20, 2016 at 8:34:14 PM UTC+1, Philip Oakley wrote:
> From: "Konstantin Khomoutov" <flat...@users.sourceforge.net <javascript:>> 
> > On Tue, 20 Sep 2016 10:14:30 -0700 (PDT) 
> <snipped>
> > 
> > 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?

Indeed that might help.

If you perform a rebase using `git rebase -i HEAD~4` and mark the second 
patch with 'edit', then running `git status` will show something like the 

$ git status
interactive rebase in progress; onto db6bc6b
Last command done (1 command done):
   edit 721730e Ensure correct mode of git-rebase executed
Next command to do (1 remaining command):
   pick 73e2ef8 Always have rebase perform finish
  (use "git rebase --edit-todo" to view and edit)
You are currently editing a commit while rebasing branch 'test' on 
  (use "git commit --amend" to amend the current commit)
  (use "git rebase --continue" once you are satisfied with your changes)

If you're performing multiple cherry-picks `git cherry-pick -e <sha1> 
<sha1>`, cherry-pick will stop to allow you to edit each commit and running 
`git status` will show something like the following:

$ git status
On branch test
You are currently cherry-picking commit 3b5e241.

In both cases `git status` is aware of what tool is involved, and the same 
is also true with merge (with some fudging).

For example running `git merge --no-commit -s ours fixups`, followed by 
`git status` displays:

$ git status
On branch test
All conflicts fixed but you are still merging.
  (use "git commit" to conclude merge)

I had originally thought that the other commands merge/rebase/cherry-pick 
checked the tree state before continuing, but I'm not sure. Having a quick 
root through the code for wt-status.c suggests that it's explicitly 
hardcoded to lookup certain refs and tree state for specific subcommands 
rather than having a pluggable interface that external tools could use to 
describe state to it as well. 'wt_longstatus_print_state' looks to be the 

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

That's pretty much it.

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

Agreed doing something unusual and yet I don't think it's unreasonable to 
have a standard way for users that leave their repo in an interim state and 
come back to it, to be easily able to know what state it is in by running 
'git status' instead of needing to remember to run a custom 'status' tool. 
Or should they forget and go to run 'git merge <blah>' for it to be 
possible to have git determine the tree is 

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

Definitely want to avoid that ... ;-)

> > 
> -- 
> Philip

Hope this makes my question more clear, the first part is answered 
automatically in that there is no mechanism for an external tool to tell 
`git status` anything about custom state, but would have to either hijack 
known refs or rely on having users call a custom script from the workflow 

Guess it's just the second part left, is this something that might be 
considered useful? Or am I a complete outlier with regards to workflow 
tooling in this case?


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