On 9/10/08 9:34 AM, "Reinhold Kainhofer" <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Mittwoch, 10. September 2008 schrieb Han-Wen Nienhuys:
>> The per-file rather than per patch-set comment confuses me, as SVN
>> uses changesets too. Do you mean that you want a view that includes
>> all diffs in a single page?
>
> Actually, what I meant was that I don't seen an easy way to work with multiple
> atomic patches, that depend on each other (i.e. upload a whole local branch
> for review, when all the features have been implemented). It appears that
> git-cl will not honor these patch sets, but rather create one huge diff of
> all changed files rather than a set of patches. This also means that all
> explanations in the git commit messages will be lost/ignored and you'll have
> to add the explanation manually.
>
> In svn you can only have uncommitted changes, once you commit, everything will
> be on the server, so this approach makes sense. But in git, you usually first
> commit (locally) several times before you send / publish a patch for review,
> so you have lots of local commits, which should normally not be merged to one
> big commit.
I've been using a bunch of local commits to track my changes, then using
git-rebase to squash them into a single change before I push. If you do
this, then the rebase commit will fly through, won't it?
Is this a wrong thing to do? I've thought it worked well for me.
Carl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
