On Mon, Sep 15, 2014 at 1:42 PM, Ian Stakenvicius <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 14/09/14 09:06 PM, Peter Stuge wrote: >> Rich Freeman wrote: >>> If you just want to do 15 standalone commits before you push you >>> can do those sequentially easily enough. A branch would be more >>> appropriate for some kind of mini-project. >> .. >>> That is the beauty of git - branches are really cheap. So are >>> repositories >> >> And commits. >> >> Not only are branches cheap, they are also very easy to create, >> and maybe most importantly they can be created at any time, even >> after the commits. >> >> It's quick and painless to create a bunch of commits which aren't >> really closely related in sequence, and only later clean the whole >> series of commits up while creating different branches for commits >> which should actually be grouped rather than mixed all together. >> > > Ahh, so the secret here would then be just to git add files on a > related per-package basis, leaving the other files out of the commit. > that makes sense. There would still be the issue of untracked files > in the repo and the ability to switch back to the 'master' branch to > cherry-pick a commit for pushing, though... I guess we'd just have to > deal with the delay there and try and push all of the changes at once?
If you really like to keep a lot of things going at once, I'd strongly recommend doing it in another branch (or more than one), so that you can cherry-pick/merge/etc stuff into master and not have a mess of an index while doing it. You need not publish that branch, and if you do publish it you need not do it on Gentoo's infra (a git repository can be synced with multiple other repositories, and the various heads don't need to stay in sync). In general you want each commit to represent a single "change." That might be a revbump in a single package, or it might be a package move that involves touching 300 packages in a single commit. The idea though is that every commit should stand on its own, so that they can be reverted on their own, etc. That's just good practice, and should be what we're trying to do with cvs with the huge limitation that multi-file changes in cvs aren't atomic. There are a lot of guides/tools/etc out there for using git. A popular one is the git-flow workflow. I'm not suggesting that it is really necessary for one person, but anybody not familiar with git should probably read up on it just so that you have some sense of how it can be used. -- Rich
