From: Rogan Dawes <lists@dawes.za.net>
To: Andy Parkins <andyparkins@gmail.com>
Cc: git@vger.kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Christoph Duelli <duelli@melosgmbh.de>
Subject: Re: restriction of pulls
Date: Fri, 09 Feb 2007 18:36:17 +0200 [thread overview]
Message-ID: <45CCA301.4060504@dawes.za.net> (raw)
In-Reply-To: <200702091619.23058.andyparkins@gmail.com>
Andy Parkins wrote:
> On Friday 2007 February 09 15:32, Rogan Dawes wrote:
>
>> One obstacle to implementing partial checkouts is that one does not know
>> which objects have changed or been deleted. One way of addressing this
>
> Why would you want to do a partial checkout. I used subversion for a long
> time before git, which does to partial checkouts and it's a nightmare.
>
> Things like this
>
> cd dir1/
> edit files
> cd ../dir2
> edit files
> svn commit
> * committed revision 100
>
> KABLAM! Disaster. Revision 100 no longer compiles/runs. The changes in dir1
> and dir2 were complimentary changes (say like renaming a function and then
> the places that call that function).
Please note that my suggestion does NOT imply allowing partial checkins
(or if it does, it was not my intention)
What I am trying to support is Jon Smirl's description of how some
Mozilla contributors work, specifically the documentation folks.
They do not have any need to look at the actual code, but simply limit
themselves to the files in the doc/ directory.
Supporting a partial checkout of this doc/ directory would allow them to
get a "check in"-able subdirectory, without having to download the rest
of the source.
What I intended to convey was that when determining which files have
changed, and presenting them to the user to decide whether to commit
them or not, the filesystem-walker would first check the "negative
index" to see if that directory/file had been explicitly excluded from
the checkout. This implies that they did not (and do not intend to)
modify that portion of the tree. Which implies that the committer can
then construct a complete view of the entire tree (now including the
changes that were made in the partial checkout) by resolving the
modified files with the knowledge of the hashes of the unmodified
files/trees.
>
> In every way that matters you can do a partial checkout - I can pull any
> version of any file out of the repository. However, it should certainly not
> be the case that git records that fact.
Why not? If you only want to modify that file, does it not make sense
that you can just check out that file, modify it, and check it back in?
Or at least if not check it in, construct a diff for mailing to the
maintainer?
Or even, allowing the maintainer to pull/merge the changes from the
contributor, even though the contributor doesn't necessarily have all
the blobs required to make up the tree he is committing? They should all
be available from the "alternate" if required.
Rogan
next prev parent reply other threads:[~2007-02-09 16:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-09 10:49 restriction of pulls Christoph Duelli
2007-02-09 11:19 ` Jakub Narebski
2007-02-09 14:54 ` Johannes Schindelin
2007-02-09 15:32 ` Rogan Dawes
2007-02-09 16:19 ` Andy Parkins
2007-02-09 16:36 ` Rogan Dawes [this message]
2007-02-09 16:45 ` Andy Parkins
2007-02-09 17:32 ` Rogan Dawes
2007-02-10 9:59 ` Andy Parkins
2007-02-10 14:50 ` Johannes Schindelin
2007-02-12 13:58 ` Rogan Dawes
2007-02-12 14:13 ` Johannes Schindelin
2007-02-12 14:29 ` Rogan Dawes
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45CCA301.4060504@dawes.za.net \
--to=lists@dawes.za.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=andyparkins@gmail.com \
--cc=duelli@melosgmbh.de \
--cc=git@vger.kernel.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).