GSoC with git, week 2

Le dans «GSoC 2018» par Alban
Mots-clés: ,

So, this week was pretty calm.

Early this week, we talked a bit about git-rebase and how it can be improved with Christian Couder and Pratik Karki on IRC1. We exchanged articles and opinions about git-rebase.

We talked a bit about rebase with history and git-imerge, as described by Michael Haggerty on his blog. His articles are really interesting (if you have not read them, do it now!) and talk clearly about the current shortcomings of the current rebase implementation, but it’s also clearly out of scope of Pratik’s and my project.

Pratik also shared an article explaining why git-rebase should never be used.

Never say never

I’ve read such articles in the past, and I’m sure you have already, too, whether they talk about ORMs, goto, operating systems, the list goes on.

I don’t really like this kind of articles. Sometimes, they hit the nail on the head (or at least raise problems), but sometimes, the author is projecting their use cases and workflow onto you, making their arguments moot.

The latter applies for this article. Depending on your workflow, you don’t necessarily have access to the upstream repository, and so to the final history. For instance, if you’re working on a free software project where patches must be sent to a mailing list (like git), rebasing changes instead of merging them remove the noise caused by merge commits, and allows you to have a clear view of the changes you’re currently making. When your patches will be merged, the history of your changes will be linear, no matter how many times you synced up with upstream. And as Christian pointed out, there actually is a way to check if every rebased commit is correct without doing it manually: --exec.

So yeah, whether you should use git-rebase or not really depends on your use case and your workflow. If you want a good starting point, this article from Atlassian is much more insightful.

Back to GSoC

But aside from ranting, I began to seriously dive into git-rebase’s code, and planning to move -p to its own script next week, when the exciting part begins :).

[1]#git-devel on