Re: [openstack-dev] [git-upstream] [Duplicate Changes] How to view only commits applied since last import
On 18/11/16 15:27, Darragh Bailey - mailing lists wrote: > > At this point, now you'll see X, X' & X'', and Y, Y' & Y''. Obviously > this cause a bit of confusion when listing the changes using: > > git log --oneline --graph E~1..local/mitaka > > you see something like the following (see [1] for how I created this): > > * 899cb6e [O] Merging Y2 into N > |\ > | * 3c08f48 [Y] Adding tmp7wtzvo69 <--- really Y'' > | * db8d2c3 [X] Adding tmpnxot0u9s > | * 97cc90c [I] Adding tmps2xhxp2f > * | 9ea35c3 [N] Merging Y1 into Y > |\ \ > | * | f361e9f [Y] Adding tmp7wtzvo69 <--- really Y' > | * | 90d58eb [X] Adding tmpnxot0u9s > | |/ > | * ed973e6 [G] Adding tmpb443aabz > | * 74cd9b8 [E] Adding tmpwcrm4bxi > * 3cc85cf [Y] Adding tmp7wtzvo69 <--- original Y > * e93f6cb [X] Adding tmpnxot0u9s I forgot to add the reference for how I generated that tree: git clone git://git.openstack.org/openstack/git-upstream cd git-upstream cat < test.yaml - tree: - [A, []] - [E, [A]] - [G, [E]] - [I, [G]] - [X, [A]] - [Y, [X]] - [X1, [G]] - [Y1, [X1]] - [N, [Y, =Y1]] - [X2, [I]] - [Y2, [X2]] - [O, [N, =Y2]] branches: head: [local/mitaka, O] upstream: [stable/mitaka, I] EOF tox -e build-tree -- test.yaml cd .git-test-trees/test -- Regards, Darragh Bailey IRC: electrofelix "Nothing is foolproof to a sufficiently talented fool" - Unknown __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [git-upstream] [Duplicate Changes] How to view only commits applied since last import
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. As mentioned I thought it might be worth addressing this piece separately, and then hopefully re-factor what's here to be added to the git-upstream docs. To start with, lets step through what things look like, and then I'll try explain why git-upstream merges history in this way. Assuming there are two local changes being carried locally that have not yet been accepted upstream. These were initally added to a local/mitaka branch and two imports were subsequently performed and the changes have not yet landed on stable/mitaka: X---Y---NO local/mitaka / // / X'--Y' / (rebase of X & Y onto G) / // / / X''--Y'' / / / -E---G---Iupstreams stable/mitaka branch When syncing latest from upstream stable/mitaka was initially at G, and this resulted git-upstream replaying X' being onto G and then creating a merge commit N which has exactly the same contents as the tree at X'. When you look at the history of N you'll see: X---Y---N / / / X'--Y' / / -E---G And then looking at O shows X---Y---NO local/mitaka / // / X'--Y' / / // / / X''--Y'' / / / -E---G---I At this point, now you'll see X, X' & X'', and Y, Y' & Y''. Obviously this cause a bit of confusion when listing the changes using: git log --oneline --graph E~1..local/mitaka you see something like the following (see [1] for how I created this): * 899cb6e [O] Merging Y2 into N |\ | * 3c08f48 [Y] Adding tmp7wtzvo69 <--- really Y'' | * db8d2c3 [X] Adding tmpnxot0u9s | * 97cc90c [I] Adding tmps2xhxp2f * | 9ea35c3 [N] Merging Y1 into Y |\ \ | * | f361e9f [Y] Adding tmp7wtzvo69 <--- really Y' | * | 90d58eb [X] Adding tmpnxot0u9s | |/ | * ed973e6 [G] Adding tmpb443aabz | * 74cd9b8 [E] Adding tmpwcrm4bxi * 3cc85cf [Y] Adding tmp7wtzvo69 <--- original Y * e93f6cb [X] Adding tmpnxot0u9s If this is limited further to: git log --oneline --graph stable/mitaka..local/mitaka * 899cb6e [O] Merging Y2 into N |\ | * 3c08f48 [Y] Adding tmp7wtzvo69 <--- really Y'' | * db8d2c3 [X] Adding tmpnxot0u9s * 9ea35c3 [N] Merging Y1 into Y |\ | * f361e9f [Y] Adding tmp7wtzvo69 <--- really Y' | * 90d58eb [X] Adding tmpnxot0u9s * 3cc85cf [Y] Adding tmp7wtzvo69 * e93f6cb [X] Adding tmpnxot0u9s <--- original Y This looks like the same 2 changes have been applied three times, and in a way, they have. This obviously can be confusing. Hence you're proposed change to provide a way to display only the interesting commits so instead would see: * 899cb6e [O] Merging Y2 into N * 3c08f48 [Y] Adding tmp7wtzvo69 <--- really Y'' * db8d2c3 [X] Adding tmpnxot0u9s > Thanks in advance for anything that might help cut through some of the > confusion. > > Cheers, > -Paul Back to the question as to why git-upstream does it this way: Looked at possibility of merges, just land patches against the tree and then on a regular basis attempt to merge in the latest from upstream. * It's possible (if a little awkward at the moment) to extract information on how many local patches are being carried. Merging would meant that you wouldn't see the same patches from the series duplicated, but you would have multiple commits in your local history that are likely not identifiable as cherry-picks of the final accepted change upstream (how many patches are accepted without any changes?) * Re-applying changes allows for conflicts with changes to be resolved in the relevant patch. Otherwise the conflicts are resolved inside a merge commit can be quite hard to review. Subsequently when the changes are accepted upstream, and then merged in on the next sync the conflicts generated will frequently be different since the change accepted upstream will be slightly different. Using a patch series approach allows to automatically drop the duplicate changes, and re-apply an update series, using a manual merge commit with conflict resolution means likely someone is going to have to spend more time resolving conflicts. * Want to avoid rebasing published branches. As far as developers inside a company are concerned, the local branches are published history, and for them to co-operate when issues need to be fixed for internal testing/releases to continue, rewriting history is likely going to make life more difficult. Rebasing a published branch can work, and I know some linux kernel developers have
