"Doing minor commits where you don't want a branch" -- but why wouldn't you want a branch? One of the great excellent points of Git is supposed to be that it makes branching so much easier, you can do branches in Git where you would never do it in SVN or any other version management system.
As for your three use cases where you recommend rebase, how will you prevent the problem described in the book if someone else has also worked on that branch? And what do you mean by "clean up commits" anyway? It is not at all clear from your description whether you think these use cases avoid rebasing pushes to a common repo, or you just don't think that is important; but how else can you avoid having to re-merge commits? The book may be "old fashioned", but it was written by one of the inventors of Git (I realize Torvalds did a lot of it too), which among other factors makes it likely that his "old fashioned" approach has unappreciated advantages over 'newer' approaches. Personally, I am especially wary of "newer approaches" after seeing how some young CS grads thought they were being clever by inventing a new workflow that involved the frequent use of the patch command -- they never figured out how much of their grief was caused by their misunderstanding of how to use Git. There are further comments interspersed below. On Sunday, July 6, 2014 3:05:50 AM UTC-7, Thomas Ferris Nicolaisen wrote: > > On Saturday, July 5, 2014 7:33:12 AM UTC+2, Matthew Johnson wrote: >> >> I usually only 'lurk' on this forum, since I am pretty new to Git myself, >> too. But there are two things that stood out here I feel I need to speak up >> about: 1) be very, very careful about following the 'guidance' from a Stack >> Overflow post where neither the question nor any of the answers got a >> rating higher than 3 2) rebase is NOT part of the normal Git workflow. Its >> use should be rather rare. I cannot imagine why you would want to do it >> after every checkout. >> > > I agree, I would personally only bother doing it every once in a while, > due to the overhead work. However, the more often you do it, the smaller > amount of conflicts you'll have to deal with at a time. In a busy > repository, it could be the right thing to do. > But you also get a "smaler amount of conflicts" if you do frequent merges. And merges have the advantage that they do not throw away commits creating look-alikes to fool your collaborators. > > >> >> In particular, the man page for git-rebase (recall that to look up git >> commands in man, you need to add the '-') has two warnings that are likely >> quite pertinent. >> >> 1) Rebasing (or any other form of rewriting) a branch that others have >> based work on is a bad idea >> > > As long as thread-starter is the only one using this feature branch in the > shared repository, it should be all right. > But in a "busy repository", you cannot count on that. On the contrary: in a busy repository it is easy to miss someone working on the same code -- until he shows up in a merge. > > >> Taking a slightly different approach, the online Git book covering rebase >> (http://git-scm.com/book/en/Git-Branching-Rebasing >> <http://www.google.com/url?q=http%3A%2F%2Fgit-scm.com%2Fbook%2Fen%2FGit-Branching-Rebasing&sa=D&sntz=1&usg=AFQjCNHmAubPITlKFW927EdqbpVTDVCzHA>) >> >> seems to imply that if what you want to do can be easily done with merge, >> then you should do so, resorting to rebase only when you want to do odd >> things like apply not the whole current branch, but only a patch in it to >> another branch. >> > > I think that's a bit old-fashioned view on things. I think we're better > off embracing rebase as a tool earlier than later, teaching new users how > and when to use it appropriately. There are several use-cases for rebase > that I would classify as normal procedure: > > * Doing minor commits on master for which you don't want a branch: git > pull --rebase > * Starting off on branches that you end up wanting to just rebase on > master instead (and fast-forward onto master) > * Rebase interactive to clean up commits > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
