Re: [gentoo-dev] git basics
Ian Stakenvicius:
>
> It's generally considered safe to push to origin/master a commit from
> a temporary local branch?
Why not?
Even if you have to rebase/merge, nothing will happen with your unstaged
local changes as long as no one has messed with the firefox ebuild in
the meantime... and then you have bigger problems.
>
> as I expect there are plenty of people that test ebuilds
> straight from CVS right now.
>
I remember people telling me to never do that, but anyway.
>
>
>> That said... I find that workflow a bit weird. Why is the firefox
>> ebuild already committed if it hasn't even been tested?
>
>
> That's just how i tend to work with git in what little i've been
> exposed to: git checkout -b tmpbranch ; develop; commit; test &&
> {squash,checkout master,cherry-pick,push} || develop []
>
> It lets me roll back to earlier commits if i want to undo something,
> or revisit some code that i discarded, or whatnot... Since committing
> != pushing, generally there isn't much harm, and i squash all these
> misc commits into one after everything's ready, so it doesn't clutter
> the history.
>
Maybe you could check if you can do some of that stuff with git stashes.
You can save them with a message indicating what it is about, apply a
particular one from the stash (ofc you can have multiple ones), drop
others, create branches based on the stash etc.
Re: [gentoo-dev] git basics
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/09/14 04:31 PM, hasufell wrote:
> hasufell:
>> Ian Stakenvicius:
>>>
>>> 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?
>>>
>>
>> 1. git checkout -b eudev-tmp (create new branch which has the
>> firefox changes you just made and switch to it) 2. git reset
>> --mixed HEAD~1 (dump the firefox patch back to the unstaged area,
>> the file is still the same!) 3. fiddle around with eudev, commit
>> and push 4. git checkout -f master (switch back to the master
>> branch and throw away the unstaged changes in eudev-tmp,
>> however... file is still the same)
>>
It's generally considered safe to push to origin/master a commit from
a temporary local branch? how would that end up working with the
repoman->push->[fail]->pull cycle due to possible non-fast-forward
conflicts? how difficult will it be to ensure local history isn't all
messed up, later on?
>> Alternatives: Copy over the firefox ebuild to your local overlay
>> before doing extensive tests and fiddling. That's what I'd do
>> anyway instead of working directly on the tree.
>>
Yes, that's always a possibility as well -- having a second copy of
the tree, pulling (local) changes from the working copy and
merge-testing from that would reduce most of these concurrency
issues.. Probably worthwhile suggesting this in the git workflow
guide, as I expect there are plenty of people that test ebuilds
straight from CVS right now.
>
> That said... I find that workflow a bit weird. Why is the firefox
> ebuild already committed if it hasn't even been tested?
>
That's just how i tend to work with git in what little i've been
exposed to: git checkout -b tmpbranch ; develop; commit; test &&
{squash,checkout master,cherry-pick,push} || develop []
It lets me roll back to earlier commits if i want to undo something,
or revisit some code that i discarded, or whatnot... Since committing
!= pushing, generally there isn't much harm, and i squash all these
misc commits into one after everything's ready, so it doesn't clutter
the history.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlQXUkoACgkQ2ugaI38ACPAmvQD9GeqZu6dHi5BSd2lpArMvHES/
whHLDOoPdXUeb3Uh99kBAKorCvYZFmKEDHWgvbnCuk/vfua58ItwOjtQIY/WG1Az
=pNOG
-END PGP SIGNATURE-
Re: [gentoo-dev] git basics
hasufell:
> Ian Stakenvicius:
>>
>> 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?
>>
>
> 1. git checkout -b eudev-tmp (create new branch which has the firefox
> changes you just made and switch to it)
> 2. git reset --mixed HEAD~1 (dump the firefox patch back to the unstaged
> area, the file is still the same!)
> 3. fiddle around with eudev, commit and push
> 4. git checkout -f master (switch back to the master branch and throw
> away the unstaged changes in eudev-tmp, however... file is still the same)
>
> Alternatives:
> Copy over the firefox ebuild to your local overlay before doing
> extensive tests and fiddling. That's what I'd do anyway instead of
> working directly on the tree.
>
That said... I find that workflow a bit weird. Why is the firefox ebuild
already committed if it hasn't even been tested?
And if it's not committed... then we don't even have a problem here,
because switching branches will just work.
Re: [gentoo-dev] git basics
Ian Stakenvicius:
>
> 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?
>
1. git checkout -b eudev-tmp (create new branch which has the firefox
changes you just made and switch to it)
2. git reset --mixed HEAD~1 (dump the firefox patch back to the unstaged
area, the file is still the same!)
3. fiddle around with eudev, commit and push
4. git checkout -f master (switch back to the master branch and throw
away the unstaged changes in eudev-tmp, however... file is still the same)
Alternatives:
Copy over the firefox ebuild to your local overlay before doing
extensive tests and fiddling. That's what I'd do anyway instead of
working directly on the tree.
Re: [gentoo-dev] git basics
-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-
Re: [gentoo-dev] git basics
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. 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). 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).
