* 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: 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 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: 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: 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 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: 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: 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 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: 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: 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 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: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: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: 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: 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: 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: 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
* recent change in git.git/master broke my repos
From: Randal L. Schwartz @ 2007-10-25 14:32 UTC (permalink / raw)
To: git
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.
Is git-fetch broken, or am I? And if it's me, how do I do what I
want instead?
And when are we gonna get "fast forward only" for git-merge?
--
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: Git and Windows
From: Johannes Schindelin @ 2007-10-25 14:19 UTC (permalink / raw)
To: Bo Yang; +Cc: git
In-Reply-To: <47208817.60804@gmail.com>
Hi,
On Thu, 25 Oct 2007, Bo Yang wrote:
> I am a new comer to this list but I have used git for two week
> development control. I think it is a very cool tool, the only flaw is
> that I have not found Windows version of it. Does git just aim at Linux
> kernel development? Is there any plan or in the future to migrate it to
> windows?
Funny. The first three hits I get from Google are
Wikipedia,
GitWiki and
msysgit
The first two pointing to the third. And happily enough, there is a
Download page at the third site. Oh, and it has a description what its
affiliation with git is.
Hth,
Dscho
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Theodore Tso @ 2007-10-25 13:24 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: <472070E5.4090303@op5.se>
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
the reason though, why I *want* to keep the topic branch around is
precisely because I don't get to push to the central repository. So I
want to keep it around so either (a) the central maintainer can pull
from me, and I delete it only after he's done the pull, or (b) so I
can use git-chery so I can see when patches that I created and sent
via git-format-patch and git-send-email have been accepted.
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. 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. And if the bulk of your users
are, ah, "aggressive ignorant" about git --- and many developers don't
care about learning the fine points of their tools, and a successful
software company needs to learn how to leverage the skills of such
mid-level engineers (only at a startup or if you are at Google can you
insist only only hiring the best and brightest) --- then it might be
that the 'hg' approach is easier. Certainly that was the approach
Larry McVoy has always used with BitKeeper, and he is focused on
meeting the needs of his corporate customers.
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?
- 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.
^ permalink raw reply
* Re: git-svnimport
From: Johannes Schindelin @ 2007-10-25 13:04 UTC (permalink / raw)
To: Felipe Balbi; +Cc: git
In-Reply-To: <31e679430710250408g679538e7ha9e1e75507c2aac5@mail.gmail.com>
Hi,
On Thu, 25 Oct 2007, Felipe Balbi wrote:
> On 10/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Thu, 25 Oct 2007, Felipe Balbi wrote:
> >
> > > I was importing busybox svn repository to git but I got a connection
> > > timeout after more than 19k commits... is there a way to continue
> > > where the error happened or should I do it all over again ??
> >
> > AFAICT git-svn is better suited, even to one-shot importing svn.
> >
> > As it happens, I got interested in this project, too, and did an
> > import some time ago. For your pleasure, I uploaded it to
> >
> > http://repo.or.cz/w/busybox.git/
>
> thanks... much better... I'm cloning your tree and I'll merge with
> current busybox tree... ;-)
FYI you'll have to do something like this:
git svn init svn://busybox.net/trunk/busybox
git svn fetch
to merge with current busybox (although I updated before I pushed).
Ciao,
Dscho
^ permalink raw reply
* Re: Feature request: Limit git-status reports to a directory
From: Wincent Colaiuta @ 2007-10-25 13:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Yin Ping, Michel Marti, git
In-Reply-To: <Pine.LNX.4.64.0710251050390.25221@racer.site>
El 25/10/2007, a las 11:55, Johannes Schindelin escribió:
> Hi,
>
> On Thu, 25 Oct 2007, Yin Ping wrote:
>
>> On 10/25/07, Michel Marti <mma@objectxp.com> wrote:
>>
>> It's also painful for me. IMHO, the behaviour of "git-status" should
>> keep consistent with "git-diff" and "git-log" which allow for the
>> path.
>
> I am not so sure. In other SCMs, "git status" may be a way to do "git
> diff --name-only" or "git ls-files", but not in git. Here, it
> strictly
> means "what would be happening if I were to commit _right_ _now_?".
Yes, but there's no reason why the user shouldn't be able to scope
that down to a specific path, just as they currently can for git-diff
(as you point out):
> IMHO it is not asking users too much when you say "git diff ." is
> for the
> current directory, and "git diff" is for the whole working tree.
Sometimes if you have a dirty tree with lots of modified files and
potentially lots of things added to the index the output of git-
status can be quite long, and perhaps all you want to know about is
what is the status of *this* directory or *that* file rather than
having to visually scan through the entire git-status output.
Accepting path info would therefore be a nice usability improvement.
Allowing git-status to accept a path would be consistent with how
other git commands (like git-diff) already work, and with other SCMs
too. The user is expected to know that what's in the index is what
will be committed, and that if he/she types "git-status foo" then he/
she may only be seeing a subset of what's staged in the index.
But the way git-status currently behaves when supplied path info is
puzzling to say the least. As the man page says:
> "The command takes the same set of options as git-commit; it shows
> what would be committed if the same options are given to git-commit."
This means that if you do try passing a path to git-status (as surely
many newcomers have done), you'll see the combined result of what is
already staged in the index *plus* what would happen if you git-added
the path(s) that you passed on the command line. I'd argue that this
is counter-intuitive, and I think that most would expect that the
paths would serve as scope *limiters* rather than indicators that
something should be *added* to the index.
To illustrate this, an example; just say you have git-status output
like this:
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: foo/bar
# modified: baz
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# NOTES
no changes added to commit (use "git add" and/or "git commit -a")
And you type "git-status foo":
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: foo/bar
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: baz
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# NOTES
I understand why it works this way, and it's explained by the man
page, but the behaviour is the very last thing I would expect.
Cheers,
Wincent
^ permalink raw reply
* Re: Feature request: Limit git-status reports to a directory
From: Michel Marti @ 2007-10-25 13:03 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0710251050390.25221@racer.site>
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
on 10/25/2007 11:55 AM Johannes Schindelin said the following:
> I am not so sure. In other SCMs, "git status" may be a way to do "git
> diff --name-only" or "git ls-files", but not in git. Here, it strictly
> means "what would be happening if I were to commit _right_ _now_?".
I somehow agree with your argument, but then again, sometimes I'm still interested in
*only* the status for a given directory.
IMHO, answering the question "what would be happening if...?" should be git-commit's task
(e.g. git-commit --dry-run). And git-status should behave similar to git-log and git-diff.
For those interested: I have attached a little script that mimics current git-status
(except the "dry-run" stuff) but also can take a list of directories/files.
[-- Attachment #2: git-status-new --]
[-- Type: text/plain, Size: 1957 bytes --]
#!/bin/sh
USAGE='[--staged] [--changed] [--untracked]'
SUBDIRECTORY_OK=1 . git-sh-setup
require_work_tree
print_stat_line() {
case "$1" in
M) echo "# modified: $2";;
A) echo "# new file: $2";;
R*) echo "# renamed: $2 -> $3";;
D) echo "# deleted: $2";;
U) echo "# unmerged: $2";;
X) echo "# $2";;
*) echo "# [$S]: $2";;
esac
}
STAGED= CHANGED= UNTRACKED= HP=
while test $# != 0
do
case "$1" in
-s|--staged) STAGED=1; shift;;
-c|--changed) CHANGED=1; shift;;
-u|--untracked) UNTRACKED=1; shift;;
--) shift; break;;
-*) usage;;
*) break;;
esac
done
if BRANCH_NAME=$(git symbolic-ref -q HEAD)
then
BRANCH_NAME="On branch $(expr "z$BRANCH_NAME" : 'zrefs/heads/\(.*\)')"
else
BRANCH_NAME="Not currently on any branch"
fi
[ "$#" = 0 ] && cd_to_toplevel
if [ -z "$STAGED$CHANGED$UNTRACKED" ]; then
STAGED=1; CHANGED=1; UNTRACKED=1
fi
SP=$(echo _/$(git rev-parse --show-cdup)|tr '/' ' '|wc -w)
echo "# $BRANCH_NAME"
# Changes to be commited
[ "$STAGED" ] && git-diff --name-status --cached -M -- "$@"|while read S F R
do
if [ -z "$HP" ]; then
echo '# Changes to be committed:'
echo '# (use "git reset HEAD <file>..." to unstage)'
echo '#'
HP=1
fi
F=$(echo $F|cut -d'/' -f$SP-)
print_stat_line "$S" "$F" "$R"
done
# Changed but not updated
[ "$CHANGED" ] && git-diff --name-status -- "$@"|while read S F
do
if [ -z "$HP" ]; then
echo '#'
echo '# Changed but not updated:'
echo '# (use "git add <file>..." to update what will be committed)'
echo '#'
HP=1
fi
F=$(echo $F|cut -d'/' -f$SP-)
print_stat_line "$S" "$F"
done
# Untracked files
[ "$UNTRACKED" ] && git-ls-files --exclude-per-directory=.gitignore -o --directory -- "$@"|while read F
do
if [ -z "$HP" ]; then
echo '#'
echo '# Untracked files:'
echo '# (use "git add <file>..." to include in what will be committed)'
echo '#'
HP=1
fi
print_stat_line "X" "$F"
done
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-25 12:58 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Steffen Prohaska, Peter Baumann, J. Bruce Fields, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <472070E5.4090303@op5.se>
Hi,
On Thu, 25 Oct 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > When you're done with a topic, why do you leave it around?
> > Cluttering up your "git branch" output?
>
> We have 91 repositories at work. Roughly 60 of those are in active use.
> The active repos are organized pretty much like the git repo with
> 'master', 'next' and 'maint'. We *do* work on all branches, but not
> every day, ofcourse. They're NOT topic branches.
I already explained in another mail (wasn't it even the one you replied
to?) how this can be done more efficiently.
Ciao,
Dscho
^ 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