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 <[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
