Arc Forumnew | comments | leaders | submitlogin
Tracking patches
4 points by CatDancer 6089 days ago | 5 comments
OK, the problem I'm having with git is that it isn't tracking patches in the way I want it to.

What I want is to be looking at each bug fix or enhancement in isolation. Here is a proposed patch to fix mkdir. Do I want to use it? Well, the first thing I want to look at is the changes between arc2 and arc2 plus this proposed mkdir fix.

In the Ankari stable branch in git, for example, there may be two, or three, or eight commits related to getting mkdir to work. And in the meantime, other commits are being made for other fixes or enhancements. So there's no one place to go to to see what is the actual change being proposed for mkdir.

In many Linux distributions, a software package for that distribution starts with the original upstream source, and then a series of patches are applied for bug fixes or to get the program to work in the environment of that particular Linux distribution. (Eventually, hopefully, those patches will be merged upstream so that over time there will be fewer patches that need to be applied).

I want something similar, where I can easily pick and choose: OK, I want Eli Barzilay's MzScheme compatibility patch, Nathan's date patch, and my atomic patch... and, as long as I'm posting my wish list, I'd like some easy way of keeping track of patch dependencies.



2 points by nex3 6089 days ago | link

This is actually pretty easy to do with "git rebase -i". Not ideal, but definitely workable, especially if you only occasionally want to generate patches. For example, take this ensure-dir-only patch: http://pastie.caboo.se/159593. I generated that by creating a new branch copying stable, running "git rebase -i official", and squashing all the related commits together, leaving a set of almost orthogonal commits (almost because ensure-dir and date both depend on $).

I'm not entirely sure what use you had in mind, so this may not be a great solution. It doesn't take into account dependency-tracking at all. But we could easily make a "patches" branch which would just be a rebased version of stable, although we'd have to keep it updated and rebased, and the constant rebasing would mean that pulling from it might get a bit nasty.

-----

1 point by mulander 6089 days ago | link

Have you considered using darcs? http://darcs.net This SCM is patch oriented, and should allow You to do exactly what You described without any trouble. I recently gave it a try and it perfectly matched my workflow.

-----

1 point by nex3 6089 days ago | link

Despite its patch-oriented nature, Darcs doesn't really offer anything (that I could see) that Git doesn't. This is part of the reason I didn't choose it for Anarki in the first place, although it really is a fun system. The patches would still be a series of separate, interdependent patches. And I don't think Darcs even has a parallel to git rebase to squash them all together.

-----

1 point by mulander 6089 days ago | link

I totally agree that Darcs is fun :) I mentioned it here because the initial post described a workflow that fits into Darcs perfectly, not in an attempt to compare Darcs to Git.

From the Darcs official manual (the tag command):

While traditional revision control systems tag versions in the time line history, darcs lets you tag any configuration of patches at any time, and pass the tags around between branches.

Also please take time to read:

http://wiki.darcs.net/DarcsWiki/SpontaneousBranches

http://wiki.darcs.net/DarcsWiki/PreparationBranches

PS. Sorry for any grammar/lexical mistakes in my writing, as english is not my native language.

-----

1 point by nex3 6089 days ago | link

I was looking into this stuff a while ago - Darcs was actually my first distributed version-control system. When I started playing around with Git, I was initially a little dismayed that it didn't seem to have the history-changing abilities darcs has (apparently called "preparation branches" - I never knew that).

I asked around a little, though, and it turns out that "git rebase -i" essentially encompasses all those capabilities. The UI isn't as nice as darcs' until you get used to it - darcs has very well-designed, intuitive UI - but all the functionality is there.

I had heard about, but forgotten, spontaneous branches. They do seem to be very much like what Cat Dancer was asking for.

Your English is excellent :-).

-----