In a bizarre twist, the -u option to git status must not have a space between it and its parameter. To actually work as expected, the first line of drush_dog_dl() should look like

  if (_dog_git_invoke('status -suno', DRUPAL_ROOT)) {

As it is, it's checking the status of the file "no", which in most cases won't exist. Git 1.7.1 at least returns nothing in this case, letting dog-dl continue.

Personally, I'd be in favor of removing the check entirely. I find myself wanting to use dog-dl on several projects in a row, and I'd rather make one commit to add them all than one for each.

Comments

ChrisBryant’s picture

ChrisBryant commented

I ran into this today as well. Git-status on older versions of Git (such as 1.5) doesn't include the sub options to the -u option so it doesn't work on older versions. Maybe 1.5 doesn't need to be supported but if it does, then the command needs to change to take into account that git status -su will still exit dog with return code 1 even when there are no unchanged files.

From the manual:

"If there is no path that is different between the index file and the current HEAD commit (i.e., there is nothing to commit by running git-commit), the command exits with non-zero status."

Seems like the check would need to be removed fully for older versions of Git.

Island Usurper’s picture

Island Usurper commented

From observing #git, I think the most common response to support requests involving Git 1.5 is, "You should update to something not ancient." It's possible that 1.6 will get this treatment soon, too. Mostly it stems from wanting to give instructions to use the more powerful or concise commands kind of like we're doing here.

Merely an observation. I don't have much opinion on what dog should do.

sdboyer’s picture

sdboyer commented
Status: Active » Fixed

Yeah, I've got no interest in supporting git 1.5. Really, I'd rather not even support 1.6. Atm there's a check in there which ensures at least 1.7, though I'd be open to relaxing that later. Problem is that there's a lot of feature backporting to older release branches, so it can be hard to peg a true "minimum" version.

As for the gist of the original issue, the initial plan is to have dog automatically commit, and possibly even auto-push, on a change that introduces a new submodule. The goal there is to minimize the likelihood of having a situation where someone makes change that affects the sled (e.g., installing a new module), someone else makes a conflicting change, and then dog has to resolve a meta-merge-conflict. It's just narshty. I already expect that we'll probably want to write a custom git merge driver for dog eventually, but I'd rather not have to do it right away. Without that safeguard, newbies could run into a situation that they don't understand and dog can't automatically resolve fairly easily - exactly what we'd like to avoid.

In the long run, I'd like to open it up a bit more and give a bit more freedom. And maybe we can do that from the start if there's some hidden option that's set (or maybe just a -f, --force). But to keep things sane, I want the initial version of dog should err more towards reliability than flexibility.

So, yeah. I've fixed it, actually by expanding it to the more readable long form --untracked-files=no.

Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.