From: Linus Torvalds <torvalds-3NddpPZAyC0@public.gmane.org>
To: "Brown, Len" <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
akpm-3NddpPZAyC0@public.gmane.org,
git-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: RE: git pull on Linux/ACPI release tree
Date: Sun, 8 Jan 2006 11:10:20 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0601081100220.3169@g5.osdl.org> (raw)
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005A13489-N2PTB0HCzHKkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Sun, 8 Jan 2006, Brown, Len wrote:
>
> Is it possible for it git, like bk, to simply ignore merge commits in its summary output?
That's not the point. It does: "git log --no-merges" does exactly that.
But fire up "gitk" to watch the history, and see the difference.
> Note that "Auto-update from upstream" is just the place-holder comment
> embedded in the wrapper script in git/Documentation/howto/using-topic-branches.txt
That has absolutely nothing to do with anything. It's not the comment
(which admittedly gives absolutely no information - but why should it,
since the _commit_ itself has no information in it?)
It's like you have empty commits that don't do anything at all, except
that they are worse, because they have two parents.
> I think that Tony's howto above captures two key requirements
> from all kernel maintainers -- which the exception of you --
No. Your commits make it harder for _everybody_ to track the history.
A merge by definition "couples" the history of two branches. That's what a
merge very fundamentally is. It ties two things together. But two things
that don't have any connection to each other _shouldn't_ be tied together.
Just as an example: because of the extra merges, you've made all your
commits dependent on what happened in my tree, with no real reason. So
let's say that somebody reports that something broke in ACPI. Now you
can't just go to the top of the ACPI history and work backwards - you'll
have tied up the two histories so that they are intertwined.
And yes, you can always work around it, but there's just no point. And
none of the other developers seem to need to do it. They do their
development, and then they say "please pull". At that point the two
histories are tied together, but now they are tied together for a
_reason_. It was an intentional synchronization point.
An "automated pull" by definition has no reason. If it works automated,
then the merge has zero semantic meaning.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2006-01-08 19:10 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-08 7:47 git pull on Linux/ACPI release tree Brown, Len
2006-01-08 8:16 ` Catalin Marinas
2006-01-08 8:16 ` David S. Miller
2006-01-08 8:44 ` Junio C Hamano
[not found] ` <F7DC2337C7631D4386A2DF6E8FB22B3005A13489-N2PTB0HCzHKkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2006-01-08 19:10 ` Linus Torvalds [this message]
2006-01-09 0:48 ` Al Viro
[not found] ` <20060109004844.GG27946-rfM+Q5joDG/XmaaqVzeoHQ@public.gmane.org>
2006-01-09 3:50 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2006-01-08 18:28 Brown, Len
[not found] ` <F7DC2337C7631D4386A2DF6E8FB22B3005A13505-N2PTB0HCzHKkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2006-01-08 19:19 ` Martin Langhoff
[not found] ` <46a038f90601081119r39014fbi995cc8b6e95774da-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2006-01-08 19:33 ` Junio C Hamano
2006-01-08 19:57 ` Linus Torvalds
2006-01-08 20:50 ` Tony Luck
2006-01-08 19:56 ` Linus Torvalds
2006-01-08 20:35 ` David S. Miller
2006-01-08 21:20 ` Luben Tuikov
2006-01-09 1:13 ` Linus Torvalds
2006-01-08 19:41 ` Linus Torvalds
[not found] ` <Pine.LNX.4.64.0601081111190.3169-hNm40g4Ew95AfugRpC6u6w@public.gmane.org>
2006-01-08 23:06 ` Adrian Bunk
[not found] ` <20060108230611.GP3774-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org>
2006-01-08 23:53 ` Willy Tarreau
2006-01-09 3:26 ` Linus Torvalds
[not found] ` <Pine.LNX.4.64.0601081909250.3169-hNm40g4Ew95AfugRpC6u6w@public.gmane.org>
2006-01-09 4:34 ` Martin Langhoff
2006-01-10 20:19 ` Adrian Bunk
[not found] ` <20060110201909.GB3911-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org>
2006-01-10 20:31 ` Linus Torvalds
2006-01-10 20:33 ` Martin Langhoff
2006-01-11 0:26 ` Andreas Ericsson
2006-01-12 1:37 ` Greg KH
[not found] ` <20060112013706.GA3339-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2006-01-12 16:10 ` Catalin Marinas
2006-01-13 14:50 ` Adrian Bunk
2006-01-09 5:53 Brown, Len
2006-01-09 6:08 ` Martin Langhoff
2006-01-09 6:13 ` Linus Torvalds
2006-01-09 6:46 ` Junio C Hamano
2006-01-09 5:55 linux
2006-01-09 6:13 Brown, Len
2006-01-09 6:27 Brown, Len
2006-01-09 7:34 Brown, Len
[not found] ` <F7DC2337C7631D4386A2DF6E8FB22B3005A136FE-N2PTB0HCzHKkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2006-01-09 10:11 ` Martin Langhoff
2006-01-09 12:31 ` Johannes Schindelin
2006-01-09 8:05 Brown, Len
2006-01-09 16:47 ` Linus Torvalds
2006-01-09 16:57 ` Linus Torvalds
2006-01-09 22:51 ` Luben Tuikov
2006-01-09 23:07 ` Linus Torvalds
2006-01-09 23:34 ` Martin Langhoff
2006-01-10 2:50 ` Linus Torvalds
2006-01-10 3:04 ` Junio C Hamano
[not found] ` <Pine.LNX.4.64.0601091845160.5588-hNm40g4Ew95AfugRpC6u6w@public.gmane.org>
2006-01-10 6:33 ` Kyle Moffett
[not found] ` <99D82C29-4F19-4DD3-A961-698C3FC0631D-ee4meeAH724@public.gmane.org>
2006-01-10 6:38 ` Martin Langhoff
2006-01-10 18:05 ` Kyle Moffett
2006-01-10 18:27 ` Linus Torvalds
[not found] ` <Pine.LNX.4.64.0601101015260.4939-hNm40g4Ew95AfugRpC6u6w@public.gmane.org>
2006-01-10 18:45 ` Johannes Schindelin
2006-01-10 19:01 ` Linus Torvalds
2006-01-10 19:28 ` Linus Torvalds
2006-01-10 19:38 ` Johannes Schindelin
2006-01-10 20:11 ` Linus Torvalds
2006-01-10 20:28 ` Linus Torvalds
2006-01-10 20:47 ` Johannes Schindelin
2006-01-13 23:35 ` Matthias Urlichs
[not found] ` <252A408D-0B42-49F3-92BC-B80F94F19F40-ee4meeAH724@public.gmane.org>
2006-01-11 3:32 ` Luben Tuikov
2006-01-09 20:06 ` Junio C Hamano
[not found] ` <7vu0cdjhd1.fsf-u5dp/1a/izZijMVVUgEtmwqrb7wDvxM8@public.gmane.org>
2006-01-10 15:31 ` Alex Riesen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0601081100220.3169@g5.osdl.org \
--to=torvalds-3nddppzayc0@public.gmane.org \
--cc=akpm-3NddpPZAyC0@public.gmane.org \
--cc=git-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).