Re: packaging with git and upstream interaction [was: Pkg-perl-cvs-commits post from legatvs@gmail.com requires approval]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, Apr 10, 2009 at 10:05:48AM +0300, Damyan Ivanov wrote:
>I admit the clive upstream merge had some hiccups. "The Imported
>Upstream version 2.1.10" commit (a62417d) should have been empty, but
>it has a significant diff. So I guess the merge from
>upstream-repo/master into upstream branch was badly made (by me, there
>were some conflicts (surprisingly) and I haven't paid enough atention
>when resolving them). Fixing this is possible, but would involve
>rewriting the history, which would break any clones of the repository
>so I leave things as they are. It should behave better next time.
In my experience, a couple of things can lead to hiccups:
* If upstream development track include .gitignore and tarball does not,
e.g. to ignore automade files during development and ship those same
files in the tarball, then git-import-src gets confused. I am not
entirely sure yet, but I believe the tool does the right thing in
"upstream" branch (prepares the tarball contents in a temporary
throwaway branch and force-replace the "upstream" branch), but for the
merge from "upstream" to "master" to succeed, you need to manually "git
rm" the .gitignore files *before* importing the new source.
* Git tries to detect files moving around: If one file is removed and
another is added with exact same content in same commit, then it is
treated as a moved file. Usually this won't happen, but syncronizing 2
different kinds of commits (upstream development, tarball imports, and
maybe also old Debian packaging cruft outside the debian/ dir) can
confuse git to apply later updates to one file onto another file. It
won't do it silently, you will have a conflict to resolve, but can be a
real mess to do.
What I have found to be the easiest way to solve merge conflicts during git-import-src is the following:
1. "git rm -rf" everything except .git/ and debian/ subdirs
2. manually unpack tarball
3. "git add" everything except .git/ and debian/ subdirs
5. Double-check with "git status" that all changes are registered
4. "git commit" to commit the resolved merge
>Hm, should I stop merging from upstream-repo? I do it only because it
>"feels right". The code flows from upstream and we add debian/ to it
>and then create the package.
I prefer this approach too.
>Or, should the post-recieve hook be improved somehow to not notify
>about commits that were merged into master (only by the 'merge' commit
>itself)? That would require using --no-ff when merging from upstream
>to master. Something to try for the next time...
Looking forward to your experiments here :-)
- jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknfBxUACgkQn7DbMsAkQLiMyQCdG3Q31AA4vbAV/JCNWS6oi1Io
QCUAn10Ae/KbawyBKdwp+Uxs8HC5OAJi
=e46W
-----END PGP SIGNATURE-----
Reply to: