* Re: Git mailing list admin wanted! :)
From: Matthieu Moy @ 2011-10-04 7:15 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <20111004071027.GA19295@ashu.dyn.rarus.ru>
Alexey Shumkin <alex.crezoff@gmail.com> writes:
> Hello, list!
>
> I have a trouble with postings to this mailing list.
> I can post from mutt or git-send-email,
> but not from claws-mail email-client (and only claws-mail, sic!)
> Messages are gone ok, CC account got that messages but not git list.
Was the message plain text, or HTML?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH/RFC] remote: support --all for the prune-subcommand
From: Erik Faye-Lund @ 2011-10-04 7:18 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111004071332.GA7308@sigill.intra.peff.net>
On Tue, Oct 4, 2011 at 9:13 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Oct 04, 2011 at 09:10:40AM +0200, Erik Faye-Lund wrote:
>
>> > git fetch --all --prune
>> >
>> I wasn't aware that fetch could prune, but yeah, that seems much
>> better to me. Perhaps a mention of this in the "git remote prune"
>> documentation could steer other users in the right direction?
>
> Yeah, that makes sense.
>
> There is one slight difference: I think "git remote prune" will _just_
> prune, and not fetch into existing refs at all. I'm not sure exactly
> why you would want that, though.
Hmm, you might want to do that on, say, a mobile network to save
bandwidth; i.e throw away the stale branches, but not yet update the
non-stale ones because downloading the objects might take a long time
(and/or be expensive).
So with that in mind, I actually think my patch makes sense in some
cases, but it certainly is less useful that I originally though ;)
A mention in the documentation seems like a good move no matter what, though.
^ permalink raw reply
* Re: Git mailing list admin wanted! :)
From: Alexey Shumkin @ 2011-10-04 7:24 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqty7pdy83.fsf@bauges.imag.fr>
plain text
during the tests for the HTML I've got an answer that HTML-messages are
not allowed
I have a thought it's somehow connected with a gmail messages
verification.
В Tue, 04 Oct 2011 09:15:08 +0200
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> пишет:
> Alexey Shumkin <alex.crezoff@gmail.com> writes:
>
> > Hello, list!
> >
> > I have a trouble with postings to this mailing list.
> > I can post from mutt or git-send-email,
> > but not from claws-mail email-client (and only claws-mail, sic!)
> > Messages are gone ok, CC account got that messages but not git list.
>
> Was the message plain text, or HTML?
>
^ permalink raw reply
* Re: Git mailing list admin wanted! :)
From: Alexey Shumkin @ 2011-10-04 7:36 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqty7pdy83.fsf@bauges.imag.fr>
Hmm!
It seems to me I got... not a reason, but the steps:
If I reply from NNTP-account (even I change an account for
sending to Gmail), messages are "lost".
If I reply from Gmail account, messages are delivered
> Alexey Shumkin <alex.crezoff@gmail.com> writes:
>
> > Hello, list!
> >
> > I have a trouble with postings to this mailing list.
> > I can post from mutt or git-send-email,
> > but not from claws-mail email-client (and only claws-mail, sic!)
> > Messages are gone ok, CC account got that messages but not git list.
>
> Was the message plain text, or HTML?
>
^ permalink raw reply
* Re: Git mailing list admin wanted! :)
From: Alexey Shumkin @ 2011-10-04 7:40 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <20111004113611.62326b3b@ashu.dyn.rarus.ru>
test reply
> Hmm!
> It seems to me I got... not a reason, but the steps:
>
> If I reply from NNTP-account (even I change an account for
> sending to Gmail), messages are "lost".
>
> If I reply from Gmail account, messages are delivered
>
> > Alexey Shumkin <alex.crezoff@gmail.com> writes:
> >
> > > Hello, list!
> > >
> > > I have a trouble with postings to this mailing list.
> > > I can post from mutt or git-send-email,
> > > but not from claws-mail email-client (and only claws-mail, sic!)
> > > Messages are gone ok, CC account got that messages but not git
> > > list.
> >
> > Was the message plain text, or HTML?
> >
>
^ permalink raw reply
* Re: [PATCH/RFC] remote: support --all for the prune-subcommand
From: Erik Faye-Lund @ 2011-10-04 7:40 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <CABPQNSZ-ELfFuxmKMqXCQaAgMZMRsZG3S5wWJLsjkYVvK6aGug@mail.gmail.com>
On Tue, Oct 4, 2011 at 9:18 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> On Tue, Oct 4, 2011 at 9:13 AM, Jeff King <peff@peff.net> wrote:
>> On Tue, Oct 04, 2011 at 09:10:40AM +0200, Erik Faye-Lund wrote:
>>
>>> > git fetch --all --prune
>>> >
>>> I wasn't aware that fetch could prune, but yeah, that seems much
>>> better to me. Perhaps a mention of this in the "git remote prune"
>>> documentation could steer other users in the right direction?
>>
>> Yeah, that makes sense.
>>
>> There is one slight difference: I think "git remote prune" will _just_
>> prune, and not fetch into existing refs at all. I'm not sure exactly
>> why you would want that, though.
>
> Hmm, you might want to do that on, say, a mobile network to save
> bandwidth; i.e throw away the stale branches, but not yet update the
> non-stale ones because downloading the objects might take a long time
> (and/or be expensive).
>
> So with that in mind, I actually think my patch makes sense in some
> cases, but it certainly is less useful that I originally though ;)
Strike that part; I hadn't had my morning coffee yet. It might make
sense to have similar _functionality_, but having this as a flag to
"git fetch" instead of "git remote prune" strikes me as the only sane
approach.
In fact, I'm not sure I understand why we simply do not always prune
by default. My guess would be backward compatibility, but this strikes
me as one of these things where we should introduce a config variable
(there's already one for git-gui: gui.pruneduringfetch), add a warning
if unset, and flip the default at some future major release. After
all, a remote branch isn't the user's branch - it's a cache/mirror
some other user's branch. If a user wants to keep another user's
branch, surely the most sane thing would be to make a local branch of
it?
^ permalink raw reply
* Re: [RFC/PATCH] git checkout $tree path
From: Jeff King @ 2011-10-04 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmxdigirk.fsf@alter.siamese.dyndns.org>
On Mon, Oct 03, 2011 at 09:08:31AM -0700, Junio C Hamano wrote:
> We can think of it both ways, but the "make it look like the other one"
> unfortunately is too big a departure from the traditional semantics. At
> least I wanted "checkout master -- $path" to mean "I want to copy $path
> out of master and _overlay_ that on top of what I have now", similar to
> the way how "tar xf master.tar $path" and "cp -r ../master/$path $path"
> would be used, so that the command can help the user advance what is in
> progress and already underway in $path in the current working tree.
Yeah, I think the "overlay" semantics at least makes some sense. The
strongest argument for "replace" semantics is that "git reset <path>"
uses them, and it would be nice if they were consistent. But I agree
that the overlay is closer to what happens now.
> Replacing could be easily done with "git rm -r [--cached] $path" followed
> by "git checkout $tree $path" under the original semantics, but overlaying
> is not very easily done if "git checkout $tree $path" had your "make $path
> look like it does in $tree" semantics.
True.
> The change brought in by the RFC/PATCH does change the behaviour, and I am
> fairly comfortable now to say that it is a bugfix ("copy and overlay" a la
> "tar xf" never clobbers/removes files not in the source, but the current
> code does).
That sounds good to me, and I think properly doing a pure overlay is way
better than the prior behavior.
This is sufficiently tricky and subtle that it is probably worth
future-proofing with some tests (e.g., the example you gave in the
commit message).
-Peff
^ permalink raw reply
* Re: Git mailing list admin wanted! :)
From: Alexey Shumkin @ 2011-10-04 7:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqty7pdy83.fsf@bauges.imag.fr>
Hmm
Now I set up SMTP-settings (duplicated ones, unfortunately; which I
was trying to avoid) for NNTP-account,
and it seems everything is ok now.
but the question "What was wrong?" still exists.
> Alexey Shumkin <alex.crezoff@gmail.com> writes:
>
> > Hello, list!
> >
> > I have a trouble with postings to this mailing list.
> > I can post from mutt or git-send-email,
> > but not from claws-mail email-client (and only claws-mail, sic!)
> > Messages are gone ok, CC account got that messages but not git list.
>
> Was the message plain text, or HTML?
>
^ permalink raw reply
* Re: [PATCH/RFC] remote: support --all for the prune-subcommand
From: Jeff King @ 2011-10-04 7:56 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
In-Reply-To: <CABPQNSb7NYTac5uWSegK9rmYz1n0yt1GJWHKUtLg1k_OYHdDNg@mail.gmail.com>
On Tue, Oct 04, 2011 at 09:40:22AM +0200, Erik Faye-Lund wrote:
> > Hmm, you might want to do that on, say, a mobile network to save
> > bandwidth; i.e throw away the stale branches, but not yet update the
> > non-stale ones because downloading the objects might take a long time
> > (and/or be expensive).
> >
> > So with that in mind, I actually think my patch makes sense in some
> > cases, but it certainly is less useful that I originally though ;)
>
> Strike that part; I hadn't had my morning coffee yet. It might make
> sense to have similar _functionality_, but having this as a flag to
> "git fetch" instead of "git remote prune" strikes me as the only sane
> approach.
I agree that "git fetch --prune-only" (or something similar) would be a
natural way to do it.
> In fact, I'm not sure I understand why we simply do not always prune
> by default.
I think the original rationale was that we didn't want fetch to be
"lossy". That is, if I were using upstream's "foo" branch as part of my
work (to diff against, or whatever), then doing a "git fetch" to update
should not suddenly make it hard to do my work. And not just hard as in
"I notice that it's gone and I adapt my workflow". But that you no
longer have _any_ record of where upstream's "foo" branch used to point,
so even doing something like:
git rebase --onto new-foo foo my-topic
is impossible.
These days we have reflogs, so you would hope to do something like:
git rebase --onto new-foo foo@{1} my-topic
But ref deletion also deletes the reflog completely, so that doesn't
work.
The right solution, IMHO, is that ref deletion should actually keep the
reflog around in a graveyard of some sort. Entries would expire
naturally over time, as they do in regular reflogs. And then it becomes
a lot safer to prune on every fetch, because you still have 90 days look
at the reflog.
There is still one sticky point, which is that your branch config may
refer to an upstream branch that gets pruned. That will break some
operations (as well it should, as the branch is gone, and the user needs
to adapt their config appropriately). It might be nice if we noticed
when accessing a ref that it doesn't exist but has a deleted reflog, so
we can give the user better advice.
> If a user wants to keep another user's branch, surely the most sane
> thing would be to make a local branch of it?
Unfortunately there are some management problems there. How do I keep my
local branch up to date with what I fetch? I have to keep checking out
and merging on every fetch (or use some plumbing), which is a pain. But
if I don't, then when the upstream branch goes away, I still have no
clue where its tip was right before it got pruned.
-Peff
^ permalink raw reply
* Re: Unable to remove a file
From: Zbigniew Jędrzejewski-Szmek @ 2011-10-04 7:57 UTC (permalink / raw)
To: robert mena; +Cc: Andreas Schwab, git
In-Reply-To: <CAAZ43xa43YjO7Vqw87cYnXhJWvsZT_ocPpLuJ81jCPc8KKRczw@mail.gmail.com>
On 10/03/2011 10:57 PM, robert mena wrote:
> Thanks.
>
> It accepted the command but rejected my push.
>
> git filter-branch --index-filter 'git rm -q --ignore-unmatch --cached
> scripts/\\' HEAD
> Rewrite 5ac83187fa298add60cf81fd1d54b194da7ae783 (57/57)
> Ref 'refs/heads/master' was rewritten
> git push
> ! [rejected] master -> master (non-fast-forward)
> error: failed to push some refs to 'git@myserver:repository'
>
> Should I do anything special?
git push -f
Zbyszek
>
> On Mon, Oct 3, 2011 at 12:04 PM, Andreas Schwab<schwab@linux-m68k.org> wrote:
>> robert mena<robert.mena@gmail.com> writes:
>>
>>> I found the command filter but it is not working.
>>>
>>> git filter-branch --index-filter 'git rm --cached scripts/\\' HEAD
>>
>> $ git filter-branch --index-filter 'git rm -q --ignore-unmatch --cached scripts/\\' HEAD
>>
>> Andreas.
>>
>> --
>> Andreas Schwab, schwab@linux-m68k.org
>> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
>> "And now for something completely different."
>>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: pack-object poor performance (with large number of objects?)
From: Piotr Krukowiecki @ 2011-10-04 7:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, Git Mailing List, Ingo Molnar
In-Reply-To: <7v62k5g988.fsf@alter.siamese.dyndns.org>
On Mon, Oct 3, 2011 at 9:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> This is on my box [*1*] that is idle (other than running the repack). The
> above is starting from an already reasonably well packed state and reuses
> deltas; with "-f" to repack everything from scratch it would take
> significantly longer:
>
> linux-3.0/master$ time git repack -a -d -f
> Counting objects: 2138578, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (2118691/2118691), done.
> Writing objects: 100% (2138578/2138578), done.
> Total 2138578 (delta 1749156), reused 344219 (delta 0)
>
> real 3m26.750s
> user 8m41.857s
> sys 0m6.716s
I've run the command and it took about 20 minutes in "Counting
objects" to count up to 500000 on idle machine and there's still 700MB
RAM free.
I wonder, when you do the repacking from a packed state, does it
physically create files on file system? In my case I have lots of
files in objects dir:
$ ls objects/ | wc -l
258
$ ls objects/00 | wc -l
6173
When I tried 'find objects | wc -l' previously (when repack was not
running) it got "stuck" too and I got impatient and killed it ;)
So it looks it's not a problem with git but rather with my disk/file
system/linux...
--
Piotr Krukowiecki
^ permalink raw reply
* Re: Git mailing list admin wanted! :)
From: Alexey Shumkin @ 2011-10-04 8:04 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <20111004114529.5fb10939@ashu.dyn.rarus.ru>
For the history:
I've got a message from Gmane Autoauthorizer <auth@gmane.org>
Now, test message as it was before
> Hmm
>
> Now I set up SMTP-settings (duplicated ones, unfortunately; which I
> was trying to avoid) for NNTP-account,
> and it seems everything is ok now.
>
> but the question "What was wrong?" still exists.
>
> > Alexey Shumkin <alex.crezoff@gmail.com> writes:
> >
> > > Hello, list!
> > >
> > > I have a trouble with postings to this mailing list.
> > > I can post from mutt or git-send-email,
> > > but not from claws-mail email-client (and only claws-mail, sic!)
> > > Messages are gone ok, CC account got that messages but not git
> > > list.
> >
> > Was the message plain text, or HTML?
> >
>
^ permalink raw reply
* Re: Git mailing list admin wanted! :)
From: Alexey Shumkin @ 2011-10-04 8:06 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <20111004120416.3cfa266c@ashu.dyn.rarus.ru>
works!
))
Sorry for the noise and such a monologue
> For the history:
> I've got a message from Gmane Autoauthorizer <auth@gmane.org>
>
> Now, test message as it was before
>
> > Hmm
> >
> > Now I set up SMTP-settings (duplicated ones, unfortunately; which I
> > was trying to avoid) for NNTP-account,
> > and it seems everything is ok now.
> >
> > but the question "What was wrong?" still exists.
> >
> > > Alexey Shumkin <alex.crezoff@gmail.com> writes:
> > >
> > > > Hello, list!
> > > >
> > > > I have a trouble with postings to this mailing list.
> > > > I can post from mutt or git-send-email,
> > > > but not from claws-mail email-client (and only claws-mail, sic!)
> > > > Messages are gone ok, CC account got that messages but not git
> > > > list.
> > >
> > > Was the message plain text, or HTML?
> > >
> >
>
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Michael Haggerty @ 2011-10-04 8:08 UTC (permalink / raw)
To: Martin Fick
Cc: Junio C Hamano, git, Christian Couder, Thomas Rast,
René Scharfe, Julian Phillips
In-Reply-To: <3e4aa1b3-5b14-4446-ac83-cef41c18a11f@email.android.com>
On 10/03/2011 02:46 AM, Martin Fick wrote:
> Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> I
>> also have some code (not pushed) that adds some intelligence to make
>> the use case
>>
>> repeat many times:
>> check if reference exists
>> add reference
>
> Would it be possible to separate the two steps into separate loops somehow? Could it instead look like this:
>
>> repeat many times:
>> check if reference exists
>
>> repeat many times:
>> add reference
Undoubtedly this would be possible. But I'd rather make the refs code
efficient and general enough that its users don't need to worry about
such things.
> [...] Of course, this would likely require checking for dups
> before running the first loop.
Yes, and this "checking for dups before running the first loop" is
approximately the same work that would have to be done within a smarter
version of the refs code.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Michael Haggerty @ 2011-10-04 8:16 UTC (permalink / raw)
To: Martin Fick
Cc: git, Christian Couder, Thomas Rast, René Scharfe,
Julian Phillips
In-Reply-To: <201110031212.13900.mfick@codeaurora.org>
On 10/03/2011 08:12 PM, Martin Fick wrote:
> On Friday, September 30, 2011 04:06:31 pm Martin Fick wrote:
>> OK, I narrowed it down I believe. If I comment out the
>> invalidate_cached_refs() line in write_ref_sha1(), it
>> speeds through this section.
>>
>> I guess this makes sense, we invalidate the cache and
>> have to rebuild it after every new ref is added?
>> Perhaps a simple fix would be to move the invalidation
>> right after all the refs are updated? Maybe
>> write_ref_sha1 could take in a flag to tell it to not
>> invalidate the cache so that during iterative updates it
>> could be disabled and then run manually after the
>> update?
>
> Would this solution be acceptable if I submitted a patch to
> do it? My test shows that this will make a full fetch of
> ~80K changes go from 4:50min to 1:50min,
No, no, no. Let's fix up the refs cache once and for all and avoid
adding special case code all over the place.
* With minor changes, we can make it possible to invalidate single refs
instead of the whole the refs cache. And we can teach the refs code to
invalidate refs by itself when necessary, so that other code can become
stupider and more decoupled from the refs code.
* With other minor changes (mostly implemented), we can support a
partly-sorted refs list that decides intelligently when to resort
itself. This will give most of the performance benefit of circumventing
the refs cache API with none of the chaos.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] po/pl.po: Eliminate fuzzy translations
From: Zbigniew Jędrzejewski-Szmek @ 2011-10-04 8:23 UTC (permalink / raw)
To: Jakub Narebski
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Marcin Cieślak
In-Reply-To: <201110032337.09975.jnareb@gmail.com>
On 10/03/2011 11:37 PM, Jakub Narebski wrote:
+# Terminologia dla kluczowych terminów z Subversion:
+# path - ścieżka
+# URL - URL
+# file - plik
+# directory - katalog
+# update - aktualizacja
+# commit - zatwierdzenie, zatwierdzenie zmian
This seems kind of awkward. E.g. 'initial commit' would become
'początkowe zatwierdzenie zmian' or 'pierwsze zatwierdzenie', which just
doesn't sound right. What about starting with the mercurial term
'changeset'? Git users also use 'commit' to mean 'change', so maybe
the polish translation of this crucial term should be 'zmiana':
'initial commit' -- 'początkowa zmiana' or 'pierwsza zmiana'
'commit message' -- 'opis zmiany'
+# version control - zarządzanie wersjami
+# repository - repozytorium
+# branch - odgałęzienie
'gałąź'? I think that's the translation which is used in informal
conversations.
+# tag - tag
'metka', 'etykieta' according to the dictionary. I'm aware of 'metka'
being used in CS anywhere, but it is short, and pretty cool, IMO.
+# merge - łączenie zmian
'łączenie gałęzi'?
+# conflict - konflikt
+# property - atrybut
+# revision - wersja
+# log message - opis zmian
+# entry/item - element
+# ancestry - pochodzenie
+# ancestor - przodek
+# working copy - kopia robocza
+# working dir - bieżący katalog
+# usage - wykorzystanie
'użycie', 'wywołanie'?
E.g. 'standardowe wywołanie tego programu to: prog arg'
+# source - źródłowy
+# destination - docelowy
+# hook - skrypt (skrypt repozytorium)
+# exclude - wykluczyć
+# crop - obciąć
+# cache - pamięć podręczna
+# child - obiekt podrzędny
Standard CS term is 'ojciec' and 'syn' for 'parent/child'.
+# obliteration - obliteracja
'wymazanie'?
+# patch - łata
+# notes - adnotacja
Zbyszek
^ permalink raw reply
* Re: [PATCH/RFC] remote: support --all for the prune-subcommand
From: Erik Faye-Lund @ 2011-10-04 8:22 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111004075608.GC7308@sigill.intra.peff.net>
On Tue, Oct 4, 2011 at 9:56 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Oct 04, 2011 at 09:40:22AM +0200, Erik Faye-Lund wrote:
>> In fact, I'm not sure I understand why we simply do not always prune
>> by default.
>
> I think the original rationale was that we didn't want fetch to be
> "lossy". That is, if I were using upstream's "foo" branch as part of my
> work (to diff against, or whatever), then doing a "git fetch" to update
> should not suddenly make it hard to do my work. And not just hard as in
> "I notice that it's gone and I adapt my workflow". But that you no
> longer have _any_ record of where upstream's "foo" branch used to point,
> so even doing something like:
>
> git rebase --onto new-foo foo my-topic
>
> is impossible.
>
Following that logic, a user cannot _ever_ safely prune a remote if he
wants to work on some of the branches. Doing something like "git
remote foo -n" to check if the branch would get pruned before doing a
proper prune is prone to a race-condition; the branch could be deleted
on the remote between the dry-run and the actual pruning.
Besides, the owner of the repo can just as easily have deleted the
branch and created a new one with the same name, causing the contents
of the branch to be lost. This happens all the time with
"for-upstream"-kind of branches, no?
> These days we have reflogs, so you would hope to do something like:
>
> git rebase --onto new-foo foo@{1} my-topic
>
> But ref deletion also deletes the reflog completely, so that doesn't
> work.
>
...and this just makes the problem I pointed out above a lot worse.
So surely, the only sane thing is to make a local branch of what
you're interested in to be safe?
> The right solution, IMHO, is that ref deletion should actually keep the
> reflog around in a graveyard of some sort. Entries would expire
> naturally over time, as they do in regular reflogs. And then it becomes
> a lot safer to prune on every fetch, because you still have 90 days look
> at the reflog.
>
Fixing the reflog to expire for ref deletion rather than completely
deleting it sounds like a good move, indeed.
>> If a user wants to keep another user's branch, surely the most sane
>> thing would be to make a local branch of it?
>
> Unfortunately there are some management problems there. How do I keep my
> local branch up to date with what I fetch? I have to keep checking out
> and merging on every fetch (or use some plumbing), which is a pain. But
> if I don't, then when the upstream branch goes away, I still have no
> clue where its tip was right before it got pruned.
Hmm, good point. I tend to just do the dirty work every now and then
myself. But I only tend to track upstream and stale
development-branches that I intend to pick up, so I'm probably not the
best user-example.
While we're on the subject, an additional argument to change "git
fetch" to always prune is that it's much much easier for user to grok
"last known state of <remote>'s branches" than "the union of all the
branches that were ever pulled from <remote>, unless --prune was
specified". But that's not a technical one, and surely there's issues
to resolve with the proposal before going in that direction.
^ permalink raw reply
* Re: [PATCH] git-completion: offer references for 'git reflog'
From: Michael Schubert @ 2011-10-04 8:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <4E7F05A6.30505@elegosoft.com>
On 09/25/2011 12:42 PM, Michael Schubert wrote:
> 'git reflog <ref>' is a valid command, therefore offer reference
> completion.
>
> Signed-off-by: Michael Schubert <mschub@elegosoft.com>
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 8648a36..63d0f08 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1774,7 +1774,7 @@ _git_reflog ()
> local subcommand="$(__git_find_on_cmdline "$subcommands")"
>
> if [ -z "$subcommand" ]; then
> - __gitcomp "$subcommands"
> + __gitcomp "$subcommands $(__git_refs)"
> else
> __gitcomp "$(__git_refs)"
> fi
Ping.?
^ permalink raw reply
* Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: Jeff King @ 2011-10-04 10:16 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Junio C Hamano, John Szakmeister
In-Reply-To: <CAG+J_DxAaw=vVENFUP5Mq9+inuDEpn_3Le_b7sO97wRUW6aFSA@mail.gmail.com>
On Mon, Oct 03, 2011 at 09:13:12AM -0400, Jay Soffian wrote:
> > Yeah. I was thinking the ACL prompt would come up more often, but I
> > guess most people would hit "allow always", since it would get annoying
> > pretty quickly otherwise (I didn't, because I was testing).
>
> In the normal case, the keychain entry would be added via the
> credential helper, so they'd never even see the prompt since the
> binary which adds an entry is automatically on that entry's ACL.
Ah, that makes sense. That wasn't what happened for me; the first time I
ran it, before I had ever given it a password, it asked if it could
access the login keychain. But that was because I _already_ had an entry
there from the GitHub for Mac client.
So I assume it was typical that most users would see it at least that
first time. But it's probably not.
> > Side note: do you know how to edit those ACLs? I couldn't find it in the
> > keychain manager. It would be helpful for testing to be able to tweak it
> > (as a workaround, I just modified the binary, which apparently the
> > keychain code cares about).
>
> Double-click on the entry in Keychain Access, then click the "Access
> Control" tab.
Thanks. For some reason I was thinking the ACL was based on the
keychain, but of course having it per-entry makes much more sense. So I
was just looking in the wrong place.
-Peff
^ permalink raw reply
* Git ksshaskpass to play nice with https and kwallet
From: Michael J Gruber @ 2011-10-04 10:19 UTC (permalink / raw)
To: Git Mailing List
Checking out bitbucket and https, I came across a stupid issue between
the default KDE setup (SSH_ASKPASS=/usr/bin/ksshakspass and KDE wallet)
and the way we call the askpass helper, which makes the combo not work
out of the box.
For those interested in getting it to work (or learning why it does not
work out of the box), you can read the details formatted on my sparse
blog (brain dump)
http://grubix.blogspot.com/2011/10/git-ksshaskpass-to-play-nice-with-https.html
or below if you don't feel like clicking through.
Cheers
Michael
By default (with GIT_ASKPASS not set etc.), Git invokes $SSH_ASKPASS
when it needs to ask you for credential info. In a KDE environment,
SSH_ASKPASS is set to /usr/bin/ksshaskpass. So far so good.
But Git calls the askpass helper with a command line like
/usr/bin/ksshaskpass Username for 'bitbucket.org':
and once again with
/usr/bin/ksshaskpass Password for 'bitbucket.org':
So far so good.
But when asked to store the credentials in the KDE wallet, ksshaskpass
tries (too) hard to guess a good key from that line. And for both
invocations, it comes up with the same key (the URL), so that when the
password info is needed, the username info from the wallet is returned.
Authentication fails.
Far from good.
If you still want to use the KDE helpers, you can save the little snippet
#!/bin/bash
set $*
exec ksshaskpass $1\@$3
into ~/bin/git-ksshaskpass (and make it executable) and set
git config --global core.askpass ~/bin/git-ksshaskpass
Gitcha!
NB:
tested and works with https
not tested with other methods (use ssh-agent)
new credential helper interface coming in Git after 1.7.7
^ permalink raw reply
* Re: Unable to remove a file
From: John Szakmeister @ 2011-10-04 10:24 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: robert mena, Andreas Schwab, git
In-Reply-To: <4E8ABC85.7090705@in.waw.pl>
2011/10/4 Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
[snip]
>> git filter-branch --index-filter 'git rm -q --ignore-unmatch --cached
>> scripts/\\' HEAD
>> Rewrite 5ac83187fa298add60cf81fd1d54b194da7ae783 (57/57)
>> Ref 'refs/heads/master' was rewritten
>> git push
>> ! [rejected] master -> master (non-fast-forward)
>> error: failed to push some refs to 'git@myserver:repository'
>>
>> Should I do anything special?
>
> git push -f
I assume you understand that you're rewriting history Robert, and that
has some consequences? You're master branch is now divergent, since
the commit ids changed.
-John
^ permalink raw reply
* Re: [RFC/PATCH]: reverse bisect v 2.0
From: Jeff King @ 2011-10-04 10:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michal Vyskocil, git, Sverre Rabbelier, Johannes Sixt,
Christian Couder
In-Reply-To: <7vfwjaggd2.fsf@alter.siamese.dyndns.org>
On Mon, Oct 03, 2011 at 10:00:25AM -0700, Junio C Hamano wrote:
> > I like this idea a lot. My "yes/no" thing was a "if I were designing
> > bisect from scratch today..." suggestion, but having something like
> > --used-to makes it a natural addition to the regular good/bad interface.
> > And I really like the prompt to help people remember what it is they're
> > declaring each time.
>
> I forgot to clarify that "tested" was only to help users who wanted
> reminder; if the user is confident with the usual "yes/no", the
> interactivity is not required.
That makes sense to me. I think in either case, it would be nice to
mention the --used-to text when we take each step. We're already
outputting some status information there (like how many commits left).
> > However, --used-to feels a bit backwards to me. I think of it as
> > "--has-property" or something similar.
>
> I do not think --used-to='frotz says xyzzy' is a good phrasing at all; it
> is grammatically incorrect. But --has-property has one large downside. At
> least --used-to makes it clear that the user is supposed to decribe the
> property of the tree in the past.
>
> Let's step back a bit to understand why I think this is not optimal.
What you say makes sense, but isn't it just a problem of the name? IOW,
a much better name than "--has-property" would be "--started-to". That
would imply the exact same cutoff as --used-to, but negate only the
yes/no bit.
So you could say:
# find a bug:
git bisect start --used-to='work with --foo=bar'
# or if you are looking for a specific undesirable behavior, you might
# write:
git bisect start --used-to='not segfault with --foo=bar'
# but now you have a negation in your condition. So it might be more
# natural to write it as:
git bisect start --started-to='segfault with --foo=bar'
# Or we can find a feature
git bisect start --used-to='not respect core.foo'
# but again, we have a negation. Instead:
git bisect start --started-to='respect core.foo'
And the --started-to would literally be implemented as flipping the
meaning of "git bisect yes" and "git bisect no", and nothing more. IOW,
it's just another way of spelling "git bisect --reverse".
I know you wanted to emphasize the "older tree has this property" of
--used-to, but I think it is clear with --started-to that the older tree
obviously obviously had the negation of the property.
-Peff
^ permalink raw reply
* Re: [BUG?] git fetch -p -t prunes all non-tag refs
From: Carlos Martín Nieto @ 2011-10-04 10:33 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, mathstuf, git
In-Reply-To: <20110927033134.GB8534@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]
On Mon, 2011-09-26 at 23:31 -0400, Jeff King wrote:
> On Tue, Sep 27, 2011 at 01:28:09AM +0200, Carlos Martín Nieto wrote:
>
> > > term I think we should fix it properly. We are already learning "what are
> > > the refs the remote side currently has" from the transport and the right
> > > fix ought to be to use that original information, not the version filtered
> > > for the use of the primary objective of fetch, which is to only fetch what
> > > the user asked for.
> >
> > Do you mean that we should ignore the refspec? Or do you mean that we
> > should look at the refspec if it exists, and only consider deleting
> > those that meet the refspec, so that `--prune --tags` would only delete
> > tags that don't exist in the remote?
>
> The latter. If I say:
>
> git fetch --prune origin refs/heads/master:refs/remotes/origin/master
>
> and refs/heads/master doesn't exist on the remote, I would expect
> refs/remotes/origin/master to be deleted locally. And that naturally
> extends to:
>
> git fetch --prune origin refs/heads/*:refs/remotes/origin/*
I have some code locally that solves this second part. If we are given
refspecs on the command-line, it will try to match against that instead
of blindly trusting what get_stale_heads tells us. I'm looking into
putting the logic into get_stale_heads so that we can trust it.
The first part might be more complicated. If the remote head doesn't
exist, get_fetch_map dies. It does take a missing_ok flag, so it might
be as easy as passing 1 there; but I'm not sure what that would do for a
non-prune fetch.
>
> We do something similar with "git push --mirror", which does pruning
> like this[1].
>
> -Peff
>
> [1] Actually, I'm not sure how correct "push --mirror" is. It would be
> nice if the prune operation could be split from the mirror, too. In
> the past, I have wanted to do both:
>
> # backup to a repository where our objects will be shared
> # with other related backups. So we must only use our slice of the
> # ref namespace.
> git push --mirror backup-repo +refs/*:refs/`hostname`/*
Is --mirror needed there? I would have thought that
refs/*:refs/`hostname`/* would do the same by itself.
>
> and:
>
> # update topic branches we have already published (using the
> # "matching" refspec), but remove any that we have deleted
> # locally.
> git push --mirror publish-point +:
>
> and I don't think either works.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [BUG?] git fetch -p -t prunes all non-tag refs
From: Jeff King @ 2011-10-04 10:36 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Junio C Hamano, mathstuf, git
In-Reply-To: <1317724404.2577.6.camel@bee.lab.cmartin.tk>
On Tue, Oct 04, 2011 at 12:33:22PM +0200, Carlos Martín Nieto wrote:
> > The latter. If I say:
> >
> > git fetch --prune origin refs/heads/master:refs/remotes/origin/master
> >
> > and refs/heads/master doesn't exist on the remote, I would expect
> > refs/remotes/origin/master to be deleted locally. And that naturally
> > extends to:
> >
> > git fetch --prune origin refs/heads/*:refs/remotes/origin/*
>
> I have some code locally that solves this second part. If we are given
> refspecs on the command-line, it will try to match against that instead
> of blindly trusting what get_stale_heads tells us. I'm looking into
> putting the logic into get_stale_heads so that we can trust it.
>
> The first part might be more complicated. If the remote head doesn't
> exist, get_fetch_map dies. It does take a missing_ok flag, so it might
> be as easy as passing 1 there; but I'm not sure what that would do for a
> non-prune fetch.
Let's not worry about the first one for now, then. It is a natural
extension of the other, but in practice, I don't expect people to really
care that much about auto-pruning one specific ref. Instead, they want
to prune wildcards. So as long as it works in the wildcard case, that is
a good start.
> > # backup to a repository where our objects will be shared
> > # with other related backups. So we must only use our slice of the
> > # ref namespace.
> > git push --mirror backup-repo +refs/*:refs/`hostname`/*
>
> Is --mirror needed there? I would have thought that
> refs/*:refs/`hostname`/* would do the same by itself.
I wanted it to auto-prune the remote branches. So if I delete
"refs/heads/foo" locally, then it will be deleted from the backup on the
next push. Regular "push" will not do that, but --mirror will.
-Peff
^ permalink raw reply
* Award Number: HL-001655NL
From: Dr.Mary Simon @ 2011-10-04 10:33 UTC (permalink / raw)
You have won the sum of 550,000.00euros from LuckyDay lottery 2011 Year bonanza award.You are to contact him with your details below:
1.Ref Number:67218/501-4242/ES
2.Batch Number:612775428-SN
3.Ticket Number:194463-85
4.Award Number: HL-001655NL
1.Name........Address ....................3.Age...........4.Occupation.........5.Phone/Fax................
Contact Person:Mr David Moolman
Email: chaletspl@aim.com
Tel:+31-647-226-334
Fax:+31-84-731-7577
Congratulations once again.
Regards,
Dr.Mary Simon
^ 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