* Re: git tag: don't complain of empty messages
From: Han-Wen Nienhuys @ 2006-11-16 1:27 UTC (permalink / raw)
To: git
In-Reply-To: <ejgbrq$o5u$1@sea.gmane.org>
Jakub Narebski escreveu:
> Han-Wen Nienhuys wrote:
>
>> Junio C Hamano escreveu:
>>> I do not have a strong objection against allowing tags without
>>> messages, but at the same time I do not see a compelling reason
>>> to allow them either. Care to explain what workflow is helped
>>> by an empty tag?
>> the tagname usually is enough of a description, but I want the tags to
>> end up in the object DB, eg.:
>>
>> git tag release/2.10.0 HEAD
>>
>> now I have to use
>>
>> git tag -m "this really sucks" release/2.10.0 HEAD
>
> Why not
>
> git tag -m "release 2.10.0" release/2.10.0 HEAD
>
> This way you would know what tag points to even if you loose it's
> reference...
that would double, given that the tag name is already in the tag object.
Currently, I have
**
[lilydev@haring gub]$ cat .git/refs/tags/gubrelease-2.9.29-2
1ac5c78609a9f79787825b62c9576542eedce795
[lilydev@haring gub]$ git cat-file tag
1ac5c78609a9f79787825b62c9576542eedce795
object b75db784e3d6a9e1d2cff3f77036aaa88598b53c
type commit
tag gub-2.9.29-2
tagger Han-Wen Nienhuys <lilydev@haring.localdomain> 1162921716 +0100
build and upload
**
'build and upload' is a polite way of saying 'this really sucks'.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Anand Kumria @ 2006-11-16 1:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611151111250.3349@woody.osdl.org>
On Wed, 15 Nov 2006 11:18:36 -0800, Linus Torvalds wrote:
> On Wed, 15 Nov 2006, Andy Parkins wrote:
>>
>> On the one hand you're arguing that git syntax is easy to learn, and on the
>> other that no one will be able to learn a new syntax just as easily.
>
> I'm saying that people who are new to git will _have_ to learn new
> concepts ANYWAY.
>
> I don't think the naming is the hard part.
It isn't - the unexpectedness of what happens is.
I've started by teaching how to do stuff locally, then "pushing" it out to
others (me). All the while being able to point out how this is either all
local, or sends stuff (without any local modifications) to others.
Come up to 'pull' and ere you have to point out that not only will you get
the remote changes but they are also merged into your repository. On the
wrong branch?
Too bad.
The problem with git-pull behaving illogically drove me to look at cogito
(an aside, perhaps cg-throw should be the corrollary to cg-fetch?)
instead. Alas it has problems with a cogito branch not being something you
can mentally map back to a git branch.
> But I bet people don't teach it that way. They _start_ by teaching "pull".
> Right?
Nope.
Anand
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Anand Kumria @ 2006-11-16 1:51 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611151524000.2591@xanadu.home>
On Wed, 15 Nov 2006 15:26:44 -0500, Nicolas Pitre wrote:
> On Wed, 15 Nov 2006, Petr Baudis wrote:
>
>> On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:
>> > You have to admit both pull and fetch have been contaminated
>> > with loaded meanings from different backgrounds. I was talking
>> > about killing the source of confusion in the longer term by
>> > removing fetch/pull/push, so we are still on the same page.
>>
>> How was/is fetch contaminated?
>
> I think "fetch" is sane. Its only problem is a missing symetrical
> counterpart verb, like "get" and "put".
"throw" ?
But I think "I'll just 'throw' this set of patches at you" is a lot
harshers sounding than "I'll just 'push' this set of patches at you".
Anand
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-16 1:53 UTC (permalink / raw)
To: git
In-Reply-To: <455BBCE9.4050503@xs4all.nl>
Han-Wen Nienhuys wrote:
> FWIW, I regularly mess up with the differences between fetching, pulling
> and merging. In particular, having to do a two step process to get
> remote changes in,
>
> git pull url-to-server master:master
> ..error message about not being a fast-forward..
>
> git pull --update-head-ok url-to-server master:master
> ..still an error message about update not being a fast-forward..
What about:
git pull --update-head-ok url-to-server +master:master
(or --force, but be careful with that one)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-checkout: allow pathspec to recover lost working tree directory
From: Junio C Hamano @ 2006-11-16 2:00 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <ejge6q$bm7$1@sea.gmane.org>
"Anand Kumria" <wildfire@progsoc.org> writes:
> On Wed, 15 Nov 2006 11:07:19 -0800, Junio C Hamano wrote:
>
>> It is often wanted on the #git channel that this were to work to
>> recover removed directory:
>>
>> rm -fr Documentation
>> git checkout -- Documentation
>> git checkout HEAD -- Documentation ;# alternatively
>>
>> Now it does.
>
> One thing I often seem to do is make some changes, test them out and
> remove the file if it wa a dead end and get my original back with
> 'cg-restore <file>'. Does this mean that the git equivalent will be 'git
> checkout -- <file>' as well?
Naming individual files has been supported for a long time.
What this patch adds is an ability to name a whole directory to
restore to the index state or a named commit state).
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-16 2:03 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <455BBCE9.4050503@xs4all.nl>
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> FWIW, I regularly mess up with the differences between fetching,
> pulling and merging. In particular, having to do a two step process
> to get remote changes in,
>
> git pull url-to-server master:master
> ..error message about not being a fast-forward..
>
> git pull --update-head-ok url-to-server master:master
> ..still an error message about update not being a fast-forward..
>
> (sigh)
Sigh indeed.
Why don't you do the simple and obvious
git pull url master
or "git pull url" if you already know the master is the branch
you are interested in.
The more advanced form of using tracking branches are there and
documentation talks about them for completeness but that does
not mean you have to use it.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Han-Wen Nienhuys @ 2006-11-16 2:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcx0gnbq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano escreveu:
>> FWIW, I regularly mess up with the differences between fetching,
>> pulling and merging. In particular, having to do a two step process
>> to get remote changes in,
>>
>> git pull url-to-server master:master
>> ..error message about not being a fast-forward..
>>
>> git pull --update-head-ok url-to-server master:master
>> ..still an error message about update not being a fast-forward..
>>
>> (sigh)
>
> Sigh indeed.
>
> Why don't you do the simple and obvious
>
> git pull url master
It is not all evident from the git-pull man-page that this is the
obvious and most common usage.
> or "git pull url" if you already know the master is the branch
> you are interested in.
Because I usually replace verbose commands with shortcuts only when I
understand exactly what the shortcut is.
To me it's very unlogical that
master:current-branch
doesn't work, but
master:
does work, and does what I'd expect
master:current-branch
to do. Interestingly, doing
pull ..url.. master:HEAD
also doesn't merge into the current branch, but rather creates a bogus
refs/heads/HEAD
I use the remote:local syntax, because I started using GIT in scripted
compiles from copied branches of remote repositories. There the explicit
remote:local statements are necessary because there is no default branch.
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Petr Baudis @ 2006-11-16 2:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejeq20$5hn$1@sea.gmane.org>
On Wed, Nov 15, 2006 at 11:28:27AM CET, Jakub Narebski wrote:
> Santi Béjar wrote:
>
> > On 11/15/06, Jakub Narebski <jnareb@gmail.com> wrote:
>
> >> You mean
> >>
> >> git merge git://repo.com/time_machine.git#branch
> >>
> >> don't you (perhaps with 'master' as default branch)?
> >
> > perhaps with remote 'HEAD' as default branch?
>
> No! HEAD might change without your notice, and you want to know
> which branch you merge. With remotes the default could be first
> branch in the pull/fetch list, but with bare URL...
No! If HEAD changed without your notice, it means that the remote
repository admin _wants_ you to start fetching another branch now.
Imagine a setup of these branches:
phooey-1.2 legacy lineage
phooey-2.0 last stable
phooey-3.0 current development (no releases yet)
phooey-4.0 stash for futuristic functionality, heavily
experimental
In this case, HEAD now points to phooey-3.0 but when it becomes stable,
it would change to phooey-4.0.
The common practice of having 'master' pointing on whatever you
currently have now and and "cutting out" the branches from it at random
times is something heavily influenced by CVS where this is the only sane
way of branching (the cutting out even hardcoded in numbering scheme).
In more advanced systems, you may want to be much more flexible wrt. this
(note that I'm not saying you necessarily _should_ be).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Michael K. Edwards @ 2006-11-16 3:02 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611151523290.3349@woody.osdl.org>
On 11/15/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Actually, with different people involved it's _much_ better to do it in
> one shot.
>
> Why? Because doing a separate "fetch to local space" + "merge from local
> space" actually loses the information on what you are merging.
>
> 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'
>
> which is what you get if you fetched it first.
Full ACK from a platform integrator's perspective. Local merge is
great for trial runs but the history in a persistent branch should be
as self-contained and self-explanatory as possible. It shouldn't
depend on what I name local tracking branches, which are just a
convenience so that I can still do trial runs when my connectivity is
broken.
I don't have to manually log the _mechanical_origin_ of a given delta;
git does that for me, and mostly just DTRT when the same delta arrives
via several paths. When I use git pull from a remote branch (with or
without an entry in remotes/heads, which for this purpose is just
shorthand), I don't have to manually log what conflicts I have and
haven't resolved, either; I must have assimilated whatever I cared
about in the remote branch's history up to that point, because as long
as there are things in that remote branch that I haven't decided how
to handle, I stick to cherry-picking.
Obviously, fetch to local space is great (especially when you spend
some of your working hours behind a firewall that blocks outbound TCP
9418). Fetch from local space is also great, when the local space you
are fetching from reflects local work (such as a sync point and
reconciliation of several upstream sources, which then needs to be
ported forward or back to the chosen core version for each platform).
Fetch from a local space that is just a tracker for remote work is not
great, because it doesn't capture the editorial decision implied by a
remote pull: I looked at what the remote branch had to offer as of
this date, systematically decided which bits did and didn't belong in
the branch to which I was pulling, and pulled.
The record of that pull becomes a first-class object because it's
attached to an actual content delta in the target branch. So it
propagates into branches that pull from it. Pulling this delta into
another branch is different from cherry-picking a feature delta; it
implies acceptance of the reconciliation and editorial work associated
with the merge in the source branch.
Coming from me, this is all rather theoretical, as I haven't been
using this particular tool for the purpose long enough to have an
independent opinion. But for what it's worth, the workflow Linus
describes isn't just for the guy at the top of the pyramid.
Cheers,
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-16 3:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn Pearce, Carl Worth, Michael K. Edwards, git
In-Reply-To: <Pine.LNX.4.64.0611151905460.2591@xanadu.home>
On Wed, 15 Nov 2006, Nicolas Pitre wrote:
>
> That is an implementation detail that should be easily overcome once the
> notion of tracking branch with URL attribute is implemented.
Nope.
I simply don't _have_ those branches.
Why? Because the kernel is _distributed_. There is no central place
(certainly not my repository) that tracks all the possible branches that
might get merged.
In other words, I repeat: in a TRULY DISTRIBUTED ENVIRONMENT it makes more
sense to have a "pull" that fetches and merges, over something that
fetches separately and then merges. Because in a truly distributed
environment, you simply DO NOT HAVE static branches that you can associate
with particular sources.
See?
And the thing is, I think the git design should be geared towards true
distribution. It should NOT be geared toward a fairly static set of
branches that all have a fairly static set of other repositories
associated with them. Can you see the difference?
I'm personally convinced that one of the reasons people tend to use git in
a centralized manner is just a mental disease that has its roots in how
they used _other_ SCM's. I don't want git design to be polluted by such a
centralized notion.
So to repeat: you can always make "pull" boil down to "pull from myself"
(aka just "merge"), but you can _not_ make "fetch + merge" boil down to
"pull" without meking up extra state to track separately. In other words,
"pull" really is the strictly more powerful operation.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Petr Baudis @ 2006-11-16 3:07 UTC (permalink / raw)
To: Sean; +Cc: Marko Macek, Shawn Pearce, Linus Torvalds, Junio C Hamano, git,
cworth
In-Reply-To: <20061115172834.0a328154.seanlkml@sympatico.ca>
On Wed, Nov 15, 2006 at 11:28:34PM CET, Sean wrote:
> Git is confusing enough for new users without "Git" and "Cogito"
> being mixed without comment on the Git webpage. At the very
> least, the links should be changed to "Cogito for CVS/SVN users".
It's not being mixed without comment, in the very first paragraph I'm
trying to explain what the difference is and why is Cogito used for
introduction to Git. I've tried to clear it up even more now.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-16 3:12 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
In-Reply-To: <455BBCE9.4050503@xs4all.nl>
On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
> Linus Torvalds escreveu:
> > - git itself has now done it that way for the last 18 months, and the
> > fact is, the people _complaining_ are a small subset of the people who
> > actually use git on a daily basis and don't complain.
>
>
> that's not a good argument; the set of git users is a small subset of those
> that looked at git, and dismissed it because they couldn't wrap their heads
> around it.
And I've said this again, and I'll say it once more: that has basically
_nothing_ to do with whether you spell "pull" as "pull" or "merge".
The reason people have trouble wrapping their heads around git is because
they have been braindamaged by CVS and SVN, and just don't understand the
fairly fundamental new concepts and workflow.
That's totally different from then arguing about stupid naming issues.
Peopel seem to believe that changign a few names or doing other totally
_minimal_ UI changes would somehow magically make things understandable. I
claim that isn't so at all. The fact is, git is different from CVS and
SVN, and git _has_ to be different from CVS and SVN. It has to be
different because the whole model of CVS and SVN is simpyl fundamentally
BROKEN.
> It's worth trying to get those on board by fixing the annoying
> little issues that have popped up in this thread.
I claim that those "annoying little issues" are totally made up by people
who had trouble wrapping their minds about git, and then make up reasons
that have nothing to do with reality for why that might be so.
Let's face it, you could just alias "merge" to "pull", and it wouldn't
really change ANYTHING. You'd still have to learn the new model.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Petr Baudis @ 2006-11-16 3:21 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Andy Parkins, git
In-Reply-To: <87r6w4s5ga.wl%cworth@cworth.org>
On Wed, Nov 15, 2006 at 11:36:21PM CET, Carl Worth wrote:
> On Wed, 15 Nov 2006 13:13:11 -0800, Junio C Hamano wrote:
> > That is a very fine example, but I do not see why it is a
> > problem. I do not think the goal of Porcelain is to make it
> > totally unnecessary for users to know about the plumbing.
>
> If not, then the promise of the porcelain fails. If cogito offers
> "Here are 40 commands so you don't have to learn git's 140" and then
> next says "Oh, and you'll still want to learn all those git commands
> too", then its existence only makes the "too much stuff to learn"
> problem worse, not better.
I didn't get this argument before either - why do you need to learn "all
those git commands" too? You'll never have to learn "git add" or even
"git commit". If you want to pick specific git commands later (like "git
bisect", which even seeks in a Cogito-compatible way), that's fine, go
ahead! But you by no means have to learn _other_ commands than those you
need. If you want to bisect, you have to learn no other Git commands
than "git bisect".
Another point is, if using _just_ _git_ requires you to learn "all those
git commands too" from git-commit-tree up (yes it does! if you want your
authorship information to be correct), something is wrong.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-16 3:27 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <455BCD2B.6060603@xs4all.nl>
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> Junio C Hamano escreveu:
>>...
>> Sigh indeed.
>>
>> Why don't you do the simple and obvious
>>
>> git pull url master
>
> It is not all evident from the git-pull man-page that this is the
> obvious and most common usage.
In the git user poll a few months ago, many people recommended
"everyday git" as a good cheat sheet, and indeed it does not
talk anything about directing the underlying git-fetch to
manipulate tracking branches by giving explicit refspec pairs to
git pull. You are obviously tripped by both the overeager
manpage (but manpage should strive to be complete so you cannot
really blame it) and less than optimally organized tutorial
style documents.
I myself do prefer, when learning a new tool, to use longhand
until I understand the shorthand, but that attitude requires a
true commitment to learn the tool, and most people do not go
that route. Tutorial style documents tend to give the commonly
used shorthand first for that exact reason.
Shorthand to give only the branch name to fetch and merge
immediately without using a tracking branch is equivalent to
longhand "branch:" as you found out, so if that was what was
desired then people with the attitude "before understanding what
longhand does I prefer using shorthand" like myself and you
would have liked to learn "git pull url branch:" notation from
Tutorial. But I think we _are_ minority. People would not want
to see that seemingly useless colon there.
> To me it's very unlogical that
>
> master:current-branch
>
> doesn't work,
That shows that you did not understand what fetch does. Maybe
you do now, but a very natural consequence of directing fetch to
update tracking branches with the colon notation is:
- "pull url master:master", while on master, is almost always
wrong and not something you would want to do, ever.
"fetch --update-head-ok url +master:master; reset --hard HEAD"
may make sense but never "pull".
> I use the remote:local syntax, because I started using GIT in scripted
> compiles from copied branches of remote repositories. There the
> explicit remote:local statements are necessary because there is no
> default branch.
If you perhaps wanted to ask "is there a better way to do what
I've been doing?", then I am willing to think with you to come
up with an answer. Unfortunately, however, I do not understand
the above paragraph, so I'd refrain from commenting on it in
this response.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-16 3:35 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <7vbqn8gjeo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
(not changing what I said but editorial)
> I myself do prefer, when learning a new tool, to use longhand
> until I understand the shorthand, but that attitude requires a
> true commitment to learn the tool, and most people do not go
> that route. Tutorial style documents tend to give the commonly
> used shorthand first for that exact reason.
Eh, sorry, "prefer to use longhand until I understand what is
going on before using the shorthand" is what I wanted to say.
> Shorthand to give only the branch name to fetch and merge
> immediately without using a tracking branch is equivalent to
> longhand "branch:" as you found out, so if that was what was
> desired then people with the attitude "before understanding what
> longhand does I prefer using shorthand" like myself and you
"prefer not using shorthand", sorry again.
> would have liked to learn "git pull url branch:" notation from
> Tutorial. But I think we _are_ minority. People would not want
> to see that seemingly useless colon there.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-16 3:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, Carl Worth, Michael K. Edwards, git
In-Reply-To: <Pine.LNX.4.64.0611151859370.3349@woody.osdl.org>
On Wed, 15 Nov 2006, Linus Torvalds wrote:
>
>
> On Wed, 15 Nov 2006, Nicolas Pitre wrote:
> >
> > That is an implementation detail that should be easily overcome once the
> > notion of tracking branch with URL attribute is implemented.
>
> Nope.
>
> I simply don't _have_ those branches.
>
> Why? Because the kernel is _distributed_. There is no central place
> (certainly not my repository) that tracks all the possible branches that
> might get merged.
>
> In other words, I repeat: in a TRULY DISTRIBUTED ENVIRONMENT it makes more
> sense to have a "pull" that fetches and merges, over something that
> fetches separately and then merges.
[...]
OK fine. git-pull is there to stay and let's make sure it remains the
same.
Let's see if, for example, git-merge can be made more useful in the mean
time for those evidently inferior people that would prefer an interface
that maps more closely to the actual operation that is being performed.
And although I do understand what "pull" does, I think I should qualify
myself as one of those inferior people nevertheless since /pull . blah"
really irritates me. OK I must be really dumb to let myself being
disturbed by such an insignificant detail... but apparently I'm not
alone.
But I promise to never change the "pull" behavior if I ever attempt to
fix the "merge" command for the inferior mortals as myself. All power
to those with superior minds shall never be removed.
;-)
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Theodore Tso @ 2006-11-16 1:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611150950170.3349@woody.osdl.org>
On Wed, Nov 15, 2006 at 10:03:18AM -0800, Linus Torvalds wrote:
> So the reason for using "git pull" is
>
> - bk did it that way, and like it or not, bk was the first usable
> distributed system. hg is totally uninteresting.
Yes, "bk pull" had an implied merge. But, the reason why bk pull was
never really a problem with Bitkeeper is because it didn't really have
support for multiple branches active within the same repository ---
what Larry called "lines of development". Or rather, Larry started
down the path of implementing lines of development, and then never
fully supported it, mainly because making it easy for people to use
was the tricky part.
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.
The moment you start supporting multiple unmerged tips in a repository
i.e., branches, it raises the question, "which branch should the pull
operation merge onto"? And git's answer, "the current branch", is
often not the right one. *That's* why always doing a merge isn't
always the right answer, and so in the git world, people are told, use
"git fetch" instead, and in the hg world, "hg pull" doesn't do the
merge. IMO, it's a fundamental result of the fact that both git and
hg have chosen to support mulitple LOD's, whereas BK punted on the
concept.
If you are operating on your local development branch, the reality is
that merging is probably not the right answer in the general case,
which is why the hg world have omitted doing the merge. And by
telling people, use "git fetch" instead, that's also an implicit
admission that merging onto the current branch is often not the Right
Thing.
The problem is that "pull" is a very evocative word, especially given
the existence "push", and so in the git world we are reduced to
telling people, "you really don't want to use pull, trust me".
Is this a major issue? Not really; I can think of a number of other
issues that make git hard to learn, and why hg has a more gentle
learning curve, and the "don't use pull" is probably a relatively
minor annoyance in the grand scheme of things.
If people are looking for a simple way out, maybe it would be enough
to have an option where if "git pull" is called from an interactive
terminal, and the "novice user" option is enabled, "git pull" returns
a warning message, "You probably want to use 'git fetch' instead; are
you sure?" If people are saying that we shouldn't be teaching "git
pull" until fairly late in the game, maybe we should have a way of
discouraging novices from using, simply because they they are used to
seeing "pull" from other distributed SCM's.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Petr Baudis @ 2006-11-16 3:53 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611150917.23756.andyparkins@gmail.com>
On Wed, Nov 15, 2006 at 10:17:22AM CET, Andy Parkins wrote:
> On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:
>
> > 3) remote branch handling should become more straight forward.
>
> I was completely confused by this origin/master/clone stuff when I started
> with git. In hindsight, now I understand git a bit more, this is what I
> would have liked:
>
> * Don't use the name "origin" twice. In fact, don't use it at all. In a
> distributed system there is no such thing as a true origin.
>
> * .git/remotes/origin should be ".git/remotes/default". "origin" is only
> special because it is the default to push and pull - it's very nice to have a
> default, but it should therefore be /called/ "default".
But "default" is way too generic a name, it's much more confusing I
think. As the one guilty of inventing master and origin, I agree that
they are somewhat silly, but if I would have to pick which one to
replace with something "better", I'd much rather pick master.
Yes, Git can operate in a completely distributed manner. People do use
it as it. And there are also people that have no origin branch in their
repository. But the vast (overwhelming!) majority of people _does_ work
in some kind of hierarchical setup, and for them origin does have a
meaning. And origin URL can even change over time!
> * git-clone should really just be a small wrapper around
> - git-init-db
> - create .git/remotes/default
> - maybe create specific .git/config
> - git-fetch default
> If git-clone does anything that can't be done with settings in the config
> and the remotes/default file then it's wrong. The reason I say this is that
> as soon as git-clone has special capabilities (like --shared, --local
> and --reference) then you are prevented from doing magic with existing
> repositories. For example; how do you create a repository that contains
> branches from two other local repositories that have the objects hard linked?
Here I think that modulo the lack of remotes support (which is not a
fundamental thing here), the general setup of how Cogito does stuff is
much more saner than the current Git mess. It does basically exactly
what you've said above, and even the fetching itself is IMHO written
much more cleanly than in Git. In an ideal world, Git would just take
Cogito's code here. :-)
> While I'm writing wishes, I'd like to jump on Junio's integration with other
> fetch-backends wish. I use git-svn, and it would be fantastic if I could
> replace:
>
> git-svn init --id upstream/trunk svn://host/path/trunk
> git-svn fetch --id upstream/trunk
> git-svn init --id upstream/stable svn://host/path/branches/stable
> git-svn fetch --id upstream/stable
>
> With a .git/remotes/svn
> SVN-URL: svn://host/path
> Pull: trunk:refs/remotes/upstream/trunk
> Pull: branches/stable:refs/remotes/upstream/stable
> and
> git fetch svn
>
> Obviously, the syntax is just made up; but you get the idea. Even better,
> would be if it could cope with my "*" syntax suggested above:
> SVN-URL: svn://host/path
> Pull: trunk:refs/remotes/upstream/trunk
> Pull: branches/*:refs/remotes/upstream/*
It shouldn't be hard to do at all. Have the porcelain call "protocol
drivers" based on protocol in some generic way, like
/usr/lib/git/protocol/$proto.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-16 4:07 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <7vbqn8gjeo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
>> Junio C Hamano escreveu:
>>>...
>>> Sigh indeed.
>>>
>>> Why don't you do the simple and obvious
>>>
>>> git pull url master
>>
>> It is not all evident from the git-pull man-page that this is the
>> obvious and most common usage.
>
> In the git user poll a few months ago, many people recommended
> "everyday git" as a good cheat sheet, and indeed it does not
> talk anything about ...
Sorry, I must have been very grumpy mood when I wrote the
message (cf. Pasky's utterance on #git a few days ago). What I
wrote was a bit incoherent, so here is an attempt to clarify.
I should point out that the colon separated refspec pairs you
can give to "pull" was designed with considerable thought; it is
not a convenience hack that we give them to "pull" that "fetches
and merges". Linus's and Michael's other messages in this
thread may seem to be saying that using tracking branches is not
a kosher way to use git, but I do not think that is a correct
interpretation of their messages.
The workflow that does not use any tracking branches is the
simplest and truly distributed way as Linus says. The command
recommended in "everyday git" document:
git pull $url $branchname
is the most natural way to express it, and simplest variant that
you do not have to say anything "colon" in it.
However that does not mean it is a bad practice to use tracking
branches. Sometimes it is handy to be able to refer to what you
fetched from the remote the last time, possibly which is what
you merged into your branch if that last fetch was done via "git
pull", so that you can later examine its history without your
own development. For that purpose, you need to store what you
fetched in your local refs/ namespace, and that is what tracking
branches are.
The workflow that fetches to tracking branches and then merges
within local repository as two separate steps loses the true
origin information ("Merge branch 'foo'" vs "Merge branch 'foo'
of git://git.bar.xz/foo.git"). That's the reason why not just
"git fetch" but also "git pull" take the colon separated refspec
pairs to direct git to update the tracking branches when "pull"
happenes. The longhands are cumbersome to type all the time,
and we have shorthand, both to store URL: and Pull: lines in
remotes/ hierarchy, and also $branchname alone is a shorthand
for saying "${branchname}:", meaning "do not use a tracking
branch to store this".
So you have options to use or not to use tracking branches.
After cloning we happen to default to track all remote branches
with corresponding local tracking branches, but that is only
because may people on the list wanted to make life easier to CVS
migrants where following mostly static set of branches is the
norm ("set" is the static part: I do not mean the branches stay
still) and we wanted to make it easier for them.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-16 4:21 UTC (permalink / raw)
To: Theodore Tso; +Cc: git, Nicolas Pitre, Linus Torvalds
In-Reply-To: <20061116011411.GB10512@thunk.org>
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).
> ... And by
> telling people, use "git fetch" instead, that's also an implicit
> admission that merging onto the current branch is often not the Right
> Thing.
>
> The problem is that "pull" is a very evocative word, especially given
> the existence "push", and so in the git world we are reduced to
> telling people, "you really don't want to use pull, trust me".
I would rather say "use 'git branch' to make sure if you are
ready to merge". Who teaches not to use "git pull"?
> If people are looking for a simple way out, maybe it would be enough
> to have an option where if "git pull" is called from an interactive
> terminal, and the "novice user" option is enabled, "git pull" returns
> a warning message,
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.
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.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Theodore Tso @ 2006-11-16 4:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Michael K. Edwards, git
In-Reply-To: <Pine.LNX.4.64.0611151226590.3349@woody.osdl.org>
On Wed, Nov 15, 2006 at 12:40:43PM -0800, Linus Torvalds wrote:
> And yes, this is why you should NOT try to use the same naming as "hg",
> for example. Last I saw, hg still didn't even have local branches, To
> mercurial, repository == branch, and that's it. It was what I came from
> too, and I used to argue for using git that way too. I've since seen the
> error of my ways, and git is simply BETTER.
Actually, that's not true. Mercurial has local branches, just as git
does. Some people choose not to *use* this particular feature, and
use the BK style repository == branch, but that's mainly because it's
conceptually easy for them, and a number of BK refugees are very
happily using Hg.
It's probably because of the BK refugee population that after you do
an hg pull, it will warn you that you need to do an "hg update" in
order to merge the working directory up to the latest version that was
just pulled --- and this change was made precisely because Hg supports
local branches, and merging with the current branch isn't always the
right thing, unlike with BK.
> And the concept of local branches is exactly _why_ you have to have
> separate "fetch" and "pull", but why you do _not_ need a separate "merge"
> (because "pull ." does it for you).
It's just that the semantics are different, and many developers have
to use multiple DSCM's, depending on what project they happen to be
developing on. So the reality is that there are people who have to
use bzr, git, and hg, all at the same time. And while eventually
newbies will figure out and remember that "git pull ." == "merge", the
naming is simply confusing, that's all. (What does "pull" have to do
with "merge"? It's not at all obvious.)
For somoene who uses git full-time, and to the exclusion of all other
systems, I'm sure it's not a problem at all.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Petr Baudis @ 2006-11-16 4:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611150950170.3349@woody.osdl.org>
On Wed, Nov 15, 2006 at 07:03:18PM CET, Linus Torvalds wrote:
> If you think "pull" is confusing, I can guarantee you that _changing_ the
> name is a hell of a lot more confusing. In fact, I think a lot of the
> confusion comes from cogito, not from git - the fact that cogito used
> different names and different syntax was a mistake, I think.
I would agree that having "pull" mean something different in Cogito
than in Git was a bad idea (explanation: historically, for some period
of time Cogito had cg-pull which meant the same as cg-fetch or hg pull;
later it got renamed to cg-fetch). But I'm also happy that Cogito just
does not use the "pull" expression at all currently: "updating" seems to
be a clear and unloaded enough concept for new people. Pull is really
_very_ confusing, with it meaning something different (but not different
enough) in _all_ other systems but BK (which is basically irrelevant
nowadays).
That said, I agree with your argument that changing it in Git now
might just result in more confusion. I'm just trying to explain Cogito's
choice here, and I believe it does no good nor harm to Core Git if it
just uses different name for the concept and avoids the original name at
all (except explaining in the docs that updating in Cogito is what
pulling is in Git).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Petr Baudis @ 2006-11-16 5:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre
In-Reply-To: <7vr6w5y7to.fsf@assigned-by-dhcp.cox.net>
On Tue, Nov 14, 2006 at 11:36:19PM CET, Junio C Hamano wrote:
> Commenting on the messages in this thread:
>
> - "resolve / resolved" are both confusing, when you are talking
> about "mark-resolved" operation.
Well that's what "resolved" is saying. But speaking of which, it took me
_weeks_ of regular (though not extensive) usage to train my fingers to
write "stg resolved" and not "stg resolve".
> - "pull/push/fetch" have undesired confusion depending on where
> people learned the term. I'd perhaps vote for replacing
> fetch with download and push with upload.
It's too long. :-(
I think if some people have a real problem with something it's "pull",
not push or fetch. Without "pull" name, there's no confusion about
merging or not merging; and without it, there's also no confusion about
"push" and the fetch/push duality. I'm not saying that this is enough an
argument to ditch pull from Git at this point.
> - I think it would be sensible to make remote tracking branches
> less visible. For example:
>
> git diff origin
>
> where origin is the shorthand for your upstream (e.g. you
> have .git/remotes/origin that records the URL and the branch
> you are tracking) should be easier to understand than
>
> git diff remotes/origin/HEAD
>
> The latter is an implementation detail.
Hmm, wait. I didn't start using refs/remotes/ yet for obvious reasons,
but wasn't it generally agreed when implementing them that what you
wrote above would work? (That a ref not found in refs/{heads,tags}/ is
looked up in remotes and if it's a directory, /HEAD is appended.) So it
doesn't for some reason?
> I could imagine we might even want to allow
>
> git diff origin#next
>
> to name the branch of the remote repository. The notion of
> "where the tips of remote repository's branches are" is
> probably be updated by "git download" (in other words, the
> above "git diff" does not automatically initiate network
> transfer).
Yes, that little syntax extension would be cute to have.
> Of course, it could even be "cg" ;-).
So, here is an arbitrary list of random reasons why cg commands are not
part of git yet:
(i) Naming issues. Example: "pull" vs. "update".
(ii) Namespace issues. Big selling point of Cogito is that it's
_simple_. A very important part of that is that your command set is
limited, so that even someone who wants to fully grok Cogito is not
overwhelmed and has just few commands in front of him. I think we're
doing pretty good here, and I very carefully weight adding another
command to the set (I'm actually pondering removing some now). The
similar applies to actual commands' usage, though certainly not so
heavily; and there are few warts here.
But overally, I think this point is pretty much unsolvable and this is
where I actually think the main "incompatibleness" of Cogito and Git
with its free mix of high- and mid- and low- level commands lies. I
don't think the thread provided any solution to this either.
(ii) Behaviour issues. Example: Cogito tries to deal with uncommitted
local changes in your repository when doing stuff. It didn't shine at it
before recent improvements (post-v0.18), but it tried to preserve your
local uncommitted changes during various operations (merging,
fast-forwarding, switching branches, seeking, ...). I think historically
Git's stance to this was negative (it'd rather block the operation), I'm
not sure what the current situation is, though.
(iii) Output format issues. Example: "status" in Git and Cogito
has a completely different format in both. I'm a die-hard fan of
Cogito's format but there're surely die-hard fans of Git's.
(iv) Control issues. I'm reluctant to give up a final word on how the UI
looks like, mostly for the reason of enforcing (ii) and proper
documentation. But this is not a blocker point.
(v) Library issues. Cogito has a pretty neat shell library which it
prices; but that could be carried around. Also, Cogito requires
/bin/bash, but mostly for performance reasons (using builtins instead of
forking for external commands at some points); Git has the advantage of
simply putting that part in C, which is though something I should've
been doing more frequently too.
(vi) Coding issues. This is probably very subjective, but a blocker for
me. I have no issues about C here, but about the shell part of Git.
Well, how to say it... It's just fundamentally incompatible with me. I
*could* do things in/with it, but it's certainly something I wouldn't
_enjoy_ doing _at all_, on a deep level. I think the current shell code
is really hard to read, the ancient constructs are frequently strange at
best, etc. It's surely fine code at functional level and there'll be
people who hate _my_ style of coding and my shell code which isn't
perfect either, but it's just how it is with me.
Now, it would be absolutely awesome if we could start to bridge at least
some of these points, shuffle some functionality around and overally
reduce the code duplication, increase features count and improve general
level of world happiness.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Marko Macek @ 2006-11-16 6:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, Linus Torvalds, git, cworth, pasky
In-Reply-To: <7vejs4l9wy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Marko Macek <marko.macek@gmx.net> writes:
>
>> For people switching from CVS and SVN it would be much better if the
>> index was hidden behind the scenes by using different defaults:
>>
>> git-commit -a
>> git-status -a
>> git-diff HEAD
>>
>> BTW, currently there's a minor bug: git-diff HEAD doesn't work before
>> you make the first commit. Perhaps this should be special cased.
>
> That's only a _bug_ in your implementation of the synonym for
> "svn diff" which blindly used "git diff HEAD".
My "implementation" is taken from git-diff man page. It seems obvious
that the situation before the first commit is just a special case if
we consider git-diff to be Porcelain (which I do).
> This "there is no HEAD yet" is not related to the index, but I
I agree, this is a separate issue.
^ permalink raw reply
* Re: how to authenticate with git-svn on a subversion repository
From: Martin Langhoff @ 2006-11-16 6:59 UTC (permalink / raw)
To: Comète; +Cc: git
In-Reply-To: <4559D37E.1070703@archlinuxfr.org>
Hi Comete,
authentication with the SVN stuff is really weird. git-svn and
git-svnimport use the SVN libraries so that means that if you do
svn login proto://host/path/to/repo
git-svn proto://host/path/to/repo
it works because svn magic cookies get stored in ~/.svn.
cheers,
^ 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