* 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
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Sergei Organov @ 2007-11-13 18:59 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jakub Narebski, Steffen Prohaska, git
In-Reply-To: <8c5c35580711131017p451f831bqd928ef033c9a0e98@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> 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.
Yeah, I understand that. But there doesn't seem to be actual reason not
to support them even with wildcards support.
> 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).
Thanks, I got it. Though the last sentence makes it less useful then it
should be. [This somewhat reminds me CVS problems when you can delete
directories that you don't want, and checkout won't restore them
(without special switch), but then you won't automatically get new
directories :( Though admittedly the situation with the remote-tracking
branches is less annoying.]
>
> The reason git-branch -d -r doesn't do this automatically is probably
> that nobody has seen a need for it to do so...
Me thinks it has probably been just overlooked when wildcards were
added. Anyway, either documentation or git-branch -d -r should be fixed,
I think.
--
Sergei.
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Junio C Hamano @ 2007-11-13 19:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jon Smirl, Jeff King, Johannes Schindelin, Git Mailing List
In-Reply-To: <vpq3avah3r0.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> "Jon Smirl" <jonsmirl@gmail.com> writes:
>
>> Execute bit was not set. I just set it for all the scripts. +x is not
>> getting turned on with a default git init-db. I just made a new repo
>> to check, no +x on the scripts.
>
> That's by design: "git init" gives you _example_ hooks, but they won't
> run until you activate them explicitely with the appropriate chmod.
>
> That said, I'm not sure there's a really good reason not to run
> update-server-info by default on push. It doesn't cost much and saves
> a lot of troubles for beginners. Perhaps there are cases where the
> performance cost is non-negligible.
One incarnation of u-s-i we had in the past was quite a lot more
expensive, but we discarded the complexity, so I'd agree it
won't cost much in the current shape now.
The expensive one tried to record information to help dumb
transports better, such as "if you have this revision then you
do not have to fetch that pack but instead fetch this", as we
were discussing packs that have objects from duplicated,
staggered ranges. The idea did not quite pan out.
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Jakub Narebski @ 2007-11-13 19:17 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <87lk9282nr.fsf@osv.gnss.ru>
Sergei Organov wrote:
> 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:
[...]
>>> 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?
Once more, with feeling.
By default now git creates on clone the configuration which essentially
says to fetch (get) all "proper" branches the remote has. (By "proper"
I mean branches residing under 'refs/heads/'). That is what the wildcard
spec above says.
Now when the remote repository dropped some branch (branch was deleted
on remote), te corresponding local tracking branch (in
'refs/remotes/origin') does not get deleted.
You can delete _all_ "stale" tracking branches, which means deleting
all tracking branches for which corresponding tracked branches were
deleted on remote. Or you can delete _one_ specified tracking branch
using "git branch -r -d".
Note that you told git to delete tracking branch, not to stop tracking
all branches in remote (as in above wildcard regexp), or stop tracking
some branch (the configuration earlier version of git created on clone,
without wildcard pathspec). So when you ask git to fetch from remote
again, it happily re-creates deleted branch. Note also that git *cannot*
distinguish (yet) between newly created branch on remote, and branch
which tracking branch you have deleted, either by accident or on purpose.
As to documentation: <tongue in cheek> if you cannot distinguish
between tracking branch and tracked branch then it is your damn fault
;-PPPP </tongue in cheek>
Analogy: if you delete file in working area (git branch -d -r), and
checkout again (git fetch), the file will be resurected.
>> 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!
I'm most interested if "fetch = !refs/heads/branch" or
"fetch = -refs/heads/branch" works as a way to specify exclusions
from refspec.
P.S. Solution would be to use git-remote or ls-remote and some magic
to generate full list of refspecs instead of wildcard refspec.
P.P.S. We used to have similar problem with the introduction of
wildcard refspec, namely: which branch from all fetched to merge :-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: The 5th issue of the msysGit Herald
From: Jakub Narebski @ 2007-11-13 19:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ikmt1md.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> 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.
...and a buckefull of time, please...
What I meant to have on blog, or rather in feed was those "What's in...",
"What's cooking...", "[ANNOUNCE]..." and "msysGit Herald" posts, not
git traffic digest. Because while I think first can be automated and
does not need manual intervention, doing the digest... well...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: wishlist: git info
From: Thomas Neumann @ 2007-11-13 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v3avat147.fsf@gitster.siamese.dyndns.org>
> 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.
well, not that I asked for the project description, but I see a small
benefit there. The point is not to know what the project is about. You
know, after all you checked it out in the first place. My goal is to
quickly/easily see "what is in this directory".
Perhaps my usage pattern is obscure, but I have something like 40
repositories checked out in different directories, and I sometimes loose
track of what actually is in a certain directory (and in what state). A
simple "ls" is not enough, as some of them look very similar on the top
level. Hence my interest for "git info".
> I haven't spoken in this thread because honestly I found most of
> the things mentioned here were totally uninteresting.
sorry for this. While I find it useful, this is certainly not an
important feature, and I can mimic it now myself.
Thomas
^ permalink raw reply
* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: Junio C Hamano @ 2007-11-13 19:25 UTC (permalink / raw)
To: Michael Smith; +Cc: git
In-Reply-To: <11949569992214-git-send-email-msmith@cbnco.com>
Michael Smith <msmith@cbnco.com> writes:
> +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`.
> +
This would work only when your 'master' happens to be at v1.1
(and identical to it) isn't it? Which means that as an example
it will be of very limited scope.
People would want to know "But my 'master' is _not_ at v1.1 but
is _based_ on v1.1. How would I handle that case?" and the
above does not answer that question.
Even worse, most people are probably not careful enough to ask
the above question, but just say "Heh, my 'master' is based on
v1.1, so I'll blindly follow that example to bind the histories
together".
I did not find any technical problem in the other parts of your
description, but I did not read the resulting document from
cover to cover, so I do not know if your change fits in the
entire organization of the document very well.
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Jon Smirl @ 2007-11-13 19:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Jeff King, Johannes Schindelin, Git Mailing List
In-Reply-To: <7vy7d2rmb8.fsf@gitster.siamese.dyndns.org>
On 11/13/07, Junio C Hamano <gitster@pobox.com> wrote:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
> > "Jon Smirl" <jonsmirl@gmail.com> writes:
> >
> >> Execute bit was not set. I just set it for all the scripts. +x is not
> >> getting turned on with a default git init-db. I just made a new repo
> >> to check, no +x on the scripts.
> >
> > That's by design: "git init" gives you _example_ hooks, but they won't
> > run until you activate them explicitely with the appropriate chmod.
> >
> > That said, I'm not sure there's a really good reason not to run
> > update-server-info by default on push. It doesn't cost much and saves
> > a lot of troubles for beginners. Perhaps there are cases where the
> > performance cost is non-negligible.
>
> One incarnation of u-s-i we had in the past was quite a lot more
> expensive, but we discarded the complexity, so I'd agree it
> won't cost much in the current shape now.
>
> The expensive one tried to record information to help dumb
> transports better, such as "if you have this revision then you
> do not have to fetch that pack but instead fetch this", as we
> were discussing packs that have objects from duplicated,
> staggered ranges. The idea did not quite pan out.
Could we add an alternates entry on the server that would cause the
client to first go fetch all objects the alternate has, then come back
and fetch from the initial server with a normal fetch? It's like a URL
redirect. You wouldn't fetch heads or tags from the alternate, just
all of the objects.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Jakub Narebski @ 2007-11-13 19:33 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910711131127i15fb1e41g54752bc10bb28239@mail.gmail.com>
Jon Smirl wrote:
> Could we add an alternates entry on the server that would cause the
> client to first go fetch all objects the alternate has, then come back
> and fetch from the initial server with a normal fetch? It's like a URL
> redirect. You wouldn't fetch heads or tags from the alternate, just
> all of the objects.
objects/info/git-alternates, similar to objects/info/http-alternates?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Update the tracking references only if they were succesfully updated on remote
From: Alex Riesen @ 2007-11-13 19:47 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20071113075240.GA21799@sigill.intra.peff.net>
Jeff King, Tue, Nov 13, 2007 08:52:40 +0100:
> On Mon, Nov 12, 2007 at 10:39:38PM +0100, Alex Riesen wrote:
>
> > It fixes the bug where local tracing branches were filled with zeroed SHA-1
> > if the remote branch was not updated because, for instance, it was not
> > an ancestor of the local (i.e. had other changes).
> >
> > Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> > ---
> >
> > Jeff, I think your change (334f4831e5a77) was either not complete or
> > got broken some time later.
>
> Yes, some of the error information placed in 'ret' was getting lost.
> Daniel and I discussed some fixes, but haven't done a final patch yet.
> Your patch doesn't work because the assumption that
> is_null_sha1(refs->new_sha1) signals error is not correct. This is also
> the case for deleted refs, which means that we are failing to update
> tracking branches for successfully deleted refs.
Yep. I extended the test with this case, checking for deletion of the
remote reference and its tracking reference. Will send it separetely.
The mainline fails the second test, my patch the third (first being
the test setup).
> I'd like to have a patch that accurately tracks per-ref errors,
> including ones from the remote. That not only will give us more accurate
> status reporting, but fixes like this will be much easier. Let me see if
> I can put something together.
I actually started almost like that: by placing an error bit in struct
ref. But than it looked like new_sha1 was just not updated for not
sent references, and the deleted ref are checked if their
peer_ref->new_sha1 is null_sha1.
Date: Mon, 12 Nov 2007 17:09:24 +0100
Subject: [PATCH] Do not update the tracking references if they could not be updated on remote
---
cache.h | 5 +++--
send-pack.c | 20 +++++++++++++-------
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/cache.h b/cache.h
index f0a25c7..081b697 100644
--- a/cache.h
+++ b/cache.h
@@ -493,8 +493,9 @@ 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 failed:1;
struct ref *peer_ref; /* when renaming */
char name[FLEX_ARRAY]; /* more */
};
diff --git a/send-pack.c b/send-pack.c
index b74fd45..c7a4c0e 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -196,8 +196,8 @@ static void update_tracking_ref(struct remote *remote, struct ref *ref)
return;
if (!remote_find_tracking(remote, &rs)) {
- fprintf(stderr, "updating local tracking ref '%s'\n", rs.dst);
- if (is_null_sha1(ref->peer_ref->new_sha1)) {
+ fprintf(stderr, "updating local tracking ref '%s' with %s\n", rs.dst, sha1_to_hex(ref->new_sha1));
+ if (is_null_sha1(ref->new_sha1)) {
if (delete_ref(rs.dst, NULL))
error("Failed to delete");
} else
@@ -211,6 +211,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
{
struct ref *ref;
int new_refs;
+#define REF_NOT_UPTODATE (-3)
int ret = 0;
int ask_for_status_report = 0;
int allow_deleting_refs = 0;
@@ -246,6 +247,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
for (ref = remote_refs; ref; ref = ref->next) {
char old_hex[60], *new_hex;
int will_delete_ref;
+ ref->failed = 0;
if (!ref->peer_ref)
continue;
@@ -253,6 +255,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
will_delete_ref = is_null_sha1(ref->peer_ref->new_sha1);
if (will_delete_ref && !allow_deleting_refs) {
+ ref->failed = 1;
error("remote does not support deleting refs");
ret = -2;
continue;
@@ -297,13 +300,12 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
* commits at the remote end and likely
* we were not up to date to begin with.
*/
+ ref->failed = 1;
error("remote '%s' is not an ancestor of\n"
- " local '%s'.\n"
- " Maybe you are not up-to-date and "
- "need to pull first?",
+ " local '%s'",
ref->name,
ref->peer_ref->name);
- ret = -2;
+ ret = REF_NOT_UPTODATE;
continue;
}
}
@@ -337,6 +339,9 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
}
}
+ if (ret == REF_NOT_UPTODATE)
+ fprintf(stderr, "\nMaybe you are not up-to-date and need to pull first?\n\n");
+
packet_flush(out);
if (new_refs && !dry_run)
ret = pack_objects(out, remote_refs);
@@ -349,7 +354,8 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
if (!dry_run && remote && ret == 0) {
for (ref = remote_refs; ref; ref = ref->next)
- update_tracking_ref(remote, ref);
+ if (!ref->failed)
+ update_tracking_ref(remote, ref);
}
if (!new_refs && ret == 0)
--
1.5.3.5.668.g22088
^ permalink raw reply related
* [PATCH] Add a test for deleting remote branches
From: Alex Riesen @ 2007-11-13 19:49 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20071113194731.GC3268@steel.home>
Check if the tracking and the remote branches are both actually deleted.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
As promised.
t/t5404-tracking-branches.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
index 20718d4..f55143a 100755
--- a/t/t5404-tracking-branches.sh
+++ b/t/t5404-tracking-branches.sh
@@ -10,6 +10,7 @@ test_expect_success 'setup' '
git commit -m 1 &&
git branch b1 &&
git branch b2 &&
+ git branch b3 &&
git clone . aa &&
git checkout b1 &&
echo b1 >>file &&
@@ -19,6 +20,8 @@ test_expect_success 'setup' '
git commit -a -m b2
'
+start_dir="$(pwd)"
+
test_expect_success 'check tracking branches updated correctly after push' '
cd aa &&
b1=$(git rev-parse origin/b1) &&
@@ -37,4 +40,17 @@ test_expect_success 'check tracking branches updated correctly after push' '
test "$(git rev-parse origin/b2)" = "$b2"
'
+test_expect_success 'delete remote branch' '
+ git push origin :refs/heads/b3 &&
+ {
+ git rev-parse origin/b3 --
+ test $? != 0
+ } &&
+ cd "$start_dir" &&
+ {
+ git rev-parse refs/heads/b3 --
+ test $? != 0
+ }
+'
+
test_done
--
1.5.3.5.668.g22088
^ permalink raw reply related
* Re: wishlist: git info
From: Andreas Ericsson @ 2007-11-13 19:49 UTC (permalink / raw)
To: Thomas Neumann; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <4739F9F7.20407@users.sourceforge.net>
Thomas Neumann wrote:
>> 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.
> well, not that I asked for the project description, but I see a small
> benefit there. The point is not to know what the project is about. You
> know, after all you checked it out in the first place. My goal is to
> quickly/easily see "what is in this directory".
>
> Perhaps my usage pattern is obscure, but I have something like 40
> repositories checked out in different directories, and I sometimes loose
> track of what actually is in a certain directory (and in what state). A
> simple "ls" is not enough, as some of them look very similar on the top
> level. Hence my interest for "git info".
>
I had that problem too, until I realized that what I really needed was to
clone repos out with the same careful structure we're using on the server,
and then just use \w instead of \W in my $PS1.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Brian Gernhardt @ 2007-11-13 19:50 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 Nov 13, 2007, at 5:50 AM, Matthieu Moy wrote:
> 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
But how is clone expected to do that when the origin is an empty
repo? There is no branch for it to track, and automagically setting
it to master is bogus because then it's tracking something that
doesn't exist.
The easy way to set up the last bit is "git checkout -b master --track
origin/master". But that won't work if origin/master doesn't exist.
The following will always work:
git config branch.master.remote origin
git config branch.master.merge refs/heads/master
But asking git-clone do do this sort of odd magic for an empty repo is
dubious at best. Perhaps convenient for your situation, but creates
repos that don't actually work. (Will give errors when trying to
merge a non-existent branch, at the very least.)
~~ Brian
^ permalink raw reply
* [PATCH] core-tutorial.txt: Fix argument mistake in an example.
From: Sergei Organov @ 2007-11-10 13:17 UTC (permalink / raw)
To: git; +Cc: gitster
One of examples has wrong output given the arguments provided.
Fix arguments to match the output.
Fix a minor syntax mistake in another place.
Signed-off-by: Sergei Organov <osv@javad.com>
---
Documentation/core-tutorial.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 401d1de..d611854 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -1152,7 +1152,7 @@ back to the earlier repository with "hello" and "example" file,
and bring ourselves back to the pre-merge state:
------------
-$ git show-branch --more=3 master mybranch
+$ git show-branch --more=2 master mybranch
! [master] Merge work in mybranch
* [mybranch] Merge work in mybranch
--
@@ -1215,7 +1215,7 @@ $ git-read-tree -m -u $mb HEAD mybranch
This is the same `git-read-tree` command we have already seen,
but it takes three trees, unlike previous examples. This reads
the contents of each tree into different 'stage' in the index
-file (the first tree goes to stage 1, the second stage 2,
+file (the first tree goes to stage 1, the second -- to stage 2,
etc.). After reading three trees into three stages, the paths
that are the same in all three stages are 'collapsed' into stage
0. Also paths that are the same in two of three stages are
--
1.5.3.4
^ permalink raw reply related
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Andreas Ericsson @ 2007-11-13 20:01 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Jakub Narebski, 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:
>>> 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?
>
It seems we agreed to disagree. However, a "tracked remote branch"
is definitely not in your local repo. I think remote-tracking branch
grammatically is the most correct, as that's the only non-ambiguous
form (remote tracking branch might mean "remote tracking-branch" or
"remote-tracking branch"). It's also the only form that works when
used with "local" in front of it. "Tracked remote branch" will
always be a "remote branch", no matter how you prefix it.
I hate that part of git nomenclature with a passion. It's ambiguous
at best and, as a consequence, downright wrong for some uses.
>
>> 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.
>
Yes, but it does make sense to say "I no longer want to track that
remote branch". If that should be implied by the user deleting its
local counterpart is, I think, what this discussion is about.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] git-remote.txt: fix typo
From: Sergei Organov @ 2007-11-13 18:17 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Sergei Organov <osv@javad.com>
---
Documentation/git-remote.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 027ba11..0da8704 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -79,7 +79,7 @@ caution.
Fetch updates for a named set of remotes in the repository as defined by
remotes.<group>. If a named group is not specified on the command line,
the configuration parameter remotes.default will get used; if
-remotes.default is not defined, all remotes which do not the
+remotes.default is not defined, all remotes which do not have the
configuration parameter remote.<name>.skipDefaultUpdate set to true will
be updated. (See gitlink:git-config[1]).
--
1.5.3.4
^ permalink raw reply related
* [PATCH] user-manual.txt: fix a few mistakes
From: Sergei Organov @ 2007-11-13 18:19 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Sergei Organov <osv@javad.com>
---
Documentation/user-manual.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d99adc6..a169ef0 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -475,7 +475,7 @@ Bisecting: 3537 revisions left to test after this
If you run "git branch" at this point, you'll see that git has
temporarily moved you to a new branch named "bisect". This branch
points to a commit (with commit id 65934...) that is reachable from
-v2.6.19 but not from v2.6.18. Compile and test it, and see whether
+"master" but not from v2.6.18. Compile and test it, and see whether
it crashes. Assume it does crash. Then:
-------------------------------------------------
@@ -1367,7 +1367,7 @@ If you make a commit that you later wish you hadn't, there are two
fundamentally different ways to fix the problem:
1. You can create a new commit that undoes whatever was done
- by the previous commit. This is the correct thing if your
+ by the old commit. This is the correct thing if your
mistake has already been made public.
2. You can go back and modify the old commit. You should
@@ -1567,8 +1567,8 @@ old history using, for example,
$ git log master@{1}
-------------------------------------------------
-This lists the commits reachable from the previous version of the head.
-This syntax can be used to with any git command that accepts a commit,
+This lists the commits reachable from the previous version of the branch.
+This syntax can be used with any git command that accepts a commit,
not just with git log. Some other examples:
-------------------------------------------------
--
1.5.3.4
^ permalink raw reply related
* [PATCH 02/11] t7501-commit.sh: Not all seds understand option -i
From: Johannes Sixt @ 2007-11-13 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1194984306-3181-2-git-send-email-johannes.sixt@telecom.at>
Use mv instead.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
t/t7501-commit.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 4dc35bd..38db2f2 100644
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -69,7 +69,8 @@ test_expect_success \
cat >editor <<\EOF
#!/bin/sh
-sed -i -e "s/a file/an amend commit/g" $1
+sed -e "s/a file/an amend commit/g" < $1 > $1-
+mv $1- $1
EOF
chmod 755 editor
@@ -88,7 +89,8 @@ test_expect_success \
cat >editor <<\EOF
#!/bin/sh
-sed -i -e "s/amend/older/g" $1
+sed -e "s/amend/older/g" < $1 > $1-
+mv $1- $1
EOF
chmod 755 editor
--
1.5.3.5.1592.g0d6db
^ 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