murphymc / depz Goto Github PK

@AbePralle has a gist which shows some unhelpful messages.

These all revolve around a case where the repo's checkout is a specific commit.

• For example on line line 14/16, it looks like the advice here is slightly wrong. It suggests checking out the commit directly, but depz should have created a branch for that commit. I think you should probably check that out.
• Bonus: We should probably have a sanity check where if the current branch is checkout_<hash>, the HEAD should actually be the given hash!
• On line 34/39, it's doing do_show_outdated and complains that it can't tell. There's a special case if the checkout is a tag, since a tag can't be outdated. I think we should attempt to apply similar logic when the checkout is a specific commit. If there are monitored branches, we should check them, but if there aren't, we should just assume things are okay (as long as the checkout commit is in the ancestors of HEAD).
• On line 35/40... this one is debatable. The warning might be fine, and the repo should just be configured with fast_forward_skip. I think that's probably best. (One could argue that if the checkout is a hash, we should just skip it, but for a couple reasons, I don't like this as well.)

Sometimes a repo might have a remote like blahblah/foo.git, e.g. because it was cloned by hand (not using depz). Depz may be looking for blahblah/foo and complain that the repo looks unrelated. We know better, but it doesn't.

The .git vs. no-.git ambiguity isn't our fault and I am not sure is good for anything, but there it is.

Offhand, I don't imagine there are many situations in which ignoring .git suffixes when comparing would cause problems. It seems like it'd mostly just be a problem if there were different repositories, one which ended with .git and one which didn't? Or if a server at one point allowed dropping .git but then started requiring it? Both of these seem kind of unlikely. And ignoring the suffixes would make this somewhat mysterious error disappear.

The other thing we could do would be to not allow it, but detect it and specifically log a message about how it's weird and tell you to fix your remote to match.

Related question: Should the default constructed remote string tag on a ".git"?

@AbePralle

In lots of cases, it'd be useful to do something like --update --outdated. Maybe even with --ff? It'd be nice if there were a really easy way to get this behavior.

Currently a repo's default_actions setting uses a simple search in a string split to check for individual actions.

def _is_default_action (option,rr):
  if not "default_actions" in rr.dict: return False
  return option in rr.default_actions.split()

This currently works because the useful per-repo commands of --init, --set-ssh-cmd, --update, --outdated, and --fast-forward do not accept arguments. However the parsing of default_actions should probably be made more robust in the future to allow options with arguments.

The default Python logging is has never been very pretty. In particular, it's annoying that due to the log level text, the messages aren't aligned. If you have coloredlogs installed, this is fixed, but we should fix the default log format string to fix it in case you don't.

This command would attempt to ensure that the checkout branch is, in fact, the current branch in the repo.

• I think it probably only applies to real repos (not archives)?
• I think it should give a warning on failure (e.g., can't switch because it would overwrite files or there are modifications which aren't committed), not an error, but I'm not sure about that...

I'm not positive if this makes sense, but I think it might be reasonable to log the set of repos that have encountered errors at the very end of a run. At debug level if nothing else! But probably something higher.

IIRC, there's currently no support for git submodules. It'd be great if there was a config key that let you mark that it should automatically sync any submodules, though.

Right now, you have to understand some of the git messages (i.e., for --outdated). Human readable ones might be nice. From @AbePralle:

WARNING: it appears the repository XYZ is in a conflicted state with its origin. If the repo has local changes, manually merge or otherwise synchronize it. If it doesn't have local changes, delete it and run 'depz --init' to restore it.

STR:

• depz --init an existing repo.
• cd repo && git checkout HEAD^ && cd ..
• depz --outdated will crash.

LOG:

DEBUG:depz:Adding . (1 file(s))
DEBUG:depz:Running function early_sanity_check
DEBUG:depz:Running function sanity_check
DEBUG:depz:Running function show_outdated
ERROR:depz:While processing Plasmacore:
Traceback (most recent call last):
  File "/Users/abe/Library/Python/3.7/lib/python/site-packages/depz/depz.py", line 872, in for_each_func
    f(rname,rr, **kw)
  File "/Users/abe/Library/Python/3.7/lib/python/site-packages/depz/depz.py", line 1245, in do_show_outdated
    compares = [r+"/"+current_branch for r in remotes]
  File "/Users/abe/Library/Python/3.7/lib/python/site-packages/depz/depz.py", line 1245, in <listcomp>
    compares = [r+"/"+current_branch for r in remotes]
TypeError: can only concatenate str (not "NoneType") to str

Feature proposal.

Right now, running depz by itself doesn't do anything. It'd be nice to be able to override this behavior with custom behaviors. For example, including a key like the following into a repo:

default_actions=--update --ff --outdated

Then just running depz would automatically try to do the above.

This would be helpful for addressing more straightforward use cases than I've had with depz so far where you'd like to have a single command "just do useful things for me" option and such a thing exists in your scenario (e.g., you are not expecting local modifications).

@AbePralle I think this would be useful to you.