1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 15/09/14 02:35 PM, hasufell wrote: |
5 |
> Ian Stakenvicius: |
6 |
>> On 14/09/14 09:06 PM, Peter Stuge wrote: |
7 |
>>> Rich Freeman wrote: |
8 |
>>>> If you just want to do 15 standalone commits before you push |
9 |
>>>> you can do those sequentially easily enough. A branch would |
10 |
>>>> be more appropriate for some kind of mini-project. |
11 |
>>> .. |
12 |
>>>> That is the beauty of git - branches are really cheap. So |
13 |
>>>> are repositories |
14 |
>> |
15 |
>>> And commits. |
16 |
>> |
17 |
>>> Not only are branches cheap, they are also very easy to |
18 |
>>> create, and maybe most importantly they can be created at any |
19 |
>>> time, even after the commits. |
20 |
>> |
21 |
>>> It's quick and painless to create a bunch of commits which |
22 |
>>> aren't really closely related in sequence, and only later clean |
23 |
>>> the whole series of commits up while creating different |
24 |
>>> branches for commits which should actually be grouped rather |
25 |
>>> than mixed all together. |
26 |
>> |
27 |
>> |
28 |
>> Ahh, so the secret here would then be just to git add files on a |
29 |
>> related per-package basis, leaving the other files out of the |
30 |
>> commit. that makes sense. There would still be the issue of |
31 |
>> untracked files in the repo and the ability to switch back to the |
32 |
>> 'master' branch to cherry-pick a commit for pushing, though... I |
33 |
>> guess we'd just have to deal with the delay there and try and |
34 |
>> push all of the changes at once? |
35 |
>> |
36 |
> |
37 |
> First, I don't think this is related to mgornys migration plans |
38 |
> anymore. |
39 |
> |
40 |
|
41 |
Completely agree; it may not even be on-topic for the git workflow |
42 |
thread.. |
43 |
|
44 |
> Second: yes, in contrary to CVS it will _never_ happen on git that |
45 |
> you accidentally commit random files because of a "dirty" tree (and |
46 |
> that happened to me as well on CVS... I didn't even know until I |
47 |
> ran repoman on a whole category by accident! oops). |
48 |
> |
49 |
> There are numerous of ways to work on multiple things at once in |
50 |
> git: 1) Just use different branches and sync them if necessary. |
51 |
> |
52 |
> 2) Don't stage everything you have modified... I guess a lot of |
53 |
> people don't really know that it's possible? As pointed out before, |
54 |
> you can even say which hunks/lines of a single file you want to |
55 |
> have staged. |
56 |
> |
57 |
> Furthermore, you don't even need to stash anything, even if you |
58 |
> switch branches, as long as the (un)staged changes don't collide |
59 |
> with the branch you are switching to (and if that is the case... |
60 |
> then you have bigger problems). |
61 |
> |
62 |
|
63 |
My concern/question is not so much how to deal with different things |
64 |
concurrently, as it is how to deal with having to do distinct git |
65 |
operations concurrently. |
66 |
|
67 |
Repeating my example, say i'm working on a new release of firefox, it |
68 |
takes ~40 mins to compile and there's some stuff it needs to do with |
69 |
files in ${FILESDIR} during src_install. So i'm 'ebuild ... |
70 |
install'ing that. In the meantime, there's a high-priority fix that |
71 |
came up that I have to do in say, eudev. Unless i'm doing my firefox |
72 |
work in the master branch locally (and probably am running these tests |
73 |
on modified-but-not-committed files), i can't just switch branches to |
74 |
do/test/commit/push while ebuild does its thing in the background. Or |
75 |
can I? I'd have to resort to (3), right? |
76 |
|
77 |
> 3) Although this is anti-git, you could still just copy paste the |
78 |
> repository directory. Every git repository is consistent in itself |
79 |
> and fully functional. You don't directly depend on any server. And |
80 |
> you can even pull from local git repositories. If you find this |
81 |
> silly, do 2) or 1). |
82 |
> |
83 |
|
84 |
If it were possible to just start up a new shell, cd /usr/portage.git; |
85 |
git checkout master ; [..do stuff..] while the current workspace in |
86 |
my old shell remains consistent, all would be fine. But so far as i |
87 |
(and everyone currently active in #-dev) are aware there's no built-in |
88 |
way to do that right now; the 'git' way would be to clone local repos, |
89 |
yes? |
90 |
|
91 |
|
92 |
-----BEGIN PGP SIGNATURE----- |
93 |
Version: GnuPG v2 |
94 |
|
95 |
iF4EAREIAAYFAlQXPgcACgkQ2ugaI38ACPCJFQD+JfDz8KfuRb5+Ybij11fAOBQv |
96 |
75jah41LD1o2F7AvH4oA/3UAqtO90XS5nin+3o1qU8gfDlL6FPn5E9YGDEPtnQ6f |
97 |
=Eo0Y |
98 |
-----END PGP SIGNATURE----- |