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