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 follows is my dev list > post on this, which was agreed and not contested: > > (Early 2016) > --- > FYI as of March 15th (10 days now), commits to branches following the pattern > (lucene|solr).* (i.e. that which start with "lucene" or "solr") will *not* > get an automated comment on corresponding JIRAissues. All others continue > to. INFRA got this done for us: > https://issues.apache.org/jira/browse/INFRA-11198 > > I could have asked for a "jira" prefix too but leaving it this ways > encourages consistent branch naming that has been the most prevalent to date. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, Nov 19, 2019 at 7:35 PM Ishan Chattopadhyaya > wrote: >> >> 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 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 coordinate PR's against a >>> > > feature branch among >>> > > multiple developers? >>> > >>> > If you create a branch with a prefix and somebody forks the project >>> > and then creates a pull request then it's still going to be against >>> > that prefixed branch (read: I don't see the problem?). >>> > >>> > Branches are just labels attached to a commit. Nothing special about >>> > the slash character (I believe). >>> > >>> > >>> > D. >>> > >>> > - >>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> > For additional commands, e-mail: dev-h...@lucene.apache.org >>> > >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
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 of March 15th (10 days now), commits to branches following the pattern (lucene|solr).* (i.e. that which start with "lucene" or "solr") will *not* get an automated comment on corresponding JIRAissues. All others continue to. INFRA got this done for us: https://issues.apache.org/ jira/browse/INFRA-11198 I could have asked for a "jira" prefix too but leaving it this ways encourages consistent branch naming that has been the most prevalent to date. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Tue, Nov 19, 2019 at 7:35 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > 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 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 coordinate PR's against a >> feature branch among >> > > multiple developers? >> > >> > If you create a branch with a prefix and somebody forks the project >> > and then creates a pull request then it's still going to be against >> > that prefixed branch (read: I don't see the problem?). >> > >> > Branches are just labels attached to a commit. Nothing special about >> > the slash character (I believe). >> > >> > >> > D. >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
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 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 coordinate PR's against a > feature branch among > > > multiple developers? > > > > If you create a branch with a prefix and somebody forks the project > > and then creates a pull request then it's still going to be against > > that prefixed branch (read: I don't see the problem?). > > > > Branches are just labels attached to a commit. Nothing special about > > the slash character (I believe). > > > > > > D. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
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 sane order > (because of prefixes). > > > If we follow that, can we use github to coordinate PR's against a feature > > branch among > > multiple developers? > > If you create a branch with a prefix and somebody forks the project > and then creates a pull request then it's still going to be against > that prefixed branch (read: I don't see the problem?). > > Branches are just labels attached to a commit. Nothing special about > the slash character (I believe). > > > D. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
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 coordinate PR's against a feature > branch among > multiple developers? If you create a branch with a prefix and somebody forks the project and then creates a pull request then it's still going to be against that prefixed branch (read: I don't see the problem?). Branches are just labels attached to a commit. Nothing special about the slash character (I believe). D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
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? -Mike - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
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 all the JIRA branches +1 if you can pull that off, that would help. But if we start pushing hundreds of jira branches it clutters things up, so we should remember to delete those branches after merge. > Using a feature branch is good for collaboration. Every committer > automatically had access to your branch That should also be possible on github PRs now (there’s a checkbox), but have not tried it yet. Jan Høydahl > 3. aug. 2019 kl. 01:13 skrev Noble Paul (JIRA) : > > >[ > https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899269#comment-16899269 > ] > > Noble Paul commented on SOLR-13677: > --- > > What we need is avoid notifications for commits to all the JIRA branches . > Using a feature branch is good for collaboration. Every committer > automatically had access to your branch > >> All Metrics Gauges should be unregistered by the objects that registered them >> - >> >>Key: SOLR-13677 >>URL: https://issues.apache.org/jira/browse/SOLR-13677 >>Project: Solr >> Issue Type: Improvement >> Security Level: Public(Default Security Level. Issues are Public) >> Components: metrics >> Reporter: Noble Paul >> Priority: Major >> Time Spent: 10m >> Remaining Estimate: 0h >> >> The life cycle of Metrics producers are managed by the core (mostly). So, if >> the lifecycle of the object is different from that of the core itself, these >> objects will never be unregistered from the metrics registry. This will lead >> to memory leaks > > > > -- > This message was sent by Atlassian JIRA > (v7.6.14#76016)
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 merge commit even when a fast forward is possible. This way I see the whole feature as a deviation from the main line of development. > In this case though, the branch has lots of tiny commits -- not because i > thought they were good and self contained, but because i was having > problems and wanted to share the current state with folks to seek feedback > & help in diagnosing problems. > i think squashing makes the most sense. I agree. It helps a lot, especially for self-contained things. Dawid - 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?
: 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 : make sense on its own, and I don't usually make lots of tiny commits. : Again, that is just my style, so for me, keeping that history is useful. gotcha - yeah. In this case though, the branch has lots of tiny commits -- not because i thought they were good and self contained, but because i was having problems and wanted to share the current state with folks to seek feedback & help in diagnosing problems. (i can think of at least 5 commits i would have happily squashed via "git-rebase -i" once i figured out why something was broken -- but i'd already pushed to get feedback to try and understand why it was broken) : If you feel more comfortable squashing into one commit, go for it. I was : only trying to explain why I thought it *can* be useful. I appreciate that ... the --first-parent tip in particular is a good note, but ultimately (at least in this case) i think squashing makes the most sense. Thanks guys. -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?
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 > attached to jira) but i don't see how every tiny commit made to the > feature branch over several months as designs evolved/changed and files > were added/removed is relevant to the master branch. > For me, I find it useful just to be able to identify the difference between a merge commit into the branch (ie syncing the branch up with master), vs another commit in the branch. This distinction can be useful eg when I see some odd looking code, and I want to identify if it was intentional, or possibly a mistake in merge resolution. It's not a perfect rule, it is gives me guidance on the probability of the reason for the suspicious code. 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 make sense on its own, and I don't usually make lots of tiny commits. Again, that is just my style, so for me, keeping that history is useful. If you feel more comfortable squashing into one commit, go for it. I was only trying to explain why I thought it *can* be useful.
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 lot of intermediate crap : It doesn't pollute history, it *is* history. If you want to only view the : history of the "main line" of development (ie each merge is just the single : merge commit), then use --first-parent in your log command. Hmm... but that's only a git-log feature correct? for things like "git bisect" all those intermediate commits that don't pass tests/precommit are still considered commits on the master line. 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 attached to jira) but i don't see how every tiny commit made to the feature branch over several months as designs evolved/changed and files were added/removed is relevant to the master branch. -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?
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 > emails among other things, but more importantly it pollutes history > with a lot of intermediate crap > It doesn't pollute history, it *is* history. If you want to only view the history of the "main line" of development (ie each merge is just the single merge commit), then use --first-parent in your log command.
Re: Git Policy/Preference: how to fold in feature branches? squash?
: 1) git merge (no fast forward) : : This creates a single merge commit that points to two parents -- the 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 lot of intermediate crap... : All of the above are useful, depends on the situation. A single : "squashed" commit is simpler to port across to other branches (it's a : single "patch" after all). It also helps to drop the noisy changes : that possibly happened during development (nocommits, intermediate : refactorings, etc.), leaving only the "clean" feature patch. yeah ... basically exactly what i want ... this keeps master and branch_6x cleaner for things like git bisect, and doesn't "lose" any historical info about decisions made because they will still be viewable in jira/SOLR-445 (and mirrors how we would do land patches or do branch merges with svn) : On the other hand, if the feature branch is long-lived and you want to : merge more than once (for some reason), you're better off with a : regular merge (because then subsequent merges would only apply : differential commits). Yep -- not something i am particularly worried about. Thanks Dawid: i mainly just wnated to make sure i hadn't missed a memo somewhere that said "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 that points to two parents -- the previous commit on master and the latest commit on jira/SOLR-445. It will preserve the history of commits on jira/SOLR-445 (exact hashes of those commits you made, etc.). 2) git merge (fast forward) If there were no intermediate commits on master since you branched jira/SOLR-445 the merge commit is not strictly necessary -- you can simply move the label of 'master' to the latest commit in jira/SOLR-445. This would also preserve all the commits you made on jira/SOLR-445, but you would no longer clearly "see" the branch-merge deviation from the master "line". Try gitk --all if you don't know what I mean. 3) git merge --squash this is effectively taking a diff of all the commits that happened on jira/SOLR-445 since it was branched from master, and this diff is applied to master as a single commit. There is no "record" of where the patch comes from (unless you leave the default commit log, which includes commit hashes, but they don't mean a thing if you remove jira/SOLR-445). > is a regular "git merge --no-squash" prefered for some reason i'm overlooking? All of the above are useful, depends on the situation. A single "squashed" commit is simpler to port across to other branches (it's a single "patch" after all). It also helps to drop the noisy changes that possibly happened during development (nocommits, intermediate refactorings, etc.), leaving only the "clean" feature patch. On the other hand, if the feature branch is long-lived and you want to merge more than once (for some reason), you're better off with a regular merge (because then subsequent merges would only apply differential commits). Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
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 jira/SOLR-445 to master" # now master has a single commit #DEADBEEF for all SOLR-445 related # work. but the full history of decisions made is still in branch # jira/SOLR-445 # later, once things have baked on master for a bit. # on branch_6x ... git cherry-pick DEADBEEF ...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, and that doesn't really seem neccessary/helpful to most people. Or am i missing something? is a regular "git merge --no-squash" prefered for some reason i'm overlooking? -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
