Re: My use case of git-buildpackage
On Thu, 03 Nov 2011, Daniel Dehennin wrote: First, I'm not a Debian maintainer, I mostly do some package for my personal use, to follow SVN trunk or git HEAD of some softwares. that is the idea behind Debian -- personal use could benefit others alike -- why not to share those packages with the rest of debian community through finalizing packaging so it is compliant with debian standards, and then seeking sponsored upload? There are some items about which I would like to discuss, like: - automatic handling of debia/changelog git-dch? - multi-distributions/version packaging (and avoiding conflicts) for neurodebian we use our backport-dsc http://github.com/neurodebian/neurodebian/blob/HEAD/tools/backport-dsc NB yet to create a blog post on our set of little helpers, altogether usually we just call nd_build4all X.dsc to get it built across releases of debian and ubuntu... interested to learn more? - management of orig.tar.gz do you mean filtering? git-import-orig does that if you specify 'filter' option in your debian/gbp.conf for the package I already read some maling-list archives, mostly the Patch mgmt workflow proposal plus the links givent in the thread, but the conversations are way to high for me. thanks for the links -- I am yet to read them ;) decided to reply first ;-) -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: Branches to patches
Both rebasing and cherry-picking don't work well with published repos because they change commit IDs. I don't see why cherry-picking is an issue -- it just replicates commit (patch) into current branch from another branch. It is quite different from rebasing where commits are moved, thus ref for that branch is changed in non-fast-forward fashion Cherry-picking is great for pulling individual commits from upstream. or introducing individual commits back into upstream (if you are upstream and want to cherry pick individual fixes from some feature branches of debian-fixes branches) Rebasing is great to keep the stuff you work on up-to-date with what others are doing, and to minimise diffs between upstream and your working imho diff should (must) stay the same if you are diffing head of upstream (or the latest split point, ie the point where upstream was either merged from last time, or rebased against) and the feature branch regardless if you kept feature branch under constant rebasing or merging from upstream. -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Branches to patches
Out of curiosity (and this is one of the places where I'm just a Git newbie), why would I ever want to rebase and not merge? I'm currently merging and it works great. I'm not sure what the advantage of rebasing instead would be. there are many use cases (there are some in git rebase --help), where rebase is the only option (like moving branch X which is based on Y, to be based on some other branch Z -- for instance feature X is apparently not to be distributed in public domain, thus should be based on branch Y which is for 'private use only', or vise versa -- and for that branch has to be rebased, and if smth was merged into it from X, then rebasing onto Y would bring X into it). But in this case for feature branches imho a branch without multiple merges from upstream branch looks much cleaner and it is easy to rebase it if needed against any ref in repository (e.g. you need to apply that branch to test if it solves issues in the maintained version of package within etch) -- another option would be cherry picking but rebasing would be cleaner imho and easier. Am I missing some other critical use cases? -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
