* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Steffen Prohaska @ 2007-11-13 18:39 UTC (permalink / raw)
To: <osv@javad.com>; +Cc: Jakub Narebski, git
In-Reply-To: <87d4ue81tv.fsf@osv.gnss.ru>
On Nov 13, 2007, at 6:58 PM, <osv@javad.com> <osv@javad.com> wrote:
>>>> 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.
Yes, it is useless. The man page should be fixed.
Steffen
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Johannes Schindelin @ 2007-11-13 18:21 UTC (permalink / raw)
To: Sergei Organov; +Cc: Jakub Narebski, git
In-Reply-To: <87prye832v.fsf@osv.gnss.ru>
Hi,
On Tue, 13 Nov 2007, Sergei Organov wrote:
> Sorry, but *I* didn't *explicitly* fetch it _again_!
>
> 1. I cloned git.git repo making no custom steps.
Which means that you wanted to track that repository. Yes, the complete
repository. Not a single branch. Not all branches except a single one.
> 2. I decided I don't need to track some of branches.
The you should have done that. But that is different from "I decided to
delete the tracking _branch_".
Ciao,
Dscho
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Lars Hjemli @ 2007-11-13 18:17 UTC (permalink / raw)
To: osv; +Cc: Jakub Narebski, Steffen Prohaska, git
In-Reply-To: <87d4ue81tv.fsf@osv.gnss.ru>
On Nov 13, 2007 6:58 PM, <osv@javad.com> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> > Steffen Prohaska wrote:
> >> 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?
I understand that the man-page could be confusing, the problem is that
these examples are quite old: they made more sense when git didn't
support wildcards in refspecs.
You want an easy way to tell git to stop tracking the pu-branch. This
can be achieved by editing the [remote "origin"] section in
.git/config: remove the fetch-line containing refs/heads/* and add one
fetch line for each ref you'd like to track. But beware that you have
to add any new branches which you would like to track in the same way
(editing .git/config).
The reason git-branch -d -r doesn't do this automatically is probably
that nobody has seen a need for it to do so...
--
larsh
^ permalink raw reply
* 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
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