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