WIP: Adding support for 'git subtree'

[johnb003]

This adds a new dialog for subtree add, and a new context menu item to invoke it.

[johnb003]

I'm still working on the other subtree commands but this is a start. And getting feedback early would be helpful for the rest of the development.

Actually one minor thing I should do, I'm depending on the 'git subtree add' command which was contributed to git not that long ago, so it might be worth doing a version check.

Any advice on how to check if a particular feature is available?

[csware]

Generelly this looks ok. However, please try not to commit so many commented lines.

Regarding the version check, see here: https://github.com/TortoiseGit/TortoiseGit/blob/master/src/TortoiseProc/AppUtils.cpp#L85

[csware]

For now we'd leave this as work-in-progress and add comments from time to time. Right now, most comments would rely to coding-style.

[csware]

A general question: Are there any problems with TGitCache and git subtree?

[csware]

If you ask me, we should discuss coding style issues (and splitting/combining of commits) when this is feature complete.

[csware]

"Subtree push" should be "subtree split and push"?

[johnb003]

I can do a code cleanup pass any time.
Rebasing to squash and cleaning up the code is no problem. Many of the commented lines are just in anticipation of the upcoming features and will be removed as the new features come online.

I guess what I need to know is would you like to me clean up the current state of 'git subtree add' or wait until I've got support for subtree push/pull/merge/split or some subset in between?

IMO, I don't see much harm in introducing it in stages, but it's your call.

@csware: re: "A general question: Are there any problems with TGitCache and git subtree?"
How do I test that? I don't even know what TGitCache does honestly.

@csware: re: "For now we'd leave this as work-in-progress and add comments from time to time. Right now, most comments would rely to coding-style."
Do you have coding style concerns other than a few spaces that crept in or some WIP commented lines? These will be no problem to clean up, but if there's some other issues, in general I tried to follow the conventions already there, but my style may have started creeping in. Just let me know and I'll fix it.

This is all sausage-making imo. If what you need are prettier sausages, that's not a problem ;)

[johnb003]

I squashed the latter 2 minor commits for now.

[csware]

@johnb003 Just keep going implementing the other stuff.

[johnb003]

Okay. I'll just keep updating this branch then with the features.

I think we should introduce subtree add, push, and pull first, and save merge and split for a second pass. They primary workflow only needs add, push and pull; split and merge are more useful as tools to handle splitting projects or doing things more manually step-by-step.

Lets use the issue tracking on my fork to comment on what you need fixed then?

[johnb003]

Adding support for push and pull went more smoothly than I expected, because the dialogs were so similar I was able to just to just reuse my dialog and apply minor tweaks for each of those commands.

The bulk of what I was planning to do for the first pass is now done.

Things I'd like to polish before it's merged:

1. git subtree from the command line is kind of annoying. You need to type in the --prefix folder you're running the command for (relative to the root) every time. I'm already at least making this part easier by defaulting the folder you right click on to launch the command. That said, I'd like to make it so that once you 'subtree add', a config is written somewhere that stores the repo and commit id last pulled in to said folder, and essentially serves as a record that it once came from a subtree. This way, I only show the push and pull options when the folder is seen as a subtree, and I can automatically populate the push/pull repos with solid guesses for the user. They can always use shift-click if they need to (like if the config isn't there but it is a subtree).
   • What config should I store the repo mapping and commit in? .git/config, or maybe a .gitsubtrees config, or what?
2. I'm using history controls but I don't think I'm properly writing or loading old values in all cases. I need to look into that.
3. What do I need to do to test TGitCache with subtrees?
4. Once we can sign off on the rest of it, I'll do a code cleanup.

[csware]

1. That's really a problem. I'd expected that there is some kind of config file in the .git folder stating that there is a subtree. Iirc we might have to search the log for "subtree-*" (however this also could cause false positives). Have you mailed to the git mailing list stressing this issue?
2. I don't see any problems with TGitCache. - If there were problems, then the overlay icons would be wrong or missing. Since a "subtree" is integrated into the working tree, it's not an issue.

[csware]

Please make sure the copyright lines are up2date.

[johnb003]

That's really a problem. I'd expected that there is some kind of config file in the .git folder stating that there is a subtree. Iirc we might have to search the log for "subtree-*" (however this also could cause false positives). Have you mailed to the git mailing list stressing this issue?

I haven't found a mailing list for subtree, but I emailed the original author who contributed it.

Currently, there is nothing written about the subtrees in any config files and it is a bit of a manual process for those using the feature on the command line.

The command is always executed by explicitly saying which folder you're working with '--prefix', and the repo / commit id you're working with. The command does search the history as you say for detecting when merges happened so it can pick the correct common ancestor in the split or merge commands. There's even a bit of a hack called --rejoin, which commits back to your branch when you push so it can base future splits from that point on. It's optional since you may actually want an older commit id in some circumstances (such as splitting to different repos).

This means, there's no way of doing an 'update all subtrees', because you won't know what's a subtree in the first place (without examining the history, which could be really slow).

My implementation so far just mimics what's provided, but I see the config as an obvious way to improve on it. My plan was to make the contribution to git subtree anyway so that it does write to .git/config, or .gitsubtrees but since it will be quite some time for users to get such a change, I will ALSO add support to tortoisegit to write to the config if the command doesn't do it already.

So, would you recommend .git/config, creating .gitsubtrees, or something like .tgitconfig?

I'd much rather do this than also try searching the history.

[johnb003]

Just for the sake of discussion, I'd say TortoiseGit provides a naturual workflow advantage over running things on the command-line. Even if you're an expert and know exactly what commands to run, the problem is with guessing data not specified. Typically if you don't give some parameter on the command line, it makes an assumption.

With the command line, what would you expect if you run 'git subtree pull' from the root? Maybe it should pull latest all subtrees that have been added, using the repo they were added with? What if you forgot you had two subtrees and meant for only one of them to pull?

Wouldn't it be nice if you could run the command and get a prompt about what it's about to do when you don't give it all the explicit details? And then assuming it confirms what you want to do, you just confirm and let it go, otherwise you make corrections. You could always have prompts like -y, to force it to make assumptions without asking you.

This could be done, but that's not how most of the git commands work.

However, that is exactly how TortoiseGit works. Using the config just allows us to cache the values that we can use to make best guesses to send to a command that requires a long list of explicit parameters. If those guesses are wrong users can always change them.

[johnb003]

I did some code cleanup, but amusingly I couldn't test it properly because I couldn't pull down the sub-modules. I'm behind a proxy here that doesn't work over http/https, so I have to use ssh.

If I really wanted to, I'd have to look up how to access each submodule with ssh if even possible and setup a bunch of public keys.

I can't wait for the day that subtrees replace submodules completely.

[csware]

I don't think that subtree will replace submodules, that have a different use cases,

[johnb003]

sure, you say that now... ;)

On Thu, Mar 13, 2014 at 2:43 PM, csware [email protected] wrote:

I don't think that subtree will replace submodules, that have a different
use cases,

Reply to this email directly or view it on GitHubhttps://github.com//pull/77#issuecomment-37590588
.

[johnb003]

Are there any differences in tgit from the normal git repo? I've been mailing a bit on the git mailing list, and on IRC, but there hasn't been much activity. I'm probably going to use the config api that's there. It seems like the tgit config is a good example. Would you recommend anything else for examples of the config api? I guess I could look up the submodule command in the git repository.

Anyway, I think I'm just going to write the config from tortoisegit for now with which folders were pulled from subtree repros, and maybe the repo and commit id for the sake of providing good defaults when using the commands that can be distributed with the parent projects.

[csware]

Are there any differences in tgit from the normal git repo?

No.

I've been mailing a bit on the git mailing list

Can you provide a link here?

I'm probably going to use the config api that's there.

Good idea, please use the libgit2 api (example https://github.com/TortoiseGit/TortoiseGit/blob/master/src/TortoiseProc/ProjectProperties.cpp).

Anyway, I think I'm just going to write the config from tortoisegit for now with which folders were pulled from subtree repros

I suppose that's a straight forward solution, however, I don't really like to have any special handling compared to vanilla git.

[ttodua]

Has there been any update on this?

[johnb003]

No, I am no longer interested in finishing this project. Someone else will have to take ownership or start again to make it happen.

…

On Sun, Jan 2, 2022 at 11:37 AM T. Todua ***@***.***> wrote: Has there been any update on this? — Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABT4XLKRPLM2WW2HTTQ4VUDUUCSOVANCNFSM4ANDPXCA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>