Is there any plan to support partial checkout or submoudule improvement?

Here is my pain when using git without partial checkout and submodule
improvement.
	I want to manage src and compiled bin together consistently. And
when deploying, I don't need the src directory.
	My directory structure is like
	Project
         Src
         Bin
Following is two schemes I have considered
1. src, bin as two submoudles
	When changes are made in src, compiled binaries are put in bin
directory. So when I commit, I have to commit 3 times and write 3 commit
comments separately (in Project, src, bin). 
	I think if some improvement in submodule, this problem can be
avoided. For example, when committing in Project directory, all changes in
submoules are also automatically committed. Maybe a new subcommand
"git-submodule commit" to commit all submodules but share a single comment
and "git-commit -A" to commit both files and submodule?

2. src, bin not submoudle, just sub directory
	When src changes, compiled binaries are still put in bin directory.
However, only one commit is required. Perfect? No, another problem when
deploying. I don't want the src directory to appear in the deployment
directory. However, without partial checkout, I can't do that, since every
time bin and src directories are checked out together.

On 10/16/07, franky <yinping@kooxoo.com> wrote:

If this is just for deployment of your bin directory, you can try

$ cd Project/bin $ git archive --prefix='Project/bin/' HEAD | gzip > Project-x.y.tar.gz

-- larsh

It works. However, I want a single "git-pull" to deploy a new version and a single "git-reset" to back to versions before. So I need another resolution.

 franky

-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf
Of Lars Hjemli
Sent: Tuesday, October 16, 2007 4:08 PM
To: franky
Cc: git@vger.kernel.org
Subject: Re: Is there any plan to support partial checkout or submoudule
improvement?

On 10/16/07, franky <yinping@kooxoo.com> wrote:

directory.

If this is just for deployment of your bin directory, you can try

$ cd Project/bin $ git archive --prefix='Project/bin/' HEAD | gzip > Project-x.y.tar.gz

-- larsh

On 10/16/07, franky <yinping@kooxoo.com> wrote:

Well, there is always

$ git archive --remote=<repo> <revspec> <path> | tar -x

This is effectively a partial checkout of an arbitrary revision from a remote repo.

-- larsh

That's actually "a single command", but a little complex. And there still are some problems with this single command

1. each time is full checkout (not incremental), so bad performance for
large bin directory
2. I can't know deployment version easily and I can't use "git-log" to see
the log and to decide which version to back to when necessary.

I just find an ugly resolution:
1. git-clone host:project.git project
Cloned project is as follows (src, bin are subdir instead of submodule)
project
    src
    bin
    .git

2. cd project && rm -rf src
3. when project.git changed, then
   git-fetch && git-checkout origin/master bin

Unfortulately, it's annoying when I run git-status which complains "deleted: src ". And "git-log" will not show the newest log since git-checkout doesn't update the index file

So, the alternative for the 3rd step is
	git-pull && rm src

It's so ugly!

Suggestion 1: how about adding a paths option for git-status just like git-diff and git-log Suggestion 2: how about changes the default paths for "git-diff", "git-log" and so on from the "top dir with .git" to "the current dir"? So when I'm in bin directory and run "git-log", it will only report log or diff in bin directory. franky

On 10/16/07, franky <yinping@kooxoo.com> wrote:

The <revspec> can be a tag. So you can easily create a wrapper script to allow such things as

$ ./deploy.sh v1.2.3 $ ./deploy.sh HEAD $ ./deploy.sh master $ ./deploy.sh <sha1>

(note: for this to work with the git:// protocol, git-daemon needs --enable=upload-archive)

But it is an online services, I must take care, so I prefer the incremental update to avoid overwriting deployment directory fully each time. Another consideration, Full update also introduces the busy network traffic.

franky

Hi,

[please do not top post. Only keep the parts of the original message that you are responding to, and put your answers just below. It is a matter of simple economy: it takes you just a couple of minutes, but spares those "millions" of readers the minutes to understand what you're talking about. In addition, it is a matter of politeness.]

On Tue, 16 Oct 2007, franky wrote:

You are talking as if your partial checkout was a project in its own right. Then make it so. Do not use a partial checkout, but make that a submodule.

One reason _not_ to support partial checkouts is exactly to avoid people falling into that mousetrap of thinking that they can sensibly merge _parts_ of the HEAD.

Ciao, Dscho

Thanks for the hint, and I have corrected this.

As I said in the first email, the submodule way suffers from the multiple
commit problem: src and bin as two submodules of project, three commits (for
the 3 dirs separately) are needed when src directory changes and compiled
binaries being put in bin directory. It's annoying to have to give 3 commit
logs.
 
franky

On Tue, Oct 16, 2007 at 19:53:08 +0800, franky wrote:

Thinking about it, it's only two commits -- src can be a submodule, but bin a normal directory (you can choose not to check out subprojects during repository checkout).

This has the advantage, that bin, even when src is not checked out, always knows what version of src it is based on (it's in the gitlink) and you only give two commit messages.

Now I would actually say that commiting bin independently is better. It allows you to commit sources more often (eg. if you are doing series of small fixes) and more flexibility for branching (you don't want to merge binaries).

 franky

a

multiple

(for

compiled

commit

bin

Thanks for the advice. It's a good idea.

<bulb@ucw.cz>