[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multiple checkout copies
From: |
Ivan Shmakov |
Subject: |
Re: Multiple checkout copies |
Date: |
Tue, 03 Feb 2015 19:17:36 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
>>>>> David Kastrup <address@hidden> writes:
>>>>> Ivan Shmakov <address@hidden> writes:
>>>>> David Kastrup <address@hidden> writes:
[…]
>>> If you want to mirror the upstream, you'll use "git fetch -p" in
>>> order to have branches that are removed upstream to get deleted in
>>> the mirror as well.
>> And why would I want that,
> In order not to accumulate temporary branches that are no longer
> present in upstream?
How would the branches “accumulate” in the case git-fetch(1) is
given an explicit list of them to follow?
>> especially given that I’m already aware that a. some of the objects
>> may be used elsewhere (and thus such an operation would be
>> potentially unsafe) and b. the packs received from the remote are
>> likely to contain a mix of Git objects belonging to both removed and
>> extant branches,
> Why would they?
Because the development happens in several branches in parallel?
>> and it would thus /not/ be possible to remove them anyway?
>> And as for repacking such a mirror from time to time, — it’s going
>> to be a sure nuisance due to backup reasons, etc.
> Uh, it's going to get repacked anyway. Git does that without asking.
… Unless disabled with gc.auto = 0, gc.autopacklimit = 0.
>>> Even without -p, references in frequently rewritten work branches
>>> (like Git's pu or next branches) will disappear eventually.
>> Do fast-forward updates (which git-fetch(1) defaults to) ever result
>> in dangling Git objects?
> Maybe it would be worth checking the man pages before making such
> statements. It's just annoying when people spray arbitrary
> statements to the list and leave it to others to clean up.
> git-fetch does not merge in any manner and consequently also does not
> "fast-forward". It updates references after making them backed by
> the respective objects. You are confusing this with the git-pull
> action of updating a local branch based on a remote-tracking branch.
Well, would you then care to explain the wording of the Git
error message below?
+ git fetch -t origin master:master
>From git://github.com/XXX/XXX
! [rejected] master -> master (non-fast-forward)
Not to mention that git-fetch(1) explicitly uses this same term
(as of Git 2.1.4.)
I do not generally support the opinion that Git terminology is
confusing, but I find it quite possible that it may sometimes be
inconsistent at best. Maybe it’s just such a case.
> There is a very limited situation when using explicit branch names
> for source and target branch where git-fetch will only update a
> reference to a non-descendant when given the option -f.
Yes.
[…]
>> Also, I’m typically interested in mirroring just a few branches
>> (mostly ‘master’ and the latest stable, if any.) Per my experience,
>> such branches rarely (if ever) get “rewritten.”
> "I'm typically interested in" is no base for promoting problematic
> workflows since it violates the "do not use it unless you understand
> what it does" dictum for the recipient of such a recipe.
The whole idea behind this discussion is to clarify when
--shared is reasonable, — and when it isn’t. Isn’t it?
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
- Re: Multiple checkout copies, (continued)
- Re: Multiple checkout copies, Richard Stallman, 2015/02/02
- Re: Multiple checkout copies, Ivan Shmakov, 2015/02/03
- Re: Multiple checkout copies, Achim Gratz, 2015/02/03
- Re: Multiple checkout copies, David Kastrup, 2015/02/03
- Re: Multiple checkout copies, Achim Gratz, 2015/02/03
- Re: Multiple checkout copies, David Kastrup, 2015/02/03
- Re: Multiple checkout copies, Ivan Shmakov, 2015/02/03
- Re: Multiple checkout copies, David Kastrup, 2015/02/03
- Re: Multiple checkout copies, Ivan Shmakov, 2015/02/03
- Re: Multiple checkout copies, David Kastrup, 2015/02/03
- Re: Multiple checkout copies,
Ivan Shmakov <=
- Re: Multiple checkout copies, David Kastrup, 2015/02/03
- Re: Multiple checkout copies, Ivan Shmakov, 2015/02/03
- Re: Multiple checkout copies, Richard Stallman, 2015/02/04
- Re: Multiple checkout copies, Stefan Monnier, 2015/02/03
Re: Multiple checkout copies, Steinar Bang, 2015/02/03