* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Karl Hasselström @ 2007-10-25 14:51 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Peter Baumann, J. Bruce Fields,
Steffen Prohaska, Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <4720903E.1070103@op5.se>
On 2007-10-25 14:46:54 +0200, Andreas Ericsson wrote:
> error: The branch 'next' is not a strict subset of your current
> HEAD. If you are sure you want to delete it, run 'git branch -D
> next'.
>
> So you want me to tell all the developers they should use "git
> branch -D maint" instead, so they can bypass the built-in security
> checks? No thanks.
Maybe the solution here is to let "git branch -d" succeed if the
branch is a subset of HEAD or the branch it is tracking? That way,
deleting would succeed if upstream has all your commits.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-25 14:58 UTC (permalink / raw)
To: Theodore Tso
Cc: Johannes Schindelin, Steffen Prohaska, Peter Baumann,
J. Bruce Fields, Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <20071025132401.GA22103@thunk.org>
Theodore Tso wrote:
> On Thu, Oct 25, 2007 at 12:33:09PM +0200, Andreas Ericsson wrote:
>> Because it's convenient, ofcourse. Don't you have 'maint', 'next'
>> and 'master' in your clone of git.git? I'm guessing at least 99% of
>> the people on this list have those branches lying around in their
>> clones, even if they only ever use 'next' and/or 'master'.
>
> I find it just as easy to say: "git checkout origin/maint" or "git
> checkout origin/next" when I want to examine some other branch.
>
> If I want to make a change against maint, then I follow up "git
> checkout origin/maint" with a "git checkout -b <topic-name>". Part of
Except that <topic-name> in this case will always be maint, since
only small bugfixes go on that branch. We tried using different-named
branches earlier, but the "git push <local-branch>" behaviour was
much too common, and we ended up with far too many randomly named
branches on the mothership repository.
>
> You're using a diferent workflow, and with users who aren't interested
> in learning the fine points of git. But main issue is that git isn't
> optimized for what you want to do.
Correct. I'm working on optimizing it right now though :)
> So I can suggest a couple of
> different approaches. One is to simply do things the 'hg' way.
> Explicitly set up different repos for the different branches. It's
> more inefficient, but it does work.
That makes diffing harder to do, and for those few long-living topics
that get pushed to mothership, there's no logical way for the user to
get only that branch. With the *:refs/remotes/foo/* config thing, this
works seemlessly today.
>
> Another would be to set up a wrapper script for "git-clone" that
> creates a separate local working directory for each branch. So for
> example, it might do something like this:
>
> #!/bin/sh
> # Usage: get-repo <URL> [dir]
> URL=$1
> dir=$2
> branches=`git-ls-remote --heads $URL | sed -e 's;.*/;;'`
> if [ "$dir"x = "x" ]; then dir=`basename $URL`; fi
> git clone $URL .temp-repo
> mkdir $dir
> cd $dir
> for i in $branches; do
> mkdir $i
> cd $i
> git init
> git remote add -t $i origin $URL
> echo ref: refs/heads/$i > .git/HEAD
> git fetch ../../.temp-repo refs/remotes/origin/$i:refs/remotes/origin/$i
> # do it a second time to get the tags (bug in fetch?)
> git fetch ../../.temp-repo refs/remotes/origin/$i:refs/remotes/origin/$i
> git merge origin/$i
> git config remote.origin.push $i:$i
> cd ..
> done
> cd ..
> rm -rf .temp-repo
>
> For bonus points, this script could be made smarter so that each of
> the branches shared a common git object database, and some error
> checking would be nice, but hopefully this gets the basic idea across.
>
> This way, the "basic git users" get a separate working directory for
> each branch, where "git pull" updates that particular branch, and "git
> push" updates changes to the remote branch.
>
> Does this do what you want?
>
Not really, I'm afraid. Apart from missing out on the auto-download of
new repos you get with "fetch = refs/heads/*:refs/remotes/origin/*",
it seems inelegant.
> - Ted
>
> P.S. Note by the way that if you are having everyone own access to
> push into a single central repository, having a "next" branch probably
> doesn't make seense. You're probably way better off just simply
> having "master" (which would be your devel branch), and "maint" for
> bug fixes.
>
We have
maint = maintenance code. some repos have several maint-branches
master = integration-tested code that will end up in next release
testing = unit-tested features, ready for integration testing
We can't really do without them, but perhaps I can do what Dscho
suggested in another email and force everyone to delete their
locally-modifiable branches once they're done making changes to
them. It'll end up being more commands to run for a single fix,
but at least it's not error-prone.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Karl Hasselström @ 2007-10-25 15:01 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86oden6z97.fsf@blue.stonehenge.com>
On 2007-10-25 07:32:36 -0700, Randal L. Schwartz wrote:
> And when are we gonna get "fast forward only" for git-merge?
I'd like that too. For cases when I know I don't have to do a merge,
and want git to yell at me if I'm mistaken. For example, in a
repository that tracks an upstream so I can build the latest version,
but where I don't normally do any development.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Theodore Tso @ 2007-10-25 15:21 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Steffen Prohaska, Peter Baumann,
J. Bruce Fields, Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <4720AF05.3050308@op5.se>
On Thu, Oct 25, 2007 at 04:58:13PM +0200, Andreas Ericsson wrote:
>
> Correct. I'm working on optimizing it right now though :)
We await your patches. :-)
>> Another would be to set up a wrapper script for "git-clone" that
>> creates a separate local working directory for each branch. So for
>> example, it might do something like this:
>>
>> #!/bin/sh
>> # Usage: get-repo <URL> [dir]
>> ...
> Not really, I'm afraid. Apart from missing out on the auto-download of
> new repos you get with "fetch = refs/heads/*:refs/remotes/origin/*",
> it seems inelegant.
You mean new branches, right?
And of course it's inelegant. You just told us we were dealing with
CVS-brain-damaged corporate developers who can't be bothered to learn
about the fine points of using things the git way. And I thought you
said there were only a few branches, "master", maint", etc. and all
the developers worked on were the tips of the branches of the
corporate mothership repository.
It's like complaining that a car with manual transmission is too hard
to drive, and then when someone points out how this could be done with
an automatic transmission, and then complaining that that you don't
have the fine control of a manual transmission. Well, of course you
don't! Having that fine control requires that you *learn* how to use
that fine control correctly.
The solution I presented is more elegant than what hg does with
separate repositories, but sure, it does require disk space. But this
disk space is cheap, even when compared with the salary costs of
CVS-damanged developers. :-)
- Ted
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Jeff King @ 2007-10-25 15:51 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86oden6z97.fsf@blue.stonehenge.com>
On Thu, Oct 25, 2007 at 07:32:36AM -0700, Randal L. Schwartz wrote:
> I have echo "ref: refs/remotes/origin/master" >.git/refs/heads/upstream
> so that my daily update script can go:
>
> git-fetch
> if [ repo is on master, and is not dirty ];
> git-merge upstream
> fi
>
> Yesterday that worked.
>
> Today I get a rash of:
>
> fatal: Couldn't find remote ref refs/remotes/origin/master
>
> from my git-fetch.
Works fine here (meaning I can examine 'upstream' as I would any other
branch, and it points to the same place as origin/master).
Why is git-fetch touching your upstream branch at all? Do you have
something in your .git/config instructing it to do so? Or do you mean
that the 'git-merge upstream' command is failing? Can you 'git-show
upstream'? If not, can you 'git-show origin/master'?
-Peff
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Randal L. Schwartz @ 2007-10-25 15:55 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071025155142.GB19655@coredump.intra.peff.net>
>>>>> "Jeff" == Jeff King <peff@peff.net> writes:
Jeff> Why is git-fetch touching your upstream branch at all? Do you have
Jeff> something in your .git/config instructing it to do so? Or do you mean
Jeff> that the 'git-merge upstream' command is failing? Can you 'git-show
Jeff> upstream'? If not, can you 'git-show origin/master'?
It's probably due to this:
[remote "origin"]
url = [obscured]
fetch = +refs/heads/*:refs/remotes/origin/*
fetch wants to sync my heads with the origin heads. But yes, it's
definitely the fetch that fails under today's version, and not
under yesterday's version.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Jeff King @ 2007-10-25 15:57 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86fxzz6vfh.fsf@blue.stonehenge.com>
On Thu, Oct 25, 2007 at 08:55:14AM -0700, Randal L. Schwartz wrote:
> It's probably due to this:
>
> [remote "origin"]
> url = [obscured]
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> fetch wants to sync my heads with the origin heads. But yes, it's
> definitely the fetch that fails under today's version, and not
> under yesterday's version.
So that should take the remote's refs/heads/* and put them in your
refs/remotes/origin/*. I don't see how that would have anything to do
with your 'refs/heads/upstream' branch.
-Peff
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Randal L. Schwartz @ 2007-10-25 15:58 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071025155712.GA21446@coredump.intra.peff.net>
>>>>> "Jeff" == Jeff King <peff@peff.net> writes:
Jeff> On Thu, Oct 25, 2007 at 08:55:14AM -0700, Randal L. Schwartz wrote:
>> It's probably due to this:
>>
>> [remote "origin"]
>> url = [obscured]
>> fetch = +refs/heads/*:refs/remotes/origin/*
>>
>> fetch wants to sync my heads with the origin heads. But yes, it's
>> definitely the fetch that fails under today's version, and not
>> under yesterday's version.
Jeff> So that should take the remote's refs/heads/* and put them in your
Jeff> refs/remotes/origin/*. I don't see how that would have anything to do
Jeff> with your 'refs/heads/upstream' branch.
Agreed, but that's the place where fetch might look at refs/heads/upstream,
and the behavior is definitely different between yesterday and today.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Jeff King @ 2007-10-25 16:01 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86bqan6v9f.fsf@blue.stonehenge.com>
On Thu, Oct 25, 2007 at 08:58:52AM -0700, Randal L. Schwartz wrote:
> Jeff> So that should take the remote's refs/heads/* and put them in your
> Jeff> refs/remotes/origin/*. I don't see how that would have anything to do
> Jeff> with your 'refs/heads/upstream' branch.
>
> Agreed, but that's the place where fetch might look at refs/heads/upstream,
> and the behavior is definitely different between yesterday and today.
Fair enough. How about my other questions. Can you 'git-show upstream'?
Can you 'git-show origin/master'?
-Peff
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued
From: Federico Mena Quintero @ 2007-10-25 16:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, git
In-Reply-To: <Pine.LNX.4.64.0710242258201.25221@racer.site>
On Wed, 2007-10-24 at 23:14 +0100, Johannes Schindelin wrote:
> Whenever I told people "pull = fetch + merge", they got it.
[snip]
> My "pupils" _always_ liked the preciseness of the nomenclature. And they
> made many less mistakes because they had a clear mental model of what is
> remote, and what is local. And that local branches are always forks.
This is a *very* powerful concept. Unfortunately, it is not 100% clear
in the documentation, at least not when you are reading about
fetch/merge/pull initially.
After reading the user's manual, I just could not understand what
"fetch" does, and therefore "merge" and "pull" did not make sense. I
could not understand where Git stored the new changes from upstream
while also keeping my working directory in the same state it was. After
10 years of using CVS/SVN, the assumption you have is, "whenever I get
changes from the remote repository, they will be visible in my working
copy (and merge conflicts are a fact of life)".
Some time later, I ran into "Git for computer scientists" and then
finally I got it, thanks to the nice diagrams and explanation. I
realized how powerful a concept "fetch" is: THIS is the right way to
examine what upstream worked on while you did your own local work.
Once you understand what's going on, however, it is not obvious how to
*visualize* the state of things after you do "git fetch". Probably
"gitk --all" is the correct way to do it, but the presentation is not
ideal --- you have to hunt down the list of commits until you find your
own "master" (or whatever branch), and *there* is where you can say,
"oh, this is where we diverged; now let's see what I'll get when I
rebase later".
So, a few problems so far, with possible solutions:
* The docs do not make it easy to understand what git-fetch does. Can
we just cut&paste most of "Git for computer scientists" into the Git
user's manual?).
* It's not obvious how to visualize the state after git-fetch, i.e.
"gitk --all" is not the first thing that occurs to you. Maybe git-fetch
should suggest you to run "gitk --all" when your remotes get changes, so
that you can see what's going on?
* It's hard to find the "divergence point" in gitk's display, since you
have to scroll down the reverse-chronological list of commits until you
find your local refs and where they started diverging. Would there be a
way to "flatten" the display a bit, so your local stuff is always easy
to find, and yet it's easy to see what the remote changes were?
> And here I have to disagree strongly. In a workflow based on a
> shared
> repository, you do not want to merge. You want to rebase.
.. And after I understood what "fetch" does, "rebase" became obvious,
and *this* is where I started loving Git. I understood that in the past
all I had been doing with CVS was to rebase by hand; that is where I
said "Git is such a powerful tool".
> But _even if_ you merge instead of rebase, I fail to see how the current
> situation is different from CVS (which many people maintain is _easier_
> than gi), where first thing you do is to "cvs update". Just for git it is
> "git pull".
It's a matter of perception. CVS requires *less* steps, even if you do
more manual work. To commit something, you need to
cvs update
<resolve conflicts by hand - they are a fact of life, remember?>
cvs commit
Whereas with Git you need
git fetch
git rebase <huh, what was the name of the remote branch?>
<fix conflicts>
git commit
git push
[Maybe that's not 100% the right sequence, but you know what I mean.]
So your perception is that you have to fiddle more with Git (look up the
remote branch name, invoke more git commands), even if Git saved you a
lot of work when rebasing.
When you start using a complex tool like CVS or Git, you do it by
voodoo: you learn sequences of commands, but you don't really
understand what they do. If one tool makes you use less comands, it is
perceived as simpler and more powerful ("because the other one needs
more babysitting").
So, Git needs to make it very clear from the beginning (in the user's
manual or the distilled tutorials) that it has *very powerful* concepts
at your disposal. It needs to *teach you* how it will save you a lot of
work when compared to traditional tools like CVS.
Federico
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Randal L. Schwartz @ 2007-10-25 16:06 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071025160159.GA21505@coredump.intra.peff.net>
>>>>> "Jeff" == Jeff King <peff@peff.net> writes:
Jeff> On Thu, Oct 25, 2007 at 08:58:52AM -0700, Randal L. Schwartz wrote:
Jeff> So that should take the remote's refs/heads/* and put them in your
Jeff> refs/remotes/origin/*. I don't see how that would have anything to do
Jeff> with your 'refs/heads/upstream' branch.
>>
>> Agreed, but that's the place where fetch might look at refs/heads/upstream,
>> and the behavior is definitely different between yesterday and today.
Jeff> Fair enough. How about my other questions. Can you 'git-show upstream'?
Jeff> Can you 'git-show origin/master'?
yes, and they show the same thing.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Federico Mena Quintero @ 2007-10-25 16:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <8fe92b430710241648j609d4d00x121836001a69d1e6@mail.gmail.com>
On Thu, 2007-10-25 at 01:48 +0200, Jakub Narebski wrote:
> git push is opposite (almost) to git fetch, not to git pull.
This asymmetry is also part of what makes Git hard to learn at first.
There is a lot of new terminology to learn:
refs
remotes
fast-forwarding
rebasing
origin
master
HEAD (which is not quite the same as good old CVS's HEAD)
etc.
The solution is not, "have a good glossary" (which is needed, anyway),
but to make the documentation introduce those concepts at the right
time, instead of being chock-full of them from the beginning :)
Carl Worth's git-ification of the Mercurial book chapter is very nice in
this regard; it doesn't dump all the terminology on you, but rather
takes its time to introduce each concept when you are ready to know
about it [1].
It's kind of sad that the first thing "man git-push" tells you is this:
git-push - Update remote refs along with associated objects
So you go, "refs? associated objects? whaaaaaat?" :)
Imagine someone learning the GIMP a few versions ago. "I want to make
this photo sharper". You go to the Filters/Enhance menu and you see
Laplace
Sobel
Sharpen
Unsharp mask
All of those sharpen the image. Which one do you pick?
[1] http://cworth.org/hgbook-git/
Federico
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued
From: J. Bruce Fields @ 2007-10-25 16:38 UTC (permalink / raw)
To: Federico Mena Quintero; +Cc: Johannes Schindelin, Steffen Prohaska, git
In-Reply-To: <1193328386.4522.352.camel@cacharro.xalalinux.org>
On Thu, Oct 25, 2007 at 11:06:26AM -0500, Federico Mena Quintero wrote:
> So, a few problems so far, with possible solutions:
>
> * The docs do not make it easy to understand what git-fetch does. Can
> we just cut&paste most of "Git for computer scientists" into the Git
> user's manual?).
It's definitely not a simple cut-and-paste--even with permission from
the author of "Git for computer scientists", fitting this in would
require rethinking the ordering of topics in the manual. Also, there's
the restriction that we'd like to keep it looking good in plain ascii,
so diagrams have to be done in ascii somehow.
But as for using ideas from "Git for computer scientists", and/or
rethinking the ordering of the user's manual to make it more helpful.
Yes, that would be great! Let me know what I can do to help.
--b.
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Jeff King @ 2007-10-25 16:56 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano, Randal L. Schwartz
In-Reply-To: <86oden6z97.fsf@blue.stonehenge.com>
On Thu, Oct 25, 2007 at 07:32:36AM -0700, Randal L. Schwartz wrote:
> I have echo "ref: refs/remotes/origin/master" >.git/refs/heads/upstream
> so that my daily update script can go:
>
> git-fetch
> if [ repo is on master, and is not dirty ];
> git-merge upstream
> fi
>
> Yesterday that worked.
>
> Today I get a rash of:
>
> fatal: Couldn't find remote ref refs/remotes/origin/master
>
> from my git-fetch.
Randal and I discussed this a bit on IRC, and it turns out not to be
related to the 'upstream' symref. Instead, he had a broken
branch.master.merge config that pointed to "refs/remotes/origin/master"
(which you can see from his script above doesn't actually get used).
So presumably the old git-fetch didn't care that the contents of
branch.*.master didn't exist (it's just that nothing got marked for
merging), but the one just merged from the db/fetch-pack topic does.
Is this behavior change intentional?
-Peff
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-25 17:05 UTC (permalink / raw)
To: Theodore Tso
Cc: Johannes Schindelin, Steffen Prohaska, Peter Baumann,
J. Bruce Fields, Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <20071025152159.GB22103@thunk.org>
Theodore Tso wrote:
> On Thu, Oct 25, 2007 at 04:58:13PM +0200, Andreas Ericsson wrote:
>> Correct. I'm working on optimizing it right now though :)
>
> We await your patches. :-)
>
>>> Another would be to set up a wrapper script for "git-clone" that
>>> creates a separate local working directory for each branch. So for
>>> example, it might do something like this:
>>>
>>> #!/bin/sh
>>> # Usage: get-repo <URL> [dir]
>>> ...
>
>> Not really, I'm afraid. Apart from missing out on the auto-download of
>> new repos you get with "fetch = refs/heads/*:refs/remotes/origin/*",
>> it seems inelegant.
>
> You mean new branches, right?
>
Yes. The few topic-branches that require input from several people are
distributed this way for peer review and trouble-shooting. It's nifty
if they're automatically downloaded, but not so much of an issue that
it matters.
> And of course it's inelegant. You just told us we were dealing with
> CVS-brain-damaged corporate developers who can't be bothered to learn
> about the fine points of using things the git way.
No, they're just surprised that what they thought would be automatic
isn't, and the curse about it when they put themselves in trouble by
forgetting about it. I've done it myself, and I've been using git since
may 2005.
> And I thought you
> said there were only a few branches, "master", maint", etc. and all
> the developers worked on were the tips of the branches of the
> corporate mothership repository.
>
It depends. For small bugfixes we sometimes commit directly on the
checked out branch. For larger issues we usually create a topic branch
and hack away, creating nicely ordered patch-series and such, but those
topic branches must be created from the tip of the upstream tracking
branch. What Dscho suggested would definitely work, but that would
mean I'd have to tell my co-workers to use 'git branch -D', which I'm
quite reluctant to do. One solution to that particular problem is
ofcourse to hack the delete-command of git-branch to honor remote
tracking branches when calculating dependencies, so the local branches
can safely be removed when they're done with them.
However, there's still this issue:
$ git checkout -b foo origin/pu
Branch foo set up to track remote branch refs/remotes/origin/pu.
Switched to a new branch "foo"
git checkout will say that every time a branch is created from a
tracking branch, unless one tells it --no-track (which people don't
learn about unless they're really into git), so it's quite natural
that people think git will actually make sure, within reasonable
limits, that 'foo' is kept in sync with refs/remotes/origin/pu.
That's not the case, however.
So we could either change the message to be:
"Branch foo set up to track remote branch refs/remotes/origin/pu,
provided you only ever issue git-pull while having branch foo
checked out."
Or we could make 'git checkout -b' default to --no-track, perhaps
giving annoying messages everytime someone "git-checkout -b"'s a
remote tracking branch.
Or we could make git-pull keep git checkout's promises.
I'm opting for the latter, since that's the one that makes a piece
of machinery do some work for me. I'd happily call the command
"git-update-all-local-branches-tracking-remote-tracking-branches"
and only ever make it actually do any work if I pass it the option
"--I-bask-in-the-glory-of-local-vs-remote-confusion", but I need
some sort of solution that
a) Doesn't normally present error messages.
b) Doesn't involve routinely using "git branch -D"
c) Doesn't require more than one or two commands per repo to get
the locally checked out copies of the remote tracking branches
(the ones git has "set up to track remote branch remotes/x/branch")
up to date with their remote counterpart.
> It's like complaining that a car with manual transmission is too hard
> to drive, and then when someone points out how this could be done with
> an automatic transmission, and then complaining that that you don't
> have the fine control of a manual transmission. Well, of course you
> don't! Having that fine control requires that you *learn* how to use
> that fine control correctly.
>
Or invent the sensatronic transmission system and get the best of both
worlds. Engineering solutions so they fit humans? Good gods, that's a
novel idea! ;-)
> The solution I presented is more elegant than what hg does with
> separate repositories, but sure, it does require disk space. But this
> disk space is cheap, even when compared with the salary costs of
> CVS-damanged developers. :-)
>
It's not so much CVS-damaged developers as it's conflicting messages.
I'm quite confused about it myself at times, but for me there's
nobody to harrass since I was the one vetoing in git as the scm to
use for all our corporate needs.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-25 17:10 UTC (permalink / raw)
To: Karl Hasselström
Cc: Johannes Schindelin, Peter Baumann, J. Bruce Fields,
Steffen Prohaska, Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <20071025145132.GA31196@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> On 2007-10-25 14:46:54 +0200, Andreas Ericsson wrote:
>
>> error: The branch 'next' is not a strict subset of your current
>> HEAD. If you are sure you want to delete it, run 'git branch -D
>> next'.
>>
>> So you want me to tell all the developers they should use "git
>> branch -D maint" instead, so they can bypass the built-in security
>> checks? No thanks.
>
> Maybe the solution here is to let "git branch -d" succeed if the
> branch is a subset of HEAD or the branch it is tracking? That way,
> deleting would succeed if upstream has all your commits.
>
Deleting branches sitting on a ref reachable from any other locally
checked out branch certainly works. Since this is done to protect
commits from being pruned, and prune honors remote tracking branches
when deciding which commits are unreachable, I see no harm in letting
branches pointing to commits reachable from any remote tracking branch
be deleted.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Nicolas Pitre @ 2007-10-25 17:46 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Randal L. Schwartz, git
In-Reply-To: <20071025150107.GB31196@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 602 bytes --]
On Thu, 25 Oct 2007, Karl Hasselström wrote:
> On 2007-10-25 07:32:36 -0700, Randal L. Schwartz wrote:
>
> > And when are we gonna get "fast forward only" for git-merge?
>
> I'd like that too. For cases when I know I don't have to do a merge,
> and want git to yell at me if I'm mistaken. For example, in a
> repository that tracks an upstream so I can build the latest version,
> but where I don't normally do any development.
Isn't that called a remote branch that gets updated with "git fetch' ?
You can even trick Git into not using the refs/remotes/ namespace for
them if you wish.
Nicolas
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued
From: Federico Mena Quintero @ 2007-10-25 18:02 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20071025152159.GB22103@thunk.org>
On Thu, 2007-10-25 at 11:21 -0400, Theodore Tso wrote:
> And of course it's inelegant. You just told us we were dealing with
> CVS-brain-damaged corporate developers who can't be bothered to learn
> about the fine points of using things the git way.
Ignore the corporate developers who use SCMs only because their company
requires them to. Git is not the right thing for them; some
Eclipse-based monstrosity probably is. It's like the horrendous
Oracle-based expense-reporting thing we have to use at Novell; I use it
because they make me, not because I'm particularly excited about
reporting expenses :)
However, *do think* of the free software developers who have been using
CVS forever. You won't make friends among them if you keep saying, "you
use CVS? You are brain-damaged, then." CVS has been as good/bad to
them as to anyone else, and they are probably delighted to get a better
solution. That solution needs to take into account the concepts to
which they have been exposed for the past N years. Just because your
new concepts are better, doesn't mean that their old ones were wrong in
their time.
You don't find quantum physicists saying, "... yeah, like Newton's
brain-damaged followers" :)
Federico
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued
From: Federico Mena Quintero @ 2007-10-25 18:06 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20071025163835.GB31888@fieldses.org>
On Thu, 2007-10-25 at 12:38 -0400, J. Bruce Fields wrote:
> It's definitely not a simple cut-and-paste--even with permission from
> the author of "Git for computer scientists", fitting this in would
> require rethinking the ordering of topics in the manual.
Oh, that can be done. It's easier to move text around than to
rearchitect code :)
> Also, there's
> the restriction that we'd like to keep it looking good in plain ascii,
> so diagrams have to be done in ascii somehow.
Hmm, what's the rationale for this? I'd assume that most people read
the user's manual as a web page (or as bedside reading if they can print
a PDF thereof), where diagrams can be pretty.
Federico
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Daniel Barkalow @ 2007-10-25 18:05 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Randal L. Schwartz
In-Reply-To: <20071025165633.GA24143@coredump.intra.peff.net>
On Thu, 25 Oct 2007, Jeff King wrote:
> On Thu, Oct 25, 2007 at 07:32:36AM -0700, Randal L. Schwartz wrote:
>
> > I have echo "ref: refs/remotes/origin/master" >.git/refs/heads/upstream
> > so that my daily update script can go:
> >
> > git-fetch
> > if [ repo is on master, and is not dirty ];
> > git-merge upstream
> > fi
> >
> > Yesterday that worked.
> >
> > Today I get a rash of:
> >
> > fatal: Couldn't find remote ref refs/remotes/origin/master
> >
> > from my git-fetch.
>
> Randal and I discussed this a bit on IRC, and it turns out not to be
> related to the 'upstream' symref. Instead, he had a broken
> branch.master.merge config that pointed to "refs/remotes/origin/master"
> (which you can see from his script above doesn't actually get used).
>
> So presumably the old git-fetch didn't care that the contents of
> branch.*.master didn't exist (it's just that nothing got marked for
> merging), but the one just merged from the db/fetch-pack topic does.
>
> Is this behavior change intentional?
It's not exactly intentional; it's just that nobody seems to have tested
this particular misconfiguration. It should probably report an error
(since the configuration is, in fact, broken and potentially misleading),
but it probably shouldn't be fatal and certainly shouldn't be so
uninformative.
I guess it's a new feature that you can use a branch.*.merge line to
select a ref that otherwise wouldn't be fetched at all, cause it to be
fetched, and have it marked for merging; previously, such a config line
would just be ignored, as it didn't exactly match anything. It's a side
effect that something that doesn't exist (by that name on the remote side)
is now an issue.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* git apply fails to apply a renamed file in a new directory
From: Sam Ravnborg @ 2007-10-25 18:07 UTC (permalink / raw)
To: git
I just stumbled on what looks like a simple bug in git apply.
I had following diff:
diff --git a/arch/i386/defconfig b/arch/x86/configs/i386_defconfig
similarity index 100%
rename from arch/i386/defconfig
rename to arch/x86/configs/i386_defconfig
diff --git a/arch/x86_64/defconfig b/arch/x86/configs/x86_64_defconfig
similarity index 100%
rename from arch/x86_64/defconfig
rename to arch/x86/configs/x86_64_defconfig
--
1.5.3.4.1157.g0e74-dirty
When trying to apply this diff using:
git apply -p1 < .../patch
I noticed that the two defconfig files were deleted as expected,
but the renamed versions did not appear in the arch/x86/configs/
directory.
The configs/ directory did not exist and was not created.
Without looking at git apply I assume that the rename failed because
it is not prepared to rename a file to a directory that does not exist.
Buried in other stuff so I did not take a look myself..
Sam
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued
From: Mike Hommey @ 2007-10-25 18:04 UTC (permalink / raw)
To: Federico Mena Quintero; +Cc: Theodore Tso, git
In-Reply-To: <1193335339.4522.398.camel@cacharro.xalalinux.org>
On Thu, Oct 25, 2007 at 01:02:19PM -0500, Federico Mena Quintero wrote:
> On Thu, 2007-10-25 at 11:21 -0400, Theodore Tso wrote:
>
> > And of course it's inelegant. You just told us we were dealing with
> > CVS-brain-damaged corporate developers who can't be bothered to learn
> > about the fine points of using things the git way.
>
> Ignore the corporate developers who use SCMs only because their company
> requires them to. Git is not the right thing for them; some
> Eclipse-based monstrosity probably is. It's like the horrendous
> Oracle-based expense-reporting thing we have to use at Novell; I use it
> because they make me, not because I'm particularly excited about
> reporting expenses :)
>
> However, *do think* of the free software developers who have been using
> CVS forever. You won't make friends among them if you keep saying, "you
> use CVS? You are brain-damaged, then." CVS has been as good/bad to
> them as to anyone else, and they are probably delighted to get a better
> solution. That solution needs to take into account the concepts to
> which they have been exposed for the past N years. Just because your
> new concepts are better, doesn't mean that their old ones were wrong in
> their time.
It's probably just a matter of writing a "git for CVS users" document.
Mike
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued
From: J. Bruce Fields @ 2007-10-25 18:16 UTC (permalink / raw)
To: Federico Mena Quintero; +Cc: git
In-Reply-To: <1193335562.4522.403.camel@cacharro.xalalinux.org>
On Thu, Oct 25, 2007 at 01:06:02PM -0500, Federico Mena Quintero wrote:
> On Thu, 2007-10-25 at 12:38 -0400, J. Bruce Fields wrote:
>
> > It's definitely not a simple cut-and-paste--even with permission from
> > the author of "Git for computer scientists", fitting this in would
> > require rethinking the ordering of topics in the manual.
>
> Oh, that can be done. It's easier to move text around than to
> rearchitect code :)
OK! I'm happy to help review patches, etc.
> > Also, there's
> > the restriction that we'd like to keep it looking good in plain ascii,
> > so diagrams have to be done in ascii somehow.
>
> Hmm, what's the rationale for this?
There have always been a lot of complaints about the difficulty of
building the documentation. (I don't know why; at least on Debian all
you need is an "apt-get build-dep git-core".) And our response has been
"no problem, you can just read the source." That's a big reason why
asciidoc was chosen.
> I'd assume that most people read the user's manual as a web page (or
> as bedside reading if they can print a PDF thereof), where diagrams
> can be pretty.
Yeah. Heck, I just read it by pointing my web browser at kernel.org's
html copy....
So you might get some sympathy for a request for fancier diagrams, I
don't know. It would require some more discussion, so I'd rather not
have other improvements blocked by this.
--b.
^ permalink raw reply
* [PATCH 2/6] Split out "exact content match" phase of rename detection
From: Linus Torvalds @ 2007-10-25 18:17 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0710251112120.30120@woody.linux-foundation.org>
From: Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH 2/6] Split out "exact content match" phase of rename detection
This makes the exact content match a separate function of its own.
Partly to cut down a bit on the size of the diffcore_rename() function
(which is too complex as it is), and partly because there are smarter
ways to do this than an O(m*n) loop over it all, and that function
should be rewritten to take that into account.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
This is, I think, identical to the patch you already have. Feel free to
skip this, and base the rest of the patch-series on your existing one.
diffcore-rename.c | 90 +++++++++++++++++++++++++++++++++--------------------
1 files changed, 56 insertions(+), 34 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 142e537..2077a9b 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -262,6 +262,58 @@ static int compute_stays(struct diff_queue_struct *q,
return 1;
}
+/*
+ * Find exact renames first.
+ *
+ * The first round matches up the up-to-date entries,
+ * and then during the second round we try to match
+ * cache-dirty entries as well.
+ *
+ * Note: the rest of the rename logic depends on this
+ * phase also populating all the filespecs for any
+ * entry that isn't matched up with an exact rename,
+ * see "is_exact_match()".
+ */
+static int find_exact_renames(void)
+{
+ int rename_count = 0;
+ int contents_too;
+
+ for (contents_too = 0; contents_too < 2; contents_too++) {
+ int i;
+
+ for (i = 0; i < rename_dst_nr; i++) {
+ struct diff_filespec *two = rename_dst[i].two;
+ int j;
+
+ if (rename_dst[i].pair)
+ continue; /* dealt with an earlier round */
+ for (j = 0; j < rename_src_nr; j++) {
+ int k;
+ struct diff_filespec *one = rename_src[j].one;
+ if (!is_exact_match(one, two, contents_too))
+ continue;
+
+ /* see if there is a basename match, too */
+ for (k = j; k < rename_src_nr; k++) {
+ one = rename_src[k].one;
+ if (basename_same(one, two) &&
+ is_exact_match(one, two,
+ contents_too)) {
+ j = k;
+ break;
+ }
+ }
+
+ record_rename_pair(i, j, (int)MAX_SCORE);
+ rename_count++;
+ break; /* we are done with this entry */
+ }
+ }
+ }
+ return rename_count;
+}
+
void diffcore_rename(struct diff_options *options)
{
int detect_rename = options->detect_rename;
@@ -270,12 +322,11 @@ void diffcore_rename(struct diff_options *options)
struct diff_queue_struct *q = &diff_queued_diff;
struct diff_queue_struct outq;
struct diff_score *mx;
- int i, j, rename_count, contents_too;
+ int i, j, rename_count;
int num_create, num_src, dst_cnt;
if (!minimum_score)
minimum_score = DEFAULT_RENAME_SCORE;
- rename_count = 0;
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
@@ -318,40 +369,11 @@ void diffcore_rename(struct diff_options *options)
if (rename_dst_nr * rename_src_nr > rename_limit * rename_limit)
goto cleanup;
- /* We really want to cull the candidates list early
+ /*
+ * We really want to cull the candidates list early
* with cheap tests in order to avoid doing deltas.
- * The first round matches up the up-to-date entries,
- * and then during the second round we try to match
- * cache-dirty entries as well.
*/
- for (contents_too = 0; contents_too < 2; contents_too++) {
- for (i = 0; i < rename_dst_nr; i++) {
- struct diff_filespec *two = rename_dst[i].two;
- if (rename_dst[i].pair)
- continue; /* dealt with an earlier round */
- for (j = 0; j < rename_src_nr; j++) {
- int k;
- struct diff_filespec *one = rename_src[j].one;
- if (!is_exact_match(one, two, contents_too))
- continue;
-
- /* see if there is a basename match, too */
- for (k = j; k < rename_src_nr; k++) {
- one = rename_src[k].one;
- if (basename_same(one, two) &&
- is_exact_match(one, two,
- contents_too)) {
- j = k;
- break;
- }
- }
-
- record_rename_pair(i, j, (int)MAX_SCORE);
- rename_count++;
- break; /* we are done with this entry */
- }
- }
- }
+ rename_count = find_exact_renames();
/* Have we run out the created file pool? If so we can avoid
* doing the delta matrix altogether.
--
1.5.3.4.330.g1dec6
^ permalink raw reply related
* Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued
From: J. Bruce Fields @ 2007-10-25 18:18 UTC (permalink / raw)
To: Mike Hommey; +Cc: Federico Mena Quintero, Theodore Tso, git
In-Reply-To: <20071025180451.GA6349@glandium.org>
On Thu, Oct 25, 2007 at 08:04:51PM +0200, Mike Hommey wrote:
> On Thu, Oct 25, 2007 at 01:02:19PM -0500, Federico Mena Quintero wrote:
> > On Thu, 2007-10-25 at 11:21 -0400, Theodore Tso wrote:
> >
> > > And of course it's inelegant. You just told us we were dealing with
> > > CVS-brain-damaged corporate developers who can't be bothered to learn
> > > about the fine points of using things the git way.
> >
> > Ignore the corporate developers who use SCMs only because their company
> > requires them to. Git is not the right thing for them; some
> > Eclipse-based monstrosity probably is. It's like the horrendous
> > Oracle-based expense-reporting thing we have to use at Novell; I use it
> > because they make me, not because I'm particularly excited about
> > reporting expenses :)
> >
> > However, *do think* of the free software developers who have been using
> > CVS forever. You won't make friends among them if you keep saying, "you
> > use CVS? You are brain-damaged, then." CVS has been as good/bad to
> > them as to anyone else, and they are probably delighted to get a better
> > solution. That solution needs to take into account the concepts to
> > which they have been exposed for the past N years. Just because your
> > new concepts are better, doesn't mean that their old ones were wrong in
> > their time.
>
> It's probably just a matter of writing a "git for CVS users" document.
First google hit for "git for CVS users":
http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
patches welcomed....
--b.
^ 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