* Re: git-log --pretty=format:%s doesn't honor option i18n.logoutputencoding?
From: René Scharfe @ 2007-11-13 18:05 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320711120404l5581b1fbpc91c2557bcad2c88@mail.gmail.com>
Ping Yin schrieb:
> $ gtcf --get-regexp i18n.*
> i18n.logoutputencoding GBK
> $ locale | grep LC_CTYPE
> LC_CTYPE=zh_CN.GBK
> $ git --version
> git version 1.5.3.4
>
> And my terminal encoding is GBK
>
> $ git log --pretty=oneline
> msgs with chinese character displayed correctly
>
> However
> $ git log --pretty=format:%s
> the chinese character doesn't display correctly
Yes, indeed, --pretty=format has always ignored encodings. I'll see if
I can cook up a patch later this week, if nobody beats me to it.
René
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: osv @ 2007-11-13 17:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Steffen Prohaska, git
In-Reply-To: <200711131842.03622.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Steffen Prohaska wrote:
>> On Nov 13, 2007, at 5:03 PM, Jakub Narebski wrote:
>>> Sergei Organov <osv@javad.com> wrote:
>
>>>> Isn't "git branch -d -r" supposed to do whatever magic is required to
>>>> get rid of the remote branch? Currently it seems like a bug
>>>> introduced by addition of wildcards refspecs, right?
>>>
>>> No, the '-r' part translates 'pu' into 'refs/remotes/origin/pu', and
>>> the '-d' option removes branch locally. It is meant I think to remove
>>> tracking of branches which were dropped in remote, as I think that
>>> wildcard refspec does create new branches, but do not delete dropped
>>> branches.
>>
>> "git remote prune origin" should be used to clean up stale
>> remote-tracking branches.
>
> "git remote prune <name>" deletes _all_ stale tracking branches
> under <name>. With "git branch -d -r <branch>" you can delete
> _single_ tracking branch.
>
>>> So I'm not sure if it is a bug, misfeature or a feature.
>>
>> It doesn't make sense to delete remote-tracking branches
>> locally if they are still present at the remote. The main
>> purpose of a remote-tracking branch is to be identical to the
>> real remote branch.
>
> True, but it would be nice to have an option to _exclude_ some
> branches from fetching (for example 'html' and 'man' branches
> of git.git), while still picking up new branches automatically
> on fetch.
Guys, could you please read man git-branch? What do you think this
example is doing?:
<quote Documentation/git-branch.txt>
Delete unneeded branch::
+
------------
$ git clone git://git.kernel.org/.../git.git my.git
$ cd my.git
$ git branch -d -r origin/todo origin/html origin/man <1>
$ git branch -D test <2>
------------
+
<1> Delete remote-tracking branches "todo", "html", "man"
</quote>
That's *exactly* what I did! And it *doesn't work*! Well, it does delete
the branches, but they are automagically re-created on the next fetch,
so "deleting" them this way is useless.
--
Sergei.
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Sergei Organov @ 2007-11-13 17:47 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Jakub Narebski, git
In-Reply-To: <A919E788-C5D0-4404-95D4-869BAFE868AC@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
[...]
> It doesn't make sense to delete remote-tracking branches locally if
> they are still present at the remote. The main purpose of a
> remote-tracking branch is to be identical to the real remote branch.
But I don't want to track those real remote branch anymore, so obviously
I don't want anything that is "identical" to it, so deleting
corresponding remote-tracking branch makes perfect sense, IMHO.
--
Sergei.
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Sergei Organov @ 2007-11-13 17:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711131703.16357.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Sergei Organov <osv@javad.com> wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>> Sergei Organov wrote:
>
>>>> I want to get rid of origin/pu remote tracking branch. What do I do?
>>>> I RTFM git-branch. What does it suggest?
>>>>
>>>> git branch -d -r origin/pu
>>>>
>>>> So far so good. However, it doesn't seem to work in practice:
> [...]
>>>> $ git branch -d -r origin/pu
>>>> Deleted remote branch origin/pu.
>>>> $ git remote show origin
>>>> * remote origin
>>>> URL: git://git.kernel.org/pub/scm/git/git.git
>>>> Remote branch(es) merged with 'git pull' while on branch master
>>>> master
>>>> New remote branches (next fetch will store in remotes/origin)
>>>> pu
>>>> ^^^^^^^^^^^^^^^^^^^ What???
>>>> Tracked remote branches
>>>> html maint man master next todo
>>>
>>> Check out what do you have in .git/config file, in the
>>> [remote "origin"] section. Most probably (if you cloned this
>>> repository using new enough git) you have wildcard refspec there,
>>> which means that git would pick all new branches when
>>> fetching / pulling from given repository.
>>
>> Sure, I've cloned git.git using rather recent git, so .git/config has:
>>
>> fetch = +refs/heads/*:refs/remotes/origin/*
>
> [...]
>> Isn't "git branch -d -r" supposed to do whatever magic is required to
>> get rid of the remote branch? Currently it seems like a bug introduced
>> by addition of wildcards refspecs, right?
>
> No, the '-r' part translates 'pu' into 'refs/remotes/origin/pu', and
> the '-d' option removes branch locally. It is meant I think to remove
> tracking of branches which were dropped in remote, as I think that
> wildcard refspec does create new branches, but do not delete dropped
> branches.
Isn't it 'git remote prune <name>' that is meant to remove tracking of
branches which were dropped in remote?
Anyway, description of '-r' in man git-branch:
-r::
List or delete (if used with -d) the remote-tracking branches.
Suggests it should be deleted. What's a point to delete it if it will be
re-created on next fetch anyway?
> So I'm not sure if it is a bug, misfeature or a feature.
>
> Can anyone better versed in wildcard refspecs speak up, please?
Yes, please!
--
Sergei.
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Jakub Narebski @ 2007-11-13 17:42 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Sergei Organov, git
In-Reply-To: <A919E788-C5D0-4404-95D4-869BAFE868AC@zib.de>
Steffen Prohaska wrote:
> On Nov 13, 2007, at 5:03 PM, Jakub Narebski wrote:
>> Sergei Organov <osv@javad.com> wrote:
>>> Isn't "git branch -d -r" supposed to do whatever magic is required to
>>> get rid of the remote branch? Currently it seems like a bug
>>> introduced by addition of wildcards refspecs, right?
>>
>> No, the '-r' part translates 'pu' into 'refs/remotes/origin/pu', and
>> the '-d' option removes branch locally. It is meant I think to remove
>> tracking of branches which were dropped in remote, as I think that
>> wildcard refspec does create new branches, but do not delete dropped
>> branches.
>
> "git remote prune origin" should be used to clean up stale
> remote-tracking branches.
"git remote prune <name>" deletes _all_ stale tracking branches
under <name>. With "git branch -d -r <branch>" you can delete
_single_ tracking branch.
>> So I'm not sure if it is a bug, misfeature or a feature.
>
> It doesn't make sense to delete remote-tracking branches
> locally if they are still present at the remote. The main
> purpose of a remote-tracking branch is to be identical to the
> real remote branch.
True, but it would be nice to have an option to _exclude_ some
branches from fetching (for example 'html' and 'man' branches
of git.git), while still picking up new branches automatically
on fetch.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Sergei Organov @ 2007-11-13 17:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0711131600590.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 13 Nov 2007, Sergei Organov wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>> > The wildcard refspec is not documented adequately, so I'm not sure if
>> > adding
>> >
>> > fetch = !refs/heads/pu
>> >
>> > would help, or do you have to replace wildcard refspec by explicit
>> > list of branches you want to fetch.
>>
>> Isn't "git branch -d -r" supposed to do whatever magic is required to
>> get rid of the remote branch?
>
> But it did! You explicitely fetched it _again_!
Sorry, but *I* didn't *explicitly* fetch it _again_!
1. I cloned git.git repo making no custom steps.
2. I decided I don't need to track some of branches.
3. I tried to find in documentation a way to remove remote tracking
branch. I found that 'git branch -d -r' should do it.
4. I used 'git branch -d -r origin/pu' to remove one of remote branches,
-- it succeeded.
5. Some time later I ran 'git fetch', and it's *git fetch* that
*implicitly* fetched it _again_! When I say *implicitly* I mean that
I did nothing to tell 'fetch' to re-create the remote branch.
Please try to look at it from the *user* POV. A poor user that has no
idea how all this is implemented internally and tries to use git
documentation to do things.
--
Sergei.
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Nicolas Pitre @ 2007-11-13 17:34 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Matthieu Moy, Junio C Hamano, Johannes Schindelin, Bill Lear,
Jan Wielemaker, git
In-Reply-To: <20071113100209.GE14735@spearce.org>
On Tue, 13 Nov 2007, Shawn O. Pearce wrote:
> Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> > I repeat the use-case I mentionned above :
> >
> > ,----
> > | a typical use-case is when I want to create a new project. I'd
> > | like to initialize an empty bare repo on my backed up disk, and then
> > | clone it to my local-fast-unreliable disk to get a working copy and do
> > | the first commit there.
> > `----
> >
> > I find this quite natural, and up to now, no one gave me either a
> > rationale not to do that, or a _simple_ way to achieve this. As I
> > said, it's currently not _very_ hard to do, but I have to edit
> > .git/config by hand, while git clone knows how to do this much faster
> > than I for non-empty repositories.
>
> Its a goal to redefine git-clone as the following, as that is
> really all it does:
>
> mkdir foo && cd foo && git init &&
> git remote add -f origin $url &&
> git checkout -b master origin/master
>
> So setting up an empty tree is basically that:
>
> mkdir foo && cd foo && git init &&
> git remote add origin $url
>
> Is that really so difficult? git-clone is a handy crutch for when
> we didn't have things like git-remote. Or remote tracking branches.
> IMHO the above may seem a little low level but it may make it easier
> to teach to newbies. They are more likely to grasp the concept of
> their repository being just like someone else's, and that they can
> track other repositories beyond just their origin.
FWIW all my Git tutorials for $work so far always avoided 'git clone'.
The 'git init' + 'git remote add' + 'git fetch' is what I ask people to
do. It is more obvious to give a good name for the remote repo that
way, and this can be performed into either a new or an existing repo
when the data is related.
Nicolas
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Steffen Prohaska @ 2007-11-13 17:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Sergei Organov, git
In-Reply-To: <200711131703.16357.jnareb@gmail.com>
On Nov 13, 2007, at 5:03 PM, Jakub Narebski wrote:
> Sergei Organov <osv@javad.com> wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>> Sergei Organov wrote:
>
>>>> I want to get rid of origin/pu remote tracking branch. What do I
>>>> do?
>>>> I RTFM git-branch. What does it suggest?
>>>>
>>>> git branch -d -r origin/pu
>>>>
>>>> So far so good. However, it doesn't seem to work in practice:
> [...]
>>>> $ git branch -d -r origin/pu
>>>> Deleted remote branch origin/pu.
>>>> $ git remote show origin
>>>> * remote origin
>>>> URL: git://git.kernel.org/pub/scm/git/git.git
>>>> Remote branch(es) merged with 'git pull' while on branch master
>>>> master
>>>> New remote branches (next fetch will store in remotes/origin)
>>>> pu
>>>> ^^^^^^^^^^^^^^^^^^^ What???
>>>> Tracked remote branches
>>>> html maint man master next todo
>>>
>>> Check out what do you have in .git/config file, in the
>>> [remote "origin"] section. Most probably (if you cloned this
>>> repository using new enough git) you have wildcard refspec there,
>>> which means that git would pick all new branches when
>>> fetching / pulling from given repository.
>>
>> Sure, I've cloned git.git using rather recent git, so .git/config
>> has:
>>
>> fetch = +refs/heads/*:refs/remotes/origin/*
>
> [...]
>> Isn't "git branch -d -r" supposed to do whatever magic is required to
>> get rid of the remote branch? Currently it seems like a bug
>> introduced
>> by addition of wildcards refspecs, right?
>
> No, the '-r' part translates 'pu' into 'refs/remotes/origin/pu', and
> the '-d' option removes branch locally. It is meant I think to remove
> tracking of branches which were dropped in remote, as I think that
> wildcard refspec does create new branches, but do not delete dropped
> branches.
"git remote prune origin" should be used to clean up stale
remote-tracking branches.
BTW, what's the right name for this type of branch.
I found "tracking branch", "remote tracking branch", and
"remote-tracking branch" in the manual. The glossary only
mentions "tracking branch". Or is it a "tracked remote branch"
as the output of "git remote show" suggests. I remember,
there was a lengthy discussion on this issue. Does someone
remember the conclusion?
> So I'm not sure if it is a bug, misfeature or a feature.
It doesn't make sense to delete remote-tracking branches
locally if they are still present at the remote. The main
purpose of a remote-tracking branch is to be identical to the
real remote branch.
In my opinion its a misfeature. "git remote prune" does the
same in a sane way.
Steffen
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Jakub Narebski @ 2007-11-13 16:03 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <87ve86889o.fsf@osv.gnss.ru>
Sergei Organov <osv@javad.com> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Sergei Organov wrote:
>>> I want to get rid of origin/pu remote tracking branch. What do I do?
>>> I RTFM git-branch. What does it suggest?
>>>
>>> git branch -d -r origin/pu
>>>
>>> So far so good. However, it doesn't seem to work in practice:
[...]
>>> $ git branch -d -r origin/pu
>>> Deleted remote branch origin/pu.
>>> $ git remote show origin
>>> * remote origin
>>> URL: git://git.kernel.org/pub/scm/git/git.git
>>> Remote branch(es) merged with 'git pull' while on branch master
>>> master
>>> New remote branches (next fetch will store in remotes/origin)
>>> pu
>>> ^^^^^^^^^^^^^^^^^^^ What???
>>> Tracked remote branches
>>> html maint man master next todo
>>
>> Check out what do you have in .git/config file, in the
>> [remote "origin"] section. Most probably (if you cloned this
>> repository using new enough git) you have wildcard refspec there,
>> which means that git would pick all new branches when
>> fetching / pulling from given repository.
>
> Sure, I've cloned git.git using rather recent git, so .git/config has:
>
> fetch = +refs/heads/*:refs/remotes/origin/*
[...]
> Isn't "git branch -d -r" supposed to do whatever magic is required to
> get rid of the remote branch? Currently it seems like a bug introduced
> by addition of wildcards refspecs, right?
No, the '-r' part translates 'pu' into 'refs/remotes/origin/pu', and
the '-d' option removes branch locally. It is meant I think to remove
tracking of branches which were dropped in remote, as I think that
wildcard refspec does create new branches, but do not delete dropped
branches.
So I'm not sure if it is a bug, misfeature or a feature.
Can anyone better versed in wildcard refspecs speak up, please?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Johannes Schindelin @ 2007-11-13 16:01 UTC (permalink / raw)
To: Sergei Organov; +Cc: Jakub Narebski, git
In-Reply-To: <87ve86889o.fsf@osv.gnss.ru>
Hi,
On Tue, 13 Nov 2007, Sergei Organov wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > The wildcard refspec is not documented adequately, so I'm not sure if
> > adding
> >
> > fetch = !refs/heads/pu
> >
> > would help, or do you have to replace wildcard refspec by explicit
> > list of branches you want to fetch.
>
> Isn't "git branch -d -r" supposed to do whatever magic is required to
> get rid of the remote branch?
But it did! You explicitely fetched it _again_!
Ciao,
Dscho
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Sergei Organov @ 2007-11-13 15:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fhcdpv$9u3$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> [Cc: Sergei Organov <osv@javad.com>, git@vger.kernel.org]
> Please CC git mailing list, git@vger.kernel.org
>
> Sergei Organov wrote:
>
>> Hello,
>>
>> I want to get rid of origin/pu remote tracking branch. What do I do? I
>> RTFM git-branch. What does it suggest?
>>
>> git branch -d -r origin/pu
>>
>> So far so good. However, it doesn't seem to work in practice:
>
>
>> $ git branch -d -r origin/pu
>> Deleted remote branch origin/pu.
>> $ git remote show origin
>> * remote origin
>> URL: git://git.kernel.org/pub/scm/git/git.git
>> Remote branch(es) merged with 'git pull' while on branch master
>> master
>> New remote branches (next fetch will store in remotes/origin)
>> pu
>> ^^^^^^^^^^^^^^^^^^^ What???
>> Tracked remote branches
>> html maint man master next todo
>
> Check out what do you have in .git/config file, in the [remote "origin"]
> section. Most probably (if you cloned this repository using new enough git)
> you have wildcard refspec there, which means that git would pick all new
> branches when fetching / pulling from given repository.
Sure, I've cloned git.git using rather recent git, so .git/config has:
fetch = +refs/heads/*:refs/remotes/origin/*
> The wildcard refspec is not documented adequately, so I'm not sure if
> adding
>
> fetch = !refs/heads/pu
>
> would help, or do you have to replace wildcard refspec by explicit list of
> branches you want to fetch.
Isn't "git branch -d -r" supposed to do whatever magic is required to
get rid of the remote branch? Currently it seems like a bug introduced
by addition of wildcards refspecs, right?
--
Sergei.
^ permalink raw reply
* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: Jakub Narebski @ 2007-11-13 15:38 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <87zlxi88op.fsf@osv.gnss.ru>
Sergei Organov wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Michael Smith wrote:
>>
>>> +You can use the gitlink:git-cherry[1] command to display the commit
>>> +IDs that are only present on your local branch, or only on the remote
>>> +branch, respectively:
>>
>> I think git-cherry is deprecated in favor of "git log --left-right" (with
>> appropriate format, for example '--abbrev-commit --pretty=oneline')
>>
>> BTW. that means that git-cherry can be removed from git-help output,
>> I think.
>
> And from core-tutorial.txt:1567:
>
> 4. Use `git cherry origin` to see which ones of your patches
> were accepted, and/or use `git rebase origin` to port your
> unmerged changes forward to the updated upstream.
>
> ???
On one hand, core-tutorial is old documentation, dating before
--left-right option to git-log.
On the other hand I have forgot that git-cherry does more throghout
checking if patch was accepted upstream (by checking changeset).
Sorry for the noise...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: Sergei Organov @ 2007-11-13 15:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fhcb29$ef$2@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Michael Smith wrote:
>
>> +You can use the gitlink:git-cherry[1] command to display the commit
>> +IDs that are only present on your local branch, or only on the remote
>> +branch, respectively:
>
> I think git-cherry is deprecated in favor of "git log --left-right" (with
> appropriate format, for example '--abbrev-commit --pretty=oneline')
>
> BTW. that means that git-cherry can be removed from git-help output,
> I think.
And from core-tutorial.txt:1567:
4. Use `git cherry origin` to see which ones of your patches
were accepted, and/or use `git rebase origin` to port your
unmerged changes forward to the updated upstream.
???
--
Sergei.
^ permalink raw reply
* Re: The 5th issue of the msysGit Herald
From: Jakub Narebski @ 2007-11-13 15:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, A.J. Rossini
In-Reply-To: <Pine.LNX.4.64.0711131440150.4362@racer.site>
Johannes Schindelin wrote:
> On Tue, 13 Nov 2007, Jakub Narebski wrote:
>
>> Is this info (and previous issues of "msysGit Herald") available
>> somewhere on the net?
>
> Yes. It is on the Wiki, too, and there is the "herald" branch in
> msysgit/historical-msysgit.git on repo.or.cz.
Ah. Yes, it is available at
http://code.google.com/p/msysgit/wiki/MSysGitHerald5
I somehow missed it when searching. Perhaps because MSysGit wiki
FrontPage (Main_Page) is practically nonexistent; it does not contain
links to "msysGit Herald" issues.
Thanks a lot.
P.S. Perhaps this link should be put in the body of msysGit Herald?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Jakub Narebski @ 2007-11-13 14:53 UTC (permalink / raw)
To: git
In-Reply-To: <874pfq9q8s.fsf@osv.gnss.ru>
[Cc: Sergei Organov <osv@javad.com>, git@vger.kernel.org]
Please CC git mailing list, git@vger.kernel.org
Sergei Organov wrote:
> Hello,
>
> I want to get rid of origin/pu remote tracking branch. What do I do? I
> RTFM git-branch. What does it suggest?
>
> git branch -d -r origin/pu
>
> So far so good. However, it doesn't seem to work in practice:
> $ git branch -d -r origin/pu
> Deleted remote branch origin/pu.
> $ git remote show origin
> * remote origin
> URL: git://git.kernel.org/pub/scm/git/git.git
> Remote branch(es) merged with 'git pull' while on branch master
> master
> New remote branches (next fetch will store in remotes/origin)
> pu
> ^^^^^^^^^^^^^^^^^^^ What???
> Tracked remote branches
> html maint man master next todo
Check out what do you have in .git/config file, in the [remote "origin"]
section. Most probably (if you cloned this repository using new enough git)
you have wildcard refspec there, which means that git would pick all new
branches when fetching / pulling from given repository. The wildcard
refspec is not documented adequately, so I'm not sure if adding
fetch = !refs/heads/pu
would help, or do you have to replace wildcard refspec by explicit list of
branches you want to fetch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git 1.5.3.5 error over NFS
From: Bill Lear @ 2007-11-13 14:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071112233309.GI2918@steel.home>
On Tuesday, November 13, 2007 at 00:33:09 (+0100) Alex Riesen writes:
>This is the almost same message I cced to lk and nfs, but with
>Git-interasting parts added.
>
>Bill Lear, Mon, Nov 12, 2007 16:39:15 +0100:
>> On Saturday, November 10, 2007 at 00:21:06 (+0100) Alex Riesen writes:
>> >Bill Lear, Fri, Nov 09, 2007 16:31:39 +0100:
>> >> I've brought this up before, but I don't recall a resolution to it.
>> >>
>> >> We have an NFS-mounted filesystem, and git pull is choking on it.
>> >>
>> >> % uname -a
>> >> Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux
>
>It is a really old kernel... Maybe you could try with some of the
>recent ones?
I'll see if we can: the machine in question is a high security one,
and not easy to change. We haven't seen this sort of problem
elsewhere on our newer systems as far as I know.
>I extend the part you quoted. The file is opened here:
>...
>This is strange. The current git should not produce anything like
>this (and does not, here). ...
You are absolutely correct. My comrade ran this with 1.5.0.1 by
mistake. He reran the strace with 1.5.3.5, and I have replaced
the tarball on my server:
http://www.zopyra.com/~rael/git/git-trace.tar.bz2
With this minor correction (!), here is the last part from
the last file (strace.out.26001):
[...]
write(2, "\n", 1) = 1
write(3, "\335\365\205\262RY\360=^h\357\372\274\374_\177\317\357"..., 3712) = 3712
fstat(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
open("/etc/mtab", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=503, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a955fa000
read(4, "/dev/sda1 / ext3 rw 0 0\nnone /pr"..., 4096) = 503
close(4) = 0
munmap(0x2a955fa000, 4096) = 0
open("/proc/meminfo", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a955fa000
read(4, "MemTotal: 16396892 kB\nMemFre"..., 1024) = 672
close(4) = 0
munmap(0x2a955fa000, 4096) = 0
write(2, "Resolving 562 deltas...\n", 24) = 24
rt_sigaction(SIGALRM, {0x40f610, [], SA_RESTORER|SA_RESTART, 0x32c512e2b0}, NULL, 8) = 0
setitimer(ITIMER_REAL, {it_interval={1, 0}, it_value={1, 0}}, NULL) = 0
pread(3, "", 242, 1268) = 0
write(2, "fatal: ", 7) = 7
write(2, "cannot pread pack file: No such "..., 49) = 49
write(2, "\n", 1) = 1
exit_group(128) = ?
Sorry for the mistake. I think Linus once commented on an alarm
that he found curious in a previous strace I sent for this some
time ago ...
Bill
^ permalink raw reply
* Re: The 5th issue of the msysGit Herald
From: Johannes Schindelin @ 2007-11-13 14:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fhcat4$ef$1@ger.gmane.org>
Hi,
[please Cc: me...]
On Tue, 13 Nov 2007, Jakub Narebski wrote:
> Is this info (and previous issues of "msysGit Herald") available
> somewhere on the net?
Yes. It is on the Wiki, too, and there is the "herald" branch in
msysgit/historical-msysgit.git on repo.or.cz.
Hth,
Dscho
^ permalink raw reply
* Re: [BUG] fast-import producing very deep tree deltas
From: Brian Downing @ 2007-11-13 14:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071113092721.GD14735@spearce.org>
On Tue, Nov 13, 2007 at 04:27:21AM -0500, Shawn O. Pearce wrote:
> Brian, does this fix it?
>
> So if the tree we reloaded was already at the maximum depth we
> wouldn't know it and make the new tree a delta. Multiply the
> number of times the branch cache has to swap out the tree times
> max_depth (10) and you get the maximum delta depth of a tree created
> by fast-import. In Brian's case above the active branch cache had
> to swap the branch out 603/604 times during this import to produce
> a tree with a delta depth of 6035.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
/Much/ better:
git-fast-import statistics:
---------------------------------------------------------------------
Alloc'd objects: 140000
Total objects: 135970 ( 62664 duplicates )
blobs : 42196 ( 13695 duplicates 19898 deltas)
trees : 72143 ( 48969 duplicates 62402 deltas)
commits: 21631 ( 0 duplicates 0 deltas)
tags : 0 ( 0 duplicates 0 deltas)
Total branches: 10 ( 1 loads )
marks: 1048576 ( 63827 unique )
atoms: 18971
Memory total: 8329 KiB
pools: 2860 KiB
objects: 5468 KiB
---------------------------------------------------------------------
pack_report: getpagesize() = 4096
pack_report: core.packedGitWindowSize = 1073741824
pack_report: core.packedGitLimit = 8589934592
pack_report: pack_used_ctr = 273071
pack_report: pack_mmap_calls = 16855
pack_report: pack_open_windows = 50 / 363
pack_report: pack_mapped = 8529277175 / 8589933814
---------------------------------------------------------------------
depths: count 135970 total 380519 min 0 max 10 mean 2.80 median 1 std_dev 3.22
In addition, fast-import ran much (probably 10x) faster and with much less
memory usage (last time it peaked around 1GB):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13098 bdowning 18 0 8223m 34m 6576 R 72 1.7 0:51.44 git-fast-import
Presumably not having to rebuild the root tree object from a hundreds-deep
delta chain many hundreds of times sped things up a bit.
Acked-by: Brian Downing <bdowning@lavos.net>
-bcd
^ permalink raw reply
* [Newbie] How to *actually* get rid of remote tracking branch?
From: Sergei Organov @ 2007-11-13 14:25 UTC (permalink / raw)
To: git
Hello,
I want to get rid of origin/pu remote tracking branch. What do I do? I
RTFM git-branch. What does it suggest?
git branch -d -r origin/pu
So far so good. However, it doesn't seem to work in practice:
$ git --version
git version 1.5.3.4
$ git remote show origin
* remote origin
URL: git://git.kernel.org/pub/scm/git/git.git
Remote branch(es) merged with 'git pull' while on branch master
master
Tracked remote branches
html maint man master next pu todo
$ git branch -d -r origin/pu
Deleted remote branch origin/pu.
$ git remote show origin
* remote origin
URL: git://git.kernel.org/pub/scm/git/git.git
Remote branch(es) merged with 'git pull' while on branch master
master
New remote branches (next fetch will store in remotes/origin)
pu
^^^^^^^^^^^^^^^^^^^ What???
Tracked remote branches
html maint man master next todo
$ git fetch
remote: Generating pack...
remote: Done counting 422 objects.
Result has 281 objects.
remote: Deltifying 281 objects...
remote: 100% (281/281) done
Indexing 281 objects...
remote: Total 281 (delta 206), reused 255 (delta 181)
100% (281/281) done
Resolving 206 deltas...
100% (206/206) done
63 objects were added to complete this thin pack.
* refs/remotes/origin/pu: storing branch 'pu' of git://git.kernel.org/pub/scm/git/git
commit: fc07419
$ git remote show origin
* remote origin
URL: git://git.kernel.org/pub/scm/git/git.git
Remote branch(es) merged with 'git pull' while on branch master
master
Tracked remote branches
html maint man master next pu todo
$
... and I get those origin/pu back?!
What do I do wrong?
--
Sergei.
^ permalink raw reply
* Re: wishlist: git info
From: Jakub Narebski @ 2007-11-13 14:20 UTC (permalink / raw)
To: git
In-Reply-To: <fhbrll$ceq$1@ger.gmane.org>
Jakub Narebski wrote:
> Thomas Neumann wrote:
> You can always write[*1*] git-info.sh or git-info.perl, and install
> it as git-info in your git installation. And send patches here, to git
> mailing list, for comments.
>
> Footnotes:
> ----------
> [*1*] Even if one of the most common complaints is "too many user-visible
> commands".
On the other hand one of the proposed and long requested features is
git-explain, which is meant to show status of git command progress. If you
could incorporate proposed features in git-info (perhaps only with some
option: --state, --explain, -v / --verbose,...) there would be no
complaints about yet another git command.
What git-info / git-explain should show:
* interrupted fetch / fetch in progress
* interrupted pull / pull in progress
* interrupted merge / merge in progress
* interrupted commit, commit --amend, or tag editing
* rebase in progress (including interactive rebase and rebasing
using merge engine)
* git-am (apply mbox) in progress
Perhaps we should also include git-count-objects in git-info, like
git-verify-tag functionality was included in 'git tag --verify'...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: Jakub Narebski @ 2007-11-13 14:07 UTC (permalink / raw)
To: git
In-Reply-To: <11949569992214-git-send-email-msmith@cbnco.com>
Michael Smith wrote:
> +You can use the gitlink:git-cherry[1] command to display the commit
> +IDs that are only present on your local branch, or only on the remote
> +branch, respectively:
I think git-cherry is deprecated in favor of "git log --left-right" (with
appropriate format, for example '--abbrev-commit --pretty=oneline')
BTW. that means that git-cherry can be removed from git-help output,
I think.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: The 5th issue of the msysGit Herald
From: Jakub Narebski @ 2007-11-13 14:04 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711130312180.4362@racer.site>
Johannes Schindelin wrote:
> Good morning git land!
>
> This lovely dark 4am (see http://youtube.com/watch?v=yXi6hg90LUU) is
> as good an occasion as any to offer to you the 5th issue of the
> msysGit Herald, the not-quite-biweekly news letter to keep you
> informed about msysGit, the effort to bring one of the most powerful
> Source Code Management systems to the poor souls stuck with Windows.
Is this info (and previous issues of "msysGit Herald") available somewhere
on the net? And I don't mean here git mailing list archives, or Google
Groups web interface...
Perhaps it is time for git to have besides Git Homepage and Git Wiki also
Git Blog or Git Feed (with announcements, what's in... and herald). What do
you think?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] user-manual: Talk about tracking third-party snapshots
From: Michael Smith @ 2007-11-13 12:29 UTC (permalink / raw)
To: git; +Cc: gitster, Michael Smith
Add some sections about tracking third-party sources to the advanced
branching chapter. This might save some guesswork for tasks like
importing snapshots and tracking local changes.
Signed-off-by: Michael Smith <msmith@cbnco.com>
---
Years of heavy CVS abuse left me partly brain damaged, and some things that
are pretty easy in Git seemed like they should have been more complicated.
Hopefully this should make it painfully obvious how do to the equivalent
of CVS vendor branches.
Documentation/user-manual.txt | 139 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 139 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d99adc6..942f851 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2711,6 +2711,145 @@ gitlink:git-config[1].
See gitlink:git-config[1] for more details on the configuration
options mentioned above.
+[[tracking-sources]]
+Tracking local changes to third-party sources
+---------------------------------------------
+
+[[tracking-sources-git]]
+Tracking changes when the upstream is a Git repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You don't have to do anything special to keep track of your changes to a
+Git project. All you need is a remote tracking branch for the upstream
+repository--either one of the remote branches created by
+gitlink:git-clone[1], or one you created according to
+<<fetching-individual-branches>>.
+
+Given a situation where you've merged the tracking branch's changes into
+your local branch, then made some more changes, as in the diagram below:
+
+................................................
+ o--o--a--c--e--f--g <-- origin/master (remote tracking branch)
+ \ \
+ b--d--m--h--i <-- master
+................................................
+
+You can view all your local changes--b, d, h, and i--with the
+gitlink:git-diff[1] command:
+
+------------------------------------------
+$ git diff origin/master...master
+------------------------------------------
+
+The three-dot `\...` tells gitlink:git-diff[1] to show the changes on the
+master branch since the last common ancestor with origin/master. (If you
+used two dots instead of three, you'd see the entire patch to go from
+origin/master to master, including reversing commits "f" and "g".)
+
+You can use the gitlink:git-cherry[1] command to display the commit
+IDs that are only present on your local branch, or only on the remote
+branch, respectively:
+
+------------------------------------------------
+$ git cherry -v origin/master master
++ 8ed8ff9315e36824e601659b168bbaad5e4d53ca b
++ 2bf7cdf2bef8e6f8b213634ce67dd01cc9e145e0 d
++ 14f97309ca82f742bc42d03fa4619a81973521a9 h
++ 4497730f04ed9849c807f2a5bf8f097f87636d3f i
+$ git cherry -v master origin/master
++ 8cc12a9763279d6f0c913ef47e0a996193aaa1c5 f
++ c793ea90311db286c0e22d227b494f09620aef3d g
+------------------------------------------------
+
+`git show <commit-id>` can display the full log message and patch for you.
+
+[[tracking-sources-snapshots]]
+Tracking changes when the upstream uses snapshots
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To track your changes to projects that aren't using Git, you can commit
+a snapshot or release onto a branch in your repository, then tag it. If
+you are used to vendor branches in CVS, you'll find this is similar,
+although CVS combines the commit, tag, and sometimes merge operations
+into one "import" command. Here's an example:
+
+------------------------------------------------
+$ mkdir project
+$ cd project
+$ git init
+$ cp -a ~/src/project-1.0/* .
+$ git add .
+$ git commit -m "Import Project v1.0"
+$ git tag v1.0
+$ git branch upstream
+------------------------------------------------
+
+Make your changes as usual on the "master" branch, or on topic branches
+that you merge to "master". For the next import, switch to the
+"upstream" branch, commit the new version, then switch back and merge in
+the changes:
+
+------------------------------------------------
+$ git checkout upstream
+$ rm -r *
+$ cp -a ~/src/project-1.1/* .
+ # "git add ." will catch the added and modified files
+$ git add .
+ # the "-a" flag will commit file deletions, too
+$ git commit -a -m "Import Project v1.1"
+$ git tag v1.1
+$ git checkout master
+$ git merge upstream
+------------------------------------------------
+
+If you are publishing your repository, you may also want to push the
+"upstream" branch and your tags.
+
+[[fixing-branch-ancestry]]
+Fixing branch ancestry
+~~~~~~~~~~~~~~~~~~~~~~
+
+Git can only do a sensible merge if it knows about a common ancestor
+between your local changes and the third-party sources. It needs to know
+the commit where your local changes and the third-party sources began to
+diverge--in other words, the last time they were merged. There are some
+cases where Git might not have a record of this merge:
+
+1. You imported CVS or Subversion vendor branch history into Git.
+Sometimes this can produce completely independent master and vendor
+branches with no merging between the two. All the changes are there,
+they just aren't linked by a merge. You can see this in `gitk --all` as
+two parallel development histories.
+2. You've been importing third-party tarballs or snapshots into Git, but
+now the upstream has switched to Git and you want to pull from their new
+repository. As far as Git knows, their branch is completely independent
+from yours, with no common ancestry.
+
+You can fix situations like these by doing a merge that isn't really a
+merge, using the "ours" merge strategy. Look through the history on the
+third-party branch and try to find the exact commit that matches the
+last snapshot you imported. Often there's a tag close to the commit, or
+on the commit, if you're lucky--but don't trust it blindly; check the
+diffs. Check out your local branch and tell Git about the relationship:
+
+------------------------------------------------
+$ git remote add upstreamgit git://upstream.org/project.git
+$ git fetch upstreamgit
+$ git tag
+v1.0
+v1.1
+v1.2
+$ git checkout master
+$ git merge --strategy=ours \
+ -m "Tie old v1.1 into our history by merging with strategy=ours." \
+ v1.1
+------------------------------------------------
+
+You'll see the branches merge together in `gitk --all` or `git
+show-branch master upstreamgit/master`. Now you'll be able to merge any
+changes from the remote branch since v1.1 with `git merge
+upstreamgit/master`.
+
[[git-concepts]]
Git concepts
--
1.5.3.2.102.ge6eb7
^ permalink raw reply related
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Jeff King @ 2007-11-13 11:40 UTC (permalink / raw)
To: Matthieu Moy
Cc: Shawn O. Pearce, Junio C Hamano, Johannes Schindelin, Bill Lear,
Jan Wielemaker, git
In-Reply-To: <vpqpryefmhj.fsf@bauges.imag.fr>
On Tue, Nov 13, 2007 at 11:50:16AM +0100, Matthieu Moy wrote:
> The "git remote add" thing adds this to my .git/config:
>
> [remote "origin"]
> url = /tmp/git1
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> While clone normally does a bit more:
>
> [remote "origin"]
> url = /tmp/git1/.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
Also, git-clone sets up the HEAD symref automagically (you can specify
it manually with git-remote, but git-clone will put it from the remote's
HEAD).
-Peff
^ permalink raw reply
* [PATCH v2 3/3] send-pack: assign remote errors to each ref
From: Jeff King @ 2007-11-13 11:37 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pierre Habouzit, Daniel Barkalow, Alex Riesen
In-Reply-To: <20071113102500.GA2767@sigill.intra.peff.net>
This lets us show remote errors (e.g., a denied hook) along
with the usual push output. There are two drawbacks to this
change:
1. cross-referencing the incoming status with the ref list
is worst case O(n^2) (where n = number of refs); this
can be fixed with a smarter implementation
2. the status parsing is not foolproof. We get a line like
ng refs/heads/master arbitrary msg
which cannot be parsed unambiguously in the face of
refnames with spaces. We do a prefix-match so that
you will only run into problems if you have two refs,
one of which is a prefix match of the other, and the
longer having a space right after the prefix.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-send-pack.c | 44 ++++++++++++++++++++++++++++++++++++++------
cache.h | 2 ++
2 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 5c84766..7d466d9 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -146,14 +146,34 @@ static void get_local_heads(void)
for_each_ref(one_local_ref, NULL);
}
-static int receive_status(int in)
+static void set_ref_error(struct ref *refs, const char *line) {
+ struct ref *ref;
+
+ for (ref = refs; ref; ref = ref->next) {
+ const char *msg;
+ if (prefixcmp(line, ref->name))
+ continue;
+ msg = line + strlen(ref->name);
+ if (*msg++ != ' ')
+ continue;
+ ref->status = REF_STATUS_REMOTE_REJECT;
+ ref->error = xstrdup(msg);
+ ref->error[strlen(ref->error)-1] = '\0';
+ return;
+ }
+}
+
+/* a return value of -1 indicates that an error occurred,
+ * but we were able to set individual ref errors. A return
+ * value of -2 means we couldn't even get that far. */
+static int receive_status(int in, struct ref *refs)
{
char line[1000];
int ret = 0;
int len = packet_read_line(in, line, sizeof(line));
if (len < 10 || memcmp(line, "unpack ", 7)) {
fprintf(stderr, "did not receive status back\n");
- return -1;
+ return -2;
}
if (memcmp(line, "unpack ok\n", 10)) {
fputs(line, stderr);
@@ -171,7 +191,7 @@ static int receive_status(int in)
}
if (!memcmp(line, "ok", 2))
continue;
- fputs(line, stderr);
+ set_ref_error(refs, line + 3);
ret = -1;
}
return ret;
@@ -258,6 +278,12 @@ static void print_push_status(const char *dest, struct ref *refs)
case REF_STATUS_NONFF:
print_ref_status('!', "[rejected]", ref, ref->peer_ref, "non-fast forward");
break;
+ case REF_STATUS_REMOTE_REJECT:
+ if (ref->deletion)
+ print_ref_status('!', "[remote rejected]", ref, NULL, ref->error);
+ else
+ print_ref_status('!', "[remote rejected]", ref, ref->peer_ref, ref->error);
+ break;
case REF_STATUS_OK:
if (ref->deletion)
print_ref_status('-', "[deleted]", ref, NULL, NULL);
@@ -297,6 +323,7 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
int allow_deleting_refs = 0;
int expect_status_report = 0;
int flags = MATCH_REFS_NONE;
+ int ret;
if (args.send_all)
flags |= MATCH_REFS_ALL;
@@ -414,12 +441,15 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
}
close(out);
- print_push_status(dest, remote_refs);
-
if (expect_status_report) {
- if (receive_status(in))
+ ret = receive_status(in, remote_refs);
+ if (ret == -2)
return -1;
}
+ else
+ ret = 0;
+
+ print_push_status(dest, remote_refs);
if (!args.dry_run && remote) {
for (ref = remote_refs; ref; ref = ref->next)
@@ -428,6 +458,8 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
if (!new_refs)
fprintf(stderr, "Everything up-to-date\n");
+ if (ret < 0)
+ return ret;
for (ref = remote_refs; ref; ref = ref->next) {
switch (ref->status) {
case REF_STATUS_NONE:
diff --git a/cache.h b/cache.h
index ca5d96d..082e03b 100644
--- a/cache.h
+++ b/cache.h
@@ -509,7 +509,9 @@ struct ref {
REF_STATUS_NONFF,
REF_STATUS_NODELETE,
REF_STATUS_UPTODATE,
+ REF_STATUS_REMOTE_REJECT,
} status;
+ char *error;
struct ref *peer_ref; /* when renaming */
char name[FLEX_ARRAY]; /* more */
};
--
1.5.3.5.1731.g0763
^ permalink raw reply related
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