Hi Paul
This might be a bit long, noticed a few more items to be added to the
documentation for git-upstream. Good thing documentation is the major
item for the next release ;-)
After an initial attempt at writing one response, I've decided to break
it up a bit into a couple of emails, because there a few topics in here
and one of them is pretty lengthy and the others follow somewhat
independent issues.
For this one I'll stick to just the 2nd and 4th paragraphs since they
are related.
And apologies in advance for anyone that didn't need to see such a dive
into git log behaviour here. :-)
On 17/11/16 12:47, Paul Bourke wrote:
> Hi Darragh / git-upstream community,
>
> I've been looking at a way to easily view a log of what commits made
> since the last upstream import when managing a branch with git-upstream.
> Right now this can be hard to do - something like 'git log
> upstream/master..HEAD' shows a lot of duplicate commits reasons I don't
> understand well enough to explain.
I'll go into that in a little more detail with a separate response, to
help anyone else reading or in the future searching. Definitely should
have been documented before now... O_o
> Darragh had suggested using the --dense option will help here, so 'git
> log --dense upstream/master..HEAD -- .' seems to generally give the
> right result. I've put up a patch to add this as a git-upstream command
> in the form of "carrying" at https://review.openstack.org/#/c/381669/.
> However, it seems there are in fact cases where the above command will
> show incorrect commits, and I'm struggling a bit to fully grok this.
Unfortunately explanation is going to be a bit lengthy, and there are
pieces of git here I'm not fully sure I understand what it's doing, and
plan to ask the git-users google group for a bit more info. Possibly may
require going to the git mailing list to get a complete picture
(g...@vger.kernel.org).
Until recently, I didn't fully grok the git-log(1) manpage,
https://www.kernel.org/pub/software/scm/git/docs/git-log.html,
specifically the section about "History Simplification", naturally I
didn't realise that until I understood what it was saying better.
Mainly to do with how TREESAME and !TREESAME apply to simplifying the
history walked and displayed.
TREESAME means that the resulting git tree is identical and you can have
multiple commits referencing the same TREE SHA1 in git. It's one of the
ways it avoids duplicating the same information, identical directories
result in the same SHA1, so each commit to a git tree only adds blobs
(for files) and tree (for directory) objects for what is different.
!TREESAME basically means there was something different between the two
directories or trees in the repo, and as git allows for path limiting,
this can be applied to any subdirectory in a git repository as well.
In the review I was referencing a particular scenario that we've come
across locally (see the url above):
1) Dev uploads a patch 'A' for review against branch tracking latest
from stable/mitaka (presumably also sent it upstream)
2) Nightly sync jobs run and bring down all the patches that landed in
the stable branch upstream over the last 24 hours
2.1) Git upstream is able to replay the current local changes without
conflict, dropping those that landed upstream automatically
2.2) Git-upstream merges the result into the tracking branch, and it now
becomes the new head (assuming it passes a gate check locally)
3) Following day or so, reviewer approves patch 'A' to land and it
merges without conflict.
See following for the actual test scenario, it's a bit more complex than
what I've discribed and the letters used differ:
https://github.com/openstack/git-upstream/blob/a52f01f89401e79db95ad9fee9195de90e5a71f2/git_upstream/tests/searchers/scenarios/changes_upload_prior_to_import.yaml
If git-upstream didn't do a special type of merge, and just produced a
new branch each time, we'd have to re-target patch 'A' to the new
branch, alternatively we could also have triggered a rebase of any
outstanding changes to avoid the particular git graph this produces.
Both of these seemed like unnecessary confusion and make-work for
developers/reviewers just trying to focus on landing changes.
The result is a git graph like the following (hope this displays correctly):
A
/ \
-M---X---N---O local/mitaka
/ /
/ X'---(rebase/cherry-pick of X onto G)
/ /
-E---F---G upstream stable/mitaka branch
M = the merge commit created by git-upstream for the previous sync
X = local change not yet upsteam
X' = replay of the local change X onto the latest stable/mitaka
N = most recent merge commit created by git-upstream
A is the commit created locally by a developer to fix a issue affecting
local deployments (and may need to be reworked for upstream)
O = merge commit created in Gerrit by approval of 'A'
When git-upstream created N, it made
