* 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
* Re: Cleaning up git user-interface warts
From: Richard CURNOW @ 2006-11-16 7:51 UTC (permalink / raw)
To: git
Cc: Shawn Pearce, Sean, Carl Worth, Linus Torvalds, Nicolas Pitre,
Michael K. Edwards
In-Reply-To: <20061115231542.GB25270@spearce.org>
* Shawn Pearce <spearce@spearce.org> [2006-11-15]:
>
> So what about making git-merge take a -m "msg" argument to supply
> the commit message, in which case it does the current behavior
> (and thus git-pull needs to change to supply -m); and then make
> git-merge without any -m parameter invoke "git pull . $@" ?
Sounds good to me.
When I'm merging in my own projects, I currently always use merge
(possibly preceded by fetch) rather than pull. Why? Because I don't
want my history full of commit messages like
Merge branch "trial_hack" from "../scratch_dir_with_silly_name"
In contrast to Linus's case of wanting to record where the remote merge
came from, I expressly don't want to record that - I want the merge
commit to describe conceptually what was being merged with what.
OK, I could use probably use pull with --no-commit, but I've already
trained my fingers to type out the merge syntax. They'd be happier with
'git merge -m "Merge feature foo with fixes for bar" bar" though.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Robin Rosenberg @ 2006-11-16 10:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: Carl Worth, Junio C Hamano, Andy Parkins, git
In-Reply-To: <20061116032157.GR7201@pasky.or.cz>
torsdag 16 november 2006 04:21 skrev Petr Baudis:
> 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.
When/why do I need git-commit-tree? Isn't git-commit enough?
^ permalink raw reply
* Git can't merge two identical move file operation
From: Alexander Litvinov @ 2006-11-16 10:26 UTC (permalink / raw)
To: git
Hello,
I have a git repo build using cvsimport. It has 'bad' directory
structure and I want to 'fix' it after each incremental update from
cvs. Here is the idea: I have 2 permanent branches master (to work
with) and cvs (to import from cvs) and one temporary branch to move
files across the project to make directory structure better. Movement
operation is always the same: move directories/files from one place to
another. But merging from temp branch to work branch fail with error
text :
CONFLICT (rename/delete): Rename a->b/a in HEAD and deleted in 791371
Here is the example script:
>git version
git version 1.4.4
> mkdir 1 && cd 1 && git init-db
defaulting to local storage area
> echo 1 > a && git add a && git commit -a -m '1'
Committing initial tree 2ce1eef76631e82282e0f7f0cf9e6f3e9a4a0b1e
> git checkout -b fix
> mkdir b && git mv a b/ && git commit -a -m 'fix 1'
> git checkout -b work master
> git pull . fix
Updating 7be4ab0..d4909bb
Fast forward
a => b/a | 0
1 files changed, 0 insertions(+), 0 deletions(-)
rename a => b/a (100%)
> git checkout -f master
> echo 2 >> a && git commit -a -m '2'
> git checkout -b fix2 master
> mkdir b && git mv a b/ && git commit -a -m 'fix 2'
> git checkout -f work
> git pull . fix2
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with 791371d91c34bc45b289319d96ebf35c8be385a0
Merging:
d4909bb fix 1
791371d fix 2
found 1 common ancestor(s):
7be4ab0 1
CONFLICT (rename/delete): Rename a->b/a in HEAD and deleted in
791371d91c34bc45b289319d96ebf35c8be385a0
Automatic merge failed; fix conflicts and then commit the result.
>
Bot fix and fix2 are temp branches and supposed to be deleted.
Why git can't merge such changes ? It should know that work holds
renamed version of file a from master and fix2 holds new renamed file
a from master too. Why it can't apply changes of a from master to work
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-16 10:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Han-Wen Nienhuys
In-Reply-To: <Pine.LNX.4.64.0611151908130.3349@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> 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.
> ...
> 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.
I had a bit different feeling about yesterday's discussion
myself.
If somebody uses git like you do in "truly distributed way", the
current pull behaviour and pull being an operational mirror to
push are natural consequence of the model and concepts, and
there is nothing to fix (modulo "the default merge source per
branch" should be made easier to use). Renaming the pull to
merge would not make it any easier to use unless the underlying
model is understood, and I fully agree with you on that.
But for people working in a project organized around central
repository in the CVS/SVN fashion, the workflow is quite
different. CVS does not even let you "fetch" without either
merging (co) or throwing away your work (co -C), and we already
do support that model with:
git clone
git pull
work work work; git commit
git push
: oops not fast forward?
git pull
resolve work; git commit
git push
without ever using a local branch, any tracking branch, nor
use of git-fetch. So we do support both extremes ("truly
distributed" and "not distributed at all") reasonably well.
The trouble starts when the users hear about this wonderful
"distributed" stuff git offers, and try to use it without
understanding the key concepts. People tend to learn by doing
and there is a leap the user need to make because now they need
to understand branched development, branches and fetching like
you explained if they want to use git the same way as you do.
Once they understand them, then the current set of tools offer
them a simple and very straightforward user interface (the tools
directly reflect the concepts and it is straightforward only
because we are talking about users who understood the concepts).
But we have to admit that this leap may rather be difficult for
people who are used to other models. Telling them that our
model is different and it is different for a good reason does
not change the fact that the more different something is, the
more difficult to learn it.
I suspect that there could be a way to use git, not like you or
I do. Our workflows are already quite different (e.g. you
almost never do topic branch merge yourself in your repository,
but I have abundance of them). There is no reason to think
there won't be other workflows that are suitable for other
people. Some workflows might be classified less distributed and
inferiour compared to the "truly git way" from "truly
distributed is the point of git" point of view, but nevertheless
could be "good enough" for those people. In other words, a
workflow that is a bit more advanced than just a single trunk
CVS/SVN usage could still take advantage of some of the features
to support distributed development model git has, while not
taking full advantage of truly distributed nature of git.
I think the complaints in the yesterday's discussion are mostly
about frustration that, while we have a reasonable support for
the both extremes, we do not either know what that middle ground
workflow is, or even if we know what that is, we do not support
it very well.
And I am not opposed to people exploring what that different
workflow would be, and while they do so if they come up with a
set of commands (get/put perhaps) to suppor that slightly
different workflow, that would be a very good thing.
Add foreign SCM importers in the mix and the situation becomes
more difficult and interesting. cvsimport mostly works and
quacks like git-fetch with set of tracking branches, which I
think is the right model for the importers, and would integrate
well with the current set of tools. I believe svnimport is the
same way. But I do not know about git-svn.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-16 10:36 UTC (permalink / raw)
To: Marko Macek; +Cc: git
In-Reply-To: <455C0033.2020309@gmx.net>
Marko Macek <marko.macek@gmx.net> writes:
>>> 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).
Yes, "git diff" is a Porcelain. No question about it.
I do not consider the current behaviour of "git diff HEAD" that
complains instead of giving runs of "foo is a new file and no
diff is available for it" a bug; you asked for diff from some
commit but the commit you gave was bogus (does not exist yet).
But if you feel strongly about it, it should be trivial to
special case the yet-to-be-born HEAD case and run the
equilvalent of:
git ls-files | sed -e 's/$/ is a new file, no diff is available./'
in such a case. Or you could even go fancier and do an
equivalent of:
git ls-files |
while read path
do
l=`wc -l <"$path"`
echo "diff --git a/$path b/$path"
echo "--- a/$path"
echo "--- b/$path"
echo "@@ -0,0 +1,$l @@"
sed -e 's/^/+/' <"$path"
done
and you can claim that it makes it consistent with the case
where you already have commits.
But I happen to think that consistency is only of academic
interest. After all, how often would one create a true "root"
commit? We are not talking about creating a new repository that
starts its life as a clone of something else, but a truly empty
one in which the initial commit is made. And how often would
one want to view "diff" from void while preparing for that
initial commit? Both that low frequency _and_ general
uselessness of the output from either of the above shell
scripts, would it be worth "fixing" it?
I do not think it adds any real practical value, and does not
even have much to do with being user friendly. I would put it
in the "when somebody is really bored and has nothing better to
do, then this _could_ be done" category.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Han-Wen Nienhuys @ 2006-11-16 10:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611151908130.3349@woody.osdl.org>
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.
> 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 me put this more personally: I continue to be bitten by stupid
naming issues, and the myriad of little mostly non-orthogonal commands.
My head is doing just fine otherwise, and has no problems wrapping it
around the core of GIT. I've also used Darcs for almost a year. Darcs,
which is much less overwhelming.
This is not about CVS or SVN, so don't put them up as a strawman.
If you want to argue that my brain is warped, use other distributed VCs
as an example.
The following
mkdir x y
cd x
hg init
echo hoi > bla
hg add
hg commit -m 'yes, I am also too stupid to refuse explicit empty
commit messages'
cd ../y
hg init
hg pull ../x
pretty much works the same in Darcs, bzr and mercurial.
With GIT, this is what happens
[hanwen@haring y]$ git pull ../x
fatal: Needed a single revision
Pulling into a black hole?
[hanwen@haring y]$ git fetch ../x
warning: no common commits
remote: Generating pack...
Done counting 3 objects.
Deltifying 3 objects.
100% (3/3) done
Total 3, wremote: ritten 3 (delta 0), reused 0 (delta 0)
Unpacking 3 objects
100% (3/3) done
[hanwen@haring y]$ git checkout
fatal: ambiguous argument 'HEAD': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions
fatal: Not a valid object name HEAD
[hanwen@haring y]$ git branch master
fatal: Needed a single revision
at this point, I resort to adding a bogus commit and/or editing
.git/HEAD by hand. I'm sure there is a saner way of doing it, but I
still haven't found out what it is.
This might not be typical GIT use, but it does show the typical GIT user
experience, at least mine.
If you want to have another example of how not to design a
user-interface, try the above on Monotone.
> 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.
>
>
> Let's face it, you could just alias "merge" to "pull", and it wouldn't
> really change ANYTHING.
I don't want ANYTHING to really change, I just want a sane interface to it.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-16 10:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre
In-Reply-To: <20061116051240.GV7201@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> (v) Library issues...
> Git has the advantage of
> simply putting that part in C, which is though something I should've
> been doing more frequently too.
It should be stressed that git-core plumbing written in C is not
just for git Porcelain-ish, and it will continue to be shared
service. We would add core support for what Porcelains need and
we would try hard to keep them generic enough so that other
Porcelains can use them. Keeping the core and Porcelain-ish in
the same project has made it easier to keep them in sync and to
find and add missing features that would benefit Porcelains (not
limited to git Porcelain-ish). But that should not be mistaken
as plumbing somehow belongs more to git Porcelain-ish than to
Cogito or others.
I also think you should take credit for some core improvements
you did yourself (e.g "ls-files -t" format was originally added
for the sole purpose of helping Cogito, but now others use it,
too).
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-16 11:11 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <455C412D.1030408@xs4all.nl>
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
You claim it is _an interface_ issue but it is not.
> With GIT, this is what happens
>
> [hanwen@haring y]$ git pull ../x
> fatal: Needed a single revision
> Pulling into a black hole?
You asked it to fetch from the neighbour repository and merge it
into your current branch which does not exist (I presume that
you omitted to describe what you did in directory y/ and I am
assuming you did "mkdir y && cd y && git initdb" and nothing
else). You are pulling into a black hole.
> [hanwen@haring y]$ git fetch ../x
>...
> [hanwen@haring y]$ git checkout
You fetched without telling it in which tracking branch to store
what you fetched, and as a result your HEAD is not updated, so
your current branch still does not exist. A failure from
checking out nothingness is not an interface issue; expectation
for it to work is a concept level issue.
> [hanwen@haring y]$ git branch master
> fatal: Needed a single revision
You are not at any commit yet and you try to create a branch?
Of course, the "right" (in some sense of the word) thing is to
do "git clone x y" in the parent directory, without creating y
upfront.
If you have an empty y to begin with, then you can do this:
$ git fetch ../x :origin
$ git reset --hard origin
which would mirror a part of what "git clone" would have done
for you. It copies from the other repository, stores the tip in
your tracking branch called "origin", and make your HEAD to be
the same as origin. After these two commands, you would have
two branches, origin and master, and you will be on master.
You can name 'origin' any way you want. You might want to name
it 'x' to make it clear (to yourself) that it is used to track
what will happen in the neighboring repository 'x'. Also, you
would most likely be fetching and merging from the same ../x
from now on, so it might be handy to set up the remotes for it:
$ cat >.git/remotes/x <<EOF
URL: ../x
Pull: master:origin
EOF
Then subsequent work of yours would be done on 'master' branch
(you have only two branches, and origin is a tracking branch so
you will never make commits on it, which means the above is a
logical consequence), and from time to time you would sync with
whoever is working in ../x
$ git pull x
Here, 'x' is just a shorthand which looks up the URL: and Pull: line
through .git/remotes/x. If your .git/remotes/ file was named origin
(not x), you could even have written:
$ git pull
because pull defaults to 'origin' (without any other configuration).
>> Let's face it, you could just alias "merge" to "pull", and it
>> wouldn't really change ANYTHING.
>
> I don't want ANYTHING to really change, I just want a sane interface to it.
I agree that you do not want to change anything. You just
needed a bit of handholding, because you deviated from the
cookbook usage, to correct your course.
^ permalink raw reply
* Re: Git can't merge two identical move file operation
From: Junio C Hamano @ 2006-11-16 11:32 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <6e1787fe0611160226r2d51d980t6899f1a1018b5fe5@mail.gmail.com>
"Alexander Litvinov" <litvinov2004@gmail.com> writes:
> Here is the example script:
>>git version
> git version 1.4.4
>> mkdir 1 && cd 1 && git init-db
> defaulting to local storage area
>> echo 1 > a && git add a && git commit -a -m '1'
> Committing initial tree 2ce1eef76631e82282e0f7f0cf9e6f3e9a4a0b1e
Could you try an exactly the same sequence except to make the
initial contents of the file 'a' a bit more meaningful (I
typically use COPYING file in git.git repository for something
like this), by replacing the above "echo 1 > a ..." line with:
$ cat COPYING >a && git add a && git commit -a -m '1'
and see if it still breaks? You do not need to change the later
modification to the file (i.e. "echo 2 >>a"), but only the above
single line change.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Alexandre Julliard @ 2006-11-16 11:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, git, Nicolas Pitre, Linus Torvalds
In-Reply-To: <7vd57of2cv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I would rather say "use 'git branch' to make sure if you are
> ready to merge". Who teaches not to use "git pull"?
We do that for Wine. The problem is that we recommend using git-rebase
to make it easier for occasional developers to keep a clean history,
and rebase and pull interfere badly.
The result is that we recommend always using fetch+rebase to keep up
to date, but this is confusing many people too, because git-fetch
appears to do a lot of work yet leaves the working tree completely
unchanged, and git-rebase doesn't do anything (since in most cases
they don't have commits to rebase) but has an apparently magical
side-effect of updating the working tree.
Ideally it should be possible to have git-rebase do the right thing
even if the branch has been merged into; then we could tell people to
always use git-pull, and when they get confused by seeing merges in
their history have them do a git-rebase to clean things up.
--
Alexandre Julliard
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Andreas Ericsson @ 2006-11-16 11:35 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: git
In-Reply-To: <f2b55d220611151902v794edd77i9f76815e4b03a966@mail.gmail.com>
Michael K. Edwards wrote:
> 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.
>
[...]
>
> 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.
>
I think it's unfortunate that git was originally written by Linus, since
he so obviously is "the guy at the top of the pyramid" in many more
senses than just "Linus said this and that patch was OK to commit",
since git was designed to work like king Arthur's round table; "Linus is
in the same circle as me, so ofcourse we help each other out".
All suggestions I've been reading about tracking branches,
separate-remotes and whatnot have their merit. If any of it gets
implemented, I'd still like to be able to do one-shot pulls from remote
repos *without* creating specific tracking branches for it. It's
extremely useful to fetch other peoples topic-branches into my own
"master" (or topic-branch) when I trust their changes to be good. Please
consider that when you're hacking away on whatever changes to do.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-16 11:47 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <7v7ixvbq80.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
>> [hanwen@haring y]$ git pull ../x
>> fatal: Needed a single revision
>> Pulling into a black hole?
Having said all that, I happen to think that this particular
case of pulling into void could deserve to be special cased to
pretend it is a fast forward (after all, nothingness is an
ancestor of anything), if only to make new people's first
experience more pleasant.
Working from nothingness is something not usually done in
everyday work, so from practical and technical point of view it
does not add much _real_ value to the people who actually uses
the system, but nevertheless, new people typically start
learning the system from either cloned repository (which I
believe is covered by the existing tools fairly well) or
emptiness (which bitten us here in a bad way), and making the
first experience more pleasnt to new people have a positive
value of flattening the learning curve.
So please consider that this is classified as a bug.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Andreas Ericsson @ 2006-11-16 11:50 UTC (permalink / raw)
To: Theodore Tso; +Cc: Linus Torvalds, Nicolas Pitre, Michael K. Edwards, git
In-Reply-To: <20061116042639.GA23026@thunk.org>
Theodore Tso wrote:
> 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.
It seems we should, cheaply, be able to avoid a large part of the
confusion by
* Mentioning git-fetch before git-pull in all documentation newborn
gitizens are likely to come across. Most git-users aren't Linus, and for
every successful project the maintainers are outnumbered 100 to 1 by the
contributors. Those projects successful *because* maintainers are
heavily outnumbered so we should make it easier for contributors by
teaching them the right things from the start and possibly have a
separate man-page for maintainer (git-{maintainer,developer} man-pages,
anyone?).
* Creating "git update" which might possibly be an internal alias to
"git pull", except that it should read .git/remotes/* by default unless
a specific remotes-file is specified.
* Renaming git-merge to git-merge-driver
* Implementing a git-merge that actually does what its name implies,
possibly by making it an internal alias to pull, but with these differences:
- It always merges into your current branch.
- It understands "git merge branch" as well as "git merge . branch".
This is just the very low-hanging fruit. If we take these steps and let
things cool down a bit, it would probably be proper to take a fresh look
at this in a couple of months.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Git can't merge two identical move file operation
From: Alexander Litvinov @ 2006-11-16 12:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wo3bp99.fsf@assigned-by-dhcp.cox.net>
В сообщении от Thursday 16 November 2006 17:32 Junio C Hamano написал(a):
> Could you try an exactly the same sequence except to make the
> initial contents of the file 'a' a bit more meaningful (I
> typically use COPYING file in git.git repository for something
> like this), by replacing the above "echo 1 > a ..." line with:
>
> $ cat COPYING >a && git add a && git commit -a -m '1'
>
> and see if it still breaks? You do not need to change the later
> modification to the file (i.e. "echo 2 >>a"), but only the above
> single line change.
Wow, that a magic ! It works !
^ permalink raw reply
* Re: Git can't merge two identical move file operation
From: Alexander Litvinov @ 2006-11-16 12:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wo3bp99.fsf@assigned-by-dhcp.cox.net>
В сообщении от Thursday 16 November 2006 17:32 Junio C Hamano написал(a):
> Could you try an exactly the same sequence except to make the
> initial contents of the file 'a' a bit more meaningful (I
> typically use COPYING file in git.git repository for something
> like this), by replacing the above "echo 1 > a ..." line with:
>
> $ cat COPYING >a && git add a && git commit -a -m '1'
>
> and see if it still breaks? You do not need to change the later
> modification to the file (i.e. "echo 2 >>a"), but only the above
> single line change.
Wow, that a magic ! It works !
Thanks for help.
^ permalink raw reply
* Re: Git can't merge two identical move file operation
From: Alexander Litvinov @ 2006-11-16 12:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wo3bp99.fsf@assigned-by-dhcp.cox.net>
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Han-Wen Nienhuys @ 2006-11-16 13:03 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <7v7ixvbq80.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano escreveu:
> You claim it is _an interface_ issue but it is not.
>> I don't want ANYTHING to really change, I just want a sane interface
>> to it.
>
> I agree that you do not want to change anything. You just
> needed a bit of handholding, because you deviated from the
> cookbook usage, to correct your course.
Users (well, I do at least) start fiddling with systems to find out how
they work. Reading the manual is usually done as a last resort. I
think this is pretty well documented in usability research.
I'm trying to show how GIT is badly suited to this. Your response is to
explain to me what I should have done. That's nice, but that approach
doesn't scale, because you don't reach the dozens of users out there who
try the same, fail and give up.
If you really want to find out the weaknesses, you'd have to sit someone
new to git in front of a computer, and let him figure how to operate it,
while videotaping everything.
Writing a manual for newbies is also an effective (and simpler and
cheaper) approach of figuring out what needs to be changed.
As another example: annoyances regarding program invocation
- option handling: -x -f -z != -xfz , "--max-count 1" doesn't work,
but needs an '='
- git --help lists an unordered set, which is too long scan quickly.
I'd expect that list to either contain everything or the minimum set for
daily use. I.e. the set introduced in a first tutorial. Why are merge,
prune, verify-tag there?
Try "bzr help" for comparison.
- --pretty option with wholly uninformative options full, medium,
short, raw. It's not even documented what each option does.
I can go on with listing idiosyncrasies, but my point is not to get help
from you, but rather to show how git can be improved.
>> With GIT, this is what happens
>>
>> [hanwen@haring y]$ git pull ../x
>> fatal: Needed a single revision
>> Pulling into a black hole?
>
> You asked it to fetch from the neighbour repository and merge it
> into your current branch which does not exist (I presume that
> you omitted to describe what you did in directory y/ and I am
> assuming you did "mkdir y && cd y && git initdb" and nothing
> else). You are pulling into a black hole.
as you remark in the other reply, there is IMO no reason for not having
an empty 'master' branch. If master + HEAD gets created on the first
commit, it might as well be created on the init-db.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Han-Wen Nienhuys @ 2006-11-16 13:11 UTC (permalink / raw)
To: git
In-Reply-To: <455C618A.7080309@xs4all.nl>
Han-Wen Nienhuys escreveu:
> I can go on with listing idiosyncrasies, but my point is not to get help
> from you, but rather to show how git can be improved.
oh, and another annoying one: git's insistence on firing up a pager if
there is nothing to page, eg. try
git-log je-n-existe-pas
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Karl Hasselström @ 2006-11-16 13:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611151309290.2591@xanadu.home>
On 2006-11-15 13:11:36 -0500, Nicolas Pitre wrote:
> On Wed, 15 Nov 2006, Junio C Hamano wrote:
>
> > Nicolas Pitre <nico@cam.org> writes:
> >
> > > But again I think it is important that the URL to use must be a
> > > per branch attribute i.e. attached to "default/master" and not
> > > just "default". This way someone could add all branches of
> > > interest into the "default" group even if they're from different
> > > repositories, and a simple get without any argument would get
> > > them all.
> >
> > I think the "one group per one remote repository" model is a lot
> > easier to explain. At least when I read your first "branch group"
> > proposal that was I thought was going on and I found it quite
> > sensible (and it maps more or less straightforwardly to the way
> > existing .git/refs/remotes is set up by default).
>
> I think one group per remote repo is how things should be by default
> too. But we should not limit it to that if possible.
Without the limitation, we risk name collisions when getting all
branches from the remote repository (that is, including any new
branches we previously didn't know about).
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Petr Baudis @ 2006-11-16 13:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre
In-Reply-To: <7vodr7brfp.fsf@assigned-by-dhcp.cox.net>
On Thu, Nov 16, 2006 at 11:45:46AM CET, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > (v) Library issues...
> > Git has the advantage of
> > simply putting that part in C, which is though something I should've
> > been doing more frequently too.
>
> It should be stressed that git-core plumbing written in C is not
> just for git Porcelain-ish, and it will continue to be shared
> service. We would add core support for what Porcelains need and
> we would try hard to keep them generic enough so that other
> Porcelains can use them. Keeping the core and Porcelain-ish in
> the same project has made it easier to keep them in sync and to
> find and add missing features that would benefit Porcelains (not
> limited to git Porcelain-ish). But that should not be mistaken
> as plumbing somehow belongs more to git Porcelain-ish than to
> Cogito or others.
Of course, I didn't mean to say that. I should do more often things
like adding --stdin to the fetchers. From one part, I'm used to work
with a fixed set of system tools and extending Git with the
functionality I want means changing my thinking mode and "jumping out of
the system" a bit. The other part is that I cannot use the improvements
in Cogito right away (at least not in the main branch) but I have to
wait for the next Git release; but this is mostly just an excuse. :-)
--
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 13:46 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Carl Worth, Junio C Hamano, Andy Parkins, git
In-Reply-To: <200611161109.13883.robin.rosenberg.lists@dewire.com>
On Thu, Nov 16, 2006 at 11:09:13AM CET, Robin Rosenberg wrote:
> torsdag 16 november 2006 04:21 skrev Petr Baudis:
> > 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.
>
> When/why do I need git-commit-tree? Isn't git-commit enough?
As I said, when you need to find out how to setup your authorship
information. It's documented as deep as on the git-commit-tree level.
BTW, the documentation is another important part of the
plumbing/porcelain separation, it's not only about the list of commands
but also that porcelain documentation should be reasonably
self-contained and not require users to peek at plumbing docs in order
to find out many stuff. It's also a consideration I take when
maintaining Cogito documentation.
--
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 13:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Andy Whitcroft, Carl Worth
In-Reply-To: <Pine.LNX.4.64.0611142048350.2591@xanadu.home>
On Wed, Nov 15, 2006 at 05:32:06AM CET, Nicolas Pitre wrote:
> 1) make "git init" an alias for "git init-db".
>
> What's the point of "-db"? Sure we're initializing the GIT database.
> But who cares? The user doesn't care if GIT uses a "database" or
> whatever. And according to some people's definition of a "database" it
> could be argued that GIT doesn't use a database at all in the purist
> sense of it. What the user wants is to get started and "init" (without
> the "-db" is so much more to the point. Doesn't matter if incidentally
> it happens to be the same keyword HG uses for the same operation because
> we are not afflicted by the NIH disease, right? And it has 3 chars less
> to type which is for sure a premium improvement to the very first GIT
> user experience!
(This is somewhat related to the HEAD issue, e.g.
<7v1wo3d6g4.fsf@assigned-by-dhcp.cox.net>, by virtue of basically
eliminating it.)
Let's see. If you are adding the alias, you can as well add some
porcelain stuffing in it, too.
What are the 99% of use cases when doing "init"?
(a) You are going to do an initial commit right away; the repository is
at this point basically useless for anything but initial commit. So you
might have "init" well just perform it for you right away.
(b) You are setting up a bare repository on a server and you will push
to it in a minute. Cogito has a separate cg-admin-setuprepo command for
it, which will also prepare it for usage by dumb servers and optionally
for shared usage in a group of users. Git could have something similar.
> 2) "pull" and "push" should be symmetrical operations
..snip..
> Conclusion: git-pull must not perform any merge. It is the symmetrical
> operation of a push meaning that it pulls content from a remote branch
> and does no more. People understands that pretty well, . This makes
> git-fetch redundant (or an alias to git-pull) in that case, and again we
> don't mind it becoming similar to in HG because we admit HG was right
> about it.
If you _really_ want to do it in Git, the only sensible way to do it is
to stop using the "pull" verb for a command name altogether for at least
some rather long period of time, otherwise that's a blatant backwards
compatibility breakage.
> 3) remote branch handling should become more straight forward.
>
> OK! Now that we've solved the pull issue and that everybody agrees with
> me (how can't you all agree with me anyway) let's have a look at remote
> branches. It should be simple:
..snip..
By the way, due to the way you describe it, it's not all that clear to
me how is this (in)compatible with the current way we do it, on other
than the usage and git-pull's auto-creation magic level.
Is it that what you are describing _is_ in fact what we do support now,
with "branch groups" meaning "remotes" etc, and you are only proposing
some enhancements to automatically create remotes in git-pull, or are
there some other differences I've missed?
--
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 14:01 UTC (permalink / raw)
To: Alexandre Julliard
Cc: Junio C Hamano, Theodore Tso, git, Nicolas Pitre, Linus Torvalds
In-Reply-To: <8764dflj5o.fsf@wine.dyndns.org>
On Thu, Nov 16, 2006 at 12:34:27PM CET, Alexandre Julliard wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > I would rather say "use 'git branch' to make sure if you are
> > ready to merge". Who teaches not to use "git pull"?
>
> We do that for Wine. The problem is that we recommend using git-rebase
> to make it easier for occasional developers to keep a clean history,
> and rebase and pull interfere badly.
How do those developers submit their changes? Do they push? If they do,
git-rebase can be saving one merge at most, and the merge is actually a
good thing (someone should write some nice standalone writeup about
that).
If they don't have push access and maintain their patches locally until
they get accepted, perhaps it would be far simpler for them to use
StGIT?
--
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: [StGIT PATCH] StGIT bash completion
From: Catalin Marinas @ 2006-11-16 14:21 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Shawn Pearce
In-Reply-To: <20061112211813.19959.73406.stgit@localhost>
On 12/11/06, Karl Hasselström <kha@treskal.com> wrote:
> A minimal bash completion script for StGIT. It completes the
> subcommand names, and options and patch names for some subcommands.
Thanks for the patch. I modified it slightly to automatically generate
the options for other commands as well (by invoking "stg help
<command>" and it doesn't seem to be slow). I'll try to push it
tonight.
Thanks for the other patches as well. I included some but haven't
finished them yet.
--
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox