| 1 |
On Mon, Sep 15, 2014 at 1:42 PM, Ian Stakenvicius <axs@g.o> wrote: |
| 2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
| 3 |
> Hash: SHA256 |
| 4 |
> |
| 5 |
> On 14/09/14 09:06 PM, Peter Stuge wrote: |
| 6 |
>> Rich Freeman wrote: |
| 7 |
>>> If you just want to do 15 standalone commits before you push you |
| 8 |
>>> can do those sequentially easily enough. A branch would be more |
| 9 |
>>> appropriate for some kind of mini-project. |
| 10 |
>> .. |
| 11 |
>>> That is the beauty of git - branches are really cheap. So are |
| 12 |
>>> repositories |
| 13 |
>> |
| 14 |
>> And commits. |
| 15 |
>> |
| 16 |
>> Not only are branches cheap, they are also very easy to create, |
| 17 |
>> and maybe most importantly they can be created at any time, even |
| 18 |
>> after the commits. |
| 19 |
>> |
| 20 |
>> It's quick and painless to create a bunch of commits which aren't |
| 21 |
>> really closely related in sequence, and only later clean the whole |
| 22 |
>> series of commits up while creating different branches for commits |
| 23 |
>> which should actually be grouped rather than mixed all together. |
| 24 |
>> |
| 25 |
> |
| 26 |
> Ahh, so the secret here would then be just to git add files on a |
| 27 |
> related per-package basis, leaving the other files out of the commit. |
| 28 |
> that makes sense. There would still be the issue of untracked files |
| 29 |
> in the repo and the ability to switch back to the 'master' branch to |
| 30 |
> cherry-pick a commit for pushing, though... I guess we'd just have to |
| 31 |
> deal with the delay there and try and push all of the changes at once? |
| 32 |
|
| 33 |
If you really like to keep a lot of things going at once, I'd strongly |
| 34 |
recommend doing it in another branch (or more than one), so that you |
| 35 |
can cherry-pick/merge/etc stuff into master and not have a mess of an |
| 36 |
index while doing it. You need not publish that branch, and if you do |
| 37 |
publish it you need not do it on Gentoo's infra (a git repository can |
| 38 |
be synced with multiple other repositories, and the various heads |
| 39 |
don't need to stay in sync). |
| 40 |
|
| 41 |
In general you want each commit to represent a single "change." That |
| 42 |
might be a revbump in a single package, or it might be a package move |
| 43 |
that involves touching 300 packages in a single commit. The idea |
| 44 |
though is that every commit should stand on its own, so that they can |
| 45 |
be reverted on their own, etc. That's just good practice, and should |
| 46 |
be what we're trying to do with cvs with the huge limitation that |
| 47 |
multi-file changes in cvs aren't atomic. |
| 48 |
|
| 49 |
There are a lot of guides/tools/etc out there for using git. A |
| 50 |
popular one is the git-flow workflow. I'm not suggesting that it is |
| 51 |
really necessary for one person, but anybody not familiar with git |
| 52 |
should probably read up on it just so that you have some sense of how |
| 53 |
it can be used. |
| 54 |
|
| 55 |
-- |
| 56 |
Rich |
Archives