The pijul git command help says

Imports a git repository into pijul

but really it adds a pijul repository to the git folder. Since there are side effects of the current way, I think it’s a bug, not to mention very unintuitive and limiting.

I don’t expect pijul git to be the default usage. I expect pijul git /path/to/mygitrepo to be the default, and that the external git repo is imported by recording the commits into the current pijul repo.

The git command gives an error when using a relative path for the repository.

pijul git ../mygitrepo

outputs: Error: failed to resolve path '': No such file or directory; class=Os (2); code=NotFound (-3)

but it does work with pijul git mygitrepo.

To see what happens, I tried importing this repo that has 1477 commits:

git clone https://github.com/mavoweb/mavo.git
cp -r mavo mavosave
pijul git mavo

During the import, the files in the git folder were constantly changing, so this command could not be done while compiling (or other simultaneous use).

After 8 minutes, it finished, and I used Meld to compare mavo and mavosave. There were differences in .git/index, .git/logs/HEAD, and .git/logs.refs/heads/master showing the reset from 1477 commits.

If there aren’t read-only git commands to get the needed information, the folder should be copied to a temp location to be manipulated, with the results put into the original working directory.

Observations:

1. the initial commit in mavo adds files inside directories. So, this repo likely suffers from #670
2. The intent of pijul git is not to use it as a git repository any longer. It is a conversion tool and “conversion” implies that it is a destructive process. I mean, sitting in a convertible car and closing the deck also does not leave you with both a cabriolet and a sedan. Maybe this intent should be described more clearly, but I don’t think it is a priority to make pijul git work non-destructively. You cannot reliably use both git and pijul on the same repository anyways. So, just make a copy of your local git repository and convert it.

The intent of pijul git is not to use it as a git repository any longer. It is a conversion tool and “conversion” implies that it is a destructive process.

Where is a user supposed to get that notion? The help for the git command only says

Imports a git repository into pijul

When I read that, I think that the current pijul repo is getting files from the external git repo. I’m referring to pijul git /mygitrepo, which should be modifying the current folder with the contents of the external repo. The pijul commands (like most commands) typically work on the current folder, and especially with a command that imports, the default assumption is the external would be brought into the current since that’s what import means.

How exactly would you phrase the help message for pijul git given the current state of the tool:

1. It is a conversion tool that may destroy your git repository
2. It is meant to be run on a particular git repository. Without any arguments it is the repository you are currently in. With an argument, pjiul git /myrepo is equivalent to cd /myrepo; pijul git. This implies that it does not particularly care about your current directory apart from assuming that it is the default git repository to convert.
3. There is certainly no remote data transfer or local copying happening.

I wouldn’t change the help; I would change the command to work like other commands.

A recent change was made to facilitate sub-repos. How would a user make a sub-repo in an existing pijul repo if the command goes off and changes the external folder instead of the current folder?

This is (likely) not actionable. So, what you can do now is improve the help of this command to match its current state. Later, the command can of course change.

“not actionable” is not the right label. I think the beta time frame is for making the tool behave the way it “should” or “is generally expected”. Changing the behavior after release would be a major version number change in semvar. The label you seem to want is “frivolous”, but believe me when I say it is totally not cool to change the external folder.

I am not arguing with you whether the tool should work differently or not. I even think that your idea is perfectly reasonable and in no way frivolous. What I try to bring across, is twofold:

1. What you want is likely not actionable, because (at least to me) it does not seem to be important right now. The tool works as advertised. So, there is no bug (as in unintentional behaviour) to be fixed. There is a new tool to be written that does a (similar but) different thing.
2. What will likely happen to this particular discussion (because of 1.), is, it will be pushed down the stack, because it will not be addressed right now. This increases its chanced to be forgotten. So, my intent to salvage this discussion, was to steer it, so that it is actionable. Changing the help messages to make it obvious what to expect from the tool, as it is right now, could be a first step towards a better user experience and does not impede your original goal to lobby for a different tool altogether.

In summary, if you can contribute to a better pijul git that works the way you think it should, please go ahead! If you cannot, I was suggesting to concentrate on what can be contributed right now, which would be a better user experience while we wait for somebody that is able to write a better pijul git.

I concur with @joyously that “import” creates the expectation that the action is done non-destructively. Most programs that have an “import” option are importing a file in a “foreign” format into the native one, but crucially, they leave the original file intact.

I think this is especially important with a top-level sub-command like pijul git, where a user might run pijul git simply to see what the “git options” are. A sub-sub-command like pijul git convert-to-pijul (leaving space for a future pijul git convert-to-git or similar option) may be more clear.

If a help-text wording change is really all that is possible, I suggest replacing import a git repository into pijul with something like convert a git repository to pijul. WARNING: This will (may?) render your repository unreadable by git. Many people’s first experience with pijul will be trying it on a git repository, so it seems to be important to not destroy their (local) data and give them a bad impression.

I agree that the current import algorithm is a bit fragile. There are times (not sure when) where it can’t restart after being stopped.

One thing that would be much better than using git reset all the time would be an implementation of libpijul::working_copy::WorkingCopy that would directly read Git’s files. I’m not certain this is doable with libgit2, but it might.

In any case, that would be a very cool mission, and I’m happy to help.

Ill just add my voice here, its weird that this import modifies things in the original folder. I was expecting a pijul project in the new folder I was in, that would as closely as pijul would let me mirror the git project. So that I could evaluate if the issue I just had in the git project would have been easier in pijul.

IF it is supposed to be destructive, rename it into pijul convert-git or something, I bet the first feature request would still be for something like pijul import-git.

the amount of times one is expected to run the commands should be inversely related to the verbosity of the command, most people I work with have git p, git st, git c

Hi there,

Just been bitten by this as well (https://discourse.pijul.org/t/solved-pijul-git-screwed-my-git-repo/970). I understand that the intent is to not use the git repo anymore, but modifying the original without any warning is not a good idea and doesn’t left a good feeling after using it.

Does this command use Git’s fast-export ?

@joyously: you already asked that question, and I already answered:

https://pijul.zulipchat.com/#narrow/stream/270693-general/topic/Changes.20in.20Git.20import/near/305087901

Git fast-export is only intended to copy a Git repo to another medium.