Re: feature branches

I love this, David. Thanks! On Thu, Nov 21, 2019 at 7:58 PM David Smiley wrote: > > Yes; I'm partly responsible for that choice. Basically I want us to > standardize our branch names, and thus this feature of no noisy bot comments > pertaining to commits is exclusive to lowercase. What

Re: feature branches

Yes; I'm partly responsible for that choice. Basically I want us to standardize our branch names, and thus this feature of no noisy bot comments pertaining to commits is exclusive to lowercase. What follows is my dev list post on this, which was agreed and not contested: (Early 2016) --- FYI as

Re: feature branches

Just another piece of gem that I know if is that if your feature branch name is in lowercase, commits there don't generate jira comments. On Wed, 20 Nov, 2019, 3:02 AM Michael Sokolov, wrote: > got it, thanks! > > On Tue, Nov 19, 2019 at 4:10 PM Dawid Weiss wrote: > > > > > Hoss said branches

Re: feature branches

got it, thanks! On Tue, Nov 19, 2019 at 4:10 PM Dawid Weiss wrote: > > > Hoss said branches must be named starting jira/, but I'm not familiar > > with this convention. > > This convention is merely so that when you do "git branch -r" the > branches displayed are sorted and presented in some

Re: feature branches

> Hoss said branches must be named starting jira/, but I'm not familiar > with this convention. This convention is merely so that when you do "git branch -r" the branches displayed are sorted and presented in some sane order (because of prefixes). > If we follow that, can we use github to

feature branches

Hi, can someone point me to how-to for feature branches? Recently, Hoss said branches must be named starting jira/, but I'm not familiar with this convention. Is it written down somewhere? If we follow that, can we use github to coordinate PR's against a feature branch among multiple developers

Use of asf-git feature branches

(Continuing discussion on list instead of in arbitrary Jira) My original concern was that pushing your feature branches to asf git adds much noise to mailing lists and should be used sparingly for issues where we expect co-authoring. > What we need is avoid notifications for commits to

Re: Git Policy/Preference: how to fold in feature branches? squash?

> But it's a judgement call. I think most things in git are. That's why I wasn't really excited about having an official "how to commit" guide -- it is really a subjective decision how to fold in a set of commits. I sometimes even do: git merge --no-ff branch to explicitly preserve an explicit

Re: Git Policy/Preference: how to fold in feature branches? squash?

: I also think having large changes broken up is useful, even when not : viewing with first parent. But it's a judgement call. If I have a tiny : commit, and I tweak it maybe from a review comment, then I will usually : squash. If I have a large commit I am working on, I try to make each commit :

Re: Git Policy/Preference: how to fold in feature branches? squash?

On Fri, Mar 25, 2016 at 10:17 AM, Chris Hostetter wrote: > Ultimately that seems like history that should *not* be on the master > branch .. preserved, sure -- great even that it's in git and easily > browsable/comparable (unlike reivewing the evolution of patch files >

Re: Git Policy/Preference: how to fold in feature branches? squash?

: > It may only create a single commit, but from the perspective of people : > viewing master, it "adds" every commit that was on the jira/SOLR-445 : > branch to the master branch -- generating an metric ass-ton of : > emails among other things, but more importantly it pollutes history : > with a

Re: Git Policy/Preference: how to fold in feature branches? squash?

On Fri, Mar 25, 2016 at 9:59 AM, Chris Hostetter wrote: > It may only create a single commit, but from the perspective of people > viewing master, it "adds" every commit that was on the jira/SOLR-445 > branch to the master branch -- generating an metric ass-ton of >

Re: Git Policy/Preference: how to fold in feature branches? squash?

t;This is the prefered/recommended/required way to land feature branches in the lucene git model" -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Git Policy/Preference: how to fold in feature branches? squash?

> ...because, unless i'm missing something, if i don't use --squash then every > intermediate commit to branch jira/SOLR-445 will be replayed on master I think it's best explained in terms of patches and single commits, Chris. 1) git merge (no fast forward) This creates a single merge commit

Git Policy/Preference: how to fold in feature branches? squash?

SOLR-445 is fairly well done, and i'm ready to land it on master (and eventually branch_6x) My impression is that the sanest way to do that is... # on master ... git merge --squash jira/SOLR-445 emacs CHANGES.txt # to add CHANGES entry git commit -m "Merging branch