From: Linus Torvalds <[email protected]>
Date: Sun, 8 Jan 2006 11:56:21 -0800 (PST)
> So my suggested git usage is to _not_ play games. Neither do too-frequent
> merges _nor_ play games with git-rebase.
>
> That said, git-rebase (and associated tools like "git-cherry-pick" etc)
> can be a very powerful tool, especially if you've screwed something up,
> and want to clean things up. Re-doing history because you realized that a
> you did something stupid that you don't want to admit to anybody else.
>
> So trying out git-rebase and git-cherry-pick just in case you decide to
> want to use them might be worthwhile. Making it part of your daily routine
> like David has done? Somewhat questionable, but hey, it seems to be
> working for David, and it does make some things much easier, so..
The time at which I do the by-hand rebasing the most are the weeks
leading up to a major release. The reason is to integrate bug fixes
that I know conflict with the 80-odd patches I have queued up for the
next development phase, or that I simply want integrated so that no
_future_ development patches create conflicts.
I think merges with conflicts that need to get resolved by hand create
a lot of noise and useless information and therefore to me they are
pointless. But this is just my opinion. It simply works easier to me
to shuffle the patches in by hand and deal with the rejects one by
one. It's very much akin to how Andrew's -mm tree works.
I think a clean history is worth an extra few minutes of someone's
time. And note that subsystem development is largely linear anyways.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
