David, A few comments.> Naming Upstream > --------------- > > The intial clone from upstream results in a git remote reference with > the rather unhelpful name of "origin." As more remote sources get > added, it is easy to forget what "origin" is. Therefore, add a remote > with a more descriptive name. > > git remote add llvm-upstream http://llvm.org/git/llvm.git master > >If the intent is to rename origin, this can be done directly: git remote rename origin llvm-upstream> Updating LLVM - no local changes > -------------------------------- > >Splitting this into "no local changes" / "with local changes" seems unnecessarily complicated. Why not just recommend doing 'git pull --rebase' all of the time? I have to ask as well - is a linear history really desired? That seems to be the intent of your instructions. I ask because for something like a reasonably sized feature that might have multiple commits, having the merge history in place can be useful, if only to separate the set of related changes from sets of unrelated changes. It also aids in reverting an entire feature composed of multiple commits. One other comment - the way I use git (and from what I've read I am not alone), I end up committing multiple times per hour / many times per day, often into different branches. I then go back and use rebase to reorder and squash commits into logically related bite-sized chunks (e.g. combine some commits related to feature A into one or more commits, some related to feature B into one or more commits, and then there might be three bug fix commits for bugs C, D, and E.). It might be helpful to add some guidelines related to this that are in line with current LLVM review process - somewhat the reverse scenario of someone asking for commits to be split. In this case, they probably don't want to see 15 different commits that in total add 75 lines of code to feature A. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110822/f6c37ff0/attachment.html>
Mark Lacey <641 at rudkx.com> writes:> David, > > A few comments. > > > Naming Upstream > --------------- > > The intial clone from upstream results in a git remote reference with > the rather unhelpful name of "origin." As more remote sources get > added, it is easy to forget what "origin" is. Therefore, add a remote > with a more descriptive name. > > git remote add llvm-upstream http://llvm.org/git/llvm.git master > > If the intent is to rename origin, this can be done directly: > git remote rename origin llvm-upstreamor simpler, do it at clone time: git clone --origin llvm-upstream Note that git clone does not only set a remote, it also sets it as "upstream" for the master branch, i.e. "git pull" without argument will fetch from origin. Adding a new remote will not do that (but one can use the --set-upstream option of various commands to fix that later). That said, I don't think it's a good idea to ask users to rename their upstream in a guideline document. Naming upstream is personnal preference, and keeping the default seems sane for most users. If you don't remember what "origin" is, then .git/config can remind you.> Updating LLVM - no local changes > -------------------------------- > > Splitting this into "no local changes" / "with local changes" seems > unnecessarily complicated. Why not just recommend doing 'git pull > --rebase' all of the time?I'd also recommand "git pull --rebase" if the goal is to keep history linear. Note that this has to go with a big, fat, warning, telling the user that rebasing published history is bad. Rebase is a very good tool to work with private history, but as soon as you've pushed it to some place visible by other people, you should stop using it.> I ask because for something like a reasonably sized feature that might > have multiple commits, having the merge history in place can be > useful, if only to separate the set of related changes from sets of > unrelated changes.Rebase is exactly meant to do this separation, and avoid history looking like - start working on feature - merge from upstream - continue working on feature - merge again from upstream ... and remove the useless "merge from upstream" commits, that would just distract reviewers. Keeping merge history when merging several clean, published branches is good though. If you look at how Git itself is developped, people use rebase a lot to send clean patch series, and the maintainer uses merge a lot to merge multiple patch series together. -- Matthieu Moy http://www-verimag.imag.fr/~moy/
> I'd also recommand "git pull --rebase" if the goal is to keep history > linear. Note that this has to go with a big, fat, warning, telling the > user that rebasing published history is bad. Rebase is a very good tool > to work with private history, but as soon as you've pushed it to some > place visible by other people, you should stop using it.This is enormously important - once submodule maintainers starts rebasing, we're screwed.
Mark Lacey <641 at rudkx.com> writes:> git remote add llvm-upstream http://llvm.org/git/llvm.git master > > If the intent is to rename origin, this can be done directly: > git remote rename origin llvm-upstreamMuch better. Thanks.> Updating LLVM - no local changes > -------------------------------- > > Splitting this into "no local changes" / "with local changes" seems unnecessarily complicated. Why not just recommend doing 'git pull --rebase' > all of the time?Actually git pull can sometimes get you into trouble. Probably git fetch / git rebase is the better combination for LLVM. I agree my distinction is artificial but for the users who simply want the most up-to-date LLVM, git pull is simpler. I certainly debated back a forth. I have no problem reworking this.> I have to ask as well - is a linear history really desired? That seems > to be the intent of your instructions.It is a stated requirement of the project.> I ask because for something like a reasonably sized feature that might > have multiple commits, having the merge history in place can be > useful, if only to separate the set of related changes from sets of > unrelated changes. It also aids in reverting an entire feature > composed of multiple commits.Reverting is just as easy with linear history, I think. Chris has stated her wants reviews to be a simple as possible and linear history gets us that. There are some more interesting points made here: http://randyfay.com/node/91 Here's an interesting article with a proposal on how to get the best of both: http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html The follow-up linked at the bottom explains how it mgiht be implement. It requires changes to git, however. Personally, I kind of like the ideas presented but I doubt it will happen any time soon.> One other comment - the way I use git (and from what I've read I am > not alone), I end up committing multiple times per hour / many times > per day, often into different branches. I then go back and use rebase > to reorder and squash commits into logically related bite-sized chunks > (e.g. combine some commits related to feature A into one or more > commits, some related to feature B into one or more commits, and then > there might be three bug fix commits for bugs C, D, and E.). It might > be helpful to add some guidelines related to this that are in line > with current LLVM review process - somewhat the reverse scenario of > someone asking for commits to be split. In this case, they probably > don't want to see 15 different commits that in total add 75 lines of > code to feature A.That makes sense. I briefly mentioned squashing in the rebase -i explanation but I can expand on that. Thanks for your feedback! -Dave
> > > I have to ask as well - is a linear history really desired? That seems > > to be the intent of your instructions. > > It is a stated requirement of the project. >Thanks - I hadn't seen that stated explicitly. I understand the points you and others make wrt rebase vs. merging - I've seen many of the arguments before. I tend to rebase a lot since I tend to not be publishing and collaborating on feature branches (so I don't have the merges from mainline to feature branch, even if the feature branch stays around). As for 'git pull' vs. 'git fetch / git merge' - since this advice really seems aimed at beginners, you might want to suggest 'git pull --ff-only' or perhaps even go as far as suggesting 'git config merge.ff only' to absolutely enforce linear history (setting the latter would be problematic of course for people who want to create feature branches and merge, etc. prior to doing some final rebase and submitting patches). Reverting is just as easy with linear history, I think. Chris has> stated her wants reviews to be a simple as possible and linear history > gets us that. >Reverting using 'git revert' when you have a separate branch that is merged in requires a single revert of the merge commit, rather than reverting the individual commits that make up the feature. I don't see how having branches increases complexity of reviews - as long as the submitted patches are rebased on top of the mainline, you still have the appearance of linear history from the reviewers POV, but maintain a separate branch that can be committed. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110823/d927da77/attachment.html>
greened at obbligato.org (David A. Greene) writes:> Actually git pull can sometimes get you into trouble. Probably git > fetch / git rebase is the better combination for LLVM.I don't get it. Doesn't "git pull --rebase" do exactly a fetch followed by a rebase? -- Matthieu Moy http://www-verimag.imag.fr/~moy/