* Re: Git shouldn't allow to push a new branch called HEAD
From: Junio C Hamano @ 2011-11-14 20:22 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Haggerty, Daniele Segato, Git Mailing List
In-Reply-To: <20111114111659.GC10847@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So one solution is to block fetching of remote branches called HEAD
> (which I would be OK with). But another is...
> ... Obviously there's a lot more to it than just tweaking the default fetch
> refspecs. The ref lookup rules need to be changed to take this into
> account. There was some discussion about this over the summer (under the
> subject of possible "1.8.0" changes), but I don't think any work has
> been done.
I would say discussing and ironing out the kinks of the design counts as
work, but I agree nobody was seriously interested in laying out a sensible
transition plan and discussion died out before anything concrete happened.
Regardless of the layout chanage, which probably is a 2.X topic, I think a
good first step would be to start forbidding anything that ends with _?HEAD
as a branch or tag name, on top of Michael's "enforce the refname rules more
vigorously when a ref is created" series.
^ permalink raw reply
* Re: [RFC] deprecating and eventually removing "git relink"?
From: Junio C Hamano @ 2011-11-14 20:18 UTC (permalink / raw)
To: Jeff King; +Cc: Simon Brenner, git
In-Reply-To: <20111114103451.GA10847@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Nov 14, 2011 at 09:48:07AM +0100, Simon Brenner wrote:
>
>> On Mon, Nov 14, 2011 at 7:06 AM, Miles Bader <miles@gnu.org> wrote:
>> > It might be nice to have a mechanism where new objects would update
>> > the _alternate_ rather than the object-store in the tree where the
>> > command was run... then you could easily have a bunch of trees using a
>> > central object store without needing to update the central store
>> > occasionally by hand (and do gc in its "clients")...
>>
>> This sounds like a nice way forward: replace/extend the current
>> alternates system ...
>
> Yes, I think that is sensible. I'm not sure there is even any core git
> code to be written. I think a wrapper that does the following would
> probably work:
I agree with your outline, which I find is in line with what I had in mind
in the message Miles responded.
The approach is different from what Miles alluded to, which is to have
"clients" create objects in the "central" place in the first place,
though.
^ permalink raw reply
* Re: Repository data loss in fast-export with a merge of a deleted submodule
From: Jens Lehmann @ 2011-11-14 19:51 UTC (permalink / raw)
To: Joshua Jensen; +Cc: git@vger.kernel.org, Elijah Newren, Johannes Sixt
In-Reply-To: <4EC12E8B.3050909@workspacewhiz.com>
Am 14.11.2011 16:06, schrieb Joshua Jensen:
> ----- Original Message -----
> From: Joshua Jensen
> Date: 11/3/2011 10:05 AM
>> ----- Original Message -----
>> From: Joshua Jensen
>> Date: 10/27/2011 1:27 PM
>>> We had a submodule that we deleted and then added back into the repository at the same location as the former submodule. When running fast-export, the newly 'added' files for the merge commit are listed and then are followed with a:
>>>
>>> M ... path/to/submodule/file
>>> D path/to/submodule
>>>
>>> On fast-import, the resultant repository becomes corrupt due to the Delete instruction above occurring AFTER the file adds/modifications. The new repository does not match the old repository where the fast-export was performed.
>>>
>>> I am not familiar with the fast-export code. Can anyone help out?
>> Okay, I looked into this further, and I came up with a patch that works for me. Nevertheless, I do not understand exactly what is going on here, so I would like to defer to someone else's patch to fix the issue.
>>
> Hi.
>
> __This is a genuine data loss problem in Git.__
>
> I'm confused at the lack of response to this. I first posted about the issue **2-1/2 weeks ago**, and there have been no responses Does no one care?
Maybe no one cares, people didn't read the message (or forgot about it)
or they are too busy ... thanks for prodding us again.
While I'm interested in this issue because submodules are affected, I'm
very short on Git time these days and can't investigate this issue
further (and I have no clue about export/import either). I added the last
two people who touched depth_first() in builtin/fast-export.c to the CC,
maybe they can tell us more about your patch to solve this issue (found
in [2]).
> In case no one received the messages, you can find them at [1] and [2].
>
> -Josh
>
> [1] http://www.spinics.net/lists/git/msg168295.html
> [2] http://www.spinics.net/lists/git/msg168691.html
^ permalink raw reply
* Re: Git: Unexpected behaviour?
From: Martin von Zweigbergk @ 2011-11-14 17:20 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J.V.
In-Reply-To: <7vlirlp1y6.fsf@alter.siamese.dyndns.org>
On Sat, Nov 12, 2011 at 11:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "J.V." <jvsrvcs@gmail.com> writes:
>
>> OK so "work tree" is a new term for me. I thought we were in isolated
>> sandboxes called "branches" and changes made in a branch would stay in
>> that branch regardless.
>
> Do not think of "branches" as isolated _sandboxes_.
>
> Rather, "branches" are where the independent states are to be _recorded_.
I think I was confused about this when learning Git too. I friend of
mine made the following argument, which I agree with and which I haven
seen on the list before:
Either you want the modifications to stay on the branch, or you want
them to carry over to the branch you are checking out. In the former
case, you would want Git to fail if there are modifications (that you
might have forgotten you made). In the latter case, you would want
"git checkout -m". The current behavior is somewhere in between. It is
not clear to me if there is a use case where the current behavior is
better (from the user's point of view) than either failing or
"checkout -m".
It is obviously too late to change this now, though.
Martin
^ permalink raw reply
* Re: Compile warnings
From: Ævar Arnfjörð Bjarmason @ 2011-11-14 16:58 UTC (permalink / raw)
To: Frans Klaver; +Cc: git@vger.kernel.org
In-Reply-To: <op.v4xyekju0aolir@keputer>
On Mon, Nov 14, 2011 at 15:55, Frans Klaver <fransklaver@gmail.com> wrote:
> Every now and then I see an 'unused result' warning come by during building.
> What is the general attitude towards these warnings? Remove them (by
> properly checking)? Or leave them be as a kind of documentation -- we know
> we're ignoring the info, but it's good to be reminded?
Under what OS / version and compiler / version and what's the warning?
Paste the full warning(s) you get verbatim.
^ permalink raw reply
* Re: feature request: git annotate -w like git blame -w
From: Raoul Bhatia [IPAX] @ 2011-11-14 16:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3sjlun4o9.fsf@localhost.localdomain>
On 2011-11-11 14:57, Jakub Narebski wrote:
> "Raoul Bhatia [IPAX]"<r.bhatia@ipax.at> writes:
>
>> is it possible to add a "git annotate -w" option like git blame has?
>
> Why not use "git blame -c -w"? `-c' turns on annotate-compatibile
> output.
>
> From git-annotate(1) manpage:
>
> The only difference between this command and git-blame(1) is that they use
> slightly different output formats, and this command exists only for back-
> ward compatibility to support existing scripts, and provide a more familiar
> command name for people coming from other SCM systems.
thanks for this clarification. somehow, i missed this part while
scanning the man pages.
thank you and sorry for the noise!
raoul
--
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc. email. r.bhatia@ipax.at
Technischer Leiter
IPAX - Aloy Bhatia Hava OG web. http://www.ipax.at
Barawitzkagasse 10/2/2/11 email. office@ipax.at
1190 Wien tel. +43 1 3670030
FN 277995t HG Wien fax. +43 1 3670030 15
____________________________________________________________________
^ permalink raw reply
* Re: Repository data loss in fast-export with a merge of a deleted submodule
From: Joshua Jensen @ 2011-11-14 15:06 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <4EB2BBB5.3030908@workspacewhiz.com>
----- Original Message -----
From: Joshua Jensen
Date: 11/3/2011 10:05 AM
> ----- Original Message -----
> From: Joshua Jensen
> Date: 10/27/2011 1:27 PM
>> We had a submodule that we deleted and then added back into the
>> repository at the same location as the former submodule. When
>> running fast-export, the newly 'added' files for the merge commit are
>> listed and then are followed with a:
>>
>> M ... path/to/submodule/file
>> D path/to/submodule
>>
>> On fast-import, the resultant repository becomes corrupt due to the
>> Delete instruction above occurring AFTER the file
>> adds/modifications. The new repository does not match the old
>> repository where the fast-export was performed.
>>
>> I am not familiar with the fast-export code. Can anyone help out?
> Okay, I looked into this further, and I came up with a patch that
> works for me. Nevertheless, I do not understand exactly what is going
> on here, so I would like to defer to someone else's patch to fix the
> issue.
>
Hi.
__This is a genuine data loss problem in Git.__
I'm confused at the lack of response to this. I first posted about the
issue **2-1/2 weeks ago**, and there have been no responses Does no one
care?
In case no one received the messages, you can find them at [1] and [2].
-Josh
[1] http://www.spinics.net/lists/git/msg168295.html
[2] http://www.spinics.net/lists/git/msg168691.html
^ permalink raw reply
* Compile warnings
From: Frans Klaver @ 2011-11-14 14:55 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
Every now and then I see an 'unused result' warning come by during
building. What is the general attitude towards these warnings? Remove them
(by properly checking)? Or leave them be as a kind of documentation -- we
know we're ignoring the info, but it's good to be reminded?
Thanks,
Frans
^ permalink raw reply
* Re: input director not compatible with git right-click
From: Carlos Martín Nieto @ 2011-11-14 14:40 UTC (permalink / raw)
To: Eric; +Cc: git
In-Reply-To: <loom.20111113T173332-656@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 514 bytes --]
On Sun, Nov 13, 2011 at 04:34:26PM +0000, Eric wrote:
> Hi,
>
> New in Git use, I use it do dev on window some administrative script. I use as
> well Input director to share keyboard and mouse on multiple computer.
Do you mean you're using it on the Windows OS?
>
> when I right-clicked on an item, it works when input director is disabled. If
Right-click on what? git doesn't have a graphical interface. If you're
using a graphical front-end to git, you should send them a bug report.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: delete deprecated refs to release disk space
From: Peter Vereshagin @ 2011-11-14 14:25 UTC (permalink / raw)
To: ??var Arnfj??r?? Bjarmason; +Cc: Peter Vereshagin, git
In-Reply-To: <CACBZZX5kBqM1eye40_Vw0W=8qnNsUQBVCE0q9JrixYomGPuZbg@mail.gmail.com>
Hello.
2011/11/13 18:01:18 +0100 ??var Arnfj??r?? Bjarmason <avarab@gmail.com> => To Peter Vereshagin :
vArB> What you're looking for is git-filter-branch + the graft facility. I
vArB> can't remember the exact invocation, but you echo the sha1 of the
vArB> commit you want to be the oldest commit to .git/info/grafts, then run
vArB> git-filter-branch.
Seem to work for me ( with 'gc' and 'prune' thereafter ) but with these quirks:
*) the git-filter-branch(1) tells that there must be two ids:
echo "$commit-id $graft-id" >> .git/info/grafts
This works for me if only one is put there.
*) I'd like to have a command for this. Is this a '--parent-filter' to make
the same thing?
N commits ago is a fine setting for me as it's a cron job backup. Thanks?
--
Peter Vereshagin <peter@vereshagin.org> (http://vereshagin.org) pgp: A0E26627
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Felipe Contreras @ 2011-11-14 13:57 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111114122556.GB19746@sigill.intra.peff.net>
On Mon, Nov 14, 2011 at 2:25 PM, Jeff King <peff@peff.net> wrote:
> On Sun, Nov 13, 2011 at 12:07:19AM +0200, Felipe Contreras wrote:
>
>> > So in that sense, it is poorly named, and "--branches" (or "--heads")
>> > would be more accurate. At the same time, it is probably more likely
>> > what the user wants to do (you almost never want to push "refs/remotes",
>> > for example).
>>
>> But you do want to push tags, and --all --tags doesn't sound right; if
>> I'm pushing everything, why do I specify I want to push more stuff.
>> And then, why it --all --tags disallowed?
>
> I agree that "--all --tags" looks silly. I don't know why it's
> disallowed; from my reading, it should be a perfectly sensible
> operation. You might try digging in the history or the mailing list.
Yeah, I might do that.
>> > So I am a little hesitant to suggest changing it, even
>> > with a warning and deprecation period.
>>
>> It is confusing and wrong, what more reason do you need?
>
> Because I am worried that "--all" pushing refs/remotes will also be
> confusing; it's not what most people are going to want.
>
> If your suggestion is to deprecate the name "--all" and start calling it
> "--branches" or "--heads", then that is an improvement. But making
> "refs/*:refs/*" easier to accidentally use might not be.
That's what I meant; replace --all with --branches (remember heads is
a plumbing name).
>> > and then it really is just a special way of spelling "refs/heads/*". But
>> > then, I also think it's good for users to understand that the options
>> > are refspecs, and what that means. It's not a hard concept, and then
>> > when they inevitably say "how can I do BRANCHES, except put the result
>> > somewhere else in the remote namespace", it's a very natural extension
>> > to learn about the right-hand side o the refspec.
>> >
>> > Of course I also think BRANCHES looks ugly, and people should just learn
>> > "refs/heads/*".
>>
>> Look, I'm all in favor of people learning stuff, but I have been
>> involved in Git since basically day 1, and up to this day I was (am?)
>> not familiar with refspecs, I don't use them regularly, and never
>> really had a need to, and that's fine. People are already complaining
>> about the learning curve of git, and what you are suggesting is that:
>>
>> Instead of doing:
>> % git push remote --branches --tags
>>
>> They should do:
>> % git push remote 'refs/heads/*' 'refs/tags/*'
>
> Sorry, I should have been more clear with what I wrote. My "of
> course..." was more of a tangential "well, this is so far from what my
> gut tells me is reasonable that I'm not sure my definition of ugly is
> even relevant here".
>
> For me personally as a user, I prefer learning how a tool actually works
> at its core (in this case, refspecs), and then applying syntactic sugar
> to simplify usage. But I also respect that not everybody feels that way.
>
>> I'm not going to investigate the subtleties of these different setups,
>> I'm going to put my common user hat and ask; how do I fetch as a
>> mirror?
>
> The problem with that question is that you haven't defined mirror. Does
> that mean you just want pruning, or does it mean that you want your
> local ref namespace to match that of the remote?
Exactly, no mirror has been defined, because I don't want a mirror. A
mirror is supposed to have all the refs in sync all the time; that's
not what I want.
> Git should be able to do each of those cases. And I think it's fine to
> have a less cumbersome syntax to specify them. But it's also important
> that we don't over-simplify the terms so much that they get option A
> when they wanted B.
>
> BTW, right now there is "git remote add --mirror ...", which sets up the
> fetch refspec for you (in this case, mirror is "make your refs look like
> the remote's"). Perhaps rather than adding syntactic sugar to fetch, it
> would be best to channel users into configuring a remote that selects
> from one of a few common setups (including different types of mirrors).
But that assumes that they would want the same refspec operation *all
the time* which is not the case (at least for me). Sometimes I want to
update only existing branches, sometimes I want to fetch new branches
too, sometimes I want to prune local branches, sometimes not.
> It's not as flexible (I can't do a one-off mirrored push without using
> actual refspecs), but my guess is that most users would want to set up
> an actual remote, and picking from a set of configuration recipes would
> be the ideal interface for them.
I don't think so. I doubt users would like a refspec that will delete
their local branches *always*; sometimes they would want to prune the
remote tracking branches.
>> > And "--prune-local" doesn't seem like a fetch operation to me. Either
>> > you are mirroring, and --prune already handles it as above. Or you are
>> > interested in getting rid of branches whose upstream has gone away. But
>> > that's not a fetch operation; that's a branch operation.
>>
>> This would make things more confusing to the user.
>>
>> Say on one side I do this push?
>> % git push test --prune 'refs/heads/*' 'refs/tags/*'
>>
>> What do I do in the other side to synchronize the repo?
>> % git fetch test --prune-local 'refs/heads/*:refs/heads/*'
>> 'refs/tags/*:refs/tags/*'
>
> No, you would just do "--prune", because your refspecs are _already_
> indicating that you are writing into the local namespace, and anything
> you have locally would be deleted by the prune operation. I.e., there is
> no need for --prune-local in this scenario; --prune already does what we
> want.
That's very risky. The user might forget that this is a mirror repo,
and delete the local branches unintentionally. Plus, it would be then
impossible to prune remote tracking branches.
>> I would prefer this of course:
>> % git fetch test --all --prune-local
>>
>> But you are saying it should be:
>> % git fetch test 'refs/heads/*:refs/heads/*' 'refs/tags/*:refs/tags/*'
>> % git branch --prune-remote test
>>
>> That doesn't sound right to me; mixing branch operations with a specific remote?
>
> I was trying to outline a situation where "--prune" wouldn't be
> sufficient, which is:
>
> : we make some topic branch based on another branch
> $ git checkout -b topic-Y origin/topic-X
>
> : later, we (or someone else) deletes topic-X upstream
> $ git push origin :topic-X
>
> : now we fetch using the regular default refspecs, which put
> : everything in a separate remote. But we ask to prune, so that
> : deleted branches will go away.
> $ git fetch --prune origin
>
> Now origin/topic-X doesn't exist, even though it's configured as the
> upstream of topic-Y. Fetch doesn't enter into the picture, because it is
> configured to only touch items in refs/remotes/.
That's only by default.
> As a user, how do I resolve the situation? I might say topic-Y is
> obsolete and get rid of it. I might rebase it onto another branch. Or I
> might declare it to have no upstream. But all of those are branch
> operations, not fetch operations.
Yes, but that has nothing to do with the operation I want to achieve:
git remote sync. By which I mean synchronize the local branches with
the branches of a certain remote.
Note that in this sync operation, the upstream branch is irrelevant.
> So what I was trying to say was that either your fetch refspecs tell
> fetch to write into your local branch namespace, or not. If they do,
> then --prune is sufficient (with no -local variant required). If not,
> then touching your local branch namespace is outside the scope of fetch.
I don't want this to be a *permanent* configuration. I see this
similar to --force. You can achieve the same by adding a + at the
beginning of the refspec, but this is something that should be
activated on a per-command basis, thus the option. I think this should
be the same.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: git behaviour question regarding SHA-1 and commits
From: Jeff King @ 2011-11-14 13:04 UTC (permalink / raw)
To: Jonathan Nieder, vinassa vinassa, git,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20111114124851.GB21854@victor>
On Mon, Nov 14, 2011 at 01:48:51PM +0100, Victor Engmark wrote:
> > Fortunately we have such a thing:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/184243
> >
> > That one actually has 40 bits of hash entropy, so you'd expect to
> > generate 2^20 (about a million) commits before accidentally colliding.
> > If you want an easier experiment, you could truncate it even further.
>
> Would it be helpful to truncate this to something ludicrous like a
> single byte of entropy, to be able to write tests for the various tools
> and options?
That's probably too small. Obviously any implementation like this is not
going to be usable for interacting with existing repositories, but if
you have too many collisions, then you won't even be able to create a
few new commits for your test.
Something like 20 bits means you can brute-force a collision for a
particular blob, commit, tree, or whatever in a few seconds, but you
won't be having accidental ones all the time.
-Peff
^ permalink raw reply
* Re: git behaviour question regarding SHA-1 and commits
From: Victor Engmark @ 2011-11-14 12:48 UTC (permalink / raw)
To: Jeff King
Cc: Jonathan Nieder, vinassa vinassa, git,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20111114113235.GE10847@sigill.intra.peff.net>
On Mon, Nov 14, 2011 at 06:32:35AM -0500, Jeff King wrote:
> On Sun, Nov 13, 2011 at 12:27:57PM -0600, Jonathan Nieder wrote:
>
> > Though I haven't tested. It would be nice to have an md5git (or even
> > truncated-sha1-git) program to test this kind of thing with.
>
> Fortunately we have such a thing:
>
> http://article.gmane.org/gmane.comp.version-control.git/184243
>
> That one actually has 40 bits of hash entropy, so you'd expect to
> generate 2^20 (about a million) commits before accidentally colliding.
> If you want an easier experiment, you could truncate it even further.
Would it be helpful to truncate this to something ludicrous like a
single byte of entropy, to be able to write tests for the various tools
and options?
Cheers,
V
--
terreActive AG
Kasinostrasse 30
CH-5001 Aarau
Tel: +41 62 834 00 55
Fax: +41 62 823 93 56
www.terreactive.ch
Wir sichern Ihren Erfolg - seit 15 Jahren
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Jeff King @ 2011-11-14 12:25 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s06p+KyJAu4ddiCa8CFRq5eogbqxxJU16Z-SUb3GSp67Q@mail.gmail.com>
On Sun, Nov 13, 2011 at 12:07:19AM +0200, Felipe Contreras wrote:
> > So in that sense, it is poorly named, and "--branches" (or "--heads")
> > would be more accurate. At the same time, it is probably more likely
> > what the user wants to do (you almost never want to push "refs/remotes",
> > for example).
>
> But you do want to push tags, and --all --tags doesn't sound right; if
> I'm pushing everything, why do I specify I want to push more stuff.
> And then, why it --all --tags disallowed?
I agree that "--all --tags" looks silly. I don't know why it's
disallowed; from my reading, it should be a perfectly sensible
operation. You might try digging in the history or the mailing list.
> > So I am a little hesitant to suggest changing it, even
> > with a warning and deprecation period.
>
> It is confusing and wrong, what more reason do you need?
Because I am worried that "--all" pushing refs/remotes will also be
confusing; it's not what most people are going to want.
If your suggestion is to deprecate the name "--all" and start calling it
"--branches" or "--heads", then that is an improvement. But making
"refs/*:refs/*" easier to accidentally use might not be.
> > Right. It looks like that is just spelled "--mirror" (which gives you
> > pruning also), or "refs/*:refs/*" (without pruning). The latter is even
> > more flexible, as you could do "refs/*:refs/foo/*" to keep several
> > related backups in one upstream repo.
>
> So, we agree that --all is the same as 'refs/heads/*'. Therefore we
> already have this mixture of refspecs and options.
True. I wonder why there has been so much confusion over "--tags", and
so little over "--all".
> > and then it really is just a special way of spelling "refs/heads/*". But
> > then, I also think it's good for users to understand that the options
> > are refspecs, and what that means. It's not a hard concept, and then
> > when they inevitably say "how can I do BRANCHES, except put the result
> > somewhere else in the remote namespace", it's a very natural extension
> > to learn about the right-hand side o the refspec.
> >
> > Of course I also think BRANCHES looks ugly, and people should just learn
> > "refs/heads/*".
>
> Look, I'm all in favor of people learning stuff, but I have been
> involved in Git since basically day 1, and up to this day I was (am?)
> not familiar with refspecs, I don't use them regularly, and never
> really had a need to, and that's fine. People are already complaining
> about the learning curve of git, and what you are suggesting is that:
>
> Instead of doing:
> % git push remote --branches --tags
>
> They should do:
> % git push remote 'refs/heads/*' 'refs/tags/*'
Sorry, I should have been more clear with what I wrote. My "of
course..." was more of a tangential "well, this is so far from what my
gut tells me is reasonable that I'm not sure my definition of ugly is
even relevant here".
For me personally as a user, I prefer learning how a tool actually works
at its core (in this case, refspecs), and then applying syntactic sugar
to simplify usage. But I also respect that not everybody feels that way.
> I'm not going to investigate the subtleties of these different setups,
> I'm going to put my common user hat and ask; how do I fetch as a
> mirror?
The problem with that question is that you haven't defined mirror. Does
that mean you just want pruning, or does it mean that you want your
local ref namespace to match that of the remote?
Git should be able to do each of those cases. And I think it's fine to
have a less cumbersome syntax to specify them. But it's also important
that we don't over-simplify the terms so much that they get option A
when they wanted B.
BTW, right now there is "git remote add --mirror ...", which sets up the
fetch refspec for you (in this case, mirror is "make your refs look like
the remote's"). Perhaps rather than adding syntactic sugar to fetch, it
would be best to channel users into configuring a remote that selects
from one of a few common setups (including different types of mirrors).
It's not as flexible (I can't do a one-off mirrored push without using
actual refspecs), but my guess is that most users would want to set up
an actual remote, and picking from a set of configuration recipes would
be the ideal interface for them.
> > And "--prune-local" doesn't seem like a fetch operation to me. Either
> > you are mirroring, and --prune already handles it as above. Or you are
> > interested in getting rid of branches whose upstream has gone away. But
> > that's not a fetch operation; that's a branch operation.
>
> This would make things more confusing to the user.
>
> Say on one side I do this push?
> % git push test --prune 'refs/heads/*' 'refs/tags/*'
>
> What do I do in the other side to synchronize the repo?
> % git fetch test --prune-local 'refs/heads/*:refs/heads/*'
> 'refs/tags/*:refs/tags/*'
No, you would just do "--prune", because your refspecs are _already_
indicating that you are writing into the local namespace, and anything
you have locally would be deleted by the prune operation. I.e., there is
no need for --prune-local in this scenario; --prune already does what we
want.
> I would prefer this of course:
> % git fetch test --all --prune-local
>
> But you are saying it should be:
> % git fetch test 'refs/heads/*:refs/heads/*' 'refs/tags/*:refs/tags/*'
> % git branch --prune-remote test
>
> That doesn't sound right to me; mixing branch operations with a specific remote?
I was trying to outline a situation where "--prune" wouldn't be
sufficient, which is:
: we make some topic branch based on another branch
$ git checkout -b topic-Y origin/topic-X
: later, we (or someone else) deletes topic-X upstream
$ git push origin :topic-X
: now we fetch using the regular default refspecs, which put
: everything in a separate remote. But we ask to prune, so that
: deleted branches will go away.
$ git fetch --prune origin
Now origin/topic-X doesn't exist, even though it's configured as the
upstream of topic-Y. Fetch doesn't enter into the picture, because it is
configured to only touch items in refs/remotes/.
As a user, how do I resolve the situation? I might say topic-Y is
obsolete and get rid of it. I might rebase it onto another branch. Or I
might declare it to have no upstream. But all of those are branch
operations, not fetch operations.
So what I was trying to say was that either your fetch refspecs tell
fetch to write into your local branch namespace, or not. If they do,
then --prune is sufficient (with no -local variant required). If not,
then touching your local branch namespace is outside the scope of fetch.
-Peff
^ permalink raw reply
* Re: git behaviour question regarding SHA-1 and commits
From: Jeff King @ 2011-11-14 11:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, vinassa vinassa, git
In-Reply-To: <7vwrb3l6v2.fsf@alter.siamese.dyndns.org>
On Sun, Nov 13, 2011 at 07:29:05PM -0800, Junio C Hamano wrote:
> If the collision is between commit objects, for example, we would write
> the (old) commit object name to the tip of the current branch. Most
> likely, the tree object recorded in the (old) commit would not match the
> tree object your "git commit" wanted to record (otherwise you have hit
> SHA-1 collision twice in a row ;-), which would mean "git status" would
> show that a whole bunch of paths have changed between the HEAD and the
> index. Also "git log" would show the history leading to the (old) commit
> that is likely to be very different from what you would expect immediately
> after committing the collided commit. Of course, you could recover from it
> with "git reset --soft" after finding out what the previous HEAD was from
> the reflog, but it won't be a pleasant experience.
>
> There can be other kinds of collisions (e.g. your latest commit might have
> collided with an existing blob or tree, in which case it is likely that
> almost nothing would work after finding a blob or tree in HEAD).
You are more likely to just have blobs collide, since we generate many
more blobs than commits (each commit should have at least one changed
blob, but typically has more).
And in that case, I expect git would silently lose that state. We would
fail to write the new blob to the object db, but "git diff" would report
nothing, as it would see that the index entry's sha1 is the same as what
is in HEAD, and that the file is up to date with respect to the stat
information in the index. So if you were to "git checkout", your content
would be lost forever. However, if you instead modify the file further,
the new content will be kept (and you will get a very confusing diff).
-Peff
^ permalink raw reply
* Re: git behaviour question regarding SHA-1 and commits
From: Jeff King @ 2011-11-14 11:32 UTC (permalink / raw)
To: Jonathan Nieder
Cc: vinassa vinassa, git, Ævar Arnfjörð Bjarmason
In-Reply-To: <20111113182757.GA15194@elie.hsd1.il.comcast.net>
On Sun, Nov 13, 2011 at 12:27:57PM -0600, Jonathan Nieder wrote:
> Though I haven't tested. It would be nice to have an md5git (or even
> truncated-sha1-git) program to test this kind of thing with.
Fortunately we have such a thing:
http://article.gmane.org/gmane.comp.version-control.git/184243
That one actually has 40 bits of hash entropy, so you'd expect to
generate 2^20 (about a million) commits before accidentally colliding.
If you want an easier experiment, you could truncate it even further.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] Copy resolve_ref() return value for longer use
From: Jeff King @ 2011-11-14 11:24 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <CACsJy8BnqoPVJiM6mbq7p3gKtLh-KGUuTshcukGokC3istTxMQ@mail.gmail.com>
On Mon, Nov 14, 2011 at 10:32:11AM +0700, Nguyen Thai Ngoc Duy wrote:
> 2011/11/14 Junio C Hamano <gitster@pobox.com>:
> >> diff --git a/builtin/branch.c b/builtin/branch.c
> >> index 0fe9c4d..5b6d839 100644
> >> --- a/builtin/branch.c
> >> +++ b/builtin/branch.c
> >> @@ -115,8 +115,10 @@ static int branch_merged(int kind, const char *name,
> >> branch->merge[0] &&
> >> branch->merge[0]->dst &&
> >> (reference_name =
> >> - resolve_ref(branch->merge[0]->dst, sha1, 1, NULL)) != NULL)
> >> + resolve_ref(branch->merge[0]->dst, sha1, 1, NULL)) != NULL) {
> >> + reference_name = xstrdup(reference_name);
> >> reference_rev = lookup_commit_reference(sha1);
> >> + }
> >> }
> >> if (!reference_rev)
> >> reference_rev = head_rev;
> >> @@ -141,6 +143,7 @@ static int branch_merged(int kind, const char *name,
> >> " '%s', even though it is merged to HEAD."),
> >> name, reference_name);
> >> }
> >> + free((char*)reference_name);
> >> return merged;
> >> }
> >
> > Now reference_name stores the result of xstrdup(), it does not have reason
> > to be of type "const char *". It is preferable to lose the cast here, I
> > think. The same comment applies to the remainder of the patch.
>
> But resolve_ref() returns "const char *", we need to type cast at
> least once, either at resolve_ref() assignment or at free(), until we
> change resolve_ref(). Or should we change resolve_ref() to return
> "char *" now?
Your problem is that you are using the same variable for two different
things: storing the pointer to non-owned memory returned from
resolve_ref, and then storing the owned memory that comes from xstrdup.
Those two things have different types, since we use "const" on non-owned
memory. Thus you end up casting.
So your code isn't wrong, but I do think it would be more obviously
correct to a reader if it used two variables and dropped the cast.
-Peff
^ permalink raw reply
* Re: Git shouldn't allow to push a new branch called HEAD
From: Jeff King @ 2011-11-14 11:16 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Daniele Segato, Git Mailing List
In-Reply-To: <4EC0F15A.9010502@alum.mit.edu>
On Mon, Nov 14, 2011 at 11:45:46AM +0100, Michael Haggerty wrote:
> The whole time, victim's .git/HEAD contains "ref: refs/heads/master",
> .git/refs/remotes/origin/HEAD contains "ref:
> refs/remotes/origin/master", and its packed-refs file contains
>
> # pack-refs with: peeled
> 4c9ebba3c0618bd6238a810013da4a8cd4f2213b refs/remotes/origin/master
>
> In "remote.git", refs/heads/HEAD contains not a symbolic reference but
> the explicit SHA1 "4c9ebba...". This is of course not affected by
> running "git fetch" in the "victim" tree. Deleting this file makes the
> problem go away.
>
>
> Given that this problem seems to be in the remote protocol rather than
> in the refs API, I think I'll stop working on this. I hope that my
> observations are helpful to somebody.
I didn't recreate the test situation and look closely, but my impression
is that this isn't a code bug at all, but rather a design problem in the
way we store remote namespaces. That is, we make "refs/remotes/foo/HEAD"
a symbolic ref with special meaning, but then fetch into it from the
remote's refs/heads namespace, writing remote's HEAD branch into
whatever our HEAD symref points to.
So one solution is to block fetching of remote branches called HEAD
(which I would be OK with). But another is to use a more sensible layout
for representing the remote refs, like:
refs/remotes/origin/HEAD (a symbolic ref)
refs/remotes/origin/heads/master
refs/remotes/origin/tags/v1.0
etc. Then the namespaces are properly separated, and the magic remote
"HEAD" symref is not in the way.
Obviously there's a lot more to it than just tweaking the default fetch
refspecs. The ref lookup rules need to be changed to take this into
account. There was some discussion about this over the summer (under the
subject of possible "1.8.0" changes), but I don't think any work has
been done.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2011, #03; Sun, 13)
From: Jeff King @ 2011-11-14 11:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmxbzl5ch.fsf@alter.siamese.dyndns.org>
On Sun, Nov 13, 2011 at 08:01:50PM -0800, Junio C Hamano wrote:
> * jc/lookup-object-hash (2011-08-11) 6 commits
> - object hash: replace linear probing with 4-way cuckoo hashing
> - object hash: we know the table size is a power of two
> - object hash: next_size() helper for readability
> - pack-objects --count-only
> - object.c: remove duplicated code for object hashing
> - object.c: code movement for readability
>
> I do not think there is anything fundamentally wrong with this series, but
> the risk of breakage far outweighs observed performance gain in one
> particular workload.
FWIW, I finally got a chance to read through this series. It was fun, as
I had not looked at cuckoo hashing before. However, the performance
results were a bit underwhelming, and the code is more complex, which
left me a bit negative. I also took a quick try at quadratic probing,
which is only a few extra lines of code. I wasn't able to show any real
performance improvement, though.
I suspect it is because our hash table is not all that big, and we keep
it pretty sparse, so linear probing does well. Googling around, it seems
that linear probing performs well up to about 70% load factor, but
there's surprisingly little theory behind it.
I notice that the decorate.c hash keeps us below 2/3 full, but the
object.c hash keeps us at 1/2. From my reading, that's just wasting
space. Pushing the boundary up to 2/3 and trying your "--count-objects"
on git.git, I don't see a big performance difference (with my change,
the best-of-5 was a little better, but well within the noise). It does
drop the maxresident by a few percent.
So I don't think it's a big deal either way, but the code change is
pretty trivial.
-Peff
^ permalink raw reply
* [PATCH] tag: implement --no-strip option
From: Kirill A. Shutemov @ 2011-11-14 11:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Kirill A. Shutemov
From: "Kirill A. Shutemov" <kirill@shutemov.name>
--no-strip turns off strip any comments or empty lines.
It's useful if you want to take a tag message as-is, without any
stripping.
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
---
Documentation/git-tag.txt | 4 ++++
builtin/tag.c | 13 ++++++++-----
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index c83cb13..947d4e5 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -99,6 +99,10 @@ OPTIONS
Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
is given.
+-S::
+--no-strip::
+ Take tag message as-is. Do not strip any comments or empty lines.
+
<tagname>::
The name of the tag to create, delete, or describe.
The new tag name must pass all checks defined by
diff --git a/builtin/tag.c b/builtin/tag.c
index 9b6fd95..427d646 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -320,7 +320,7 @@ static int build_tag_object(struct strbuf *buf, int sign, unsigned char *result)
}
static void create_tag(const unsigned char *object, const char *tag,
- struct strbuf *buf, int message, int sign,
+ struct strbuf *buf, int message, int sign, int nostrip,
unsigned char *prev, unsigned char *result)
{
enum object_type type;
@@ -356,7 +356,7 @@ static void create_tag(const unsigned char *object, const char *tag,
if (!is_null_sha1(prev))
write_tag_body(fd, prev);
- else
+ else if (!nostrip)
write_or_die(fd, _(tag_template), strlen(_(tag_template)));
close(fd);
@@ -367,7 +367,8 @@ static void create_tag(const unsigned char *object, const char *tag,
}
}
- stripspace(buf, 1);
+ if (!nostrip)
+ stripspace(buf, 1);
if (!message && !buf->len)
die(_("no tag message?"));
@@ -423,7 +424,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
const char *object_ref, *tag;
struct ref_lock *lock;
- int annotate = 0, sign = 0, force = 0, lines = -1,
+ int annotate = 0, sign = 0, nostrip = 0, force = 0, lines = -1,
list = 0, delete = 0, verify = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
@@ -443,6 +444,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
"tag message", parse_msg_arg),
OPT_FILENAME('F', "file", &msgfile, "read message from file"),
OPT_BOOLEAN('s', "sign", &sign, "annotated and GPG-signed tag"),
+ OPT_BOOLEAN('S', "no-strip", &nostrip,
+ "turn off tag message stripping"),
OPT_STRING('u', "local-user", &keyid, "key-id",
"use another key to sign the tag"),
OPT__FORCE(&force, "replace the tag if exists"),
@@ -525,7 +528,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (annotate)
create_tag(object, tag, &buf, msg.given || msgfile,
- sign, prev, object);
+ sign, nostrip, prev, object);
lock = lock_any_ref_for_update(ref.buf, prev, 0);
if (!lock)
--
1.7.7.2
^ permalink raw reply related
* Re: Git shouldn't allow to push a new branch called HEAD
From: Michael Haggerty @ 2011-11-14 10:45 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <1321261662.2941.13.camel@mastroc3.mobc3.local>
On 11/14/2011 10:07 AM, Daniele Segato wrote:
> On Fri, 2011-10-14 at 13:35 +0200, Daniele Segato wrote:
>> On Fri, 2011-10-14 at 13:31 +0200, Daniele Segato wrote:
>>> following from a discussion in IRC freenode #git between me, sitaram an
>>> shruggar
>>>
>>>
>>> step to reproduce:
>>>
>>> $ mkdir /tmp/gitbug
>>> $ cd /tmp/gitbug/
>>>
>>> $ # create a fake remote repo
>>> $ git init --bare remote.git
>>>
>>> $ # clone it with the user that will generate the bug
>>> $ git clone remote.git buggenerator
>>> $ cd buggenerator/
>>> $ touch whatever
>>> $ git add .
>>> $ git commit -m "first commit"
>>> $ git push origin master
>>>
>>> $ # now clone the same repo the other guy is the "victim" of this issue
>>> $ cd ..
>>> $ git clone remote.git victim
>>>
>>> $ # time to create the remote HEAD branch
>>> $ cd buggenerator/
>>> $ git push origin HEAD:HEAD
>>>
>>> $ # the remote refs has been created!
>>> $ git ls-remote
>>>
>>> $ # another commit
>>> $ echo 'any change' >> whatever
>>> $ git commit -a -m "some change"
>>> $ git push origin master
>>>
>>> $ # the refs/heads/HEAD is still where it was
>>> $ git ls-remote
>>>
>>> $ # now from the victim perspective
>>> $ cd ../victim/
>>>
>>> $ # every time executing a fetch he will get a force update
>>> $ # or maybe even an error, seen it my real repo, don't know how
>>> $ # to reproduce
>>> $ git fetch
>>> $ git fetch
>>> $ git ls-remote
>>> $ git fetch
>>> $ git ls-remote
>>> $ git branch -a
>>
>> This should also help understanding what happen in the "victim" local
>> repo at every fetch:
>>
>> mastro@mastroc3 /tmp/gitbug/victim (master) $ git br -av
>> * master 11d0a12 [behind 1] first commit
>> remotes/origin/HEAD -> origin/master
>> remotes/origin/master 77852ef some change
>> mastro@mastroc3 /tmp/gitbug/victim (master) $ git fetch
>> From /tmp/gitbug/remote
>> + 77852ef...11d0a12 HEAD -> origin/HEAD (forced update)
>> mastro@mastroc3 /tmp/gitbug/victim (master) $ git br -av
>> * master 11d0a12 first commit
>> remotes/origin/HEAD -> origin/master
>> remotes/origin/master 11d0a12 first commit
>
> I'm aware my request has been ignored for a good reason but I would
> appreciate someone stepping in and explaining to me why this is not a
> bug or why it has been ignored.
This is a nice little bug.
I'm sure that you noticed that running "git fetch" repeatedly from the
"victim" repository alternates between two behaviors (I'm using 1.7.7.2):
> $ git fetch
> From /home/mhagger/tmp/gitbug/remote
> + 6bf3df1...4c9ebba HEAD -> origin/HEAD (forced update)
> $ git for-each-ref
> 4c9ebba3c0618bd6238a810013da4a8cd4f2213b commit refs/heads/master
> 4c9ebba3c0618bd6238a810013da4a8cd4f2213b commit refs/remotes/origin/HEAD
> 4c9ebba3c0618bd6238a810013da4a8cd4f2213b commit refs/remotes/origin/master
> $ git fetch
> From /home/mhagger/tmp/gitbug/remote
> 4c9ebba..6bf3df1 master -> origin/master
> $ git for-each-ref
> 4c9ebba3c0618bd6238a810013da4a8cd4f2213b commit refs/heads/master
> 6bf3df178cd92ca72625ae5bda9206c4333fd807 commit refs/remotes/origin/HEAD
> 6bf3df178cd92ca72625ae5bda9206c4333fd807 commit refs/remotes/origin/master
> $ git fetch
> From /home/mhagger/tmp/gitbug/remote
> + 6bf3df1...4c9ebba HEAD -> origin/HEAD (forced update)
> $ git fetch
> From /home/mhagger/tmp/gitbug/remote
> 4c9ebba..6bf3df1 master -> origin/master
The whole time, victim's .git/HEAD contains "ref: refs/heads/master",
.git/refs/remotes/origin/HEAD contains "ref:
refs/remotes/origin/master", and its packed-refs file contains
# pack-refs with: peeled
4c9ebba3c0618bd6238a810013da4a8cd4f2213b refs/remotes/origin/master
In "remote.git", refs/heads/HEAD contains not a symbolic reference but
the explicit SHA1 "4c9ebba...". This is of course not affected by
running "git fetch" in the "victim" tree. Deleting this file makes the
problem go away.
Given that this problem seems to be in the remote protocol rather than
in the refs API, I think I'll stop working on this. I hope that my
observations are helpful to somebody.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [RFC] deprecating and eventually removing "git relink"?
From: Jeff King @ 2011-11-14 10:34 UTC (permalink / raw)
To: Simon Brenner; +Cc: git
In-Reply-To: <CAD=rjTXgH+AivmK+zLurQVC+=p1UYqFy_p=wBF-1-TOQ=Cqjtw@mail.gmail.com>
On Mon, Nov 14, 2011 at 09:48:07AM +0100, Simon Brenner wrote:
> On Mon, Nov 14, 2011 at 7:06 AM, Miles Bader <miles@gnu.org> wrote:
> > It might be nice to have a mechanism where new objects would update
> > the _alternate_ rather than the object-store in the tree where the
> > command was run... then you could easily have a bunch of trees using a
> > central object store without needing to update the central store
> > occasionally by hand (and do gc in its "clients")...
>
> This sounds like a nice way forward: replace/extend the current
> alternates system with support for a shared object store that is
> "intelligently" shared so that it can be gc:d based on all refs from
> all referring repositories. I imagine it would be something very much
> like a bare repository - except it wouldn't have any refs of its own,
> just a list of other repositories it should search for refs when
> GC:ing.
Yes, I think that is sensible. I'm not sure there is even any core git
code to be written. I think a wrapper that does the following would
probably work:
1. Make new repo groups. E.g.:
$ git share init foo
which would be implemented something like:
ROOT=$HOME/.git-share
git init --bare $ROOT/$1
2. Add a repo to a group.
$ git share add foo
implemented as:
echo $ROOT/$1/objects >>.git/objects/info/alternates
git --git-dir=$ROOT/$1 config --add share.child $PWD
3. Compact a group.
$ git share compact foo
implemented as:
# delete any existing refs
git for-each-ref --format='%(refname)' | xargs git update-ref -d
# now make new refs for each child
n=1
for dir in `git config --all share.child`; do
if ! test -d $dir; then
echo >&2 "warning: $dir went away"
continue
fi
git fetch $dir refs/*:refs/$1/*
n=$(($n + 1))
done
# and then repack/prune
git repack -ad
# and then gc each child, dropping anything in the share
for dir in `git config --all share.child`; do
git --git-dir=$dir gc
done
I'm sure I'm missing a corner case or two, and of course there are
quoting issues and error handling missing. But the point is, I don't
think there's a real reason that the UI can't wrap the existing
mechanism, creating a momentary list of refs and pruning based on that.
One issue with this scheme (or most similar schemes) is that child repos
are uniquely identified by their directory name. In the absence of
alternates, it's perfectly reasonable to do:
git init; hack hack hack; commit commit commit
cd .. ; mv project new-project-name
but here it would break the shared repo's link to the child (which is
not just inconvenient, but dangerous, as we will not respect its refs
when pruning). Probably the "warning" above should actually error out
and force the user to say "yes, I deleted this child" or "no, I moved it
here".
You could try to be clever with assigning each child a UUID, but then
you have to resort to grepping the filesystem for the UUID to detect a
move. Which is complex and still not foolproof (i.e., if you don't find
it, is it because the repo was deleted, or because it got moved
somewhere that we didn't look?).
-Peff
^ permalink raw reply
* Re: [RFC] deprecating and eventually removing "git relink"?
From: Junio C Hamano @ 2011-11-14 10:24 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <buomxbzutjm.fsf@dhlpc061.dev.necel.com>
Miles Bader <miles@gnu.org> writes:
> It might be nice to have a mechanism where new objects would update
> the _alternate_ rather than the object-store in the tree where the
> command was run.
With the alternate mechanism, your borrowing is read-only and that is
exactly why you can borrow from other peoples' repositories to which you
have no write permission to.
What you are suggesting is fundamentally different from the alternates
mechanism. I am not saying it is better or worse, though. Not yet at this
point in this message.
> .. then you could easily have a bunch of trees using a
> central object store without needing to update the central store
> occasionally by hand (and do gc in its "clients")...
If you write objects to the central store, "gc" in the "clients" will be a
no-op because they do not have their own objects. But instead, crufts your
"clients" accumulate will be in the central store. There is still need for
"gc" at the central store to remove things that are no longer used by any
client, isn't it? Unless you declare that you do not care because perhaps
the central store is large enough, that is.
At least with the alternates, running "gc" in the "clients" is a safe
operation and the only change necessary is to make fsck/repack aware of
the repositories that borrow from the repository these commands are run,
and the logic to do so is exactly the same as the case to run "gc" in your
central store, I would think.
^ permalink raw reply
* Re: Git shouldn't allow to push a new branch called HEAD
From: Daniele Segato @ 2011-11-14 9:07 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <1318592153.2938.21.camel@mastroc3.mobc3.local>
On Fri, 2011-10-14 at 13:35 +0200, Daniele Segato wrote:
> On Fri, 2011-10-14 at 13:31 +0200, Daniele Segato wrote:
> > Hi all,
> >
> >
> > following from a discussion in IRC freenode #git between me, sitaram an
> > shruggar
> >
> >
> > step to reproduce:
> >
> > $ mkdir /tmp/gitbug
> > $ cd /tmp/gitbug/
> >
> > $ # create a fake remote repo
> > $ git init --bare remote.git
> >
> > $ # clone it with the user that will generate the bug
> > $ git clone remote.git buggenerator
> > $ cd buggenerator/
> > $ touch whatever
> > $ git add .
> > $ git commit -m "first commit"
> > $ git push origin master
> >
> > $ # now clone the same repo the other guy is the "victim" of this issue
> > $ cd ..
> > $ git clone remote.git victim
> >
> > $ # time to create the remote HEAD branch
> > $ cd buggenerator/
> > $ git push origin HEAD:HEAD
> >
> > $ # the remote refs has been created!
> > $ git ls-remote
> >
> > $ # another commit
> > $ echo 'any change' >> whatever
> > $ git commit -a -m "some change"
> > $ git push origin master
> >
> > $ # the refs/heads/HEAD is still where it was
> > $ git ls-remote
> >
> > $ # now from the victim perspective
> > $ cd ../victim/
> >
> > $ # every time executing a fetch he will get a force update
> > $ # or maybe even an error, seen it my real repo, don't know how
> > $ # to reproduce
> > $ git fetch
> > $ git fetch
> > $ git ls-remote
> > $ git fetch
> > $ git ls-remote
> > $ git branch -a
>
> This should also help understanding what happen in the "victim" local
> repo at every fetch:
>
> mastro@mastroc3 /tmp/gitbug/victim (master) $ git br -av
> * master 11d0a12 [behind 1] first commit
> remotes/origin/HEAD -> origin/master
> remotes/origin/master 77852ef some change
> mastro@mastroc3 /tmp/gitbug/victim (master) $ git fetch
> From /tmp/gitbug/remote
> + 77852ef...11d0a12 HEAD -> origin/HEAD (forced update)
> mastro@mastroc3 /tmp/gitbug/victim (master) $ git br -av
> * master 11d0a12 first commit
> remotes/origin/HEAD -> origin/master
> remotes/origin/master 11d0a12 first commit
Hi again,
I'm aware my request has been ignored for a good reason but I would
appreciate someone stepping in and explaining to me why this is not a
bug or why it has been ignored.
Thanks.
Regards,
Daniele Segato
^ permalink raw reply
* Re: [RFC] deprecating and eventually removing "git relink"?
From: Chris Packham @ 2011-11-14 9:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miles Bader, git
In-Reply-To: <7v62inkymg.fsf@alter.siamese.dyndns.org>
On 14/11/11 19:27, Junio C Hamano wrote:
> Miles Bader <miles@gnu.org> writes:
>
>> Do you mean a more elaborate UI that does this nicely...?
>
> Yes, that is what I meant. I also have a feeling that people would prefer
> to have an option that treats these two repositories equally; your
> illustration makes one a subordinate to the other.
Not sure if it's what you're after but there was this patch [1] that I
was kicking around a while back. I've still got the code in an old
branch if there is interest in resurrecting it. It looks like I started
addressing Junio's comments and never posted v3.
[1] http://article.gmane.org/gmane.comp.version-control.git/143164
^ 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