Open Stack

On Tue, 2014-08-05 at 03:18 +0400, Yuriy Taraday wrote:
> 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.

I just create a short-term branch to record this.

> 
> 
> 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.

Hi Yuriy,

I like my local history matching what is up for review and
don't value the interim messy commits (I make a short term branch to
save the history so I can go back to it - if I mess up a merge).

Tho' others might love this idea.

-Angus

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140805/7476526d/attachment.pgp>