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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: This is a digitally signed message part
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
