How we use Git

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

How we use Git

Gervase Markham
A quick quiz:

Q1: What git commands would I use to obtain an exact copy of 4.4.6 from
our git repo?

Q2: Same question for 4.4.4.

As far as I can see, the only way of doing this currently is to do:

git clone http://git.mozilla.org/bugzilla/bugzilla.git
cd bugzilla
git log
<look for the final 4.4.4 commit>
git checkout <sha1>
<get strange message about "detached HEAD">

Am I wrong?

If I'm not, then this isn't good.

Currently, we have branches for each release, but these contain all
fixes checked on on that branch, so even if you want "the latest 4.4
release", if you:

git checkout -b 4.4 origin/4.4

(which is already a complex command) then you actually get 4.4.6 plus
some more fixes.

I believe we need metadata in our git repo such that any (recent)
released version can be pulled and run bit-for-bit identical to the
release tarball. I think we also need a pointer (tag?) to "latest stable
release" on each branch which moves when we do a new release. Does that
make sense to people?

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Simon Green
On 31/10/14 21:26, Gervase Markham wrote:

> git clone http://git.mozilla.org/bugzilla/bugzilla.git
> cd bugzilla
> git log
> <look for the final 4.4.4 commit>
> git checkout <sha1>
> <get strange message about "detached HEAD">
>
> Am I wrong?
>
> If I'm not, then this isn't good.

I'm going to leave that to the people that know more than git than I do,
but that does seem correct.

> I believe we need metadata in our git repo such that any (recent)
> released version can be pulled and run bit-for-bit identical to the
> release tarball. I think we also need a pointer (tag?) to "latest stable
> release" on each branch which moves when we do a new release. Does that
> make sense to people?

I would turn the question around. If you are using git (or bzr or csv)
to get code, what is wrong with getting the latest code for the branch,
rather than the latest release of the code?

Things in 4.4.6+ are going to be part of 4.4.7 when that is released,
and there is a documented policy on what can be backported.

--
Simon Green
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Randall S. Becker
In reply to this post by Gervase Markham
Gerv,

I think it might be best to have a separate branch every release, not just
the minors. So you would have a branch for 4.4.6 as well as 4.4. If you end
up with 4.4.6.1, that too would be a branch - although you could get away
with a tag. The decision between branch and tag really comes down to the
granularity of fix releases. If there will be a 4.4.6.1.1, then branching at
4.4.6.1 is needed, otherwise not. Numbered releases are arbitrary in Git,
unlike in anything derived from the RSC paradigm.

Even if you are going to fix 4.4.6 (on some 4_4 branch or 4_4_6) with
patches to create 4.4.7, in Git, you would normally create a branch for the
pre-approved fixes, check things out, modify, commit, test, and once happy,
merge back into your working branch. From there, tag or branch for the
release, as named - but that is really just an arbitrary identifier to Git.

I hope I didn't confuse things more ;)

Cheers,

Randall

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Gervase Markham
Sent: October 31, 2014 7:27 AM
To: [hidden email]
Subject: How we use Git

A quick quiz:

Q1: What git commands would I use to obtain an exact copy of 4.4.6 from our
git repo?

Q2: Same question for 4.4.4.

As far as I can see, the only way of doing this currently is to do:

git clone http://git.mozilla.org/bugzilla/bugzilla.git
cd bugzilla
git log
<look for the final 4.4.4 commit>
git checkout <sha1>
<get strange message about "detached HEAD">

Am I wrong?

If I'm not, then this isn't good.

Currently, we have branches for each release, but these contain all fixes
checked on on that branch, so even if you want "the latest 4.4 release", if
you:

git checkout -b 4.4 origin/4.4

(which is already a complex command) then you actually get 4.4.6 plus some
more fixes.

I believe we need metadata in our git repo such that any (recent) released
version can be pulled and run bit-for-bit identical to the release tarball.
I think we also need a pointer (tag?) to "latest stable release" on each
branch which moves when we do a new release. Does that make sense to people?

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=rsbecker@...>

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Mark Côté
In reply to this post by Gervase Markham
On 2014-10-31 7:26 AM, Gervase Markham wrote:

> A quick quiz:
>
> Q1: What git commands would I use to obtain an exact copy of 4.4.6 from
> our git repo?
>
> Q2: Same question for 4.4.4.
>
> As far as I can see, the only way of doing this currently is to do:
>
> git clone http://git.mozilla.org/bugzilla/bugzilla.git
> cd bugzilla
> git log
> <look for the final 4.4.4 commit>
> git checkout <sha1>
> <get strange message about "detached HEAD">
>
> Am I wrong?

Almost.  You would do up to 'cd bugzilla', then

git checkout bugzilla-4.4.6

'bugzilla-4.4.6' is a tag on the last commit included in the release.
We create similar tags for all releases.

Yes, you will then often get a message about a detached head.  What that
means is that you are no longer on the head (very latest commit) of a
particular branch; you've gone back in time.  That's fine, but it means
you can't push anything up to git.mozilla.org without creating a new
branch--which is the correct behaviour, since the detached-head message
means there are commits done in that branch after this tag was made, and
you don't want to change history.  I would imagine you wouldn't be
interested in creating new commits if you were looking to go back to
4.4.6's exact last commit anyway.

Regarding Randall's message, we could branch for every release; indeed,
given git's very light-weight approach to branches, there are many
strategies for developing under git.  However, given our relatively
small change volume, I don't think it's worth the extra overhead, at the
moment at least.

Let me know if anything is still unclear.  Btw, for anyone still
confused about git, I *highly* recommend the book Pro Git, which is
available for free at http://git-scm.com/book/.  It's pretty much
essential to understand the model behind git to do anything beyond the
basics, and that book will definitely help you (I felt much more
knowledgeable after just the first few chapters).

Mark

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Michiel Beijen
Hi,

On Fri, Oct 31, 2014 at 7:29 PM, Mark Côté <[hidden email]> wrote:
>
> On 2014-10-31 7:26 AM, Gervase Markham wrote:
> > A quick quiz:
> >
> > Q1: What git commands would I use to obtain an exact copy of 4.4.6 from
> > our git repo?
> >
> > Q2: Same question for 4.4.4.

> Regarding Randall's message, we could branch for every release; indeed,
> given git's very light-weight approach to branches, there are many
> strategies for developing under git.  However, given our relatively
> small change volume, I don't think it's worth the extra overhead, at the
> moment at least.

I don't think there would be any additional benefit for having
branches over tags for releases. I think tags are actually beneficial
since they are *fixed* i.e. they can not change over time (as with a
release, which you create at one given day and then it's out of the
door, as with the 4.4.4 release) whereas the branch has the
possibility of future releases: you might want to check out the branch
of 4.4 to work on it to create 4.4.7 one day. And if you want to go
back to 4.4.4 or 3.2.whatever then you can still check out the tag,
create a branch from that point with your patch, or perform your test,
and it would work.

Git also has the notion of signed tags so you can cryptographically
guarantee a tag is exact *this* version of the project, and the source
has not been messed with. Although I think I don't know many projects
that actually use this feature. Usually a sha1 of a tarbal is deemed
enough.

If you have a reasonably new git (1.8) you can even clone a repo at a
given tag. So your question above would be answered with:

git clone --branch bugzilla-4.4.6 http://git.mozilla.org/bugzilla/bugzilla

BTW the answer of your initial question is also mentioned on this
page: https://wiki.mozilla.org/Bugzilla:Git#Getting_A_Specific_Release

--
Mike
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Damien
I would do...

cd bugzilla

# hum, what is new today?
git fetch

# hum what tags are there (in case i missed reading the output of git fetch)
git tags

# hum what branches are still alive?
git branches -a

# I want that one for some reason.
git checkout bugzilla-4.4.6

...

# let's get to business.
git checkout -b werk origin/4.4
git add ...
git commit ...

# reviews.
# more hacking
# ...
# done
git push origin werk:origin/4.4




On Fri, Oct 31, 2014 at 3:10 PM, Michiel Beijen <[hidden email]> wrote:
Hi,

On Fri, Oct 31, 2014 at 7:29 PM, Mark Côté <[hidden email]> wrote:
>
> On 2014-10-31 7:26 AM, Gervase Markham wrote:
> > A quick quiz:
> >
> > Q1: What git commands would I use to obtain an exact copy of 4.4.6 from
> > our git repo?
> >
> > Q2: Same question for 4.4.4.

> Regarding Randall's message, we could branch for every release; indeed,
> given git's very light-weight approach to branches, there are many
> strategies for developing under git.  However, given our relatively
> small change volume, I don't think it's worth the extra overhead, at the
> moment at least.

I don't think there would be any additional benefit for having
branches over tags for releases. I think tags are actually beneficial
since they are *fixed* i.e. they can not change over time (as with a
release, which you create at one given day and then it's out of the
door, as with the 4.4.4 release) whereas the branch has the
possibility of future releases: you might want to check out the branch
of 4.4 to work on it to create 4.4.7 one day. And if you want to go
back to 4.4.4 or 3.2.whatever then you can still check out the tag,
create a branch from that point with your patch, or perform your test,
and it would work.

Git also has the notion of signed tags so you can cryptographically
guarantee a tag is exact *this* version of the project, and the source
has not been messed with. Although I think I don't know many projects
that actually use this feature. Usually a sha1 of a tarbal is deemed
enough.

If you have a reasonably new git (1.8) you can even clone a repo at a
given tag. So your question above would be answered with:

git clone --branch bugzilla-4.4.6 http://git.mozilla.org/bugzilla/bugzilla

BTW the answer of your initial question is also mentioned on this
page: https://wiki.mozilla.org/Bugzilla:Git#Getting_A_Specific_Release

--
Mike
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>

Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Gervase Markham
In reply to this post by Gervase Markham
On 31/10/14 12:33, Simon Green wrote:
> I would turn the question around. If you are using git (or bzr or csv)
> to get code, what is wrong with getting the latest code for the branch,
> rather than the latest release of the code?

Because then each person who has "4.4.6" installed actually has slightly
different code to everyone else. If I want to reproduce your bug, I
can't just ask you what version you have, I have to ask for the SHA-1 ID.

I'm not sure I know of any project which has defined "version X.Y.Z" as
referring to any one of 10 possible versions of the code which existed
around that time", and I can sort of see why no-one has tried this. :-)

Gerv

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Gervase Markham
In reply to this post by Mark Côté
On 31/10/14 18:29, Mark Côté wrote:
> Almost.  You would do up to 'cd bugzilla', then
>
> git checkout bugzilla-4.4.6
>
> 'bugzilla-4.4.6' is a tag on the last commit included in the release.
> We create similar tags for all releases.

You see, I did not know that. That is important information :-)

So your "Almost" is actually a "not really"!

I will update the new docs accordingly.

How about this for a suggestion? We currently tag the first in the "4.4"
series as "bugzilla-4.4". Would it be better to tag it as
"bugzilla-4.4.0", either instead or additionally? That would make
instructions on how to pull a particular version easier to write,
because you wouldn't need to special-case the first release.

You see, it's not immediately clear to an observer if
git checkout bugzilla-4.4
is pulling the latest 4.4 or the original release of 4.4.

> Let me know if anything is still unclear.  Btw, for anyone still
> confused about git, I *highly* recommend the book Pro Git, which is
> available for free at http://git-scm.com/book/.

I've been reading O'Reillys "Version control with Git" which is also
very good.

Gerv

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Gervase Markham
In reply to this post by Mark Côté
On 31/10/14 22:10, Michiel Beijen wrote:
> If you have a reasonably new git (1.8) you can even clone a repo at a
> given tag. So your question above would be answered with:
>
> git clone --branch bugzilla-4.4.6 http://git.mozilla.org/bugzilla/bugzilla

So to be clear: you use "--branch" even if you are cloning at a given tag?

Will the repo you get be exactly the same, the only difference being
that the checkout will be switched to the correct branch/tag?

> BTW the answer of your initial question is also mentioned on this
> page: https://wiki.mozilla.org/Bugzilla:Git#Getting_A_Specific_Release

Why did I not know about that page? :-) There's good stuff in there.

Gerv

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Gervase Markham
In reply to this post by Mark Côté
On 31/10/14 18:29, Mark Côté wrote:
> Almost.  You would do up to 'cd bugzilla', then
>
> git checkout bugzilla-4.4.6
>
> 'bugzilla-4.4.6' is a tag on the last commit included in the release.
> We create similar tags for all releases.

You see, I did not know that. That is important information :-)

So your "Almost" is actually a "not really"!

I will update the new docs accordingly.

How about this for a suggestion? We currently tag the first in the "4.4"
series as "bugzilla-4.4". Would it be better to tag it as
"bugzilla-4.4.0", either instead or additionally? That would make
instructions on how to pull a particular version easier to write,
because you wouldn't need to special-case the first release.

You see, it's not immediately clear to an observer if
git checkout bugzilla-4.4
is pulling the latest 4.4 or the original release of 4.4.

> Let me know if anything is still unclear.  Btw, for anyone still
> confused about git, I *highly* recommend the book Pro Git, which is
> available for free at http://git-scm.com/book/.

I've been reading O'Reillys "Version control with Git" which is also
very good.

Gerv

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Mark Côté
In reply to this post by Gervase Markham
On 2014-11-03 8:45 AM, Gervase Markham wrote:
> On 31/10/14 18:29, Mark Côté wrote:
>> Almost.  You would do up to 'cd bugzilla', then
>>
>> git checkout bugzilla-4.4.6
>>
>> 'bugzilla-4.4.6' is a tag on the last commit included in the release.
>> We create similar tags for all releases.
>
> You see, I did not know that. That is important information :-)

It's the same procedure we did with bzr, no?  It's also a very common
practice.  That said, if it's not documented anywhere, I agree that it
should be.

> How about this for a suggestion? We currently tag the first in the "4.4"
> series as "bugzilla-4.4". Would it be better to tag it as
> "bugzilla-4.4.0", either instead or additionally? That would make
> instructions on how to pull a particular version easier to write,
> because you wouldn't need to special-case the first release.
>
> You see, it's not immediately clear to an observer if
> git checkout bugzilla-4.4
> is pulling the latest 4.4 or the original release of 4.4.

I would counter for two reasons:

1. The name of the release is 4.4, not 4.4.0.  I would argue that it's
more confusing that, to find 4.4's release, you have to look for
bugzilla-4.4.0, that is, unless we want to change how we name the
initial release of a new version.

2. bugzilla-4.4 is a tag, whereas 4.4 is a branch.  Across many VCSes,
not just git, tags are used to indicate snapshots, often releases, and
branches are where development specific to a base release (e.g. 4.4.*)
occurs.  This is again roughly how we used bzr.  If you ever want the
latest of anything, you go to the head of the branch.  It's the same for
master as it is for any release branch.

Mark



_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Gervase Markham
On 03/11/14 14:13, Mark Côté wrote:
> It's the same procedure we did with bzr, no?  

Yes, indeed. I just hadn't twigged that Git had tags and that we were
still using them. <shrug> For some reason, I expected to see them listed
with "git branch".

> It's also a very common
> practice.  That said, if it's not documented anywhere, I agree that it
> should be.

Well, it's because I'm writing the docs that I asked! :-) But it seems
to be documented on the wiki.

> 1. The name of the release is 4.4, not 4.4.0.

That would be a reason to tag as 4.4.0 in addition, rather than instead
of, 4.4.

> 2. bugzilla-4.4 is a tag, whereas 4.4 is a branch.  

That is true. However, it seems from previous conversations that git
uses git checkout --branch to pull both. I'm just saying it may not be
obvious to a new Bugzilla admin that:

git checkout --branch bugzilla-4.4

gives you the checkout of a tag, which doesn't move, but:

git checkout --branch 4.4

gives you a branch, which does.

> Across many VCSes,
> not just git, tags are used to indicate snapshots, often releases, and
> branches are where development specific to a base release (e.g. 4.4.*)
> occurs.  This is again roughly how we used bzr.  If you ever want the
> latest of anything, you go to the head of the branch.  It's the same for
> master as it is for any release branch.

I'm not arguing we should change our plan about what's a branch and
what's a tag, or change our general development practice.

It's not a big deal, though.

Gerv

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Gervase Markham
In reply to this post by Gervase Markham
On 31/10/14 11:26, Gervase Markham wrote:
> A quick quiz:

OK, follow up. So it seems like the best way to get from git a copy of
Bugzilla to run is:

git clone http://git.mozilla.org/bugzilla/bugzilla.git
cd bugzilla
git checkout bugzilla-stable

This will give you whatever the latest stable code is, right?

Some time later, as an admin, I want to update my code to take the
latest security releases for my version. What do I do? If I try:

git pull
git checkout bugzilla-stable

might well upgrade me to a new version, if one has been released
mean-time! I could find out what the new version is from the release
announcement and do:

git pull
git checkout bugzilla-X.Y.Z

but it would be easier to document if we had

bugzilla-4.2-stable
bugzilla-4.4-stable
etc.

tags. Looking at the list, we don't seem to have them. Are they a good idea?

Gerv

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Mark Côté
In reply to this post by Gervase Markham
On 2014-11-03 9:24 AM, Gervase Markham wrote:
> On 03/11/14 14:13, Mark Côté wrote:
>> 1. The name of the release is 4.4, not 4.4.0.
>
> That would be a reason to tag as 4.4.0 in addition, rather than instead
> of, 4.4.

Sure, that still strikes me as slightly confusing (browsing the list of
tags, seeing "bugzilla-4.4.0", then looking at release list and not
seeing it).  But less so than not taking bugzilla-4.4 at all.  However,
see my proposal at the bottom of this post.

>> 2. bugzilla-4.4 is a tag, whereas 4.4 is a branch.  
>
> That is true. However, it seems from previous conversations that git
> uses git checkout --branch to pull both. I'm just saying it may not be
> obvious to a new Bugzilla admin that:
>
> git checkout --branch bugzilla-4.4
>
> gives you the checkout of a tag, which doesn't move, but:
>
> git checkout --branch 4.4
>
> gives you a branch, which does.

Wellllll sorta.  Branches and tags are almost the exact same thing in
git.  The difference is that the latter (--branch 4.4) takes you to the
*HEAD* of the 4.4 branch.  Essentially, "4.4" is a movable tag that
always points to the last commit in that branch (the HEAD), whereas
"bugzilla-4.4" is always frozen to a particular commit.

You can see how the two ideas bleed over when you try checking out a
remote branch, e.g. 'git checkout <origin>/<branch>'; although you are
checking out someone's *branch*, since it's remote you can't add to it,
so you are given the same "detached head" warning (you have to create a
local branch to do commits).  But I digress. :)

Maybe a lot of confusion would be eliminated by using the tag name
"release-4.4" instead of "bugzilla-4.4".  Really, "bugzilla" is pretty
redundant in tag names.  I would be up for doing that (we can also
retroactively apply that tag name, though we'd want to leave the old
style in there as well for existing releases).

Mark

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Mark Côté
In reply to this post by Gervase Markham
On 2014-11-03 9:27 AM, Gervase Markham wrote:
> On 31/10/14 11:26, Gervase Markham wrote:
> but it would be easier to document if we had
>
> bugzilla-4.2-stable
> bugzilla-4.4-stable
> etc.
>
> tags. Looking at the list, we don't seem to have them. Are they a good idea?

Not a bad idea at all; however, I would want to make them technically
branches, not tags, since tags are supposed to be unmovable (we should
be doing this with bugzilla-stable as well, but I'm not sure how, since
it jumps from branch to branch).  But you don't have to think of them as
branches, since they won't diverge from the parent branch.  It will
avoid having to do a "push -f", which we need to do with bugzilla-stable
right now, but which we should actually never ever never do.

Mark

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Gervase Markham
In reply to this post by Mark Côté
On 03/11/14 14:46, Mark Côté wrote:
> Maybe a lot of confusion would be eliminated by using the tag name
> "release-4.4" instead of "bugzilla-4.4".  Really, "bugzilla" is pretty
> redundant in tag names.  I would be up for doing that (we can also
> retroactively apply that tag name, though we'd want to leave the old
> style in there as well for existing releases).

Yep, I'd buy that. We'd want to retroactively apply it in order to make
writing documentation easier. That would eliminate the confusion, I think.

Gerv


_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Gervase Markham
In reply to this post by Mark Côté
On 03/11/14 14:53, Mark Côté wrote:
> Not a bad idea at all; however, I would want to make them technically
> branches, not tags, since tags are supposed to be unmovable (we should
> be doing this with bugzilla-stable as well, but I'm not sure how, since
> it jumps from branch to branch).  But you don't have to think of them as
> branches, since they won't diverge from the parent branch.  It will
> avoid having to do a "push -f", which we need to do with bugzilla-stable
> right now, but which we should actually never ever never do.

Yes, that sounds like a good idea.

Do we actually want a bugzilla-stable branch/tag? Given the risks of
accidentally moving from e.g. 4.2 to 4.4 by using it, why would anyone
ever want to track it?

I think we should only have "bugzilla-X.X-stable" branches, and if
someone wants to upgrade further than a point release, they have to
actively take the steps to move branch (git checkout etc.) rather than
just a git pull.

So the workflows would then be:

Initial installation:

git clone http://git.mozilla.org/bugzilla/bugzilla.git
cd bugzilla
git checkout bugzilla-4.2-stable

Upgrade to latest 4.2 release at any time:

git pull

Upgrade to 4.4:

git pull
git checkout bugzilla-4.4-stable

That all seems nice and simple to me.

Gerv

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Mark Côté
On 2014-11-03 10:15 AM, Gervase Markham wrote:

> On 03/11/14 14:53, Mark Côté wrote:
>> Not a bad idea at all; however, I would want to make them technically
>> branches, not tags, since tags are supposed to be unmovable (we should
>> be doing this with bugzilla-stable as well, but I'm not sure how, since
>> it jumps from branch to branch).  But you don't have to think of them as
>> branches, since they won't diverge from the parent branch.  It will
>> avoid having to do a "push -f", which we need to do with bugzilla-stable
>> right now, but which we should actually never ever never do.
>
> Yes, that sounds like a good idea.
>
> Do we actually want a bugzilla-stable branch/tag? Given the risks of
> accidentally moving from e.g. 4.2 to 4.4 by using it, why would anyone
> ever want to track it?
>
> I think we should only have "bugzilla-X.X-stable" branches, and if
> someone wants to upgrade further than a point release, they have to
> actively take the steps to move branch (git checkout etc.) rather than
> just a git pull.

A very good point.  I'm up for removing bugzilla-stable.  And in keeping
with the other thread, we should probably name these "release-X.X-stable".

> So the workflows would then be:
>
> Initial installation:
>
> git clone http://git.mozilla.org/bugzilla/bugzilla.git
> cd bugzilla
> git checkout bugzilla-4.2-stable

or just

git clone --branch bugzilla-4.2-stable
http://git.mozilla.org/bugzilla/bugzilla.git

> Upgrade to latest 4.2 release at any time:
>
> git pull
>
> Upgrade to 4.4:
>
> git pull
> git checkout bugzilla-4.4-stable

Technically in the upgrade case you just need to do

git fetch
git checkout bugzilla-4.4-stable

"pull" does a "fetch" but also also merges in changes to your current
branch, which you don't need if you'll be switching branches.

> That all seems nice and simple to me.

It sure does! :)

Mark

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Gervase Markham
On 03/11/14 15:39, Mark Côté wrote:
> A very good point.  I'm up for removing bugzilla-stable.  And in keeping
> with the other thread, we should probably name these "release-X.X-stable".

Well, release-4.4.6 would be a tag, but release-4.4-stable would be a
branch. And yet they feel like similar things. Is that a problem, or not?

> or just
>
> git clone --branch bugzilla-4.2-stable
> http://git.mozilla.org/bugzilla/bugzilla.git

Yes, indeed :-)

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: How we use Git

Mark Côté
On 2014-11-03 10:52 AM, Gervase Markham wrote:
> On 03/11/14 15:39, Mark Côté wrote:
>> A very good point.  I'm up for removing bugzilla-stable.  And in keeping
>> with the other thread, we should probably name these "release-X.X-stable".
>
> Well, release-4.4.6 would be a tag, but release-4.4-stable would be a
> branch. And yet they feel like similar things. Is that a problem, or not?

Hm, well, it's easy enough to tell which is which, and I'm not sure that
naming one "release" and one "bugzilla" would really lessen any
confusion.  They function pretty similarly, and I bet most people
probably wouldn't use the tag at all.  But I'm open to other suggestions.

Mark

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
12