* 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: [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
* 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/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] 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
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