* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-16 18:23 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: git
In-Reply-To: <f2b55d220611160957s2e68059dk99bbe902e7e1f416@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]
On Thu, 16 Nov 2006 09:57:00 -0800, "Michael K. Edwards" wrote:
> What do you want all of those branches for? They haven't been
> published to you (that's a human interaction that doesn't go through
> git), so for all you know they're just upstream experiments, and doing
> things with them is probably shooting yourself in the foot.
The same "what do you want them all for" question could be asked of
git-clone which also fetches all available branches. I really just
want to be able to easily watch what's going on in multiple
repositories.
I want to be able to just say "git update" (or whatever) and then be
able to list and browse and explore the stuff locally.
Yes, there's still outside communication that's necessary, but with
the ability to easily track all the remote branches that communication
can be even less formal if I can easily browse and explore things
locally. For example, I might not even know the name of the branch:
Me: Have you pushed a branch for your new work on the frob-widget?
Friend: Yes
And then I can "get fetch" and see "cool-new-frob" come in without
having to be told that name. Or I could have even just fetched
without the specific communication if I was already expecting it for
some reason.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
From: Linus Torvalds @ 2006-11-16 18:21 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
In-Reply-To: <455CA2A8.5010700@xs4all.nl>
On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
>
> You're misunderstanding me: the multi-repo is at git.sv.gnu.org is the
> remote one. The example I gave was about locally creating a single
> project repo from a remote multiproject repo.
Ahh.
Ok, try the patch I just sent out, and see if it works for you. It
_should_ allow you to do exactly that
mkdir new-repo
cd new-repo
git init-db
git pull <remote> <onehead>
and now your "master" branch should be initialized to "onehead".
Oh, except I just realized that I forgot to do a "git checkout" in my
patch, so you'd need to add that (or do it by hand, but you really
shouldn't need to, since the checkout is implied by the "pull").
The downside with this is that it does NOT populate your "remotes"
information (like "git clone" would have done), so either we'd need to
teach "git pull" to do that too, or you just have to do it by hand (so
that you then can do the shorthand "git pull" to update in the future).
> On a tangent: why is there no reverse-clone? I have no shell access
> to the machine, so when I created the remote repo, I had to push, and
> ended up putting 1.2 Gb data on the server.
Yeah, you're supposed to "init-db" and "push". Right now, that tends to
unpack everything (which is bad), although that is hopefully getting fixed
(ie the receiving end shouldn't unpack any more if it is recent. Junio?)
> <looks at manpage>
>
> is this send-pack?
"git push" uses send-pack internally, you shouldn't ever need to use it
yourself.
> From UI perspective it would be nice if this could also be done with clone,
>
> git clone . ssh+git://....
The creation of a new archive tends to need special rights (with _real_
ssh access and a shell you could do it, but "ssh+git" really means "git
protocol over a connection that was opened with ssh, but doesn't
necessarily have a real shell at the other end").
So for most protocols, you simply cannot (and shouldn't) do it. Think
about services like the one that Pasky has set up, that allow you to set
up a new git repo - the setup phase really _has_ to be separate (because
you need to set up your keys etc).
So I think the above syntax is actually not a good one, because it cannot
work in the general case. It's much better to get used to setting up a
repo first, and then pushing into it, and just accepting that it's a
two-phase thing.
Also, from a bandwidth standpoint, you can often (although obviously not
always) make the setup start with something that is _closer_ to what you
want to do. So, for example, you'd often do something like:
(a) ssh to central repository
(b) create the new repository by cloning it _locally_ at the central
place from some other repository that is related
(c) then, from your local (non-central) repository, do a "git push --force"
to force your changes (which now only needs the _incremental_ thing).
An example of this is again the "forking" thing that he repos at at
http://git.or.cz/ already supports.
> >And that "git pull" semantic actually means that if you want a _bare_
> >repository, I think "git --bare init-db" + "git --bare fetch" actually
>
> yes, this works. Two remarks:
>
> * it needs
>
> website/master:master
>
> otherwise you still don't have a branch.
Right. In fact, you should probably do
website/master:refs/heads/master
just to make it really explicit.
> * why are objects downloaded twice? If I do
>
> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master
>
> it downloads stuff, but I don't get a branch.
A "fetch" by default won't actually generate a local branch unless you
told it to. It just squirrels the end result into the magic FETCH_HEAD
name, so that you can do
# do the fetch
git fetch git://git.sv.gnu.org/lilypond.git web/master
# look at changes
gitk ..FETCH_HEAD
# If you're happy with them, merge them in
git merge "merge new code" HEAD FETCH_HEAD
and you never actually created a real local branch at all.
If you want "git fetch" to fetch _into_ a branch, you need to tell it so,
by using the full "src:dest" format. Otherwise it doesn't know what branch
to fetch it into.
(And, of course, you can define that branch relationship in your remote
configuration, so you don't actually have to say it explicitly every time)
> If I then do
>
> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master
>
> it downloads the same stuff again.
Right. So you can either
(a) do it that way to begin with (because you now told it to put the
results in "master", so you never needed to do the second fetch in
the first place)
or
(b) after you did the first fetch (into FETCH_HEAD), you could also have
just decided to do
git update-ref HEAD FETCH_HEAD ""
(where that "" at the end is really not technically necessary, but it
tells "update-ref" that you _only_ want to do this if the old HEAD
was empty/undefined. Without it, "git update-ref" will just
overwrite HEAD without caring what it contained before, so it can be
a dangerous operation!)
See?
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-16 18:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611160904010.3349@woody.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Thu, 16 Nov 2006 09:17:32 -0800 (PST), Linus Torvalds wrote:
> So the way you'd normally set up a single repo that contains multiple
> other existing repositories is to basically start with one ("git clone")
> and then add the other branches and "git fetch" them.
For that we'd also need a way for clone to be able to fetch just a
single branch, and not all of them as well.
There is some clone vs. fetch asymmetry here that has annoyed me for a
while, and that I don't think has been mentioned in this thread
yet. Namely:
clone: can only be executed once, fetches all branches, "remembers"
URLs for later simplified use
fetch: can be executed many times, fetches only named branches,
doesn't remember anything for later
I've often been in the situation where I cloned a long time ago, but
I'd like to be able to fetch everything that I would get if I were to
start a fresh clone.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git-PS1 bash prompt setting
From: Sean @ 2006-11-16 18:01 UTC (permalink / raw)
To: git; +Cc: Theodore Tso
Ted mentioned in the wart thread that having multiple branches per repo
means that the standard bash prompt isn't as much help as it could be.
For what it's worth i'll post a little script i've been using for quite
some time that helps a little. It's called git-PS1 and is used by
including it in your bash PS1 variable like so:
export PS1='$(git-PS1 "[\u@\h \W]\$ ")'
If you're not in a git repo, the bash prompt you pass on the git-PS1
command line is used instead. If you are in a git repo, you'll get
the following as a prompt:
[branch!repo/relative/path]$
Where "repo" is the basename of the path to the root of your repo.
An example would look like this:
[master!linus-2.6/Documentation/vm]$
Cheers,
Sean
#!/bin/bash
BR=$(git symbolic-ref HEAD 2>/dev/null) || { echo "$@" ; exit ; }
BR=${BR#refs/heads/}
REL=$(git rev-parse --show-prefix)
REL="${REL//%\/}"
LOC="${PWD%/$REL}"
echo "[$BR!${LOC/*\/}${REL:+/$REL}]$ "
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-16 17:57 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611160904010.3349@woody.osdl.org>
On Thu, 16 Nov 2006, Linus Torvalds wrote:
>
> (And the real reason for that is simple: "git pull" simply wants to have
> something to _start_ with. It's not hugely fundamental, it's just how it
> was written).
Here's a very lightly tested patch that allows you to use "git pull" to
populate an empty repository.
I'm not at all sure this is necessarily the nicest way to do it, but it's
fairly straightforward.
Junio, what do you think?
Linus
---
diff --git a/git-pull.sh b/git-pull.sh
index ed04e7d..7e5cee2 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -44,10 +44,10 @@ do
shift
done
-orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
+orig_head=$(git-rev-parse --verify HEAD 2> /dev/null)
git-fetch --update-head-ok --reflog-action=pull "$@" || exit 1
-curr_head=$(git-rev-parse --verify HEAD)
+curr_head=$(git-rev-parse --verify HEAD 2> /dev/null)
if test "$curr_head" != "$orig_head"
then
# The fetch involved updating the current branch.
@@ -80,6 +80,11 @@ case "$merge_head" in
exit 0
;;
?*' '?*)
+ if test -z "$orig_head"
+ then
+ echo >&2 "Cannot merge multiple branches into empty head"
+ exit 1
+ fi
var=`git-repo-config --get pull.octopus`
if test -n "$var"
then
@@ -95,6 +100,12 @@ case "$merge_head" in
;;
esac
+if test -z "$orig_head"
+then
+ git-update-ref -m "initial pull" HEAD $merge_head "" || exit 1
+ exit
+fi
+
case "$strategy_args" in
'')
^ permalink raw reply related
* Re: Cleaning up git user-interface warts
From: Michael K. Edwards @ 2006-11-16 17:57 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87fycjs5yg.wl%cworth@cworth.org>
On 11/16/06, Carl Worth <cworth@cworth.org> wrote:
> First, the pull may just fast-forward in which case there's no message
> at all. And we've been through that topic enough recently that we all
> know that no important information is lost by not doing any separate
> recording in that case.
>
> So you can't turn around and argue that the remote URL information is
> suddenly important when it just so happens that it's not a fast
> forward.
When it's a fast forward, the puller hasn't had to make any judgment
calls, so there's no editorial history to record. When it's not, but
the puller chooses to retain the result on a persistent branch, that
_is_ an editorial decision (even if the result of the auto-merge is
clean); I like having that in the history.
> > And in a truly distributed situation, "pull" is strictly more powerful
> > than a separate "fetch" + separate "merge".
>
> I don't buy it. In my usage, I have several different remote
> repositories I'm interested in tracking, each with any number of
> branches. What I really want is an easy command that fetches all of
> those branches, (even new ones that I've never heard about---but never
> any of their "tracking branches" that wouldn't be of interest to
> me). And I want to do that once, to get the online-access-required
> part over with and get all the data into my local repository where I
> can start working with it.
What do you want all of those branches for? They haven't been
published to you (that's a human interaction that doesn't go through
git), so for all you know they're just upstream experiments, and doing
things with them is probably shooting yourself in the foot.
I do agree that a robust form of "for b in .git/remotes/*; do git
fetch `basename $b`; done" would be a nice bit of porcelain. The
entries in .git/remotes would probably need to grow a "Fetch-options:"
field so that you could choose whether or not to follow tags, etc.
Patch to follow.
Cheers,
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Sean @ 2006-11-16 17:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: Carl Worth, Andreas Ericsson, Theodore Tso, Nicolas Pitre,
Michael K. Edwards, git
In-Reply-To: <Pine.LNX.4.64.0611160924250.3349@woody.osdl.org>
On Thu, 16 Nov 2006 09:30:47 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:
> Yeah. Each branch should
>
> (a) have a "default source" initialized on the initial "clone"
>
> (b) have a way to set the source afterwards
>
> (c) error out if you do just a "git pull" or "git pull remotename" if
> there is no default branch for the current local branch for that
> remote.
This would be _great_. You just shouldn't have to hack at the
.git/config file to get reasonable default sources after a clone.
Or even for that matter after fetching a new branch into an
existing repo.
^ permalink raw reply
* multi-project repos (was Re: Cleaning up git user-interface warts)
From: Han-Wen Nienhuys @ 2006-11-16 17:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611160904010.3349@woody.osdl.org>
Linus Torvalds escreveu:
>
> On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
>> Actually, only a 2 weeks ago, you suggested that I share the website
>> and main source code for my project in a single repository for reasons
>> of organization.
>>
>> In this setup I find it logical to do
>>
>> git init-db
>> git pull ..url.. website/master
>
> I don't disagree per se. It should be easy to support, it's just that it's
> not traditionally been something we've ever done.
>
> So the way you'd normally set up a single repo that contains multiple
> other existing repositories is to basically start with one ("git clone")
You're misunderstanding me: the multi-repo is at git.sv.gnu.org is the
remote one. The example I gave was about locally creating a single
project repo from a remote multiproject repo.
On a tangent: why is there no reverse-clone? I have no shell access
to the machine, so when I created the remote repo, I had to push, and
ended up putting 1.2 Gb data on the server.
<looks at manpage>
is this send-pack? From UI perspective it would be nice if this could
also be done with clone,
git clone . ssh+git://....
>And that "git pull" semantic actually means that if you want a _bare_
>repository, I think "git --bare init-db" + "git --bare fetch" actually
yes, this works. Two remarks:
* it needs
website/master:master
otherwise you still don't have a branch.
* why are objects downloaded twice? If I do
git --bare fetch git://git.sv.gnu.org/lilypond.git web/master
it downloads stuff, but I don't get a branch. If I then do
git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master
it downloads the same stuff again.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-16 17:30 UTC (permalink / raw)
To: Carl Worth
Cc: Andreas Ericsson, Theodore Tso, Nicolas Pitre, Michael K. Edwards,
git
In-Reply-To: <87ejs3s4vn.wl%cworth@cworth.org>
On Thu, 16 Nov 2006, Carl Worth wrote:
>
> On Thu, 16 Nov 2006 08:30:55 -0800 (PST), Linus Torvalds wrote:
> > The form I use is actually a lot simpler (conceptually) than the "short"
> > form.
> >
> > When you do
> >
> > git pull <reponame> <branchname>
>
> Yes, that's what the user almost always wants. The UI problem here is
> that the conceptually simpler form is syntactically longer, (which
> means users aren't likely to find it).
Yeah.
And this is something I absolutely agree with. Our default branches for
"pull" are horrible. You can "fix" it, but you can only fix it by adding
_explicit_ branches to your .git/config file by hand, so I don't think
that's actually a real fix at all. We should just fix the default (where
even a "I don't know what branch you want" _error_ would be preferable
over the current situation).
Along with the "git checkout <tag>" thing, I think these two things are
definitely worth just fixing.
> The behavior is sane, but having to always type the branch name
> specifically because it never changes... that's a user-interface bug.
Yeah. Each branch should
(a) have a "default source" initialized on the initial "clone"
(b) have a way to set the source afterwards
(c) error out if you do just a "git pull" or "git pull remotename" if
there is no default branch for the current local branch for that
remote.
We actually have (b) in a weak form right now ("weak" because it requires
you to manually edit the config file: we've got the mechanism, but not a
nice UI for it), but (a) and (c) are just broken.
And yeah, we should allow pulling into a branch that hasn't been
initialized.
^ permalink raw reply
* Re: [PATCH] Add a MIME-Version header to e-mails
From: Catalin Marinas @ 2006-11-16 17:24 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061111122403.GC11224@diana.vm.bytemark.co.uk>
On 11/11/06, Karl Hasselström <kha@treskal.com> wrote:
> One potentially hazardous thing: you encode the mail before letting
> the user edit it (with the -e and -E switches). This means that the
> user can insert non-ascii characters in the body after you've already
> decided it's safe to use 7bit encoding. It also means that the user
> must be careful to rfc2047-encode any changes to the Subject: and
> From: headers.
I changed this to edit the mail before encoding it. You can no longer
see the full headers (those added by StGIT) but even in a normal
e-mail client you can only see the whole headers after sending it (and
if you receive it back).
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-16 17:17 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
In-Reply-To: <455C94FA.3050903@xs4all.nl>
On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
>
> Actually, only a 2 weeks ago, you suggested that I share the website
> and main source code for my project in a single repository for reasons
> of organization.
>
> In this setup I find it logical to do
>
> git init-db
> git pull ..url.. website/master
I don't disagree per se. It should be easy to support, it's just that it's
not traditionally been something we've ever done.
So the way you'd normally set up a single repo that contains multiple
other existing repositories is to basically start with one ("git clone")
and then add the other branches and "git fetch" them.
So again, instead of "git init-db" + "git pull", you'd just use "git
clone" instead.
Note that there _is_ another difference between "git pull" and
"fetch+merge". The difference being that "git pull" implicitly does the
checkout for you (I say "implicitly", because that's the way the git
merge conceptually works: we always merge in the working tree. That's not
the only way it _could_ be done, though - for trivial merges, we could do
them without any working tree at all, but we don't suppotr that).
And that "git pull" semantic actually means that if you want a _bare_
repository, I think "git --bare init-db" + "git --bare fetch" actually
does exactly the right thing right now too. But "git pull" would not be
the right thing to use.
Btw, another normal way to generate a central "multi-headed repo" for is
to not use "pull" or "fetch" or "clone" at ALL, but I would likely do
something like
mkdir central-repo
cd central-repo
git --bare init-db
and that's it. You now have a central repository, and you _never_ touch it
again in the central place except to repack it and do other "maintenance"
(eg pruning, fsck, whatever).
Instead, from the _outside_, you'd probably just do
git push central-repo mybranch:refs/heads/central-branch-name
(actually, you'd probably set up that branch-name translation of
"mybranch:refs/heads/central-branch-name" in your remote description, but
I'm writing it out in full as an example).
So there are many ways to do it. It just happens that "git init-db"
followed by "git pull" is not one of them ;)
(And the real reason for that is simple: "git pull" simply wants to have
something to _start_ with. It's not hugely fundamental, it's just how it
was written).
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-16 17:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Theodore Tso, Nicolas Pitre, Michael K. Edwards,
git
In-Reply-To: <Pine.LNX.4.64.0611160824040.3349@woody.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]
On Thu, 16 Nov 2006 08:30:55 -0800 (PST), Linus Torvalds wrote:
> The form I use is actually a lot simpler (conceptually) than the "short"
> form.
>
> When you do
>
> git pull <reponame> <branchname>
Yes, that's what the user almost always wants. The UI problem here is
that the conceptually simpler form is syntactically longer, (which
means users aren't likely to find it).
So if we can just get <reponame> and <branchname> to default
correctly, (based on the current branch name, and clone/fetch/pull
history), then the conceptually simple form ends up syntactically
simple as "git pull".
And I definitely don't have any problem with that. I'd love to be able
to teach that kind of simple thing to new users.
> driver tree, and because I'm always on that branch, what I do is
>
> git pull origin modesetting
...
> Well, as mentioned, I think even for non-developers, doing pulls with
> explicit branchnames is actually perfectly sane.
The behavior is sane, but having to always type the branch name
specifically because it never changes... that's a user-interface bug.
This is a good example of the kind of thing I wanted to hit when
starting this thread. I don't think there are any big conceptual
changes needed in git to make it easier for new users. But there are
little things that are problems that really should be fixed. Wouldn't
it be great to have the following exchange:
User: How do I track on-going development in a branch?
Master: Use "git pull"
Rather than:
User: How do I track on-going development in a branch?
Master Use "git pull origin <name-of-branch-you-are-already-on>"
?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Theodore Tso @ 2006-11-16 16:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre, Linus Torvalds
In-Reply-To: <20061116160700.GA3383@thunk.org>
On Thu, Nov 16, 2006 at 11:07:00AM -0500, Theodore Tso wrote:
> I think the problem is the people who have had years of BK or Hg
> experience. Maybe it's more of a documentation problem; perhaps a
> "git for BK" or "git for Hg" users is what's needed. The problem
> though is that while use of BK is definitely legacy, there are going
> to be a lot of people who need to use both BK and Hg.
Err, what I meant to say is that there are going to be a lot of people
who will need to simultaneously use both git and Hg.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Han-Wen Nienhuys @ 2006-11-16 16:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611160814560.3349@woody.osdl.org>
Linus Torvalds escreveu:
> So current rule (and this is not new, it's always been true): the ONLY
> time you use "git init-db" is when you are going to start a totally new
> project. Never _ever_ otherwise. If you want to track another project, use
> "git clone".
Actually, only a 2 weeks ago, you suggested that I share the website
and main source code for my project in a single repository for reasons
of organization.
In this setup I find it logical to do
git init-db
git pull ..url.. website/master
to wind up with just the 5mb website, instead of the complete 70mb
of packed source code with all of its branches and tags.
> It's not that it isn't typical, it's that you are using the wrong model.
> Maybe it's not well documented, I can easily give you that, but ALL your
> problems come from that fundamental starting point: you shouldn't have
> used "git init-db" in the first place.
>
> Somebody want to document it?
>
> Alternatively, we certainly _could_ make "git pull" just accept an empty
> git repo, and make it basically create the current branch.
Yes, I would like that.
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-16 16:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, Nicolas Pitre, Michael K. Edwards, git
In-Reply-To: <Pine.LNX.4.64.0611151523290.3349@woody.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]
On Wed, 15 Nov 2006 15:33:43 -0800 (PST), Linus Torvalds wrote:
> It's a lot more useful to have a merge message like
>
> Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
>
> than one like
>
> Merge branch 'for-linus'
There's more information in the first, sure. But I absolutely don't
accept that it's necessarily more useful, and definitely not that this
is a good argument for using pull with a remote branch instead of
fetch followed by merge with a local branch.
First, the pull may just fast-forward in which case there's no message
at all. And we've been through that topic enough recently that we all
know that no important information is lost by not doing any separate
recording in that case.
So you can't turn around and argue that the remote URL information is
suddenly important when it just so happens that it's not a fast
forward.
> And in a truly distributed situation, "pull" is strictly more powerful
> than a separate "fetch" + separate "merge".
I don't buy it. In my usage, I have several different remote
repositories I'm interested in tracking, each with any number of
branches. What I really want is an easy command that fetches all of
those branches, (even new ones that I've never heard about---but never
any of their "tracking branches" that wouldn't be of interest to
me). And I want to do that once, to get the online-access-required
part over with and get all the data into my local repository where I
can start working with it.
As for the URL from which I'm fetching all this stuff, it's really not
interesting to me at all. The URL for "Keith's stuff" keeps changing
anyway---I have no interest in recording that. But I do think it's
worth recording that the commits came from Keith's repository. I do
that right now with a keith/ prefix for his branches. It could also be
done by bringing in his .git/description during the fetch and storing
it somewhere. But I honestly don't see how storing something like that
during would make the system any less distributed in any sense.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-16 16:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Theodore Tso, Nicolas Pitre, Michael K. Edwards, git
In-Reply-To: <455C5079.3010701@op5.se>
On Thu, 16 Nov 2006, Andreas Ericsson wrote:
>
> * Mentioning git-fetch before git-pull in all documentation newborn gitizens
> are likely to come across.
However, I also think it might make sense to talk about the _simple_ form
of "git pull" first.
The form I use is actually a lot simpler (conceptually) than the "short"
form.
When you do
git pull <reponame> <branchname>
there are very few things that can confuse you (although trying to do it
without a current branch at all is apparently one such thing ;).
There are no local branches to worry about, and there aren't any issues
about what the default repository or branchname on the remote side would
be either.
So in many ways, if you use this format, you simply never have to worry.
You may have to _type_ a bit more, so it's not the short or concise
format, but it sure is the _simple_ format. There simply isn't anything to
be confused about.
And yes, I actually tend to use this even for project that I don't develop
on, partly because the defaults for the short and concise formats are bad.
For example, I follow the "modesetting" branch on the xorg intel graphics
driver tree, and because I'm always on that branch, what I do is
git pull origin modesetting
which works correctly (while "git pull" would _not_ have done the right
thing: it would have picked the right repository, but it would have picked
the "master" branch of that repository, not the "modesetting" branch).
And notice how I don't do _any_ development there, I just follow that
branch. The "merge" will obviously always be a fast-forward, but that's
exactly what I want.
> Most git-users aren't Linus, and for every successful project the
> maintainers are outnumbered 100 to 1 by the contributors.
Well, as mentioned, I think even for non-developers, doing pulls with
explicit branchnames is actually perfectly sane.
^ permalink raw reply
* Re: [StGIT PATCH] StGIT bash completion
From: Karl Hasselström @ 2006-11-16 16:29 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0611160812s6ffec19fm4bf079e08e5fce01@mail.gmail.com>
On 2006-11-16 16:12:43 +0000, Catalin Marinas wrote:
> Indeed, stg help takes over 200ms on my machine as well, with hot
> caches but this is mainly because it imports all the
> stgit.commands.* modules in order to read the short description. The
> 'stg help <command>' takes around 90ms on my machine since it only
> imports one module
Excellent. However, this suggests that an option should be added to
stg that makes it print just the subcommand names, without importing
anything, to get this kind of speed there as well. Call it
--generate-tab-completion or something, and don't print it in the help
output.
> (I actually reduced it to 85ms by minimizing the imports even
> further).
Goodie. For reference, I think git was able to list its subcommands in
about 20 ms. Just so you know what to aim for. :-)
> I could actually hard-code the commands only in the script. At the
> moment I removed the _stg_* functions and added some common
> _stg_all_patches() to avoid duplicating the code (see attached).
Seems reasonable.
Next time I do some StGIT hacking (not this weekend, unfortunately), I
was planning to build more tab-completion stuff. On top of my list are
fixing basic completion for all subcommands, and fixing some kind of
filename completion. But do feel free to do it first if you like. :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-16 16:23 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
In-Reply-To: <455C412D.1030408@xs4all.nl>
On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
>
> This is not about CVS or SVN, so don't put them up as a strawman.
> If you want to argue that my brain is warped, use other distributed VCs as an
> example.
Your example has nothing at all to do with "pull" vs "fetch", though.
Your example is about something totally _different_, namely that under
git, "git init-db" is _only_ for creating a _new_ project.
> The following
>
> mkdir x y
> cd x
> hg init
> echo hoi > bla
> hg add
> hg commit -m 'yes, I am also too stupid to refuse explicit empty commit messages'
> cd ../y
> hg init
> hg pull ../x
>
> pretty much works the same in Darcs, bzr and mercurial.
>
> With GIT, this is what happens
>
> [hanwen@haring y]$ git pull ../x
Bzzt. This is where you went wrong, and you blamed "pull".
The way you do this in git is to NOT do "git init". Instead, you replace
all the
mkdir y
cd ../y
hg init
hg pull ../x
with a simple
git clone x y
and YOU ARE DONE.
Now, we could certainly _make_ "git pull" work on an empty git project,
but that has _nothing_ to do with what people have been talking about.
In fact, the fact that "git fetch" kind of works is not exactly accidental
(because "git fetch" _is_ meant to add new local branches too), but all
the problems you have with it are due to the SAME issue. You started
without any branch at all, because you started with an empty git repo, and
you're simply not _supposed_ to do that.
So current rule (and this is not new, it's always been true): the ONLY
time you use "git init-db" is when you are going to start a totally new
project. Never _ever_ otherwise. If you want to track another project, use
"git clone".
> This might not be typical GIT use, but it does show the typical GIT user
> experience, at least mine.
It's not that it isn't typical, it's that you are using the wrong model.
Maybe it's not well documented, I can easily give you that, but ALL your
problems come from that fundamental starting point: you shouldn't have
used "git init-db" in the first place.
Somebody want to document it?
Alternatively, we certainly _could_ make "git pull" just accept an empty
git repo, and make it basically create the current branch.
(And we probably should improve the error messahe)
> I don't want ANYTHING to really change, I just want a sane interface to it.
The sane interface _exists_. It's called "git clone".
^ permalink raw reply
* Re: [StGIT PATCH] StGIT bash completion
From: Catalin Marinas @ 2006-11-16 16:12 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Shawn Pearce
In-Reply-To: <20061116154002.GA20729@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]
On 16/11/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-11-16 14:21:27 +0000, Catalin Marinas wrote:
> > Thanks for the patch. I modified it slightly to automatically
> > generate the options for other commands as well (by invoking "stg
> > help <command>" and it doesn't seem to be slow). I'll try to push it
> > tonight.
>
> Hmm. I'll have to try it, but I was half planning to hard-code the
> list of subcommands instead of calling "stg help" since it causes a
> tangible delay. On the machines I've tried, it easily takes 0.2
> seconds to run "stg help" (with hot caches; with cold caches, it's
> _really_ bad), and that's bad for interactive behavior.
Indeed, stg help takes over 200ms on my machine as well, with hot
caches but this is mainly because it imports all the stgit.commands.*
modules in order to read the short description. The 'stg help
<command>' takes around 90ms on my machine since it only imports one
module (I actually reduced it to 85ms by minimizing the imports even
further).
I could actually hard-code the commands only in the script. At the
moment I removed the _stg_* functions and added some common
_stg_all_patches() to avoid duplicating the code (see attached).
--
Catalin
[-- Attachment #2: stgit-completion.bash --]
[-- Type: application/octet-stream, Size: 4282 bytes --]
# bash completion support for StGIT -*- shell-script -*-
#
# Copyright (C) 2006, Karl Hasselström <kha@treskal.com>
# Based on git-completion.sh
#
# To use these routines:
#
# 1. Copy this file to somewhere (e.g. ~/.stgit-completion.bash).
#
# 2. Add the following line to your .bashrc:
# . ~/.stgit-completion.bash
stg_commands="
--help
--version
add
applied
assimilate
branch
delete
diff
clean
clone
commit
export
files
float
fold
goto
help
id
import
init
log
mail
new
patches
pick
pop
pull
push
refresh
rename
resolved
rm
series
show
status
top
unapplied
uncommit
"
# The path to .git, or empty if we're not in a repository.
_gitdir ()
{
echo "$(git rev-parse --git-dir 2>/dev/null)"
}
# Name of the current branch, or empty if there isn't one.
_current_branch ()
{
local b=$(git symbolic-ref HEAD 2>/dev/null)
echo ${b#refs/heads/}
}
# List of all applied patches.
_applied_patches ()
{
local g=$(_gitdir)
[ "$g" ] && cat "$g/patches/$(_current_branch)/applied"
}
# List of all unapplied patches.
_unapplied_patches ()
{
local g=$(_gitdir)
[ "$g" ] && cat "$g/patches/$(_current_branch)/unapplied"
}
# List of all patches.
_all_patches ()
{
local b=$(_current_branch)
local g=$(_gitdir)
[ "$g" ] && cat "$g/patches/$b/applied" "$g/patches/$b/unapplied"
}
# List of all patches except the current patch.
_all_other_patches ()
{
local b=$(_current_branch)
local g=$(_gitdir)
[ "$g" ] && cat "$g/patches/$b/applied" "$g/patches/$b/unapplied" \
| grep -v "^$(< $g/patches/$b/current)$"
}
# List the command options
_cmd_options ()
{
stg $1 --help | grep -e " --[A-Za-z]" | sed -e "s/.*\(--[A-Za-z]\+\).*/\1/"
}
# Generate completions for patches and patch ranges from the given
# patch list function, and options from the given list.
_complete_patch_range ()
{
local patchlist="$1" options="$2"
local pfx cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
*..*)
pfx="${cur%..*}.."
cur="${cur#*..}"
COMPREPLY=($(compgen -P "$pfx" -W "$($patchlist)" -- "$cur"))
;;
*)
COMPREPLY=($(compgen -W "$options $($patchlist)" -- "$cur"))
;;
esac
}
# Generate completions for options from the given list.
_complete_options ()
{
local options="$1"
COMPREPLY=($(compgen -W "$options" -- "${COMP_WORDS[COMP_CWORD]}"))
}
_stg_common ()
{
_complete_options "$(_cmd_options $1)"
}
_stg_all_patches ()
{
_complete_patch_range _all_patches "$(_cmd_options $1)"
}
_stg_other_patches ()
{
_complete_patch_range _all_other_patches "$(_cmd_options $1)"
}
_stg_applied_patches ()
{
_complete_patch_range _applied_patches "$(_cmd_options $1)"
}
_stg_unapplied_patches ()
{
_complete_patch_range _unapplied_patches "$(_cmd_options $1)"
}
_stg ()
{
local i c=1 command
while [ $c -lt $COMP_CWORD ]; do
if [ $c == 1 ]; then
command="${COMP_WORDS[c]}"
fi
c=$((++c))
done
# Complete name of subcommand.
if [ $c -eq $COMP_CWORD -a -z "$command" ]; then
COMPREPLY=($(compgen \
-W "$stg_commands" \
-- "${COMP_WORDS[COMP_CWORD]}"))
return;
fi
# Complete arguments to subcommands.
case "$command" in
# repository commands
id) _stg_all_patches $command ;;
# stack commands
float) _stg_all_patches $command ;;
goto) _stg_other_patches $command ;;
pop) _stg_applied_patches $command ;;
push) _stg_unapplied_patches $command ;;
# patch commands
delete) _stg_all_patches $command ;;
export) _stg_applied_patches $command ;;
files) _stg_all_patches $command ;;
log) _stg_all_patches $command ;;
mail) _stg_applied_patches $command ;;
pick) _stg_unapplied_patches $command ;;
rename) _stg_all_patches $command ;;
show) _stg_all_patches $command ;;
# all the other commands
*) _stg_common $command ;;
esac
}
complete -o default -F _stg stg
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Theodore Tso @ 2006-11-16 16:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre, Linus Torvalds
In-Reply-To: <7vd57of2cv.fsf@assigned-by-dhcp.cox.net>
On Wed, Nov 15, 2006 at 08:21:36PM -0800, Junio C Hamano wrote:
> Theodore Tso <tytso@mit.edu> writes:
> > So with Bitkeeper, with "bk pull" there was never any question about
> > which branch ("line of development") you would be merging into after
> > doing a "bk pull", since there was only one LOD, and given that BK had
> > the rule that a within a LOD only one tip was allowed, a "bk pull"
> > _had_ to do do a merge operation.
>
> I've never used Bk and I really appreciate your comments here.
>
> > If you are operating on your local development branch, the reality is
> > that merging is probably not the right answer in the general case,
>
> I agree, but I wonder why you are pulling/fetching (with or
> without merge) if you are operating on your local development
> branch (implying that you are in the middle of something else).
Well, when I was using BitKeeper, I never would. Bitkeeper has what
Linus calls the broken "repository == branch" model. So normally I
would have one repository where I would track the upstream branch, and
only do bk pull into that branch. I would do my hacking in another
repository (i.e., branch), and periodically keep track wha was going
on in mainline by cd'ing to the mainline repository and doing the bk
pull there.
The challenge when you put multiple branches into a single repository,
is you have to keep track of which branch you happen to be in. In the
BK world, this was obvious because it would show up in my shell
prompt:
<tytso@candygram> {/usr/src/linux-2.6}
2%
(OK, obviously I'm in the Linux 2.6 upstream repository)
In a system where you need to keep track of what branch you are in via
an SCM-specific local state information, it's easy to get confused and
do a pull when you are in the "wrong" branch, or while you have local
state in your working directory.
What I currently do (and I'm sure I'm being really horrible and need
to be say 100 "Hail, Linus"'es for penance for not adhering staying in
the one true distributed state of grace) is that I keep an entirely
separate Linux 2.6 git repository just to make sure I never get
confused about what branch I might happen to be in when I do the "git
pull" --- and yeah, I could have used "git fetch", but 3+ years of BK
usage plus Hg usage is hard to get away from. I'm sure this is where
Linus would say that use of BK and Hg, causes permanent brain damage,
ala's Dijkstra's ofted quoted comment about use of Basic inducing
brain damage....
> I have to disagree with this. In the simplest CVS-like central
> repository with single branch setup in which many "novice users"
> start out with, there is almost no need for "git fetch" nor
> tracking branch. You pull, resolve conflicts, attempt to push
> back, perhaps gets "oh, no fast forward somebody pushed first",
> pull again, then push back. So I am not sure where "you really
> do not want to use pull. trust me" comes from.
I think the problem is the people who have had years of BK or Hg
experience. Maybe it's more of a documentation problem; perhaps a
"git for BK" or "git for Hg" users is what's needed. The problem
though is that while use of BK is definitely legacy, there are going
to be a lot of people who need to use both BK and Hg.
> It is a different story for people who _know_ git enough to know
> what is going on. They may be using multiple branches and
> interacting with multiple remote branches, and there are times
> you would want fetch and there are other times you would want
> pull. But for them, I do think the suggestion would never end
> with "trust me" -- they would understand what the differences
> are.
Well, I think this is where git's learning curve challenges are. Yes,
for users that are doing the stupidest, most simplistic usage models,
git is quite easy to use. And I am willing to grant that for people
who are using the deepest, most complicated and most distributed
development, who understand multiple branches and the index, and all
of the deep git plumbing, there's also no problem.
The challenge is in between; to use a car analogy, git has a great
automatic transmision, and an extremely powerful "racing clutch". But
for someone where the automatic transmission isn't good enough, when
as they start to learn how to use the manual transmission, git's
extremely touchy "racing clutch" is much more difficult master ---
especially in comparison to people who have learned to drive other,
more pedestrian "standard transmission" cars. So people who try to
use git's racing clutch keep stalling out the car, and some give up in
frustration.
And maybe the problem is one that should be addressed only by lots of
training, but at the moment, that's the reason why I believe a number
of projects have chosen Hg instead of git; they need more than the
"stupid simple" git usage, but if they don't need the extreme power of
git, Hg is simpler for people to learn how to use. The problem, of
course, comes when later on, the project finds out they really want
git's power, and now they have to deal with the repository conversion
as well as retraining their entire development community.
But hey, maybe this isn't a problem the git community wants to solve;
clearly git is optimized for the Linux kernel development, and maybe
it's too much to ask that it also work well for somewhat less
extremely distributed development models. But in any case, that's why
I chose Hg for e2fsprogs. At the time when I made my choice, git was
just too painful to learn how to use its more esoteric features, and
Hg was much closer to BK's model. (Since then, Hg has added more
functionality, including better multiple branches in a repository
support, and it's gotten more complicated, but it's still much simper
to teach someone how to use Hg than git.)
Regards,
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Alexandre Julliard @ 2006-11-16 15:48 UTC (permalink / raw)
To: Petr Baudis
Cc: Junio C Hamano, Theodore Tso, git, Nicolas Pitre, Linus Torvalds
In-Reply-To: <20061116140141.GZ7201@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> How do those developers submit their changes? Do they push? If they do,
> git-rebase can be saving one merge at most, and the merge is actually a
> good thing (someone should write some nice standalone writeup about
> that).
No, they use git-format-patch and mail them in.
> If they don't have push access and maintain their patches locally until
> they get accepted, perhaps it would be far simpler for them to use
> StGIT?
For regular developers, sure. But regular developers will need to
properly understand the git model anyway, and then they will able to
make sense even of the standard git commands ;-) The problem is that
there isn't a smooth progression to that point.
At first, a user will simply want to download and build the code, and
for that git-pull works great, it's a one-stop command to update their
tree.
Then after a while the user will fix a bug here and there, and at that
point git-rebase is IMO the best tool, it's reasonably easy to use,
doesn't require learning other commands, and once the patch is
accepted upstream it nicely gets the tree back to the state that the
user is familiar with.
The problem is that rebase doesn't work with pull, so the user needs
to un-learn git-pull and start using git-fetch; it's to avoid this
that we recommend using git-fetch from the start, which is unfortunate
since it makes things harder for beginners.
--
Alexandre Julliard
^ permalink raw reply
* Re: [StGIT PATCH] StGIT bash completion
From: Karl Hasselström @ 2006-11-16 15:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Shawn Pearce
In-Reply-To: <b0943d9e0611160621g60a0cac2r5205e37ed7d9fe9f@mail.gmail.com>
On 2006-11-16 14:21:27 +0000, Catalin Marinas wrote:
> On 12/11/06, Karl Hasselström <kha@treskal.com> wrote:
>
> > A minimal bash completion script for StGIT. It completes the
> > subcommand names, and options and patch names for some
> > subcommands.
>
> Thanks for the patch. I modified it slightly to automatically
> generate the options for other commands as well (by invoking "stg
> help <command>" and it doesn't seem to be slow). I'll try to push it
> tonight.
Hmm. I'll have to try it, but I was half planning to hard-code the
list of subcommands instead of calling "stg help" since it causes a
tangible delay. On the machines I've tried, it easily takes 0.2
seconds to run "stg help" (with hot caches; with cold caches, it's
_really_ bad), and that's bad for interactive behavior.
There's also the point that some switches need (or can benefit from)
the tab completion machinery, and thus can't just be automatically
extracted and used. But autocompleting the switch names shouldn't
interfere with that, and hard-coding stuff that changes every now and
then is both morally wrong and a lot of work.
> Thanks for the other patches as well. I included some
Ah, thanks!
> but haven't finished them yet.
No problem. Thanks to the power of modern version control systems, I'm
able to use my own branch of StGIT in the meantime, on all the various
computers that I use. :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: git-svn bug?
From: Seth Falcon @ 2006-11-16 15:32 UTC (permalink / raw)
To: git
In-Reply-To: <20061115223709.GG24861@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Seth Falcon <sethfalcon@gmail.com> wrote:
>> I always send commits as:
>>
>> git-svn dcommit remotes/git-svn..master
>>
>> Possibly replacing master with whatever git branch I'm working on.
>
> Or just:
>
> git-svn dcommit remotes/git-svn..
>
> to send the current branch.
Yes, but be warned. As I just discovered, dcommit always commits up
to the HEAD of the current branch. So I just did:
git-svn dcommit remotes/git-svn..HEAD~3
And the ~3 was ignored. :-(
Not a bug, as the doc says that dcommit operates on HEAD, but it would
be convenient to have this work -- especially since reviewing with
diff (or better log -p) seems natural.
^ permalink raw reply
* Re: how to authenticate with git-svn on a subversion repository
From: Seth Falcon @ 2006-11-16 15:27 UTC (permalink / raw)
To: git
In-Reply-To: <4559D37E.1070703@archlinuxfr.org>
Comète <comete@archlinuxfr.org> writes:
> hello !
>
> i would like to use git-svn to commit some modifications to a
> Subversion repository but i don't know where i can enter my username
> and password to commit to the repository ? Is there any special file
> to put them.
> For now i get an error:
There may be a better way, but if you just use the svn command line
client to create a small working copy from the repository, you will
have a place to enter credentials and they will be cached in
~/.subversion and git-svn will find them.
^ permalink raw reply
* Re: [StGIT PATCH] StGIT bash completion
From: Catalin Marinas @ 2006-11-16 14:21 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Shawn Pearce
In-Reply-To: <20061112211813.19959.73406.stgit@localhost>
On 12/11/06, Karl Hasselström <kha@treskal.com> wrote:
> A minimal bash completion script for StGIT. It completes the
> subcommand names, and options and patch names for some subcommands.
Thanks for the patch. I modified it slightly to automatically generate
the options for other commands as well (by invoking "stg help
<command>" and it doesn't seem to be slow). I'll try to push it
tonight.
Thanks for the other patches as well. I included some but haven't
finished them yet.
--
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox