* "Already up-to-date!" merge isn't a no-op?
[not found] <1826064298.2151517.1362605175796.JavaMail.root@genarts.com>
@ 2013-03-06 21:48 ` Stephen Bash
2013-03-06 22:08 ` Junio C Hamano
0 siblings, 1 reply; 2+ messages in thread
From: Stephen Bash @ 2013-03-06 21:48 UTC (permalink / raw)
To: Git Mailing List
Hi all-
I have a branch history that looks like this:
----------M-----M-- master
\ / /
x---------------- feature
\ \
x-------------A- maint
In other words we had a new feature that was "so cool" that after testing on master was back-ported to maint (luckily we knew ahead of time this was likely). When it came time to merge feature into maint the process looked something like this:
Yesterday (not shown above):
$ git checkout master
$ git merge maint
Today:
$ git checkout maint
$ git merge feature
Merge made by the 'recursive' strategy.
$ git checkout master
$ git merge maint
Already up-to-date!
Merge made by the 'recursive' strategy.
$ git --version
git version 1.8.1.5
In the past, I've only seen "Already up-to-date!" when there is literally nothing to do (all commits are reachable from HEAD). In this case, the merge of feature into maint (commit A) is the only commit not reachable from HEAD, and Git does create a merge commit (though the new commit and the first parent point to the same tree). The fact that a commit is created makes me call this something more than a no-op, even though no content changed.
So what is the actual meaning of "Already up-to-date!"? Is it based on the tree, the reachable commits, or something more complicated?
Thanks,
Stephen
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: "Already up-to-date!" merge isn't a no-op?
2013-03-06 21:48 ` "Already up-to-date!" merge isn't a no-op? Stephen Bash
@ 2013-03-06 22:08 ` Junio C Hamano
0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2013-03-06 22:08 UTC (permalink / raw)
To: Stephen Bash; +Cc: Git Mailing List
Stephen Bash <bash@genarts.com> writes:
> So what is the actual meaning of "Already up-to-date!"? Is it
> based on the tree, the reachable commits, or something more
> complicated?
The resulting tree of the merge happened to be the same as the
original tree (i.e. "git diff HEAD^ HEAD" is empty).
This happens quite often and is perfectly normal. After merging
topics that has been cooking in 'next' to 'master', merging the
resulting 'master' to 'next' is likely to result in that situation,
unless 'master' has gained some other changes, such as updating the
draft release notes with a commit on it, or applying an obvious and
trivial fix before cooking it in 'next'.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-03-06 22:08 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1826064298.2151517.1362605175796.JavaMail.root@genarts.com>
2013-03-06 21:48 ` "Already up-to-date!" merge isn't a no-op? Stephen Bash
2013-03-06 22:08 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).