* 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: 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: [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: [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: [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: [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: 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: 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: 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: 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: [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: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: 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: 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: 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: 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: [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: 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: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Junio C Hamano @ 2007-11-13 18:41 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Johannes Schindelin, Bill Lear, Jan Wielemaker, git
In-Reply-To: <vpqzlxiiii6.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> To create an initial commit in a bare repository, the most natural way
> for me is to clone it, create the commit in the clone, and then push.
>
> Bare-ness _does_ matter for that.
You are still wrong.
The most natural is to create a commit in a non-bare repository
you create, and push into a bare empty repository. The
repository that is pushed into can be non-bare, but bareness of
that does _NOT_ matter.
Where bareness matters is on your end, the local private
repository you create the initial commit in.
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Sergei Organov @ 2007-11-13 18:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0711131819490.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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.
I think I did my best to try to do that (basing my attempts on current
git documentation). Isn't it?
> But that is different from "I decided to delete the tracking
> _branch_".
Yes, but the question is *why*? Isn't it an obvious application of
deleting tracking branch? And, as I've already asked in another
sub-thread of this one, what the following example in the man git-branch
is supposed to achieve?:
<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>
Sorry, but I still believe that it's not me who needs fixing.
--
Sergei.
^ permalink raw reply
* Re: [PATCH 4/2] Fix parent rewriting in --early-output
From: Junio C Hamano @ 2007-11-13 18:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linus Torvalds, Marco Costalba, Git Mailing List
In-Reply-To: <18233.30098.470244.421468@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> In fact it would be easier for me if, instead of getting the id of
> some random ancestor commit, I got an explicit indication to say
> "unknown parent", such as just a "-" in place of the id of the
> unknown parent(s). Would that be doable? I could then just not do
> the processing for any unknown parent, and make sure to do it when I
> see the final version of the commit.
I suspect that a "-" in place of a commit object name may not be
enough for your purpose, as the _number_ of parents can later
change in the later re-output.
I wonder if the presense of "incomplete" on the "Final output"
line is a good enough indication for that. That is, until you
see "Final output: $N done", you will treat the parent
information as unreliable.
^ permalink raw reply
* Re: The 5th issue of the msysGit Herald
From: Junio C Hamano @ 2007-11-13 18:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fhcat4$ef$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> 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?
I miss the "Kernel Traffic" (and its cousin, the unfortunate
first and only issue of "Git Traffic").
If you are stepping up as the chief "Git Traffic" editor (with
help from others), I'd imagine it would be greatly appreciated
by the community.
I certainly would.
^ permalink raw reply
* Git and Scmbug integration
From: Kristis Makris @ 2007-11-13 19:06 UTC (permalink / raw)
To: git-u79uwXL29TY76Z2rM5mHXA; +Cc: scmbug-users-G8y9j4K4DsPiwOUmbS1EgQ
[-- Attachment #1.1: Type: text/plain, Size: 1002 bytes --]
Hello,
I've been working on adding Git support in Scmbug, a system that
integrates software configuration management with bug-tracking. I've run
across what seem to be limitations in the Git hooks mechanism (at least
in version 1.5.1.3). In particular:
(1)
http://bugzilla.mkgnu.net/show_bug.cgi?id=991
There's no hook that will trigger when a tag is applied.
(2)
http://bugzilla.mkgnu.net/show_bug.cgi?id=992
Git does not offer metadata describing a change on the commit trigger
The commit trigger seems to be "post-commit" but it supplies no arguments. The
"update" trigger supplies a lot of information but that's only triggered when
changes are published to a remote repository.
I could not find a way to extract this information from what I've read in:
http://www.kernel.org/pub/software/scm/git/docs/hooks.html
Are there plans to implement these hooks ? Or, could someone help me
understand how to extract such information ?
Thanks,
Kristis
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
scmbug-users mailing list
scmbug-users-G8y9j4K4DsPiwOUmbS1EgQ@public.gmane.org
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
^ permalink raw reply
* Re: [PATCH/RFC 1/3] send-pack: track errors for each ref
From: Alex Riesen @ 2007-11-13 19:04 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Pierre Habouzit, Daniel Barkalow
In-Reply-To: <20071113102709.GA2905@sigill.intra.peff.net>
Jeff King, Tue, Nov 13, 2007 11:27:09 +0100:
> diff --git a/cache.h b/cache.h
> index 5f40e12..ca5d96d 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -499,8 +499,17 @@ struct ref {
> struct ref *next;
> unsigned char old_sha1[20];
> unsigned char new_sha1[20];
> - unsigned char force;
> - unsigned char merge;
> + unsigned char force : 1;
> + unsigned char merge : 1;
> + unsigned char nonff : 1;
unsigned char fastforward : 1; ? ffwd?
> + unsigned char deletion : 1;
> + enum {
> + REF_STATUS_NONE = 0,
> + REF_STATUS_OK,
> + REF_STATUS_NONFF,
isn't it a duplication of nonff?
^ permalink raw reply
* Re: wishlist: git info
From: Junio C Hamano @ 2007-11-13 19:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Neumann, git
In-Reply-To: <Pine.LNX.4.64.0711131111220.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 13 Nov 2007, Thomas Neumann wrote:
>
>> Perhaps also project description (if it exists?) one can specify a
>> project description? I did not even know this. But yes, this would be
>> useful, too. In general I think git info should show everything to
>> quickly understand what is currently checked out.
>
> Is slightly troubles me that you put so much emphasis on what I would call
> "remote information". I understand that in svn, your working directory
> without the server is not very useful. But we do not have that problem.
I mildly disagree.
Exactly because you can do so much more in isolation than with
other systems like SVN, I tend to think that you would want to
know what "git remote show" gives you, and a lot more (e.g. what
"git shortlog origin@{1}..origin" would give you if you were to
fetch now). You can deviate from the others quite a lot without
synchronizing, because git allows you to do so very easily, and
I can understand that some people will find it scary when it
comes to the point to synchronize with the others.
A stronger support to learn "what happened there while I was
looking the other way" would be a definite plus.
But "project description"? Give me a break. If you have cloned
the repository (or learned the existence of repository), you
already learned from elsewhere what the project is about.
I haven't spoken in this thread because honestly I found most of
the things mentioned here were totally uninteresting.
^ 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