I'm a non git expert and I would prefer to have guidelines to follow. Understanding the complexities here is not something I have any interest in. I just want to merge and commit in some agreed apon standard way.
Joel Bernstein http://joelsolr.blogspot.com/ On Mon, Jan 25, 2016 at 10:37 AM, Shai Erera <ser...@gmail.com> wrote: > Hi Dawid, > > Yes, I know what --amend does. I never amend the parent commit, only my > initial commit. I think we're talking about the same thing, but just to > clarify, this is what I mean: > > git checkout -b feature-branch > git commit -a -m "message" > (Get reviews) > git commit --amend (addressing review comments) > > I do not intend to stack additional commits on top of the initial commit, > and then in the end squash them or whatever. I treat it all as one piece of > work and commit, and I don't think our history should reflect every comment > someone makes on an issue. In analogy, today in JIRA we always update a > full .patch file, and eventually commit it, irrespective of the number of > iterations that issue has gone through. > > Again, I think we're sync, but wanted to clarify what I meant. > > About the guidelines, I'd prefer that we use rebase, but that's not what I > was after with the guide. Today I've made my first commit to Git (in > Lucene!), and the way I handled trunk and branch_5x is as follows: > > git checkout -b feature master (i.e. trunk) > (work, commit locally, publish ...) > (time to push, i.e. SVN commit) > git fetch origin > git checkout master && git pull --rebase (this is nearly identical to the > previous 'svn up') > git checkout feature && git rebase master > git push origin HEAD:master (this is the equivalent of svn commit) > > ('merge' to branch_5x) > git checkout branch_5x > git pull --rebase (pulls from origin/branch_5x) > git checkout -b feature_5x branch_5x > git cherry-pick feature (this is partly 'svn merge') > git push origin HEAD:branch_5x > > (a) Is this (one of) the correct way to do it? > (b) Is there a less verbose way to do it, aside from rebasing feature on > origin/branch_5x? > > So, if we can have such sequence of operations written somewhere, even if > only as a proposed way to handle it, I think it will make it easy on the > Git newcomers among committers, since they're going to need to do this a > lot. And certainly if there's a quicker way to do it! > > Shai > > On Mon, Jan 25, 2016 at 5:15 PM Dawid Weiss <dawid.we...@gmail.com> wrote: > >> Hi Shai, >> >> > I usually do 'git commit --amend', >> >> When do you do this? Note that what the above command does is: >> >> 1) it takes the last commit on the current local branch, >> 2) it takes its parent commit, >> 3) it applies the diff from the last commit to the parent, permits you >> to modify the message and commits this new stuff on top of the parent, >> *resetting* the branch's HEAD reference to this new commit. >> >> If you already pushed your unamended commit to the remote then it's >> too late -- you'd end up with diverged local branch. Again, the >> simplest way to "see" this would be gitk. I'm sorry if I'm explaining >> something obvious. >> >> > is beneficial. But if I upload a patch, get reviews and intend to >> upload an >> > updated patch, I will --amend my commit. >> >> I don't see any relation with commits and --amend here. As long as >> you're working on a branch, this really doesn't matter -- you can just >> commit your changed stuff after a review and push it to a remote >> feature branch for others to see (or keep it local if you work on it >> alone). Amending commit is meant merely to fix a typo in a commit >> message. Yes, you can play with commits in a serious way (skipping >> commits, merging them together, changing commit contents, etc.), but >> this is really beyond the scope of a new git user (for those who are >> interested -- see what an interactive rebase is -- rebase -i). >> >> > I also agree w/ Uwe, I think it will really help if we have a >> > guidelines/cheatsheet that document how do we expect dev to happen in >> the >> > Git world. >> >> Even if it seems right I don't think this is realistic, given that >> people have their own preferences and (strong) opinions. For example I >> disagree with Mark that multiple merges and then final merge are a bad >> thing in general. They are fairly straightforward in the commit graph >> and they very clearly signify that somebody was working on their own >> stuff and periodically synced up with changes on the master (or any >> other branch). Finally, when the feature is ready, a merge to the >> mainline happens. It's no different to what we used in SVN, actually. >> This is a classic example of flying fish strategy -- it's been with >> versioning systems for ages. What I think Mark is worried about is >> merges across multiple branches, which indeed can quickly become >> mind-boggling. That's why I suggested that, at first, everyone should >> stick to simple cherry picks and squashed merges -- not that they're >> "the best" way to work with git, it's just that they're conceptually >> simpler to understand for those who start their adventure with >> distributed revision control systems. I personally use a lot of >> partial merges and I have no problem with them at all. >> >> > What you (Dawid) put on Github is great for Git newcomers, but as >> > a community I think that having rough standards and guidelines will >> help, >> >> I didn't have enough time and I'm on vacation with my family this >> week. But I agree with Robert here -- these guidelines should make the >> job easier for people who are new to git, but they should *not* >> restrict the liberty of how one chooses to work in general. We can >> make some restrictions with respect to "release" branches -- master, >> branch_5x, but I don't see the reason of forbidding whatever one >> desires on private branches. Also, see my example below. >> >> >> git merge origin/master # merge any changes from remote master, >> > >> > I would do a rebase here. Is there a reason you pick merge in the >> example - >> > i.e. do u think it's the preferred way, or was it just an example? >> (asking >> > for educational reasons) >> >> See the attached picture, it highlights four different ways in which a >> branch can be reintegrated into the mainline, definitely not >> exhausting all the possibilities. The difference between them is in: >> >> 1) how frequently (and when) you resolve conflicts against the branch >> you eventually target your work at; I'd argue it's simpler with >> multiple partial merges during your work on a feature than one final >> rebase (which needs to resolve conflicts for all commits), >> 2) whether you want others to see intermediate stages of your work or >> just the final outcome, >> 3) how difficult it'll be to reapply the patch to some other branch. >> 4) if you rebase your feature branch all the commits hashes change. In >> effect, you can't really work on a single feature branch with others >> -- you'd be overwriting each other's changes by forcing new commits >> with push to a common repository. >> >> I don't think any of them is better than another, they're just >> different. I do all of these things depending on the circumstances. >> >> > 'svn' does the equivalent of a git rebase when pushing a new commit >> that isn't otherwise some explicit merge. >> >> Hmm.. I think in this case the comparison to SVN is apples to oranges >> because SVN lacks a lot of the extended scenarios of what git rebasing >> is used for. In my example, see the fourth strategy -- this is >> canonical "merge a feature atomically, preserving all intermediate >> commits" case. It has benefits if you wish to see how the feature >> evolved, but it still very intuitive (and easy to revert). >> >> Dawid >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org > >
