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" <[email protected] <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 following: $ 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 'db6bc6b'. (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 function. > 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 tool. 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? -- Darragh -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
