4:54 p.m.
This has bugged me forever and I think I've got it figured out now (thanks
mdomsch for pointing me in the right direction)
Lets say you've been working for weeks on a module in staging and you want
to cherry pick those commits. How do you do it? It becomes trickier even
if someone else has been working on other modules in staging. This seems
to do the trick:
git log --name-status master..staging module/path
or to see the diff
git diff master staging module/path
The only thing to be careful of that I can tell is if one of the commits
listed in git-log includes something in another path outside of your
module.
Anyway, if you can think of a better way to do this let me know, so far
though this worked well for me.
-Mike
5:08 p.m.
On Tue, Sep 15, 2009 at 2:54 PM, Mike McGrath <mmcgrath(a)redhat.com> wrote:
This has bugged me forever and I think I've got it figured out
now (thanks
mdomsch for pointing me in the right direction)
Lets say you've been working for weeks on a module in staging and you want
to cherry pick those commits. How do you do it? It becomes trickier even
if someone else has been working on other modules in staging. This seems
to do the trick:
git log --name-status master..staging module/path
or to see the diff
git diff master staging module/path
The only thing to be careful of that I can tell is if one of the commits
listed in git-log includes something in another path outside of your
module.
Anyway, if you can think of a better way to do this let me know, so far
though this worked well for me.
-Mike
Depending on what you're looking for, this can be achieved a few
different ways.
If the goal is to copy the end-result (or, current state) between
branches, and maintaining commit history isn't as important, you can
just do this:
git diff --relative branch1 branch2 -- path/to/files | git-apply --index
or
git diff --relative branch1 branch2 -- path/to/files | patch -p1
If the goal is to cherry-pick every commit and replay them into a new
branch, then your above method is probably the best way to do it.
For reference, here's a good explanation from Linus on this issue:
http://thread.gmane.org/gmane.comp.version-control.git/37600/focus=37683
---Brett.
2:33 a.m.
On Tue, 2009-09-15 at 16:54 -0500, Mike McGrath wrote:
This has bugged me forever and I think I've got it figured out
now (thanks
mdomsch for pointing me in the right direction)
Lets say you've been working for weeks on a module in staging and you want
to cherry pick those commits. How do you do it? It becomes trickier even
if someone else has been working on other modules in staging.
It's probably better to have a topic branch for your changes and merge
that regularly into staging while you're working on it. When it's all
done, you can merge the topic branch into master.
Cheers,
Mark.
7:46 a.m.
On Wed, 16 Sep 2009, Mark McLoughlin wrote:
On Tue, 2009-09-15 at 16:54 -0500, Mike McGrath wrote:
> This has bugged me forever and I think I've got it figured out now (thanks
> mdomsch for pointing me in the right direction)
>
> Lets say you've been working for weeks on a module in staging and you want
> to cherry pick those commits. How do you do it? It becomes trickier even
> if someone else has been working on other modules in staging.
It's probably better to have a topic branch for your changes and merge
that regularly into staging while you're working on it. When it's all
done, you can merge the topic branch into master.
There's no way to properly test the changes with that method though
unfortunately.
-Mike
8:26 a.m.
On Wed, 2009-09-16 at 07:46 -0500, Mike McGrath wrote:
On Wed, 16 Sep 2009, Mark McLoughlin wrote:
> On Tue, 2009-09-15 at 16:54 -0500, Mike McGrath wrote:
> > This has bugged me forever and I think I've got it figured out now (thanks
> > mdomsch for pointing me in the right direction)
> >
> > Lets say you've been working for weeks on a module in staging and you want
> > to cherry pick those commits. How do you do it? It becomes trickier even
> > if someone else has been working on other modules in staging.
>
> It's probably better to have a topic branch for your changes and merge
> that regularly into staging while you're working on it. When it's all
> done, you can merge the topic branch into master.
>
There's no way to properly test the changes with that method though
unfortunately.
How is it different?
Merging the topic branch into staging is the same as doing the working
on staging itself, except the work is better isolated for merging into
master later.
Cheers,
Mark.
8:41 a.m.
On Wed, 16 Sep 2009, Mark McLoughlin wrote:
On Wed, 2009-09-16 at 07:46 -0500, Mike McGrath wrote:
> On Wed, 16 Sep 2009, Mark McLoughlin wrote:
>
> > On Tue, 2009-09-15 at 16:54 -0500, Mike McGrath wrote:
> > > This has bugged me forever and I think I've got it figured out now
(thanks
> > > mdomsch for pointing me in the right direction)
> > >
> > > Lets say you've been working for weeks on a module in staging and you
want
> > > to cherry pick those commits. How do you do it? It becomes trickier
even
> > > if someone else has been working on other modules in staging.
> >
> > It's probably better to have a topic branch for your changes and merge
> > that regularly into staging while you're working on it. When it's all
> > done, you can merge the topic branch into master.
> >
>
> There's no way to properly test the changes with that method though
> unfortunately.
How is it different?
Merging the topic branch into staging is the same as doing the working
on staging itself, except the work is better isolated for merging into
master later.
Because we have to pick which branch to send to staging. So if I picked
branch 'mmcgrath' and luke picked branch 'lmacken' neither of them would
end up being tested in our actual staging environment since we have to
point the staging environment at a specific branch.
-Mike
9:57 a.m.
On Wed, 2009-09-16 at 08:41 -0500, Mike McGrath wrote:
On Wed, 16 Sep 2009, Mark McLoughlin wrote:
> On Wed, 2009-09-16 at 07:46 -0500, Mike McGrath wrote:
> > On Wed, 16 Sep 2009, Mark McLoughlin wrote:
> >
> > > On Tue, 2009-09-15 at 16:54 -0500, Mike McGrath wrote:
> > > > This has bugged me forever and I think I've got it figured out
now (thanks
> > > > mdomsch for pointing me in the right direction)
> > > >
> > > > Lets say you've been working for weeks on a module in staging and
you want
> > > > to cherry pick those commits. How do you do it? It becomes trickier
even
> > > > if someone else has been working on other modules in staging.
> > >
> > > It's probably better to have a topic branch for your changes and
merge
> > > that regularly into staging while you're working on it. When it's
all
> > > done, you can merge the topic branch into master.
> > >
> >
> > There's no way to properly test the changes with that method though
> > unfortunately.
>
> How is it different?
>
> Merging the topic branch into staging is the same as doing the working
> on staging itself, except the work is better isolated for merging into
> master later.
>
Because we have to pick which branch to send to staging. So if I picked
branch 'mmcgrath' and luke picked branch 'lmacken' neither of them would
end up being tested in our actual staging environment since we have to
point the staging environment at a specific branch.
I was assuming there was a branch called 'staging'
$> git checkout -b mmcgrath-fix-foo-bar origin/staging
... do stuff while other people do stuff on staging ...
$> git fetch origin
$> git checkout -b staging-merge origin/staging
$> git merge mmcgrath-fix-foo-bar
$> git push origin HEAD:staging
Then when it has been tested:
$> git fetch origin
$> git checkout -b final-merge origin/master
$> git merge mmcgrath-fix-foo-bar
$> git push origin HEAD:master
That should work fine.
Cheers,
Mark.
10:03 a.m.
Mike McGrath wrote:
On Wed, 16 Sep 2009, Mark McLoughlin wrote:
> Merging the topic branch into staging is the same as doing the
> working on staging itself, except the work is better isolated for
> merging into master later.
Because we have to pick which branch to send to staging. So if I
picked branch 'mmcgrath' and luke picked branch 'lmacken' neither of
them would end up being tested in our actual staging environment
since we have to point the staging environment at a specific branch.
I think Mark's suggested workflow goes something like this:
# Want to test out some changes for, say, geoip
git co -b geoip-changes staging
# Work, work, work
# Merge to staging
git co staging
git merge geoip-changes
# Push to puppet1
git push origin staging
# Test, test, Test
# Looks good, let's get this into production
git co master
git merge geoip-changes
This makes it easier to do that merge, whereas merging staging into
master would involve cherry-picking commits most times. The trouble
with cherry-picking is that it just creates a new commit with the same
changes. You lose the commit-id which makes it harder to see just
what commits are on staging that are not merged into master and vice
versa.
For collaboration, sharing these topic branches is also trivial with
git. If both you and Matt wanted to work on the geoip-changes topic,
you can add each others's personal repos as remotes and share that
way. Or if you really wanted, that topic branch could be pushed to
the main repository for easy collaboration among everyone.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A fool's brain digests philosophy into folly, science into
superstition, and art into pedantry. Hence University education.
-- George Bernard Shaw
10:06 a.m.
On Wed, 16 Sep 2009, Todd Zullinger wrote:
Mike McGrath wrote:
> On Wed, 16 Sep 2009, Mark McLoughlin wrote:
>> Merging the topic branch into staging is the same as doing the
>> working on staging itself, except the work is better isolated for
>> merging into master later.
>
> Because we have to pick which branch to send to staging. So if I
> picked branch 'mmcgrath' and luke picked branch 'lmacken' neither
of
> them would end up being tested in our actual staging environment
> since we have to point the staging environment at a specific branch.
I think Mark's suggested workflow goes something like this:
# Want to test out some changes for, say, geoip
git co -b geoip-changes staging
# Work, work, work
# Merge to staging
git co staging
git merge geoip-changes
# Push to puppet1
git push origin staging
# Test, test, Test
# Looks good, let's get this into production
git co master
git merge geoip-changes
This makes it easier to do that merge, whereas merging staging into
master would involve cherry-picking commits most times. The trouble
with cherry-picking is that it just creates a new commit with the same
changes. You lose the commit-id which makes it harder to see just
what commits are on staging that are not merged into master and vice
versa.
For collaboration, sharing these topic branches is also trivial with
git. If both you and Matt wanted to work on the geoip-changes topic,
you can add each others's personal repos as remotes and share that
way. Or if you really wanted, that topic branch could be pushed to
the main repository for easy collaboration among everyone.
Ahh, I've got you now. So we're not actually using the temporary branch,
at least not directly.
-Mike
5333
days inactive
5334
days old
infrastructure@lists.fedoraproject.org
8 comments
4 participants
participants (4)
-
brett lentz -
Mark McLoughlin -
Mike McGrath -
Todd Zullinger