| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 15/09/14 04:31 PM, hasufell wrote: |
| 5 |
> hasufell: |
| 6 |
>> Ian Stakenvicius: |
| 7 |
>>> |
| 8 |
>>> Repeating my example, say i'm working on a new release of |
| 9 |
>>> firefox, it takes ~40 mins to compile and there's some stuff it |
| 10 |
>>> needs to do with files in ${FILESDIR} during src_install. So |
| 11 |
>>> i'm 'ebuild ... install'ing that. In the meantime, there's a |
| 12 |
>>> high-priority fix that came up that I have to do in say, eudev. |
| 13 |
>>> Unless i'm doing my firefox work in the master branch locally |
| 14 |
>>> (and probably am running these tests on |
| 15 |
>>> modified-but-not-committed files), i can't just switch branches |
| 16 |
>>> to do/test/commit/push while ebuild does its thing in the |
| 17 |
>>> background. Or can I? I'd have to resort to (3), right? |
| 18 |
>>> |
| 19 |
>> |
| 20 |
>> 1. git checkout -b eudev-tmp (create new branch which has the |
| 21 |
>> firefox changes you just made and switch to it) 2. git reset |
| 22 |
>> --mixed HEAD~1 (dump the firefox patch back to the unstaged area, |
| 23 |
>> the file is still the same!) 3. fiddle around with eudev, commit |
| 24 |
>> and push 4. git checkout -f master (switch back to the master |
| 25 |
>> branch and throw away the unstaged changes in eudev-tmp, |
| 26 |
>> however... file is still the same) |
| 27 |
>> |
| 28 |
|
| 29 |
It's generally considered safe to push to origin/master a commit from |
| 30 |
a temporary local branch? how would that end up working with the |
| 31 |
repoman->push->[fail]->pull cycle due to possible non-fast-forward |
| 32 |
conflicts? how difficult will it be to ensure local history isn't all |
| 33 |
messed up, later on? |
| 34 |
|
| 35 |
>> Alternatives: Copy over the firefox ebuild to your local overlay |
| 36 |
>> before doing extensive tests and fiddling. That's what I'd do |
| 37 |
>> anyway instead of working directly on the tree. |
| 38 |
>> |
| 39 |
|
| 40 |
Yes, that's always a possibility as well -- having a second copy of |
| 41 |
the tree, pulling (local) changes from the working copy and |
| 42 |
merge-testing from that would reduce most of these concurrency |
| 43 |
issues.. Probably worthwhile suggesting this in the git workflow |
| 44 |
guide, as I expect there are plenty of people that test ebuilds |
| 45 |
straight from CVS right now. |
| 46 |
|
| 47 |
|
| 48 |
> |
| 49 |
> That said... I find that workflow a bit weird. Why is the firefox |
| 50 |
> ebuild already committed if it hasn't even been tested? |
| 51 |
> |
| 52 |
|
| 53 |
That's just how i tend to work with git in what little i've been |
| 54 |
exposed to: git checkout -b tmpbranch ; develop; commit; test && |
| 55 |
{squash,checkout master,cherry-pick,push} || develop [....] |
| 56 |
|
| 57 |
It lets me roll back to earlier commits if i want to undo something, |
| 58 |
or revisit some code that i discarded, or whatnot... Since committing |
| 59 |
!= pushing, generally there isn't much harm, and i squash all these |
| 60 |
misc commits into one after everything's ready, so it doesn't clutter |
| 61 |
the history. |
| 62 |
|
| 63 |
|
| 64 |
-----BEGIN PGP SIGNATURE----- |
| 65 |
Version: GnuPG v2 |
| 66 |
|
| 67 |
iF4EAREIAAYFAlQXUkoACgkQ2ugaI38ACPAmvQD9GeqZu6dHi5BSd2lpArMvHES/ |
| 68 |
whHLDOoPdXUeb3Uh99kBAKorCvYZFmKEDHWgvbnCuk/vfua58ItwOjtQIY/WG1Az |
| 69 |
=pNOG |
| 70 |
-----END PGP SIGNATURE----- |
Archives