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

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

[franky]

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.

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

[Lars Hjemli]

On 10/16/07, franky <yinping@kooxoo.com> 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

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

[franky]

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:
> 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

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

[Lars Hjemli]

On 10/16/07, franky <yinping@kooxoo.com> 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

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

[franky]

> 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

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

[Lars Hjemli]

On 10/16/07, franky <yinping@kooxoo.com> wrote:
> lars said:
> > $ 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

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

[Johannes Schindelin]

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

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

[franky]

> 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

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

[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:
> 
> > 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

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

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

On Tue, Oct 16, 2007 at 19:53:08 +0800, 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.
> 
> 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 <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: Is there any plan to support partial checkout or submouduleimprovement?

[franky]

 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:
> > > 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).
> 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
<bulb@ucw.cz>