Naming branches so that life is easier

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

Naming branches so that life is easier

Dawid Weiss-2
Hey folks. Just noticed new branches are being pushed to the Apache
repository. Having digested SVN's branches I'd like to suggest a
naming convention for branches so that they appear more palatable. For
example:

$ git branch -r
  origin/HEAD -> origin/master
  origin/apiv2
  origin/branch_3x
  origin/branch_4x
  origin/branch_5x
  origin/lucene-6835
  origin/master
  origin/master-solr-8621


The labels (branches and tags) in git can be pseudo-hierarchical. It
is therefore nice to see more "semantic" branches, like:

origin/jira/solr8621
origin/dweiss/fooBarExperiment
origin/staging/lucene-solr-x.y.z

I don't think it's realistic to enforce any rigid convention, but I'm
sure you get the gist.

These branches are no different to regular, they're just labeled with a slash:

# checkout a given branch/ commit (master here) and create a branch from it.
git checkout master -b dweiss/jira3826
# push this branch to origin and make it track changes on the origin's
pushed branch.
git push origin HEAD -u

This is a suggestion only, not a requirement, but I'm sure you'll grow
to like it. The upside is that everyone then knows whether it's your
experimental stuff, something still being worked on, etc.

Dawid

P.S. There is always a way to "rename" a branch -- it is a label
attached to a commit after all -- I'll leave these commands for you to
digest:

git checkout master-solr-8621 -b jira/solr8621-master
git push origin HEAD -u
# remove local branch
git branch -D master-solr-8621
# remove remote branch (use *only* on the stuff you actually control
and merged back or abandoned)
git push origin :master-solr-8621

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Naming branches so that life is easier

Michael McCandless-2
Thanks for the points Dawid ... I'll try to follow this going forward.

The use of a single inserted ':' to mean "delete this branch" is a
scary design to me...

Mike McCandless

http://blog.mikemccandless.com


On Wed, Feb 3, 2016 at 4:59 AM, Dawid Weiss <[hidden email]> wrote:

> Hey folks. Just noticed new branches are being pushed to the Apache
> repository. Having digested SVN's branches I'd like to suggest a
> naming convention for branches so that they appear more palatable. For
> example:
>
> $ git branch -r
>   origin/HEAD -> origin/master
>   origin/apiv2
>   origin/branch_3x
>   origin/branch_4x
>   origin/branch_5x
>   origin/lucene-6835
>   origin/master
>   origin/master-solr-8621
>
>
> The labels (branches and tags) in git can be pseudo-hierarchical. It
> is therefore nice to see more "semantic" branches, like:
>
> origin/jira/solr8621
> origin/dweiss/fooBarExperiment
> origin/staging/lucene-solr-x.y.z
>
> I don't think it's realistic to enforce any rigid convention, but I'm
> sure you get the gist.
>
> These branches are no different to regular, they're just labeled with a slash:
>
> # checkout a given branch/ commit (master here) and create a branch from it.
> git checkout master -b dweiss/jira3826
> # push this branch to origin and make it track changes on the origin's
> pushed branch.
> git push origin HEAD -u
>
> This is a suggestion only, not a requirement, but I'm sure you'll grow
> to like it. The upside is that everyone then knows whether it's your
> experimental stuff, something still being worked on, etc.
>
> Dawid
>
> P.S. There is always a way to "rename" a branch -- it is a label
> attached to a commit after all -- I'll leave these commands for you to
> digest:
>
> git checkout master-solr-8621 -b jira/solr8621-master
> git push origin HEAD -u
> # remove local branch
> git branch -D master-solr-8621
> # remove remote branch (use *only* on the stuff you actually control
> and merged back or abandoned)
> git push origin :master-solr-8621
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Naming branches so that life is easier

Dawid Weiss-2
> The use of a single inserted ':' to mean "delete this branch" is a
> scary design to me...

This is scary, crappy and trappy (as Robert pointed out to me in a
private discussion). Unfortunately there is no other syntax (that I
know of) that could replace it.

Also, branches (and tags) propagate to people's own forked clones and
they *stay* there, at least until somebody "prunes" their set of
remote tags or branches (intentionally not giving the command syntax
here...).

My remark about making branches more "semantic" was in part also
because deleting branches (from the origin) is prone to errors and not
that intuitive (it is logical, but not intuitive). So we can just
leave branches forever but it'll quickly get sickly scary if we just
name them whatever at the top level.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Naming branches so that life is easier

Dawid Weiss-2
> Unfortunately there is no other syntax (that I  know of) that could replace it.

Actually, you can create an alias for deleting a local (and remote)
branch, but I think this is even more scary than just learning what
the ':' stands for in a push...

http://stackoverflow.com/a/16740731/1633019

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Naming branches so that life is easier

Stefan Matheis-2
since git 1.7.0 you can use "git push origin --delete <branchName>"
instead of "git push origin :<branchName>", which makes a bit more
sense :) found that option some time ago on
http://stackoverflow.com/a/2003515

-Stefan

On Wed, Feb 3, 2016 at 11:19 AM, Dawid Weiss <[hidden email]> wrote:

>> Unfortunately there is no other syntax (that I  know of) that could replace it.
>
> Actually, you can create an alias for deleting a local (and remote)
> branch, but I think this is even more scary than just learning what
> the ':' stands for in a push...
>
> http://stackoverflow.com/a/16740731/1633019
>
> D.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Naming branches so that life is easier

Dawid Weiss-2
Thanks Stefan, this is good to know!

Dawid

On Wed, Feb 3, 2016 at 4:22 PM, Stefan Matheis <[hidden email]> wrote:

> since git 1.7.0 you can use "git push origin --delete <branchName>"
> instead of "git push origin :<branchName>", which makes a bit more
> sense :) found that option some time ago on
> http://stackoverflow.com/a/2003515
>
> -Stefan
>
> On Wed, Feb 3, 2016 at 11:19 AM, Dawid Weiss <[hidden email]> wrote:
>>> Unfortunately there is no other syntax (that I  know of) that could replace it.
>>
>> Actually, you can create an alias for deleting a local (and remote)
>> branch, but I think this is even more scary than just learning what
>> the ':' stands for in a push...
>>
>> http://stackoverflow.com/a/16740731/1633019
>>
>> D.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Naming branches so that life is easier

david.w.smiley@gmail.com
In reply to this post by Dawid Weiss-2
Establishing conventions and adhering to them would be good.

Some observations I have with your example:  you suggested a hypothetical branch named "dweiss/jira3826".  IMO that branch name isn't a great name because it is ambiguous with respect to it being for Lucene or Solr.  Most of our branches in the past have been in the format for the JIRA issue; sometimes lowercased or sometimes with an underscore.  It'd be nice to standardize that.  I propose the form "solr_3626" but I care little and only would like to see something adhered to.  Incorporating a branch for a JIRA issue with someone's user id is I think questionable, but I have no strong opinion.  I think we should generally do it or not do it.

~ David

On Wed, Feb 3, 2016 at 5:00 AM Dawid Weiss <[hidden email]> wrote:
Hey folks. Just noticed new branches are being pushed to the Apache
repository. Having digested SVN's branches I'd like to suggest a
naming convention for branches so that they appear more palatable. For
example:

$ git branch -r
  origin/HEAD -> origin/master
  origin/apiv2
  origin/branch_3x
  origin/branch_4x
  origin/branch_5x
  origin/lucene-6835
  origin/master
  origin/master-solr-8621


The labels (branches and tags) in git can be pseudo-hierarchical. It
is therefore nice to see more "semantic" branches, like:

origin/jira/solr8621
origin/dweiss/fooBarExperiment
origin/staging/lucene-solr-x.y.z

I don't think it's realistic to enforce any rigid convention, but I'm
sure you get the gist.

These branches are no different to regular, they're just labeled with a slash:

# checkout a given branch/ commit (master here) and create a branch from it.
git checkout master -b dweiss/jira3826
# push this branch to origin and make it track changes on the origin's
pushed branch.
git push origin HEAD -u

This is a suggestion only, not a requirement, but I'm sure you'll grow
to like it. The upside is that everyone then knows whether it's your
experimental stuff, something still being worked on, etc.

Dawid

P.S. There is always a way to "rename" a branch -- it is a label
attached to a commit after all -- I'll leave these commands for you to
digest:

git checkout master-solr-8621 -b jira/solr8621-master
git push origin HEAD -u
# remove local branch
git branch -D master-solr-8621
# remove remote branch (use *only* on the stuff you actually control
and merged back or abandoned)
git push origin :master-solr-8621

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
Reply | Threaded
Open this post in threaded view
|

Re: Naming branches so that life is easier

Shai Erera
I think that all remote branches should be JIRA related. I.e. I don't see myself pushing a remote branch like shaie/something. Since we do all development through JIRA, then if someone experiments with something and wants to push it to the Git repo, I think that should be done within the context of a JIRA issue.

Naming these branches jira/lucene-XXXX or jira/solr-XXXX (I don't mind if we use hyphen or underscore) or dropping the jira/ prefix -- I'm fine w/ both. I personally don't think that we need the JIRA prefix, since it's pretty obvious to tell by the name of the branch, but I can go either way.

Shai

On Thu, Feb 4, 2016 at 12:01 AM [hidden email] <[hidden email]> wrote:
Establishing conventions and adhering to them would be good.

Some observations I have with your example:  you suggested a hypothetical branch named "dweiss/jira3826".  IMO that branch name isn't a great name because it is ambiguous with respect to it being for Lucene or Solr.  Most of our branches in the past have been in the format for the JIRA issue; sometimes lowercased or sometimes with an underscore.  It'd be nice to standardize that.  I propose the form "solr_3626" but I care little and only would like to see something adhered to.  Incorporating a branch for a JIRA issue with someone's user id is I think questionable, but I have no strong opinion.  I think we should generally do it or not do it.

~ David


On Wed, Feb 3, 2016 at 5:00 AM Dawid Weiss <[hidden email]> wrote:
Hey folks. Just noticed new branches are being pushed to the Apache
repository. Having digested SVN's branches I'd like to suggest a
naming convention for branches so that they appear more palatable. For
example:

$ git branch -r
  origin/HEAD -> origin/master
  origin/apiv2
  origin/branch_3x
  origin/branch_4x
  origin/branch_5x
  origin/lucene-6835
  origin/master
  origin/master-solr-8621


The labels (branches and tags) in git can be pseudo-hierarchical. It
is therefore nice to see more "semantic" branches, like:

origin/jira/solr8621
origin/dweiss/fooBarExperiment
origin/staging/lucene-solr-x.y.z

I don't think it's realistic to enforce any rigid convention, but I'm
sure you get the gist.

These branches are no different to regular, they're just labeled with a slash:

# checkout a given branch/ commit (master here) and create a branch from it.
git checkout master -b dweiss/jira3826
# push this branch to origin and make it track changes on the origin's
pushed branch.
git push origin HEAD -u

This is a suggestion only, not a requirement, but I'm sure you'll grow
to like it. The upside is that everyone then knows whether it's your
experimental stuff, something still being worked on, etc.

Dawid

P.S. There is always a way to "rename" a branch -- it is a label
attached to a commit after all -- I'll leave these commands for you to
digest:

git checkout master-solr-8621 -b jira/solr8621-master
git push origin HEAD -u
# remove local branch
git branch -D master-solr-8621
# remove remote branch (use *only* on the stuff you actually control
and merged back or abandoned)
git push origin :master-solr-8621

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
Reply | Threaded
Open this post in threaded view
|

Re: Naming branches so that life is easier

Jack Krupansky-3
I don't recall any discussion of the status of existing svn non-release branches (most of which were named LUCENE-<Jira#>)... was it decided to just abandon them or are they hidden somewhere now in git/github?

And is the new policy to encourage such branches in git/github or that people should keep them in private forks?

-- Jack Krupansky

On Thu, Feb 4, 2016 at 1:32 AM, Shai Erera <[hidden email]> wrote:
I think that all remote branches should be JIRA related. I.e. I don't see myself pushing a remote branch like shaie/something. Since we do all development through JIRA, then if someone experiments with something and wants to push it to the Git repo, I think that should be done within the context of a JIRA issue.

Naming these branches jira/lucene-XXXX or jira/solr-XXXX (I don't mind if we use hyphen or underscore) or dropping the jira/ prefix -- I'm fine w/ both. I personally don't think that we need the JIRA prefix, since it's pretty obvious to tell by the name of the branch, but I can go either way.

Shai

On Thu, Feb 4, 2016 at 12:01 AM [hidden email] <[hidden email]> wrote:
Establishing conventions and adhering to them would be good.

Some observations I have with your example:  you suggested a hypothetical branch named "dweiss/jira3826".  IMO that branch name isn't a great name because it is ambiguous with respect to it being for Lucene or Solr.  Most of our branches in the past have been in the format for the JIRA issue; sometimes lowercased or sometimes with an underscore.  It'd be nice to standardize that.  I propose the form "solr_3626" but I care little and only would like to see something adhered to.  Incorporating a branch for a JIRA issue with someone's user id is I think questionable, but I have no strong opinion.  I think we should generally do it or not do it.

~ David


On Wed, Feb 3, 2016 at 5:00 AM Dawid Weiss <[hidden email]> wrote:
Hey folks. Just noticed new branches are being pushed to the Apache
repository. Having digested SVN's branches I'd like to suggest a
naming convention for branches so that they appear more palatable. For
example:

$ git branch -r
  origin/HEAD -> origin/master
  origin/apiv2
  origin/branch_3x
  origin/branch_4x
  origin/branch_5x
  origin/lucene-6835
  origin/master
  origin/master-solr-8621


The labels (branches and tags) in git can be pseudo-hierarchical. It
is therefore nice to see more "semantic" branches, like:

origin/jira/solr8621
origin/dweiss/fooBarExperiment
origin/staging/lucene-solr-x.y.z

I don't think it's realistic to enforce any rigid convention, but I'm
sure you get the gist.

These branches are no different to regular, they're just labeled with a slash:

# checkout a given branch/ commit (master here) and create a branch from it.
git checkout master -b dweiss/jira3826
# push this branch to origin and make it track changes on the origin's
pushed branch.
git push origin HEAD -u

This is a suggestion only, not a requirement, but I'm sure you'll grow
to like it. The upside is that everyone then knows whether it's your
experimental stuff, something still being worked on, etc.

Dawid

P.S. There is always a way to "rename" a branch -- it is a label
attached to a commit after all -- I'll leave these commands for you to
digest:

git checkout master-solr-8621 -b jira/solr8621-master
git push origin HEAD -u
# remove local branch
git branch -D master-solr-8621
# remove remote branch (use *only* on the stuff you actually control
and merged back or abandoned)
git push origin :master-solr-8621

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker

Reply | Threaded
Open this post in threaded view
|

RE: Naming branches so that life is easier

Uwe Schindler

Hi,

 

they are still there as tags. If you want to “reactivate” them, just create a new branch from the tag:

 

e.g., history/branches/lucene-solr/solr7790

 

Most of them were unused (because we did not always delete them at reintegrate), so we just moved them to history as tags.

 

In general I have private branches in my local checkout. I name them “private/LUCENE-xxxx” and never push them. For larger changes where more than one person works on, we can push branches, but as discussed before, they should follow a naming convention and should not be top-level.

 

Uwe

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

http://www.thetaphi.de

eMail: [hidden email]

 

From: Jack Krupansky [mailto:[hidden email]]
Sent: Thursday, February 04, 2016 3:00 PM
To: Lucene-dev <[hidden email]>
Subject: Re: Naming branches so that life is easier

 

I don't recall any discussion of the status of existing svn non-release branches (most of which were named LUCENE-<Jira#>)... was it decided to just abandon them or are they hidden somewhere now in git/github?

 

And is the new policy to encourage such branches in git/github or that people should keep them in private forks?


-- Jack Krupansky

 

On Thu, Feb 4, 2016 at 1:32 AM, Shai Erera <[hidden email]> wrote:

I think that all remote branches should be JIRA related. I.e. I don't see myself pushing a remote branch like shaie/something. Since we do all development through JIRA, then if someone experiments with something and wants to push it to the Git repo, I think that should be done within the context of a JIRA issue.

Naming these branches jira/lucene-XXXX or jira/solr-XXXX (I don't mind if we use hyphen or underscore) or dropping the jira/ prefix -- I'm fine w/ both. I personally don't think that we need the JIRA prefix, since it's pretty obvious to tell by the name of the branch, but I can go either way.

Shai

 

On Thu, Feb 4, 2016 at 12:01 AM [hidden email] <[hidden email]> wrote:

Establishing conventions and adhering to them would be good.

 

Some observations I have with your example:  you suggested a hypothetical branch named "dweiss/jira3826".  IMO that branch name isn't a great name because it is ambiguous with respect to it being for Lucene or Solr.  Most of our branches in the past have been in the format for the JIRA issue; sometimes lowercased or sometimes with an underscore.  It'd be nice to standardize that.  I propose the form "solr_3626" but I care little and only would like to see something adhered to.  Incorporating a branch for a JIRA issue with someone's user id is I think questionable, but I have no strong opinion.  I think we should generally do it or not do it.

 

~ David

 

On Wed, Feb 3, 2016 at 5:00 AM Dawid Weiss <[hidden email]> wrote:

Hey folks. Just noticed new branches are being pushed to the Apache
repository. Having digested SVN's branches I'd like to suggest a
naming convention for branches so that they appear more palatable. For
example:

$ git branch -r
  origin/HEAD -> origin/master
  origin/apiv2
  origin/branch_3x
  origin/branch_4x
  origin/branch_5x
  origin/lucene-6835
  origin/master
  origin/master-solr-8621


The labels (branches and tags) in git can be pseudo-hierarchical. It
is therefore nice to see more "semantic" branches, like:

origin/jira/solr8621
origin/dweiss/fooBarExperiment
origin/staging/lucene-solr-x.y.z

I don't think it's realistic to enforce any rigid convention, but I'm
sure you get the gist.

These branches are no different to regular, they're just labeled with a slash:

# checkout a given branch/ commit (master here) and create a branch from it.
git checkout master -b dweiss/jira3826
# push this branch to origin and make it track changes on the origin's
pushed branch.
git push origin HEAD -u

This is a suggestion only, not a requirement, but I'm sure you'll grow
to like it. The upside is that everyone then knows whether it's your
experimental stuff, something still being worked on, etc.

Dawid

P.S. There is always a way to "rename" a branch -- it is a label
attached to a commit after all -- I'll leave these commands for you to
digest:

git checkout master-solr-8621 -b jira/solr8621-master
git push origin HEAD -u
# remove local branch
git branch -D master-solr-8621
# remove remote branch (use *only* on the stuff you actually control
and merged back or abandoned)
git push origin :master-solr-8621

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--

Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker

 

Reply | Threaded
Open this post in threaded view
|

Re: Naming branches so that life is easier

Jack Krupansky-3
Thanks, Uwe. I guess the problem is that the tas list is way too long to easily view in the drop-down list, compared to the full page view I am used to from the old svn view.

Is there some way to reorder the tags? I mean, most commonly I just want to access recent releases, but 5.4.1 is way down the list. And Solr 1.4 is right at the top! I guess I'll have to use the search box to more quickly access releases.

The fact that all the tags have this long string of "releases/(lucene|solr|lucene-solr)/" prefixes just makes it even less easy to use the drop-down list.

The branch drop-down will probably quickly hit that non-ease of use if people push a lot of work-in-progress branches. Again, i would be nice if the most recent branches were at the top of the list.

But these are all relatively minor nits. Overall, I'm happier to view code in github than the old viewvc. Somebody still needs to update the Solr Resources page to include the github link in addition to the legacy svn viewvc link.


-- Jack Krupansky

On Thu, Feb 4, 2016 at 9:49 AM, Uwe Schindler <[hidden email]> wrote:

Hi,

 

they are still there as tags. If you want to “reactivate” them, just create a new branch from the tag:

 

e.g., history/branches/lucene-solr/solr7790

 

Most of them were unused (because we did not always delete them at reintegrate), so we just moved them to history as tags.

 

In general I have private branches in my local checkout. I name them “private/LUCENE-xxxx” and never push them. For larger changes where more than one person works on, we can push branches, but as discussed before, they should follow a naming convention and should not be top-level.

 

Uwe

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

http://www.thetaphi.de

eMail: [hidden email]

 

From: Jack Krupansky [mailto:[hidden email]]
Sent: Thursday, February 04, 2016 3:00 PM
To: Lucene-dev <[hidden email]>
Subject: Re: Naming branches so that life is easier

 

I don't recall any discussion of the status of existing svn non-release branches (most of which were named LUCENE-<Jira#>)... was it decided to just abandon them or are they hidden somewhere now in git/github?

 

And is the new policy to encourage such branches in git/github or that people should keep them in private forks?


-- Jack Krupansky

 

On Thu, Feb 4, 2016 at 1:32 AM, Shai Erera <[hidden email]> wrote:

I think that all remote branches should be JIRA related. I.e. I don't see myself pushing a remote branch like shaie/something. Since we do all development through JIRA, then if someone experiments with something and wants to push it to the Git repo, I think that should be done within the context of a JIRA issue.

Naming these branches jira/lucene-XXXX or jira/solr-XXXX (I don't mind if we use hyphen or underscore) or dropping the jira/ prefix -- I'm fine w/ both. I personally don't think that we need the JIRA prefix, since it's pretty obvious to tell by the name of the branch, but I can go either way.

Shai

 

On Thu, Feb 4, 2016 at 12:01 AM [hidden email] <[hidden email]> wrote:

Establishing conventions and adhering to them would be good.

 

Some observations I have with your example:  you suggested a hypothetical branch named "dweiss/jira3826".  IMO that branch name isn't a great name because it is ambiguous with respect to it being for Lucene or Solr.  Most of our branches in the past have been in the format for the JIRA issue; sometimes lowercased or sometimes with an underscore.  It'd be nice to standardize that.  I propose the form "solr_3626" but I care little and only would like to see something adhered to.  Incorporating a branch for a JIRA issue with someone's user id is I think questionable, but I have no strong opinion.  I think we should generally do it or not do it.

 

~ David

 

On Wed, Feb 3, 2016 at 5:00 AM Dawid Weiss <[hidden email]> wrote:

Hey folks. Just noticed new branches are being pushed to the Apache
repository. Having digested SVN's branches I'd like to suggest a
naming convention for branches so that they appear more palatable. For
example:

$ git branch -r
  origin/HEAD -> origin/master
  origin/apiv2
  origin/branch_3x
  origin/branch_4x
  origin/branch_5x
  origin/lucene-6835
  origin/master
  origin/master-solr-8621


The labels (branches and tags) in git can be pseudo-hierarchical. It
is therefore nice to see more "semantic" branches, like:

origin/jira/solr8621
origin/dweiss/fooBarExperiment
origin/staging/lucene-solr-x.y.z

I don't think it's realistic to enforce any rigid convention, but I'm
sure you get the gist.

These branches are no different to regular, they're just labeled with a slash:

# checkout a given branch/ commit (master here) and create a branch from it.
git checkout master -b dweiss/jira3826
# push this branch to origin and make it track changes on the origin's
pushed branch.
git push origin HEAD -u

This is a suggestion only, not a requirement, but I'm sure you'll grow
to like it. The upside is that everyone then knows whether it's your
experimental stuff, something still being worked on, etc.

Dawid

P.S. There is always a way to "rename" a branch -- it is a label
attached to a commit after all -- I'll leave these commands for you to
digest:

git checkout master-solr-8621 -b jira/solr8621-master
git push origin HEAD -u
# remove local branch
git branch -D master-solr-8621
# remove remote branch (use *only* on the stuff you actually control
and merged back or abandoned)
git push origin :master-solr-8621

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--

Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker

 


Reply | Threaded
Open this post in threaded view
|

Re: Naming branches so that life is easier

Dawid Weiss-2
> was it decided to just abandon them or are they hidden somewhere now in git/github?

Read here:
https://github.com/dweiss/lucene-git-guides/blob/master/10-locate-historical-svn-commit-or-branch.sh

> The fact that all the tags have this long string of "releases/(lucene|solr|lucene-solr)/" prefixes just makes it even less easy to use the drop-down list.

Maybe. But the drop-down list is not git on apache, it's github. The
naming convention was suggested by me (search the archives) and nobody
objected. I don't see any other (better) way of differentiating tags
from three (!) different projects and making this transparent.

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Naming branches so that life is easier

Uwe Schindler
Hi,

> > was it decided to just abandon them or are they hidden somewhere now in
> git/github?
>
> Read here:
> https://github.com/dweiss/lucene-git-guides/blob/master/10-locate-
> historical-svn-commit-or-branch.sh
>
> > The fact that all the tags have this long string of
> "releases/(lucene|solr|lucene-solr)/" prefixes just makes it even less easy to
> use the drop-down list.
>
> Maybe. But the drop-down list is not git on apache, it's github. The
> naming convention was suggested by me (search the archives) and nobody
> objected. I don't see any other (better) way of differentiating tags
> from three (!) different projects and making this transparent.

To me this makes 100% sense. Generally you won't need them every day. As said before, if you are looking for an old release, it is now easy to fine. You can also download Lucene 1.0.1 !!! (phantastic, no idea where 1.0 is - sourceforge only?)

The abandoned branches under history are easy to reactivate (as said before), just branch off the tag - done.

Finally, Github also orders the drop downlist in correct order (backwards by version), so where is the issue? If you figured out how its ordered, you can switch very fast. Many thanks for this, I am fully happy. Really everything is there - in contrast to SVN where you have to search!

Uwe


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]