Comments on: Wanted: Git Help for HIG

By: Calum

Calum — Wed, 22 Apr 2009 19:47:09 +0000

Yeah, I wouldn’t worry too much about preserving history, tbh. At this stage, I think it’s not unlikely that the current devel version of the HIG will be scrapped and rewritten for 3.0 anyway… or perhaps that’s just wishful thinking

By: Owen Taylor

Owen Taylor — Wed, 22 Apr 2009 12:34:02 +0000

It’s going to be pretty hard to recover that branch. Not only is there the difference of tree structure, but a) the initial commit of the branch doesn’t have the right parent commit, so it looks unrelated to history prior to 2007 b) older version in the branch are missing files *within* hig/C; the files appear only when first modified.

With a fair bit of work, git-filter-branch –parent-filter and git-filter-branch –tree-filter could be used to rewrite the branch “as it should have been” by using the right parent commit, moving stuff to the subdir, and adding missing files. If you decide to go that route and get something you like, find me on IRC for help in pushing the rewritten branch to git.gnome.org.

However, I don’t see much useful history on that branch, so maybe it isn’t worth it.

By: Mark Drago

Mark Drago — Wed, 22 Apr 2009 11:27:58 +0000

Maybe the subtree merge strategy of git is what you’re looking for? Check `man git-branch` which has a very brief description. I haven’t had the need to use it yet, but it sounds like it might be just what you need.

By: garrett

garrett — Wed, 22 Apr 2009 09:15:54 +0000

(Note: The typewriter single and double quote marks got WordPressified into typographical marks.)

By: garrett

garrett — Wed, 22 Apr 2009 09:12:18 +0000

I made two experimental local branches, first starting from the hig-devel branch, re-writing it to move all the files to hig/C/ like so:

git filter-branch –tree-filter ‘mkdir -p hig/C; ls | grep -v “^hig$” | xargs -ifoo mv foo hig/C/’ HEAD

Then I did a “git merge master” to merge in the changes. There were conflicts, so I opted for the branch’s version with “git checkout –ours” (and then the conflicting files). I did a “git add” for those conflicting files, and then a “git commit”.

An option is to rebase the new version of the branch off of master with “git rebase master”, to move the commits above the trunk. It’s a bit of a mess, and you’ll get conflicts along the way. I did the “checkout –ours” thing for the files each step of the way, and then a “git rebase –continue” (after adding the conflicting files). After a while of doing that, it was finally finished. For good measure, I did a “git merge –squash” (and then the original branch), since there were so many conflicts.

Neither is perfect, but it moves the files to where they are supposed to be and they’re both attempts to preserve much of the history.

I can publish the two versions of the changed branches somewhere (even to the official repository) if you’d like to inspect them… just let me know.

If you do decide to make a modified version of the branch an official one, you would have to do a force push if you keep the same name, and make sure everyone else who checked it out does a force pull. I suggest just using a different name for the branch and removing the original “hig-devel”, to spare possible confusion.

By: Johannes Berg

Johannes Berg — Wed, 22 Apr 2009 09:09:23 +0000

So basically you have two independent pieces of work in two git branches, right?

I’m not sure how it worked, but it’s definitely possible — the btrfs merge in the Linux kernel did that. I can try to dig it up, send me an email.

By: Santi

Santi — Wed, 22 Apr 2009 08:41:22 +0000

As daniels said, you can use git-filter-branch (you already have the history in git.gnome.org so no need to use git-svn).

Basically you need to do three things:

1) Reparent the first commit in the branch (using a graft file)
2) Move all the files to the corresponding place (there is an exemple in the git filter-branch man page)
3) Add all the other files (maybe with git-read-tree .

Another option could be export all the commits in the branch with git format-patch, fix the paths, and apply them with ‘git am’.

At the end the only difference between the two should be the commit date, it is preserved with git filter-branch while with ‘git am’ it would be the present date (I think in the last git release or in the master branch there is a flag to use the author date as committer date).

HTH,
Santi

By: David

David — Wed, 22 Apr 2009 08:25:43 +0000

I think you want a subtree merge, but it gets a bit more complex by originating from svn, especially if you want to preserve the original branch point.

Google for “giit subtree merge”

By: daniels

daniels — Wed, 22 Apr 2009 08:11:13 +0000

Import with git-svn or something, which is aware of svn’s directory stupidity, and you can then use git-filter-branch to construct a more sane set of history along that branch, with fixed filenames etc. Once you’ve done that, you should be able to do a clean merge.

By: Jesse

Jesse — Wed, 22 Apr 2009 07:22:04 +0000

I think what you are looking for is git filter-branch –subdirectory-filter []. You can make a new branch with the full history, then apply this to it, which should result in a separate branch with the history that touched only that subdirectory. Let me know if it works out (because I could have used this yesterday also, but was to lazy to look it up )