Has there been any talk about adding a stub for git subtrees in .git/config?

The primary benefits would be:

1. Determine what sub directories of the project were at one time
pulled from another repo (where from and which commit id), without
having to attempt to infer this by scanning the log.
2. Simplify command syntax by providing a predictable default (ie.
last pulled from, last pushed to), and not requiring the repo argument
optional.
3. Improvement for default commit id to start split operations over
using --rejoin which creates blank log entries just so the log scan
can find it (afaict). It's a default either way, so it can still
always be explicitly specified.

If this information were available in the config, I think additional
features could be added as well:

- The command 'git subtree pull' for instance could be made to pull
*all* subtrees, similar to the way 'git submodule update' works.
- An option -i (interactive), or -p (prompt), etc. could be added that
confirms the defaults read from the config before actually executing
the command with implicit arguments, and the ability to modify the
arguments before the command actually executes.
- If the current working directory from which the command is run
happens to be a subtree specified in the config, the --prefix could
even be implied.


None of these ideas would break the way the command currently works
since it can still always take explicit arguments. There's a comment
in the documentation about the command that says:

> Unlike submodules, subtrees do not need any special constructions (like 
> .gitmodule files or gitlinks) be present in your repository

It would still be true that subtrees do not *need* any special config
settings, but that doesn't mean they are bad, and by having them the
command could be improved and made easier to use.

I'm happy to contribute the changes myself if this proposal is acceptable.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to