On Mon, 9 Jan 2006, Brown, Len wrote:
> >
> >The huge majority of my "automatic update from upstream" merges
> >go into my test branch ... which never becomes part of the real
> >history as I never ask Linus to pull from it.
> >
> >-Tony
> >
> >[1] Sometimes I goof on this because I forget that I've applied
> >a trivial patch directly to the release branch without going through
> >a topic branch. I think I'll fix my update script to check
> >for this case.
>
> I figured that checking some trivial patches directly into "release"
> would be a convenient way to make sure I didn't forget to push them --
> as they didn't depend on anything else in my tree. Okay.
One thing we could do is to make it easier to apply a patch to a
_non_current_ branch.
In other words, let's say that we want to encourage the separation of a
"development branch" and a "testing and use" branch (which I'd definitely
personally like to encourage people to do).
And one way to do that might be to teach "git-apply" to apply patches to a
non-active branch, and then you keep the "testing and use" branch as your
_checked_out_ branch (and it's going to be really dirty), but when you
actually apply patches you could do that to the "development" branch with
something like
git-apply -b development < patch-file
(Now, of course, that's only if you apply somebody elses patch - if you
actually do development _yourself_, you'd either have to check out the
development branch and do it there, or you'd move the patch you have in
your "ugly" checked-out testing branch into the development branch with
git diff | git-apply -b development
or something similar..)
Then you could always do "git pull . development" to pull in the
development stuff into your working branch - keeping the development
branch clean all the time.
Do you think that kind of workflow would be more palatable to you? It
shouldn't be /that/ hard to make git-apply branch-aware... (It was part of
my original plan, but it is more work than just using the working
directory, so I never finished the thought).
> I'm hopeful that gitk users will not be irritated also
> by the liberal use of topic branches.
"gitk" is actually pretty good at showing multiple branches. Try doing a
gitk --all -d
and you'll see all the topic branches in date order. The "-d" isn't
strictly necessary, and to some degree makes the output messier by
interleaving the commits from different branches, so you may not want to
do it, but it is sometimes nice to see the "relative dates" of individual
commits rather than the denser format that gitk defaults to.
> In the case where a topic branch is a single commit, gitk users
> will see both the original commit, as well as the merge commit
> back into "release".
Yes, topic branches will always imply more commits, but I think they are
of the "nice" kind.
I definitely encourage people to use git as a distributed concurrent
development system ratehr than the "collection of patches" thing. Quilt is
much better at the collection of patches.
So I'd encourage topic branches - even within something like ACPI, you
might have separate topics ("interpreter" branch vs "x86" branch vs
"generic-acpi" branch).
And yes, that will make history sometimes messier too, and it will cause
more merges, but the difference there is that the merges will be
meaningful (ie merging the "acpi interpreter" branch into the generic ACPI
branch suddenly has _meaning_, even if there only ends up being a couple
of commits per merge).
Ok?
Linus
-
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]
