* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-15 20:40 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Michael K. Edwards, git
In-Reply-To: <Pine.LNX.4.64.0611151516360.2591@xanadu.home>
On Wed, 15 Nov 2006, Nicolas Pitre wrote:
>
> Actually I believe it would make things even clearer if "merge" was
> taught at that point. Only when the user is comfortable with the
> separate notions of fetching and merging might the pull shorthand
> possibly be mentioned.
I agree. I just expect that "merge" is such a simple concept that it
doesn't really need a whole lot of explaining.
People kind of expect merging to be hard, but I think it's because CVS et
al have tought people that merging is _painful_. I don't think it's a very
complicated concept per se, especially if you have explained branches with
gitk already.
But yes, the order should be:
(a) explain what "branches" mean in git (and in that situation, "fetch"
is very natural - I think fetching itself is probably easier to
explain than "branches" are).
(b) once you've explained branches, the notion of "merge" comes next, and
I _think_ that is very obvious. This is where UI issues come in,
because "git merge" is really a totally internal program with a
pretty horrid UI, but I think we could fix the syntax, and even with
the current syntax you can really just gloss it over, because nobody
is really going to care.
(c) once "fetching branches" and "merging" have been explained, "pull" is
really pretty damn trivial, and in fact, if you then explain that
it's just easier to do "git pull . branchname" than to use "git
merge", I think people may just even agree with you.
I think I saw that particular discussion on #git: somebody didn't expect
"git pull . branch" to be the way to merge. And again, I think it's
not _really_ because "pull" is hard to understand, it's because people
haven't been walked through the thing in this way.
Once you understand local branches, fetching and merging, it's actually
_easier_ to explain why we merge even local branches with "git pull .":
you just tell them that this way you can use the same command regardless
of whether you're merging something local or something remote. Again, if
it's explained that way, I bet a lot of people react with "ahh, that's
clever", and _like_ the fact that they only really need to learn _one_
command, instead of learning two.
See? Explain it that way: "pull" really is simple. By using "pull", you
don't have to learn about "merge" syntax. You -can- use "merge" as a
separate program if you want to, but the syntax isn't very nice, exactly
because you're not really expected to.
But the real issue here is to explain local branches. I will happily admit
that local branches are very VERY different from just about any other SCM,
but I also claim that git is just much BETTER than other SCM's in this
respect.
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.
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).
If you don't understand local branches, you'll never understand git usage.
And once you _do_ understand local branches, "fetch" vs "pull" actually is
rather simple.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-15 20:41 UTC (permalink / raw)
To: Marko Macek; +Cc: Shawn Pearce, Linus Torvalds, git, cworth, pasky
In-Reply-To: <455B64F7.9040506@gmx.net>
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".
"git diff HEAD" is not a synonym for "svn diff" when HEAD does
not exist yet, because you are asking "please give me a diff
between the tree in the HEAD commit and my working tree files
through the index". So if you are doing "git-svnish-diff"
Porcelain script, it should notice that HEAD does not exist yet
and take an appropriate action. We do something similar in
git-status; the porcelain notices and acts differently when HEAD
is not there yet.
This "there is no HEAD yet" is not related to the index, but I
am skeptical about trying to hide the index from the end user.
You can make some things map more naturally to systems like SVN
and CVS than other things. For example, Nico's proposal to
always use remote tracking branches and defaulting to use
refs/remotes/ would be a way to match UI of pull/push to another
existing system and that would work well (I am not agreeing to
the change to make 'pull' not to do the merge which would break
existing users -- I am just saying that the result would be self
consistent). But things that have difference at the concept
level, I suspect no clever mapping to hide the differences would
work well.
The index is quite central to the way git works at the concept
level, and I think it is doing disservice to the end user to try
hiding it forever from them and failing to do so, rather than
being honest and teaching them the concept upfront.
But me thinking so does not necessarily mean you are forbidden
from trying. Your efforts may result in a system where the
index is totally invisible and the end user never has to know
about it.
^ permalink raw reply
* Re: [PATCH] gitweb: Put back shortlog instead of graphiclog in the project list.
From: Junio C Hamano @ 2006-11-15 20:49 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git, pasky
In-Reply-To: <87irhgla3l.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> Looks like a repo.or.cz-specific change slipped in.
>
> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Sorry and thanks.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-15 20:50 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611151524000.2591@xanadu.home>
On Wed, 15 Nov 2006, Nicolas Pitre wrote:
>
> I think "fetch" is sane. Its only problem is a missing symetrical
> counterpart verb, like "get" and "put".
If you're a dog owner, the obvious counterpart for "fetch" is "throw" ;)
I think "get" and "put" would be bad, just because of confusion with
"sccs get" (ie it has that "get this file" connotations).
Maybe "fetch" and "push" aren't totally diametrically opposite, but
really, I don't think they are that hard to understand either. We do have
the BK legacy of "pull" implying a merge, and that's fairly fundamental.
It's also true that in a lot of usage schenarios, what people actually
_use_ is "pull" and "push", and no, they aren't mirror images (since push
will _not_ do the merge), but at the same time, from a _usage_ standpoint
they really _are_ each others opposites.
You "pull" to get other peoples data into your branch (and once you've
internalized local branches and the merge thing, you know what this
means), and you "push" to push your changes out. It really _is_ the usage
schenario, and using "opposite" words really _does_ make sense.
It's true that _technically_ "fetch" is the opposite of "push", but at the
same time, that really is about technology, not about usage models. You
normally wouldn't do a "git fetch + git push" pair. You _can_ do so, but
it's not the natural way to work - unless you're just doing a mirror
service.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-15 20:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Whitcroft, Petr Baudis
In-Reply-To: <7v3b8lv9c9.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 6788 bytes --]
On Tue, 14 Nov 2006 16:31:50 -0800, Junio C Hamano wrote:
> I do not think the Porcelain-ish UI that is shipped with git
> should be taken with the same degree of "authority" as git
> Plumbing.
I think we should fix this. "This is great technology with a crap
interface on top" really isn't a good story. I don't actually agree
with that---I don't think the git interface is really all that bad,
it's just got a few little things that tend to trip up new users in my
experience.
And what git does really well, (history exploring, allowing for
pipeline on-liners to iterate over revisions in A..B), are things that
don't even exist in other tools, nor even in the "alternate"
porcelains for git. This stuff is where git's interface is really
fantastic, and it would be a shame to write it off.
> I think
> single isolated developers, contributors and CVS style shared
> repository usage could be a lot improved because neither of us
> were concentrating in their workflows. This needs somebody
> motivated enough to improve things in that area. For example,
> StGIT with its 'float' command is a great improvement over what
> rebase does for people in the contributor role.
Yes, there are some specific workflow-oriented operations that git
doesn't handle as well as it could. Things like commit --amend are
certainly improvements. One that is still totally broken is "follow
all the development in another repository" where clone followed by
repeated fetch doesn't do the job as soon as the remote adds or
deletes a branch.
> But making it more usable for whom is a big question.
>
> Quite frankly, I do not think there can be _the_ single UI that
> would satisfy different types of workflows for some of the
> commands.
I strongly disagree. Or at least, I don't think we've tried hard
enough yet that we should give up on this.
I do agree that people in different roles will have different lists of
"most used operations" and that some operations won't appear on some
users lists at all, (someone who's just "watching" development won't
commit or merge, for example---[or so they thing when they start]).
But I really don't think that for any given operation that different
roles impose a different desire on the behavior of the operation. We
have different people with different background and disagreement on
names and silly things like that, but I don't think that's related to
the roles in which they are working with the tool.
> For example, fetching and merging from many places without
> necessarily having corresponding tracking branches is a great
...
I don't think we've ever had this right in git. The new
--use-separate-remotes stuff or similar will start to help as it
becomes the default. I don't see how this won't benefit everybody.
> For another example, having a commit command to commit
> everything by default is disastrous for people who allow their
> workflows to often be interrupted.
Workflow-interruption is an important thing to support, but separating
update-index and commit really doesn't address it nearly as much as I
would like. The lack of really good workflow-interruption support has
been one of my longest-running annoyances with git, (perhaps because I
have a problem with trying to do too many things at once). Git can
create and change branches fast enough that it really should be able
to help me better with this. The only missing piece is being able to
stash the dirty stuff on the current branch, to be able to come back
to it later. I've talked a bit about what I would like in this area
before, and I really just need to code it up.
> It is not just command line syntax and the defaults, but
> concepts as well. People in the integrator role often need to
> deal with merges and you would need to be aware of the role of
> the index and need to be able to manipulate the index, ...
Again, I think it's more that the specific operations bring in
concepts, (merge bringing in the index here). As such, someone never
doing a merge could easily get by not having to understand the index.
> A Porcelain that does a very similar thing in slightly different
> way is obviously a waste, but otherwise I do not think it is a
> problem to have different Porcelains. StGIT does not compete
> with the "sucky" Porcelain-ish shipped with git but makes the
> user's life a lot more pleasant by complementing what the sucky
> one does not do well. It is not very useful while I am playing
> the integrator role, but when I am doing my own thing it is a
> great addition to my toolchest.
But even here, there's a bunch of waste in StGit. For example, there
are a lot of commands in StGit whose only purpose is to translate back
and forth between the StGit and non-StGit views of the world, (init,
assimilate, commit, uncommit). Those could all be discarded if the
functionality of StGit were brought down into git itself. Then there
are a myriad of StGit commands which are basically just the same as
their git counterparts.
Now, StGit is a great tool, and I know that it works really well for
some people in the role of just maintaining a stack of changes against
some upstream, and can use StGit alone and never touch "git" the
command-line.
But for someone like me who already uses git regularly, and
occasionally just wants to pop back a few commits, amend it, and then
push again, StGit is not helpful, (the series of init, assimilate, and
uncommits just to get started is prohibitive compared to just working
out the awkward steps needed to make a temporary branch and
rebase). So I'd love to see just a couple of commands added to "git"
to support these kinds of operations more smoothly.
> I am from the camp that does _not_ want to hide the index, so
> obviously I do not see any value in its effort to hide the
> index. But other aspects of it, most notably being friendly to
> simpler workflows, is a very good thing.
I don't think "hide or not-to-hide" is the right way to frame the
discussion about the index. I regularly use update-index to stage
partial commits, and I find that very useful. And obviously the index
is involved in resolving merge conflicts.
But I don't think the user-interface for either of those operations
(partial commit, resolve conflicts), is ideal, and the current
requirement to use either "update-index <paths>" or "commit -a" after
modifying a file for the first time is demonstrably a hangup for a lot
of new users. So I really think it's possible to address both of these
at once.
Anyone, that's enough generic rambling from me without any specific
content. I'll try to keep future messages focused on specific
desirable operations that have problematic interfaces in git right
now, along with proposals for improving them.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-15 20:57 UTC (permalink / raw)
To: git
In-Reply-To: <87wt5wsabs.wl%cworth@cworth.org>
Carl Worth wrote:
>On Tue, 14 Nov 2006 16:31:50 -0800, Junio C Hamano wrote:
>>
>> For another example, having a commit command to commit
>> everything by default is disastrous for people who allow their
>> workflows to often be interrupted.
>
> Workflow-interruption is an important thing to support, but separating
> update-index and commit really doesn't address it nearly as much as I
> would like. The lack of really good workflow-interruption support has
> been one of my longest-running annoyances with git, (perhaps because I
> have a problem with trying to do too many things at once). Git can
> create and change branches fast enough that it really should be able
> to help me better with this. The only missing piece is being able to
> stash the dirty stuff on the current branch, to be able to come back
> to it later. I've talked a bit about what I would like in this area
> before, and I really just need to code it up.
There is git-stash/git-unstash floating somewhere in the archive.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* git-svn bug?
From: Troy Telford @ 2006-11-15 21:05 UTC (permalink / raw)
To: git@vger.kernel.org
I've got a repository I've converted over to git from svn. (using
git-svn. since there's only been one branch, I figured I could skip
git-svnimport).
For quite a while, all I did was fetch/rebase from the svn repository to
my git repository; all of my own work was committed to the git repository;
none of the changes were commited to the svn repository.
Then came the time to commit changes from my git repository to the svn
repository.
Being somewhat cautious, I created an empty 'dummy' svn repository and
familiarize myself with using git-svn to commit from git -> svn.
I ran:
git-svn fetch
git-svn rebase remotes/git-svn (already updated)
git-svn dcommit (to push my changes to the svn repository)
Everything seemed to work fine with the dummy repository.
Encouraged, I did the same with the 'real' repository, and received the
following error:
(Using git 1.4.3.5, svn 1.4.0 on a Gentoo box)
fatal: Not a valid object name 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
32768 at /usr/lib64/perl5/5.8.8/Memoize.pm line 269
(using git 1.4.4, svn 1.3.0 on a SLES 9 SP3 box)
fatal: Not a valid object name 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
32768 at /usr/lib/perl5/5.8.3/Memoize.pm line 269
(using git 1.4.4, svn 1.3.1 on a SLES 10 box)
fatal: Not a valid object name 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
32768 at /usr/lib/perl5/5.8.8/Memoize.pm line 269
I had NFS mounted the git repository, so the SLES 9 was local the other
two were NFS. In any event, the error seems to be essentially identical
on every platform I've tried.
Additionally, I had created three branches for the purpose of pushing my
changes to svn:
master (used for my own development)
svn (created using git checkout -b svn remotes/git-svn -- basically only
what is in svn)
merge (git checkout -b merge svn; git rebase master)
`git diff-tree merge master | wc -l` returns 0 (which I assume means no
changes)
`git diff-tree svn merge | wc -l` returns 44 (again, I assume this means
44 changes)
I couldn't find an object named
"92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1" in .git/
Aside from my cluelessness, is there anything else wrong?
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-15 21:08 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>
[-- Attachment #1: Type: text/plain, Size: 3521 bytes --]
On Wed, 15 Nov 2006 12:40:43 -0800 (PST), Linus Torvalds wrote:
> On Wed, 15 Nov 2006, Nicolas Pitre wrote:
> >
> > Actually I believe it would make things even clearer if "merge" was
> > taught at that point. Only when the user is comfortable with the
> > separate notions of fetching and merging might the pull shorthand
> > possibly be mentioned.
>
> I agree. I just expect that "merge" is such a simple concept that it
> doesn't really need a whole lot of explaining.
Well, one of the problems is that with current git I can teach, (and I
have), that there's a conceptual:
pull = fetch + merge
But then shortly after I have to teach an interface notion:
merge = pull .
So there's this goofy circular notion that people end up with
mentally. If we fix it so that a local merge really is performed with
"git merge <branch>" instead of "git pull . <branch>" then teaching
pull=fetch+merge really is a lot easier.
In the meantime, pull would still be useless to me, I think. But maybe
that's just the "default branch to merge" selection being broken. If
that were fixed, maybe I would start using pull.
> (a) explain what "branches" mean in git (and in that situation, "fetch"
> is very natural - I think fetching itself is probably easier to
> explain than "branches" are).
There's a piece missing here, namely the mapping between remote and
local branch names and any notion of "tracking branches". I think a
sane story for that is still being invented, (or if it exists now, I
haven't seen it yet).
> (c) once "fetching branches" and "merging" have been explained, "pull" is
> really pretty damn trivial, and in fact, if you then explain that
> it's just easier to do "git pull . branchname" than to use "git
> merge", I think people may just even agree with you.
Well, they get pretty darn confused at this point, in my experience.
> Once you understand local branches, fetching and merging, it's actually
> _easier_ to explain why we merge even local branches with "git pull .":
> you just tell them that this way you can use the same command regardless
> of whether you're merging something local or something remote. Again, if
> it's explained that way, I bet a lot of people react with "ahh, that's
> clever", and _like_ the fact that they only really need to learn _one_
> command, instead of learning two.
No. It's really, really broken to use "pull ." for local merging. Not
a feature at all. We just got done establishing that pull is a
shorthand for doing fetch+merge, so reusing it when there is _no_
fetch at all is insane.
You just established quite clearly hat git has a huge advantge over
all other systems by having a model that everything is fetched in
and then worked with locally. I agree that this is a major
selling-point of git, and I'm also baffled that systems like bzr and
hg try so hard to push every branch into a separate repository.
But I think that git's "work with everything locally" story is undercut
a bit by regular usage being to use a transfer-inducing command like
"pull" for a totally local merge.
Anyway, I think we all agree that we'd really rather have "git merge
<branch>" be usable for local merges, so let's get that in place and
users can pick whichever they like.
> But the real issue here is to explain local branches. I will happily admit
> that local branches are very VERY different from just about any other SCM,
> but I also claim that git is just much BETTER than other SCM's in this
> respect.
Totally agree.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Josef Weidendorfer @ 2006-11-15 21:12 UTC (permalink / raw)
To: Petr Baudis
Cc: Jakub Narebski, git, Linus Torvalds, Nicolas Pitre,
Junio C Hamano
In-Reply-To: <20061115203517.GN7201@pasky.or.cz>
On Wednesday 15 November 2006 21:35, Petr Baudis wrote:
> On Wed, Nov 15, 2006 at 09:31:13PM CET, Josef Weidendorfer wrote:
> > Often, I find myself doing "git branch" just to make sure that I am on
> > "master", so that a following pull does not do a bogus merge.
> >
> > Can we please disable this behavior, e.g. by allowing a fake first
> > Pull line like "Pull: (not-for-merge)" to prohibit any merge?
>
> Wait, if you don't want pull to merge, why do you pull and not fetch?
I am not really opposed to pull doing a merge. It only should work in
a useful way: ie. only do the merge of updated origin branch when
current branch is master (given "Pull: master:origin").
I want "git pull" being harmless if I find myself accidently on a
branch != master. I always can do "git checkout master; git pull . origin"
afterwards.
For this to work, I currently need to specify a "branch.<name>.merge"
config for _every_ branch I have, as otherwise I get this bogus pull
merge behavior. This is not needed if there was a way to configure no
merge at all as default pull behavior.
I just noted that allowing such a config option would be kind of a
working compromise for all the people which want
pull to be the opposite of push.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-15 21:13 UTC (permalink / raw)
To: Carl Worth; +Cc: Andy Parkins, git
In-Reply-To: <87y7qcsbsa.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> I'm not the original poster, but I feel the same way about the line
> being unclear.
>
> Here's a real-world example from last week.
>...
> Anyway, when I announced this I also mentioned how easily someone
> might generate an entire series of reports for a series of
> commits. The command I gave as an example is:
>
> for rev in $(git rev-list 1.2.6..HEAD); do
> cairo-perf-diff $rev
> done
>
> I think that's a perfectly legitimate one-liner for users to use, and
> it really shows off the easy-scriptability of git. But certainly, no
> "new porcelain" author is going to consider rev-list to be porcelain
> rather than plumbing, right? So as soon as I start teaching people to
> do useful stuff like this, they might have to reach down into the
> "scary" git interface.
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.
The one-liner is essentially a new Porcelain command that is
useful in the cairo developers' workflow, and implementing it
with a plumbing command makes perfect sense. The whole point of
git plumbing is to be friendly for scripted use. If the user
who learns that one-liner from you gets curious why and how that
one-liner works, that would be a good gentle introduction to the
plumbing, but otherwise the user is not forced to know about it.
Also I do not see a problem if some plumbing commands happen to
be also useful by themselves ("[alias] less = -p cat-file -p"
comes to mind for example).
Some plumbing commands may be too deep magic and users do not
have to directly deal with them every day. Some other plumbing
commands are so low-level and needs combination with others to
be any useful, and it is cumbersome to type the combination
every day. For the latter kind, we have Porcelain commands that
implement the frequently used combination and the end users do
not have to know about them.
So it is true that by having a rich and usable set of Porcelain,
there is less need for the users to know about all the plumbing
details, but I consider that is a happy consequence. It does
not have to be the goal of having a good Porcelain to hide the
whole plumbing.
^ permalink raw reply
* Re: Sometimes "Failed to find remote refs" means "try git-fetch --no-tags"
From: Horst H. von Brand @ 2006-11-15 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael K. Edwards, git
In-Reply-To: <7vvelhs6bw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
[...]
> However "fetch --no-tags" from http upstream is a band-aid to
> hide that the upstream repository has stale info/refs, and I do
> not think we would want to encourage the band-aid. Rather, the
> message should say "yell loudly at the repository owner" ;-).
I'm seeing this gem here:
[vonbrand@laptop13 git]$ git pull
fatal: read error (Connection reset by peer)
Fetch failure: git://git.kernel.org/pub/scm/git/git.git
fatal: read error (Connection reset by peer)
Failed to find remote refs
No changes.
Who shall I yell at? ;-)
Seriously, this is broken. I get 4 different error messages, plus a
(reassuring?) "No changes". Yes, I know this is what I'll see if the
machine is overloaded.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-15 21:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611151243030.3349@woody.osdl.org>
On Wed, 15 Nov 2006, Linus Torvalds wrote:
>
>
> On Wed, 15 Nov 2006, Nicolas Pitre wrote:
> >
> > I think "fetch" is sane. Its only problem is a missing symetrical
> > counterpart verb, like "get" and "put".
>
> If you're a dog owner, the obvious counterpart for "fetch" is "throw" ;)
Yeah. You could always throw a branch to your dog.
Or maybe we should introduce the concept of "bones" to GIT in place of
branches? ;-)
> I think "get" and "put" would be bad, just because of confusion with
> "sccs get" (ie it has that "get this file" connotations).
Has SCCS really had a similar level of influence than BK or CVS in that
matter?
> Maybe "fetch" and "push" aren't totally diametrically opposite, but
> really, I don't think they are that hard to understand either. We do have
> the BK legacy of "pull" implying a merge, and that's fairly fundamental.
>
> It's also true that in a lot of usage schenarios, what people actually
> _use_ is "pull" and "push", and no, they aren't mirror images (since push
> will _not_ do the merge), but at the same time, from a _usage_ standpoint
> they really _are_ each others opposites.
The problem is the "usage standpoint" distinction that has to be made.
Exactly because in GIT it is a bit distorted from what most people
expect from other standpoints.
> You "pull" to get other peoples data into your branch (and once you've
> internalized local branches and the merge thing, you know what this
> means), and you "push" to push your changes out. It really _is_ the usage
> schenario, and using "opposite" words really _does_ make sense.
But that's exactly why newbies have problems. Instead of simply
understanding the bare operation (fetch data in a branch _then_ merge
it) they sort of need to abstract the concept of branch away because a
"pull" does it all automagically. Which is fine as long as you're
willing to ignore branch concepts altogether. But once branches are
back in the picture for more involved operations then the "pull" word
simply feels odd. Even more so with the local merge syntax.
When I say to someone "just merge branch weezee with your current
branch" the most intuitive command would be:
git merge weezee
But because "pull" mixes two concepts together this makes the thing more
esoteric. Unless, of course, you get used to the mental model you
outlined above, but IMHO simply needing a mental model to explain the
tool is a sign that something is mapped wrong.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-15 21:31 UTC (permalink / raw)
To: Carl Worth; +Cc: Nicolas Pitre, Michael K. Edwards, Linus Torvalds, git
In-Reply-To: <87velgs9hx.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> So there's this goofy circular notion that people end up with
> If we fix it so that a local merge really is performed with
> "git merge <branch>" instead of "git pull . <branch>" then teaching
> pull=fetch+merge really is a lot easier.
I am wondering if that could be "git merge <committish>..."
instead. I do not care too much about the ... part (i.e. an
Octopus), but I often find myself doing:
git checkout next
git merge "Merge early part of branch 'foo'" HEAD foo~3
when earlier part of "foo" topic are worthy to be in 'next' but
not the later ones.
> In the meantime, pull would still be useless to me, I think. But maybe
> that's just the "default branch to merge" selection being broken.
Have you looked into per-branch configuration for default merge
source recently? It might not be documented well enough,
though, because I do not use it myself, but you should be able
to improve on that (meaning both documentation and setting up
the defaults upon cloning and fetching).
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-15 21:31 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Petr Baudis, Jakub Narebski, git, Nicolas Pitre, Junio C Hamano
In-Reply-To: <200611152212.35978.Josef.Weidendorfer@gmx.de>
On Wed, 15 Nov 2006, Josef Weidendorfer wrote:
>
> I am not really opposed to pull doing a merge. It only should work in
> a useful way: ie. only do the merge of updated origin branch when
> current branch is master (given "Pull: master:origin").
I absolutely agree.
We should _only_ use the default head when pulling from the default head
("master"). If we don't pull from within the default branch, we should
either require an explicit head _or_ we should require that an explicit
mapping has been set up in .git/config or in .git/remotes/..
So doing a "git pull" from any other branch than "master" should probably
by default say "which branch do you want to pull from today"?
^ permalink raw reply
* Re: [PATCH] gitweb: Put back shortlog instead of graphiclog in the project list.
From: Petr Baudis @ 2006-11-15 21:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexandre Julliard, git
In-Reply-To: <7vac2sl9jj.fsf@assigned-by-dhcp.cox.net>
On Wed, Nov 15, 2006 at 09:49:52PM CET, Junio C Hamano wrote:
> Alexandre Julliard <julliard@winehq.org> writes:
>
> > Looks like a repo.or.cz-specific change slipped in.
> >
> > Signed-off-by: Alexandre Julliard <julliard@winehq.org>
>
> Sorry and thanks.
Sorry from me too. :-)
--
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: Nicolas Pitre @ 2006-11-15 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, Michael K. Edwards, Linus Torvalds, git
In-Reply-To: <7virhgjt25.fsf@assigned-by-dhcp.cox.net>
On Wed, 15 Nov 2006, Junio C Hamano wrote:
> I am wondering if that could be "git merge <committish>..."
> instead. I do not care too much about the ... part (i.e. an
> Octopus), but I often find myself doing:
>
> git checkout next
> git merge "Merge early part of branch 'foo'" HEAD foo~3
>
> when earlier part of "foo" topic are worthy to be in 'next' but
> not the later ones.
Indeed !
^ permalink raw reply
* Re: git-svn bug?
From: Junio C Hamano @ 2006-11-15 21:43 UTC (permalink / raw)
To: Troy Telford; +Cc: git, Eric Wong
In-Reply-To: <op.ti2svo0ozidtg1@rygel.lnxi.com>
"Troy Telford" <ttelford.groups@gmail.com> writes:
> (using git 1.4.4, svn 1.3.1 on a SLES 10 box)
> fatal: Not a valid object name 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
> 32768 at /usr/lib/perl5/5.8.8/Memoize.pm line 269
>...
> I couldn't find an object named
> "92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1" in .git/
Troy, do you have object 92e2e0c5? Is it a root commit (i.e. a
commit that does not have a parent)?
The only place that mentions ~1 in git-svn seems to be inside
dcommit but it seems that it unconditionally appends ~1 to the
rev. I do not know how the code guarantees it does not go down
to the root commit.
Eric, any clues?
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-15 21:45 UTC (permalink / raw)
To: Carl Worth; +Cc: Nicolas Pitre, Michael K. Edwards, git
In-Reply-To: <87velgs9hx.wl%cworth@cworth.org>
On Wed, 15 Nov 2006, Carl Worth wrote:
>
> Well, one of the problems is that with current git I can teach, (and I
> have), that there's a conceptual:
>
> pull = fetch + merge
>
> But then shortly after I have to teach an interface notion:
>
> merge = pull .
This is why I would suggest teaching the _concept_ of the "merge", and not
the actual command.
I don't think you should basically ever use the "git merge" command
itself, not in teaching, and not in real life. So after talking about
branches and having taught people to use "git fetch", the next stage is
not so much to teach people to use "git merge", but to explain to them the
_concept_ of merging.
I really think that's a fairly quick thing, partly exactly _because_ you
shouldn't at that point need to worry about syntax or details or anything
like that at all. You just tell them that there's a notion of "merging"
two branches by joining them together and havign the result have the
changes from both branches. So it's a _conceptual_ issue, and that's why I
said I think you should just totally gloss over the whole issue of "git
merge" syntax.
Once you've explained the _concept_ of merging, you then introduce the
command to actually _execute_ the merge: it's "git pull".
See? No circular thinking at all. One is a _concept_ ("join two branches
together by including both in the result") and the other is a command
("pull will fetch the remote data if any, and merge it into the current
branch").
If you explain it that way, then _obviously_ if you don't need to fetch
any remote data, doing "git pull . xyzzy" will merge the local branch
"xyzzy" into the current branch.
^ permalink raw reply
* git-blame: handling of revisions and filenames
From: Alex Riesen @ 2006-11-15 21:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
I noticed that there is no safe way to give a revision to git-blame:
it can always be interpreted as an existing file:
- "git blame rev -- file.txt" can fail if "rev" is a file
- "git blame rev^0 -- file.txt" can file there is a "rev^0" file
(happens if you type too fast with a tool not designed for keyboard)
- "git blame file.txt rev" is ambiguos too, for the same reasons.
I did the simple patch (below) to resolve at least the very first one,
just because that is how git-rev-list does it.
But if all forms of git-blame command line are expected to live, a
more serious surgery of the argv[] handling code needed.
And I afraid the patch has a small chance of crashing: I don't check
if there is enough space in argv (don't actually even know how to),
so Junio, please do not apply it (it passes blame tests, though).
I also suspect git-blame is not the only command using revision
machinery which has the same problem, so this message is more like a
discussion starter.
diff --git a/builtin-blame.c b/builtin-blame.c
index 066dee7..83c8905 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1787,6 +1787,7 @@ int cmd_blame(int argc, const char **arg
/* Now we got rev and path. We do not want the path pruning
* but we may want "bottom" processing.
*/
+ argv[unk++] = "--";
argv[unk] = NULL;
init_revisions(&revs, NULL);
^ permalink raw reply related
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-15 21:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611151638550.2591@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Wed, 15 Nov 2006, Junio C Hamano wrote:
>
>> I am wondering if that could be "git merge <committish>..."
>> instead. I do not care too much about the ... part (i.e. an
>> Octopus), but I often find myself doing:
>>
>> git checkout next
>> git merge "Merge early part of branch 'foo'" HEAD foo~3
>>
>> when earlier part of "foo" topic are worthy to be in 'next' but
>> not the later ones.
>
> Indeed !
Indeed, what?
That means that updated "git merge" (not the current one) would
not be able to assume it's parameter is a branch name, and still
has to come up with the merge message "Merge <branch>".
Merging only within the local branch namespace already has the
problem you need to solve to come up with a nicely formatted
"Merge <branch> of <remote repository>" some way. I am not
saying that this is unsolvable (you can look at remotes/ files
to see what remote tracking branch the branch is about), but
something you need to keep in mind when implementing the
improved "git merge".
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-15 21:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac2sjs28.fsf@assigned-by-dhcp.cox.net>
On Wed, 15 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Wed, 15 Nov 2006, Junio C Hamano wrote:
> >
> >> I am wondering if that could be "git merge <committish>..."
> >> instead. I do not care too much about the ... part (i.e. an
> >> Octopus), but I often find myself doing:
> >>
> >> git checkout next
> >> git merge "Merge early part of branch 'foo'" HEAD foo~3
> >>
> >> when earlier part of "foo" topic are worthy to be in 'next' but
> >> not the later ones.
> >
> > Indeed !
>
> Indeed, what?
What you propose would be excellent indeed.
> That means that updated "git merge" (not the current one) would
> not be able to assume it's parameter is a branch name, and still
> has to come up with the merge message "Merge <branch>".
>
> Merging only within the local branch namespace already has the
> problem you need to solve to come up with a nicely formatted
> "Merge <branch> of <remote repository>" some way. I am not
> saying that this is unsolvable (you can look at remotes/ files
> to see what remote tracking branch the branch is about), but
> something you need to keep in mind when implementing the
> improved "git merge".
Right. But that is an _implementation_ detail, not a usability issue.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Shawn Pearce @ 2006-11-15 22:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejfutp$cgc$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Carl Worth wrote:
> >On Tue, 14 Nov 2006 16:31:50 -0800, Junio C Hamano wrote:
> >>
> >> For another example, having a commit command to commit
> >> everything by default is disastrous for people who allow their
> >> workflows to often be interrupted.
> >
> > Workflow-interruption is an important thing to support, but separating
> > update-index and commit really doesn't address it nearly as much as I
> > would like. The lack of really good workflow-interruption support has
> > been one of my longest-running annoyances with git, (perhaps because I
> > have a problem with trying to do too many things at once). Git can
> > create and change branches fast enough that it really should be able
> > to help me better with this. The only missing piece is being able to
> > stash the dirty stuff on the current branch, to be able to come back
> > to it later. I've talked a bit about what I would like in this area
> > before, and I really just need to code it up.
>
> There is git-stash/git-unstash floating somewhere in the archive.
I find that a "git commit -a -m parked; git checkout -b ..." works
well to stash my current stuff off. Then I just amend the commit
when I come back to that branch.
The problem I just ran into today was "git checkout" doesn't double
check the file stat data against the index before switching branches.
If the file is unchanged between the two branches there's no error.
So I switched branches with dirty files that I forgot to park on
the old branch.
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Shawn Pearce @ 2006-11-15 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marko Macek, Linus Torvalds, git, cworth, pasky
In-Reply-To: <7vejs4l9wy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> The index is quite central to the way git works at the concept
> level, and I think it is doing disservice to the end user to try
> hiding it forever from them and failing to do so, rather than
> being honest and teaching them the concept upfront.
>
> But me thinking so does not necessarily mean you are forbidden
> from trying. Your efforts may result in a system where the
> index is totally invisible and the end user never has to know
> about it.
I agree with what you are saying about the index.
But in git-gui I found myself writing code on Monday which tries to
hide the index from the user unless he/she requested that the index
be made visible.
The reason is there are some users who I'd like to give git-gui to
who I'm not sure I trust to make sure their index is in sync with
their working directory before they commit. In some cases I'm lucky
that the user even knows what directory their file is stored in. :-(
Yes, there really are computer users who are afraid of directories
and command lines.
I probably could try to teach them to make sure the final file
is included in the index before committing, but I think that for
most of them they would find this to be just another couple of
mouse clicks they have to perform before every commit, meaning its
something that the #$@!*@!*@$# tool should just do for them.
--
^ permalink raw reply
* Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Timur Tabi @ 2006-11-15 22:11 UTC (permalink / raw)
To: git
After doing a "make mrproper" in my Linux git tree, the result is still 1.1GB
of files. Compare that with just the tarball, which is just one-forth the size.
Is there a way to "trim away" old commits from the repository, so that it just
doesn't take up that much space? I don't care about any commits made in 2005.
As long as I can still do "git pull" from the source repo to update mine,
that's good enough.
--
Timur Tabi
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Shawn Pearce @ 2006-11-15 22:16 UTC (permalink / raw)
To: Timur Tabi; +Cc: git
In-Reply-To: <455B90AD.3060707@freescale.com>
Timur Tabi <timur@freescale.com> wrote:
> After doing a "make mrproper" in my Linux git tree, the result is still
> 1.1GB of files. Compare that with just the tarball, which is just
> one-forth the size.
>
> Is there a way to "trim away" old commits from the repository, so that it
> just doesn't take up that much space? I don't care about any commits made
> in 2005. As long as I can still do "git pull" from the source repo to
> update mine, that's good enough.
No. However...
Have you tried "git repack -a -d" to repack the loose objects into
a pack file? Doing this every so often should reduce your disk
space consumed by a HUGE amount.
--
^ 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