Yuriy,

It looks like this would automate a standard workflow that my group often uses: 
multiple commits, create “delivery” branch, git merge --squash, git review.  
That looks really useful.

Having it be repeatable is a bonus.

Per last bullet of the implementation, I would not require not modifying 
current index/HEAD. A checkout back to working branch can be done at the end, 
right?

-Steve

From: Yuriy Taraday [mailto:yorik....@gmail.com]
Sent: Monday, August 04, 2014 16:18
To: openstack-dev; openstack-infra
Subject: [OpenStack-Infra] [git-review] Supporting development in local branches

Hello, git-review users!

I'd like to gather feedback on a feature I want to implement that might turn 
out useful for you.

I like using Git for development. It allows me to keep track of current 
development process, it remembers everything I ever did with the code (and 
more).
I also really like using Gerrit for code review. It provides clean interfaces, 
forces clean histories (who needs to know that I changed one line of code in 
3am on Monday?) and allows productive collaboration.
What I really hate is having to throw away my (local, precious for me) history 
for all change requests because I need to upload a change to Gerrit.

That's why I want to propose making git-review to support the workflow that 
will make me happy. Imagine you could do smth like this:

0. create new local branch;

master: M--....
         \
feature:  *

1. start hacking, doing small local meaningful (to you) commits;

master: M--....
         \
feature:  A-B-...-C

2. since hacking takes tremendous amount of time (you're doing a Cool Feature 
(tm), nothing less) you need to update some code from master, so you're just 
merging master in to your branch (i.e. using Git as you'd use it normally);

master: M--....-N-O-...
         \    \    \
feature:  A-B-...-C-D-...

3. and now you get the first version that deserves to be seen by community, so 
you run 'git review', it asks you for desired commit message, and <poof, 
magic-magic> all changes from your branch is uploaded to Gerrit as _one_ change 
request;

master: M--....-N-O-...
         \    \    \----E* <= uploaded
feature:  A-B-...-C-D-...-E

4. you repeat steps 1 and 2 as much as you like;
5. and all consecutive calls to 'git review' will show you last commit message 
you used for upload and use it to upload new state of your local branch to 
Gerrit, as one change request.

Note that during this process git-review will never run rebase or merge 
operations. All such operations are done by user in local branch instead.

Now, to the dirty implementations details.

- Since suggested feature changes default behavior of git-review, it'll have to 
be explicitly turned on in config (review.shadow_branches? 
review.local_branches?). It should also be implicitly disabled on master branch 
(or whatever is in .gitreview config).
- Last uploaded commit for branch <branch-name> will be kept in 
refs/review-branches/<branch-name>.
- For every call of 'git review' it will find latest commit in gerrit/master 
(or remote and branch from .gitreview), create a new one that will have that 
commit as its parent and a tree of current commit from local branch as its tree.
- While creating new commit, it'll open an editor to fix commit message for 
that new commit taking it's initial contents from 
refs/review-branches/<branch-name> if it exists.
- Creating this new commit might involve generating a temporary bare repo 
(maybe even with shared objects dir) to prevent changes to current index and 
HEAD while using bare 'git commit' to do most of the work instead of loads of 
plumbing commands.

Note that such approach won't work for uploading multiple change request 
without some complex tweaks, but I imagine later we can improve it and support 
uploading several interdependent change requests from several local branches. 
We can resolve dependencies between them by tracking latest merges (if branch 
myfeature-a has been merged to myfeature-b then change request from myfeature-b 
will depend on change request from myfeature-a):

master:    M--....-N-O-...
            \    \    \---------E*
myfeature-a: A-B-...-C-D-...-E   \
                      \       \   J* <= uploaded
myfeature-b:           F-...-G-I-J

This improvement would be implemented later if needed.

I hope such feature seams to be useful not just for me and I'm looking forward 
to some comments on it.

--
Kind regards, Yuriy.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to