#19 rebasing a repository (squashing some commits)

Hi,

sometimes I like to perform git rebase (normally no more than squashing several commits), so that the history becomes easier to grab when I run git log.

But it does not seem so straightforward in Gin.

1. Is it in any way possible? If so, can you provide me with any pointer where I can learn about it?
2. Is it a design decision that you cannot git rebase easily on Gin?

I think I understand that it would be a reasonable design, too, not to be able to run git rebase for a repository of research data. But I would be as happy if a Gin repository can be more manageable.

Hello,

To clarify, are you asking whether you can do a rebase/squash using the GIN command line client? If that's the case, there's no command for this in the client. You could do the rebase using git rebase and force push, as you would with any other git repository. After that, it might be a good idea to do a gin sync or gin upload to make sure the annex branches are updated accordingly.

Sorry if I misunderstood your question. If you mean something else, please clarify.

Thanks.

Thanks Achilleas,

that is the information what I wanted. I may have forgotten to force push the other time. I will try.

thanks again!

So I managed to rebase the repository, and the annex branches synced properly. still I don't like the way the annex branches merges the git repository.

Isn't it possible to rebase/reorganize the annex branches alongside the git master branch?

Cheers

Git annex does a lot of things on those branches that I'm not entirely familiar with (and I'm not sure they're well documented). It's understandable that you might want to clean up. There's a discussion about this topic on the git-annex website if you'd like to investigate: http://git-annex.branchable.com/forum/safely_dropping_git-annex_history/.

The safest strategy would be to make a copy of the entire repository (to experiment on), squash the branches and run git annex fsck. If there are any issues, they should appear (and likely be repaired) by the fsck command. If all your large-files are accessible, it should all be good.

If the .git directory is still very large from the multiple old copies of the annexed files, it can be cleaned up using git annex unused (walkthrough here). This scans for leftover files that are no longer accessible by any commits in the history. A subsequent git annex dropunused will prompt you to delete these.

I intend to add the (drop)unused functionality to the gin client, but that's still in development.