From: Daniel Barkalow <barkalow@iabervon.org>
To: "Steve Frécinaux" <nudrema@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Things that surprise naive users
Date: Wed, 18 Apr 2007 18:28:21 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0704181746410.27922@iabervon.org> (raw)
In-Reply-To: <1176930970.7733.9.camel@mejai>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; CHARSET=X-UNKNOWN, Size: 2143 bytes --]
On Wed, 18 Apr 2007, Steve Frécinaux wrote:
> On Wed, 2007-04-18 at 16:55 -0400, Daniel Barkalow wrote:
>
> > 1. If your organization has a bunch of different projects, and there's
> > some central location holding the upstream that people regularly pull
> > from, there's no way to abbreviate this parent directory. (Equivalent
> > of CVSROOT environment variable)
> >
> > I.e., we've got file-server:/var/git/<project>.git at my work, with
> > dozens of projects, and you have to give the whole thing to git clone
> > each time.
>
> export GITROOT=file-server:/var/git
> git-clone $GITROOT/project.git
>
> git doesn't enforce that but you can still do it with some shell karma.
>
> BTW as far as I know no other scm than CVS provides this kind of thing,
> and it's more often seen as a defect than an advantage. For instance, a
> novice which had to checkout a CVS project from sourceforge and another
> from cvs.gnome.org and another from... wasn't helped at all. SVN has it
> much simpler (understandable) by just providing a URL for checkouts.
It's counterproductive to require both a "root" and a "module" if there
isn't any sort of commonality, but it's useful to be able to have a
default. Besides CVS, arch also has something of the sort. I haven't used
anything else in a corporate setting (where most of the things you check
out are from the same place).
> > 2. There's no easy way to tell that you've made commits that you haven't
> > pushed upstream. In fact, it's impossible to tell when disconnected
> > whether you've pushed everything. This needs some command to report it,
> > and also for push to update the fetch sides of remote heads it updates.
>
> I surprised myself doing so:
> git-push $remote
> git-fetch $remote
> given that the remote in question pushes master, and pulls into $remote.
> Maybe such a thing (in the idea) should be done implicitely.
I mentioned it a while back, but never got around to implementing it,
mostly because it's all in shell scripts (or was).
-Daniel
*This .sig left intentionally blank*
next prev parent reply other threads:[~2007-04-18 22:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-18 20:55 Things that surprise naive users Daniel Barkalow
2007-04-18 21:16 ` Steve Frécinaux
2007-04-18 22:28 ` Daniel Barkalow [this message]
2007-04-18 23:57 ` Martin Langhoff
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.0704181746410.27922@iabervon.org \
--to=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=nudrema@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).