| 1 |
hasufell: |
| 2 |
> Ian Stakenvicius: |
| 3 |
>> |
| 4 |
>> Repeating my example, say i'm working on a new release of firefox, it |
| 5 |
>> takes ~40 mins to compile and there's some stuff it needs to do with |
| 6 |
>> files in ${FILESDIR} during src_install. So i'm 'ebuild ... |
| 7 |
>> install'ing that. In the meantime, there's a high-priority fix that |
| 8 |
>> came up that I have to do in say, eudev. Unless i'm doing my firefox |
| 9 |
>> work in the master branch locally (and probably am running these tests |
| 10 |
>> on modified-but-not-committed files), i can't just switch branches to |
| 11 |
>> do/test/commit/push while ebuild does its thing in the background. Or |
| 12 |
>> can I? I'd have to resort to (3), right? |
| 13 |
>> |
| 14 |
> |
| 15 |
> 1. git checkout -b eudev-tmp (create new branch which has the firefox |
| 16 |
> changes you just made and switch to it) |
| 17 |
> 2. git reset --mixed HEAD~1 (dump the firefox patch back to the unstaged |
| 18 |
> area, the file is still the same!) |
| 19 |
> 3. fiddle around with eudev, commit and push |
| 20 |
> 4. git checkout -f master (switch back to the master branch and throw |
| 21 |
> away the unstaged changes in eudev-tmp, however... file is still the same) |
| 22 |
> |
| 23 |
> Alternatives: |
| 24 |
> Copy over the firefox ebuild to your local overlay before doing |
| 25 |
> extensive tests and fiddling. That's what I'd do anyway instead of |
| 26 |
> working directly on the tree. |
| 27 |
> |
| 28 |
|
| 29 |
That said... I find that workflow a bit weird. Why is the firefox ebuild |
| 30 |
already committed if it hasn't even been tested? |
| 31 |
|
| 32 |
And if it's not committed... then we don't even have a problem here, |
| 33 |
because switching branches will just work. |
Archives