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 [off-list ref] wrote:

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.

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 [off-list ref] wrote:

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.

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 [off-list ref] wrote:

I want a single "git-pull" to deploy a new version and a
single "git-reset" to back to versions before

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

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.

--

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 [off-list ref] wrote:

lars said:

quoted

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

I can't know deployment version easily

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)

-- 
larsh

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:

I want a single "git-pull" to deploy a new version and a
single "git-reset" to back to versions before [on partial checkouts]

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

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>

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

[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.]

Thanks for the hint, and I have corrected this.

On Tue, 16 Oct 2007, franky wrote:

quoted

I want a single "git-pull" to deploy a new version and a
single "git-reset" to back to versions before [on partial checkouts]

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.

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

-
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

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

quoted

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.

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.

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).

-- 
						 Jan 'Bulb' Hudec [off-list ref]

 franky

-----Original Message-----
From: Jan Hudec [mailto:bulb@ucw.cz]
Sent: Wednesday, October 17, 2007 5:34 AM
To: franky
Cc: 'Johannes Schindelin'; 'Lars Hjemli'; git@vger.kernel.org
Subject: Re: Is there any plan to support partial checkout or
submouduleimprovement?

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

quoted

quoted

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

quoted

quoted

submodule.

As I said in the first email, the submodule way suffers from the

multiple

quoted

commit problem: src and bin as two submodules of project, three commits

(for

quoted

the 3 dirs separately) are needed when src directory changes and

compiled

quoted

binaries being put in bin directory. It's annoying to have to give 3

commit

quoted

logs.

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).
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).

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

--
						 Jan 'Bulb' Hudec

[off-list ref]