* 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: 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: 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 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 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: 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: 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: [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: 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: [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: [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: 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: 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: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: [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: 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: Jeff King @ 2011-10-04 7:13 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
In-Reply-To: <CABPQNSZrfxhyA3em8TN2=d7pAHopZMgRg47baKnDT9h14=rxkA@mail.gmail.com>
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. Presumably you run "prune" after you
just fetched, anyway. Combining the two steps saves an extra network
connection.
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] remote: support --all for the prune-subcommand
From: Erik Faye-Lund @ 2011-10-04 7:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111004070006.GA6824@sigill.intra.peff.net>
On Tue, Oct 4, 2011 at 9:00 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 03, 2011 at 02:16:08PM +0200, Erik Faye-Lund wrote:
>
>> I recently needed to prune remote branches in a repo with a lot
>> of remotes, and to my surprise "git remote prune" didn't support
>> the --all option. So I added it. Perhaps this is useful for other
>> people as well?
>
> You could do:
>
> git remote update --prune
>
> But I thought we were trying to get away from remote doing fetch-like
> things in the long term. Isn't the "right" way to do this these days:
>
> git fetch --all --prune
>
> ?
>
> -Peff
>
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?
^ permalink raw reply
* Git mailing list admin wanted! :)
From: Alexey Shumkin @ 2011-10-04 7:10 UTC (permalink / raw)
To: git
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.
I wrote a message with a question about this to Lars Ingebrigtsen
<larsi@gnus.org> but he redirected me to "the admin for the git mailing
list"
>>From: Lars Ingebrigtsen <larsi@gnus.org>
>>To: Shumkin Alexey <alex.crezoff@gmail.com>
>>Subject: Re: Mail delivery to Git mailing list fails
>>Date: Fri, 30 Sep 2011 20:10:48 +0200
>>Shumkin Alexey <alex.crezoff@gmail.com> writes:
> I CC-ed my another account in one of the test messages and I got it on
> that another account. So, I suspect my account can be in a blacklist
> or
> something like that.
>
> Could you found out what is the problem?
>>Sorry; you'll have to take that up with the admin for the git mailing
>>>list.
Could anyone tell me who is the admin of this list?
Sorry for the offtopic, but I did not found another way to get an
answer.
Thanks in advance.
P.S. Advices to change email-client are not accepted ;;;)
^ permalink raw reply
* Re: Do we have a convenient way to refer to a specific commit in an already filtered rev-list?
From: Jeff King @ 2011-10-04 7:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tzu-Jung Lee, git
In-Reply-To: <7v1uutg8xw.fsf@alter.siamese.dyndns.org>
On Mon, Oct 03, 2011 at 12:40:43PM -0700, Junio C Hamano wrote:
> Tzu-Jung Lee <roylee17@gmail.com> writes:
>
> > And also teach the rev-list to parse or interpret the 'saved' refs differently.
> > So we can have the following use case:
> >
> > git log branch_foo --author=some_one -S some_string --saved=cached_ref
> > git log cached_ref
> > git cherry-pick cached_ref~4
> > git format-patch cached_ref~6..cached_ref~2
> >
> > I often have such use cases. not sure others would be benefited from
> > such feature.
> > Just asking for comment. :)
>
> It feels too much hackery for too little gain.
Agreed. It means that each entry in refs/saved is subtly _not_ a ref,
but rather a list of refs. Until now, most refs are considered equal
with respect to basic things like ref lookup. So if git were to save
this, I'm not sure refs/ would be the right place. A reflog would be a
bit closer in concept.
But I really don't see the need for git to handle this at all. There is
already a general solution:
> $ git log --oneline master..branch --author=A.U.Thor -Spickaxe >foos.txt
>
> and working from the text file foos.txt at least would not contaminate any
> ref namespace and you do not have to clean them after you are done.
Which works just as well, and is way more flexible. You have to be a
little more proficient in using the shell, but that is at least a
general skill which transfers to many other programs.
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] remote: support --all for the prune-subcommand
From: Jeff King @ 2011-10-04 7:00 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
In-Reply-To: <1317644168-5808-1-git-send-email-kusmabite@gmail.com>
On Mon, Oct 03, 2011 at 02:16:08PM +0200, Erik Faye-Lund wrote:
> I recently needed to prune remote branches in a repo with a lot
> of remotes, and to my surprise "git remote prune" didn't support
> the --all option. So I added it. Perhaps this is useful for other
> people as well?
You could do:
git remote update --prune
But I thought we were trying to get away from remote doing fetch-like
things in the long term. Isn't the "right" way to do this these days:
git fetch --all --prune
?
-Peff
^ permalink raw reply
* Re: [PATCH 7/9] po/hi.po: add Hindi Translation
From: Ramkumar Ramachandra @ 2011-10-04 4:55 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, Peter Krefting, Marcin Cieślak,
Sam Reed, Jan Engelhardt, Jan Krüger
In-Reply-To: <1317668297-2702-8-git-send-email-avarab@gmail.com>
Hi,
Ævar Arnfjörð Bjarmason writes:
> From: Ramkumar Ramachandra <artagnon@gmail.com>
> [...]
> Note that Devanagari rendering is broken on many applications by
> default at this time- the latest Emacs, Vim and Chrome render it
> incorrectly.
The latest Chrome seems to render it fine now. In retrospect, I don't
see what value this paragraph adds to the commit message- the first
paragraph should suffice.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH] request-pull: List the hash that results from merging onto baserev
From: Chris Ball @ 2011-10-04 3:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzkhhcufo.fsf@alter.siamese.dyndns.org>
Hi Junio,
On Mon, Oct 03 2011, Junio C Hamano wrote:
> Isn't the series leading to 7eb32b8 (request-pull: use the branch
> description, 2011-09-20) insufficient?
Yes, your series is much better; sorry for the noise. I didn't know
about the work in 'pu', but see now that I should have looked there.
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* Re: [PATCH] request-pull: List the hash that results from merging onto baserev
From: Junio C Hamano @ 2011-10-04 3:22 UTC (permalink / raw)
To: Chris Ball; +Cc: git
In-Reply-To: <m28vp1msth.fsf@bob.laptop.org>
Isn't the series leading to 7eb32b8 (request-pull: use the branch
description, 2011-09-20) insufficient?
^ permalink raw reply
* [PATCH] request-pull: List the hash that results from merging onto baserev
From: Chris Ball @ 2011-10-04 1:47 UTC (permalink / raw)
To: git
This patch modifies the request-pull message to contain both the base
hash and the top commit hash that results when the new commits are
merged onto that base.
The motivation for doing this is to turn cryptographically signing a
pull request into an operation that enables detection of commits having
been maliciously altered before being downloaded. Before this patch, a
pull request contained only a list of commit names and a diffstat; this
is not sufficient to detect subsequent alteration of the changed files.
After this patch, the person merging may choose to rewind to $baserev,
apply the received commits, and check that the resulting hash matches.
Signed-off-by: Chris Ball <cjb@laptop.org>
---
git-request-pull.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index fc080cc..9a686a5 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -73,6 +73,9 @@ are available in the git repository at:' $baserev &&
echo " $url $branch" &&
echo &&
+echo "(Applying these commits produces hash $headrev)" &&
+echo &&
+
git shortlog ^$baserev $headrev &&
git diff -M --stat --summary $patch $merge_base..$headrev || exit
exit $status
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox