From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Christian MICHON <christian.michon@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: newby question about merge.
Date: Wed, 16 May 2007 23:39:08 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.64.0705162325020.6410@racer.site> (raw)
In-Reply-To: <46d6db660705161235k130fabc2i6acb45d71b85891e@mail.gmail.com>
Hi,
On Wed, 16 May 2007, Christian MICHON wrote:
> On 5/16/07, Johannes Schindelin wrote:
> > [please, Christian, do not cut the Cc: list. In particular, do _not_
> > cut the person you are _responding_ to from the Cc: list]
>
> [ oops. I thought some of us sometimes receive doublets of emails,
> being in reply_to and cc of git@vger.kernel.org. point *taken* ]
Actually, I get doublets. Which is good, since I am more unlikely to just
delete _two_ copies of the same mail.
> I know the API changes frequently. But engineers don't like too many
> changes usually, and like to carry a portable/stable way. "git cat-file"
> at least behaves as it was in 1.4.x :)
Those changes were good changes. "git-show" is here to stay.
"git-cat-file" only appeals to Unix zealots who even sleep in their
command line.
> > > As far as I can tell, using git-1.4.4.4 or ealier, you would still
> > > need git-cat-file -p... to fix this merge conflict.
> >
> > If you are using pre-1.5 Git, you should really, really upgrade.
>
> While in principle I'd agree, in practice I do not. Git API changes
> increased learning curve for people who actually started with git a year
> ago.
I think I can pretty much guarantee that git-cat-file will stay plumbing.
As much as it will keep its not-exactly-user-friendly command line
arguments.
And I can pretty much guarantee that git-show will always be the good
thing for an end user to call.
> > And most importantly: if you suggest a change in the man pages, it
> > should reflect the new Git versions, _not_ the old ones.
>
> nope, I would not dare to suggest. I'm not a git developer: just a git
> user :)
You are right: for general help, this list is open for older versions of
Git. What triggered my response, though, was the suggestion to put that
particular command line, which indeed scares people away from Git (I tried
it on somebody), into a man page.
git-show <revision>:<path>
is so much nicer.
Ciao,
Dscho
prev parent reply other threads:[~2007-05-16 22:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-15 9:38 newby question about merge picca
2007-05-15 10:25 ` Alex Riesen
2007-05-15 10:34 ` Jakub Narebski
2007-05-15 11:37 ` picca
2007-05-15 21:47 ` Junio C Hamano
2007-05-16 6:33 ` picca
2007-05-16 11:43 ` Johannes Schindelin
2007-05-16 14:21 ` Christian MICHON
2007-05-16 14:45 ` Johannes Schindelin
2007-05-16 19:35 ` Christian MICHON
2007-05-16 22:39 ` Johannes Schindelin [this message]
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.0705162325020.6410@racer.site \
--to=johannes.schindelin@gmx.de \
--cc=christian.michon@gmail.com \
--cc=git@vger.kernel.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).