Documentation questions

[eric-s-raymond]

1. It looks like gitcc rebase is the functional equivalent of git pull --rebase on a git repo. Is this correct?

2. The "synchronise just a portion of your git history" procedure is really confusing. Why use the keyword :"tag"? Is that command actually declaring a tag in any sense?

3. Is a config file required? If not, is the default to pull all content and branches and labels?

4. If no users module is specified, what is the CC username "foo" mapped to?

[charleso]

1. Yep. I regret not calling the command pull.
2. It's the implementation bleeding though. Git-cc uses two git tags to track the "state" of the sync, so this command literally just creates/or moves a tag.
3. Yes a config file is required. The "init" command creates one with the path to your mounted Clearcase directory, and I think the default branches filter list which starts as "main". They're the two critical bits of config. Just a heads up, git-cc doesn't sync labels in any way.
4. I can't quite remember but looking at the code I believe the git committer email would be "foo@" (which is invalid). I vaguely recall the user mapping file was required to at least provide the mail suffix to make legal email addresses.

Does that help?

[eric-s-raymond]

It does help, a lot. Would you take an MR updating your README to fold in some of this info?

1. What's stopping you from just renaming the rebase command? I would.

2. I hope the filter can be set to "all branches". I'm going to need that.

Here's my situation. I need a a cc-fast-export command that will ship a fast-import stream capturing an entire CC history to stdout, with branches and labels. I don't care about live-syncing. Your rebase command, the way it uses lsh, looks like a place to start.

I don't know how interested you are in this use case, so I don't know whether I should plan to up-gun your code (adding a fast-export command) or write my own tool. If I were to write my own it would probably be in Go - I like Python but dragging in all the dependencies that implies is unappealing.

Relevant fact: I maintain these...

http://www.catb.org/~esr/reposurgeon/

http://www.catb.org/esr/cvs-fast-export/

I may have figured out how to solve the deletions problem. My solution depends on two assumptions:

a. A directory's version gets bumped when - and only when - a file is added to or deleted from it.

b. It is possible to specify a directory and a revision number and get a list of the filenames it had at that revision.

Are these premises correct?

Do you have a sandbox machine you can give me ssh access to with CC on it?

[charleso]

It does help, a lot. Would you take an MR updating your README to fold in some of this info?

For sure.

1. What's stopping you from just renaming the rebase command? I would.

Only that I haven't used git-cc in 8 years and don't actively maintain it and only answer questions.

1. I hope the filter can be set to "all branches". I'm going to need that.

It can. I should warn you that lshistory doesn't return all the events you might want to construct a full history (see below). It's made all the more complicated by something called a config spec which is like a big query over the history and, from memory, would make it difficult to reconstruct history for all branches. My memory is extremely fuzzy on this though. I (and you I guess) would have to try it again to work out the constraints again to be sure.

I don't know how interested you are in this use case, so I don't know whether I should plan to up-gun your code (adding a fast-export command) or write my own tool. If I were to write my own it would probably be in Go - I like Python but dragging in all the dependencies that implies is unappealing.

I would _strongly_ recommend not using git-cc as a tool. It was written long ago, and not very well with no tests. I would not rely on it directly, only as a reference.

a. A directory's version gets bumped when - and only when - a file is added to or deleted from it. b. It is possible to specify a directory and a revision number and get a list of the filenames it had at that revision. Are these premises correct?

They are, and in facts that's exactly what I currently do. But the problem you run in to is not the deletion event, it's that lshistory, at least how I was using it, doesn't return file events for the file after the delete happens. So you're unable to get a true/full history from scratch. It was actually worse for renames without changes because you don't get the events for the previous version of the file. You can see what file was added but from memory you don't know what version it was at that directory revision. I figured out a work around but I can't remember what it was. Not sure if that makes sense? Or even if that's a concern for you .

Do you have a sandbox machine you can give me ssh access to with CC on it?

I'm afraid I do not. I only ever used the version at a previous employer, and wouldn't even know where to begin on getting or setting up access. I'm sorry I can't help you much more than that.

[charleso]

If you do get access to a Clearcase instance I would just double check if "lshistory -all" returns data for deleted files. That would improve the import quality if it does. I'm sorry I can't confirm that myself. :(

[eric-s-raymond]

OK, it's write my own then.

lshistory not returning events for the file after the delete happens...presumably it starts doing so again if the file is recreated? I will bear it in mind to try lshistory --all.

[charleso]

Good luck! Do let me know if you get anywhere as I feel bad for people who start using git-cc but hit all of the rough edges.

…

On Sun, 23 Feb 2020, 10:44 am Eric S. Raymond, ***@***.***> wrote: OK, it's write my own then. lshistory not returning events for the file after the delete happens...presumably it starts doing so again if the file is recreated? I wuill bear it in mind to try lshistory --all. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#97?email_source=notifications&email_token=AAAHSU6OJIX4L5NQLEJCQ6LREHBIJA5CNFSM4KZSOC4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMVOKDY#issuecomment-590013711>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAHSU7X56N75JM5TDYXZYTREHBIJANCNFSM4KZSOC4A> .