Want: a version of python (wrapper?) that runs code from git, not from work tree

Python Help
1

we have a problem: we always forget to git commit until we’re far too deep into a change and then we wish we could go back and look at history because something we did earlier would’ve been helpful now.

we thought: if we can’t run from work tree, then we have to commit.

this would force us to write history. this would then let us look back on history and apply the things we learned to the work we’re currently doing. and once we’re done, we can clean it up a little with a rebase.

so we want a python fork that ignores the work tree altogether.

is it uh, possible to do this? has anyone done this before?

this is a very personal problem so we don’t expect this to be useful to anyone else but we may as well put it out here.

2

Running from Git commits in the work history. Hmm. What’s storing the work history, if it’s not being committed?

Maybe this is a PEBKAS that new software is not the best solution for.

3

Doesn’t git stash solve this particular problem?

4

I think you could write a gitimport hook, similar to zipimport.

Even if you do, though, you’ll need to modify how you invoke Python to make sure that you’re importing from project/.git instead of project/. I suspect it’s more work than it’s worth.

1 Like
5

as in git stash && python?

… sure, that could work. not the most elegant, but…

6

Sounds like what you want is a pseudo-filesystem that, instead of reading from the current directory, fetches files by running git cat-file -p HEAD:some_file_name - that’ll give you the content of the file (on stdout) as of the latest commit, ignoring any changes.

But I would be inclined to do this at the filesystem level, not the Python level - in case there are non-Python files you load this way too. And if you’re going to do that, the easiest way would probably be to have a separate clone of the same repo. Then have a script that pulls changes (maybe from local filesystem, not upstream, so you still get unpushed commits) and runs from there.

So here’s my thought:

  1. Clone your repository locally, into another directory. For example: cd ..; git clone project project_committed This will get you a clone that reuses, as much as possible, existing objects. It’s a fast clone.
  2. Whenever you want to test, use (cd ../project_committed; git pull; python ...) to run it, preferably as a script.
  3. Any time you change branches, you’ll need to update the ‘committed’ version too.

In theory, you could do all this within the local tree, but in practice, I think it’s easier to have the clone.

2 Likes
7

A slightly better approach would be to use git worktree, which lets you have an additional set of checked out files.