git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Baudis <pasky@suse.cz>
To: Martin Langhoff <martin.langhoff@gmail.com>
Cc: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: [PATCH] GIT commit statistics.
Date: Mon, 14 Nov 2005 10:25:54 +0100	[thread overview]
Message-ID: <20051114092554.GR30496@pasky.or.cz> (raw)
In-Reply-To: <46a038f90511140051o1fa5ef7cyb9dd723fb8161ef9@mail.gmail.com>

Dear diary, on Mon, Nov 14, 2005 at 09:51:29AM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> In the meantime, the user experience of working with a small team and
> a shared repo has improved significantly by switching from cg-update
> to cg-fetch && git-rebase origin. So much so that I suspect that it'd
> be a big win for cg-update to default to rebase on merges from
> 'origin'.

I still don't understand what's the point. And it is confusing for
the user, since the history suddenly doesn't reflect how the GIT
development happened (which is what the history is about), and it is
downright deadly as soon as more than one branch gets around, which
makes it even more confusing for the user (you can do cg-update, yeah
- oh wait, unless you do X, then you need to remember to always do
cg-update -R or whatever).

All the woes just to get rid of the merge commits. What's wrong on merge
commits? If they irritate you so much, cg-log -M. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

  reply	other threads:[~2005-11-14  9:26 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-07 16:48 Comments on recursive merge Linus Torvalds
2005-11-07 16:56 ` Linus Torvalds
2005-11-07 23:19   ` [PATCH] merge-recursive: Only print relevant rename messages Fredrik Kuivinen
2005-11-07 23:54     ` Junio C Hamano
2005-11-09 10:36       ` Fredrik Kuivinen
2005-11-07 22:58 ` Comments on recursive merge Fredrik Kuivinen
2005-11-08  0:13   ` Junio C Hamano
2005-11-08  0:33     ` Linus Torvalds
2005-11-08  0:59       ` Junio C Hamano
2005-11-08 11:58       ` Johannes Schindelin
2005-11-08 21:02         ` Fredrik Kuivinen
2005-11-08 21:47           ` Junio C Hamano
2005-11-08 21:52           ` Linus Torvalds
2005-11-08 22:36             ` Fredrik Kuivinen
2005-11-08 23:05               ` Linus Torvalds
2005-11-08 23:18                 ` Johannes Schindelin
2005-11-09  0:18                   ` Linus Torvalds
2005-11-09  6:10                     ` Junio C Hamano
2005-11-09  0:32                 ` Petr Baudis
2005-11-09  0:51                   ` Linus Torvalds
2005-11-09  0:59                     ` Junio C Hamano
2005-11-09  1:22                       ` Linus Torvalds
2005-11-09  1:42                         ` Junio C Hamano
2005-11-09 10:20                           ` Junio C Hamano
2005-11-09 14:59                             ` Petr Baudis
2005-11-09 16:30                             ` Linus Torvalds
2005-11-09 20:13                               ` Junio C Hamano
2005-11-09 21:58                                 ` Linus Torvalds
2005-11-09 22:56                                   ` Junio C Hamano
2005-11-09 23:34                                     ` Linus Torvalds
2005-11-11  2:58                                   ` merge-base: fully contaminate the well Junio C Hamano
2005-11-11  5:36                                     ` Linus Torvalds
2005-11-11  6:04                                       ` Junio C Hamano
2005-11-11 16:18                                         ` Linus Torvalds
2005-11-11  8:28                                       ` Junio C Hamano
2005-11-08 23:04           ` Comments on recursive merge Johannes Schindelin
2005-11-08 16:21       ` [RFC/PATCH] Make git-recursive the default strategy for git-pull Junio C Hamano
2005-11-11 22:25       ` Comments on recursive merge Junio C Hamano
2005-11-11 22:53         ` Linus Torvalds
2005-11-12  0:42           ` Junio C Hamano
2005-11-12  6:35         ` Ryan Anderson
2005-11-12  7:44           ` [PATCH] GIT commit statistics Junio C Hamano
2005-11-12 12:19             ` Martin Langhoff
2005-11-12 12:53               ` Petr Baudis
2005-11-15 10:04                 ` Catalin Marinas
2005-11-15 15:29                   ` Chuck Lever
2005-11-12 19:04               ` Johannes Schindelin
2005-11-13 10:59               ` Junio C Hamano
2005-11-13 20:42                 ` Martin Langhoff
2005-11-14  3:33                   ` Junio C Hamano
2005-11-14  4:01                     ` Martin Langhoff
2005-11-14  6:06                       ` Junio C Hamano
2005-11-14  8:51                         ` Martin Langhoff
2005-11-14  9:25                           ` Petr Baudis [this message]
2005-11-14 21:25                             ` Martin Langhoff
2005-11-14  9:27                           ` Junio C Hamano
2005-11-15  3:00                           ` Junio C Hamano
2005-11-13 11:11               ` Petr Baudis

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=20051114092554.GR30496@pasky.or.cz \
    --to=pasky@suse.cz \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=martin.langhoff@gmail.com \
    /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).