<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 5, 2014 at 5:15 AM, Angus Salkeld <span dir="ltr"><<a href="mailto:angus.salkeld@rackspace.com" target="_blank">angus.salkeld@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Tue, 2014-08-05 at 03:18 +0400, Yuriy Taraday wrote:<br>
> Hello, git-review users!<br>
><br>
><br>
> I'd like to gather feedback on a feature I want to implement that<br>
> might turn out useful for you.<br>
><br>
><br>
> I like using Git for development. It allows me to keep track of<br>
> current development process, it remembers everything I ever did with<br>
> the code (and more).<br>
> I also really like using Gerrit for code review. It provides clean<br>
> interfaces, forces clean histories (who needs to know that I changed<br>
> one line of code in 3am on Monday?) and allows productive<br>
> collaboration.<br>
> What I really hate is having to throw away my (local, precious for me)<br>
> history for all change requests because I need to upload a change to<br>
> Gerrit.<br>
<br>
</div>I just create a short-term branch to record this.<br></blockquote><div><br></div><div style>I tend to use branches that are squashed down to one commit after the first upload and that's it. I'd love to keep all history during feature development, not just the tip of it.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
><br>
><br>
> That's why I want to propose making git-review to support the workflow<br>
> that will make me happy. Imagine you could do smth like this:<br>
><br>
><br>
> 0. create new local branch;<br>
><br>
><br>
> master: M--....<br>
> \<br>
> feature: *<br>
><br>
><br>
> 1. start hacking, doing small local meaningful (to you) commits;<br>
><br>
><br>
> master: M--....<br>
> \<br>
> feature: A-B-...-C<br>
><br>
><br>
> 2. since hacking takes tremendous amount of time (you're doing a Cool<br>
> Feature (tm), nothing less) you need to update some code from master,<br>
> so you're just merging master in to your branch (i.e. using Git as<br>
> you'd use it normally);<br>
><br>
> master: M--....-N-O-...<br>
> \ \ \<br>
> feature: A-B-...-C-D-...<br>
><br>
><br>
> 3. and now you get the first version that deserves to be seen by<br>
> community, so you run 'git review', it asks you for desired commit<br>
> message, and <poof, magic-magic> all changes from your branch is<br>
> uploaded to Gerrit as _one_ change request;<br>
><br>
> master: M--....-N-O-...<br>
> \ \ \----E* <= uploaded<br>
> feature: A-B-...-C-D-...-E<br>
><br>
><br>
> 4. you repeat steps 1 and 2 as much as you like;<br>
> 5. and all consecutive calls to 'git review' will show you last commit<br>
> message you used for upload and use it to upload new state of your<br>
> local branch to Gerrit, as one change request.<br>
><br>
><br>
> Note that during this process git-review will never run rebase or<br>
> merge operations. All such operations are done by user in local branch<br>
> instead.<br>
><br>
><br>
> Now, to the dirty implementations details.<br>
><br>
><br>
> - Since suggested feature changes default behavior of git-review,<br>
> it'll have to be explicitly turned on in config<br>
> (review.shadow_branches? review.local_branches?). It should also be<br>
> implicitly disabled on master branch (or whatever is in .gitreview<br>
> config).<br>
> - Last uploaded commit for branch <branch-name> will be kept in<br>
> refs/review-branches/<branch-name>.<br>
> - For every call of 'git review' it will find latest commit in<br>
> gerrit/master (or remote and branch from .gitreview), create a new one<br>
> that will have that commit as its parent and a tree of current commit<br>
> from local branch as its tree.<br>
> - While creating new commit, it'll open an editor to fix commit<br>
> message for that new commit taking it's initial contents from<br>
> refs/review-branches/<branch-name> if it exists.<br>
> - Creating this new commit might involve generating a temporary bare<br>
> repo (maybe even with shared objects dir) to prevent changes to<br>
> current index and HEAD while using bare 'git commit' to do most of the<br>
> work instead of loads of plumbing commands.<br>
><br>
><br>
> Note that such approach won't work for uploading multiple change<br>
> request without some complex tweaks, but I imagine later we can<br>
> improve it and support uploading several interdependent change<br>
> requests from several local branches. We can resolve dependencies<br>
> between them by tracking latest merges (if branch myfeature-a has been<br>
> merged to myfeature-b then change request from myfeature-b will depend<br>
> on change request from myfeature-a):<br>
><br>
> master: M--....-N-O-...<br>
> \ \ \---------E*<br>
> myfeature-a: A-B-...-C-D-...-E \<br>
> \ \ J* <= uploaded<br>
> myfeature-b: F-...-G-I-J<br>
><br>
><br>
> This improvement would be implemented later if needed.<br>
><br>
><br>
> I hope such feature seams to be useful not just for me and I'm looking<br>
> forward to some comments on it.<br>
<br>
</div></div>Hi Yuriy,<br>
<br>
I like my local history matching what is up for review and<br>
don't value the interim messy commits (I make a short term branch to<br>
save the history so I can go back to it - if I mess up a merge).<br></blockquote><div><br></div><div style>You'll still get this history in those special refs. But in your branch you'll have your own history.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Tho' others might love this idea.<br>
<br>
-Angus<br><br></blockquote></div><br clear="all"><div><br></div>-- <br><br><div>Kind regards, Yuriy.</div>
</div></div>