From: Filippo Zangheri <filippo.zangheri@yahoo.it>
To: Rogan Dawes <lists@dawes.za.net>
Cc: "Shawn O. Pearce" <spearce@spearce.org>,
Jakub Narebski <jnareb@gmail.com>,
git@vger.kernel.org
Subject: Re: [QUESTION] Selective fetch possible?
Date: Tue, 11 Mar 2008 13:29:10 +0100 [thread overview]
Message-ID: <47D67B16.8040709@yahoo.it> (raw)
In-Reply-To: <47D64BE4.9010009@dawes.za.net>
Rogan Dawes ha scritto:
(...)
> I think that one should not *expect* to be able to complete merges with
> only a partial checkout, though. It *may* work in cases where there are
> no conflicts, but I think it would be a perfectly valid error path to
> fail if there is a conflicting merge in a part of the tree that has not
> been checked out.
>
> So, for a user working on partial trees, they would be able to modify
> their partial tree, and check in their changes, but merges would have to
> be done by someone with a complete checkout. For the given examples
> where partial trees make sense (documentation workers), this seems like
> a reasonable compromise.
I think this is what every reasonable developer should have in mind
when he's working on just a project subset :). And I also think,
this is not a valid reason for forbidding/not implementing such a
partial (or subtree) checkout.
--
Filippo Zangheri
GPG key ID: 0xE1D879FA
Key fingerprint: 816B CE57 D43C 0A47 EF35 3378 EA5F A72A E1D8 79FA
Key server: pgp.mit.edu
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GE d- s+:- a-- C++ UL+++ P+ L+++ E-- W+ N* o-- K- w--- O-- M--
V- PS++ PE+ Y+ PGP++ t 5-- X++ R* tv b+ DI-- D---- G-- e++ h--
r++ z*
------END GEEK CODE BLOCK------
prev parent reply other threads:[~2008-03-11 12:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-10 22:02 [QUESTION] Selective fetch possible? Filippo Zangheri
2008-03-10 22:53 ` Shawn O. Pearce
2008-03-10 23:34 ` Jakub Narebski
2008-03-11 7:26 ` Rogan Dawes
2008-03-11 7:50 ` Shawn O. Pearce
2008-03-11 9:07 ` Rogan Dawes
2008-03-11 12:29 ` Filippo Zangheri [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47D67B16.8040709@yahoo.it \
--to=filippo.zangheri@yahoo.it \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=lists@dawes.za.net \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.