* Re: New to Git / Questions about single user / multiple projects
From: Jakub Narebski @ 2009-08-19 7:59 UTC (permalink / raw)
To: Rob (gmail); +Cc: git
In-Reply-To: <a2db4dd50908181852s1e2c64fen8b883faf76b3136d@mail.gmail.com>
"Rob (gmail)" <robvanb@gmail.com> writes:
> I'm new to git and have some (I think) basic questions that I have
> not been able to find answers to in the documentation. It's very
> possible that these are the result of my lack in understanding git /
> version control, so feel free to point me to documentation that
> might contain the answers.
Documentation you might want to read:
* "Git User's Manual", distributed with Git (installed at least on
Linux at $sharedir/doc/git-$version/user-manual.html), also at
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
* "The Git Community Book", available at
http://book.git-scm.com/
* "Pro Git. Professional version control", available at
http://progit.org/book/
> Q1:
> Can I create a single repository (project?) for all my code, knowing
> that there are multiple small, unrelated projects. Or should I create
> a new repository for each project ?
You should create a new repository for each project. In git each
commit is about state of whole repository.
If you have single unrelated files, you might want to consider using
Zit tool (see http://git.or.cz/gitwiki/InterfacesFrontendsAndTools for
details), but beware that it is in early stages of development.
(Although if you choose one big repository, you can split it later
with some effort using git-filter-branch (or git-split somewhere in
mailing list archives) if you didn't publish your repositories).
> Q2:
> After initalizing my repository, and comitting the 1st batch of code:
> When further working on the code, will the command "git add ." add all
> changed and new files ? Or do I specifically need to list the new
> files ?
"git add ." would add _all_ new not ignored files, and would stage all
changed files. But you would have to be sure that all files you don't
want to be comitted, like generated files (*.o, *.log,...) and backup
files of your editor (*~ or *.bak), are ignored using .gitignore
(usually for generated files) and .git/info/excludes or
core.excludesFile (usually for specific patterns like backup files).
> Q3: Can I run 'git add x' in any subdirectory, or do I need to issue
> if from the root of the project ?
Most git commands take subdirectory they are in into consideration
when acting. "git add <filename>" in subdirectory works as expected.
Note that some commands need to have '.' as filename / pattern to be
limited to current subdirectory / act on current directory.
> --
> When in trouble or in doubt, run in circles, scream and shout
:-)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Simple commit mechanism for non-technical users
From: Johannes Schindelin @ 2009-08-19 7:49 UTC (permalink / raw)
To: D Sundstrom; +Cc: git
In-Reply-To: <ef72456d0908180905u18593b63tdc850b8552db30b9@mail.gmail.com>
Hi,
On Tue, 18 Aug 2009, D Sundstrom wrote:
> I use git to manage all project artifacts, including documentation,
> proposals, presentations, and so on.
>
> However, I have a hard time convincing non-technical staff to learn
> enough about git or to take the time to go through the effort of
> committing changes to a repository. So the steady stream of email
> attachments with "Acme Specification v3" or "final final spemco
> proprosal" continues.
>
> I'd hoped there was a simple web interface that would allow a user to
> upload and commit a file to a repository, but I've had no luck finding
> one. (I've used cgit for browsing, but it is read-only).
>
> Is anyone aware of a simple way I can have my non-technical users
> manage their documents against a git repository? Ideally this would
> involve no installation of software on their machine (unless it were
> compelling, for example, the Finder plugin for SVN on the mac was a
> great tool for these users; or at least those on a mac...)
You contradict yourself here, the Finder plugin needs to be installed, and
SVN, too.
As for your problem: I think you need a specific solution. If I
understand you correctly, files which have the same name (but maybe a
suffix "v3" or similar before the extension), and they should be
committed to a Git repository.
Then you have a bunch of people who do not want to care about learning
proper version control.
This is what I would do: write a very simple .cgi (I'd use Perl for that),
which has a file upload button, takes the name as commit message (or maybe
adds a field where you can type in a commit message, but that might be
asking your bunch of Aunt Tillies too much), strips the "v3"-like suffixes
($name =~ s/[-_ ]*v\d+(\.[A-Za-z0-9]{1,5})$/$1/;), set author and
committer information according to IP (and refuse if the IP is not in the
internal mapping) and commit.
The whole script would probably not be larger than 50 lines, and require
Git to be installed on the server.
The bigger problem is that your Aunt Tillies most likely would not love
gitweb, so you need a fancier interface.
Ciao,
Dscho
^ permalink raw reply
* Re: Continue git clone after interruption
From: Johannes Schindelin @ 2009-08-19 7:35 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Tomasz Kontusz, git
In-Reply-To: <alpine.LFD.2.00.0908181936130.6044@xanadu.home>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1531 bytes --]
Hi,
On Tue, 18 Aug 2009, Nicolas Pitre wrote:
> On Wed, 19 Aug 2009, Johannes Schindelin wrote:
>
> > But seriously, I miss a very important idea in this discussion: we
> > control the Git source code. So we _can_ add a upload_pack feature
> > that a client can ask for after the first failed attempt.
>
> Indeed. So what do you think about my proposal? It was included in my
> first reply to this thread.
Did you not talk about an extension of the archive protocol? That's not
what I meant. The archive protocol can be disabled for completely
different reasons than to prevent restartable clones.
But you brought up an important point: shallow repositories.
Now, the problem, of course, is that if you cannot even get a single ref
(shallow'ed to depth 0 -- which reminds me: I think I promised to fix
that, but I did not do that yet) due to intermittent network failures, you
are borked, as you said.
But here comes an idea: together with Nguyễn's sparse series, it is
conceivable that we support a shallow & narrow clone via the upload-pack
protocol (also making mithro happy). The problem with narrow clones was
not the pack generation side, that is done by a rev-list that can be
limited to certain paths. The problem was that we end up with missing
tree objects. However, if we can make a sparse checkout, we can avoid
the problem.
Note: this is not well thought-through, but just a brainstorm-like answer
to your ideas.
Ciao,
Dscho "who should shut up now and get some work done instead ;-)"
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Marius Storm-Olsen @ 2009-08-19 7:29 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Erik Faye-Lund, Johan 't Hart, Junio C Hamano, msysgit, git,
lznuaa, bonzini
In-Reply-To: <alpine.DEB.1.00.0908190910270.5594@intel-tinevez-2-302>
[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]
Johannes Schindelin said the following on 19.08.2009 09:16:
> On Wed, 19 Aug 2009, Erik Faye-Lund wrote:
>> On Wed, Aug 19, 2009 at 12:38 AM, Johannes
>> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>>>> Nope, you're still able to skip through the erros (with F4)
>>>> as ususal. I've been using a sed-script to translate
>>>> gcc-style errors to msvc-style errors for makefile projects
>>>> before with great success. In this case, the errors are
>>>> already in msvc-style, so that part should really not be any
>>>> issue.
>>> At this point you are just piling work-around on work-around.
>> At what point?
>
> At the point where you bolt on a sed script on top of a bolted-on
> build procedure.
>
> Using a Makefile from within Visual Studio is just not the intended
> way to do things, so you will hit the limitations sooner or later.
>
> For example when the sed script encounters a situation which was
> not anticipated by the script author.
>
> So I think if we support Microsoft Visual C++, it should be either
> through .vcproj files, or through a procedure that creates them.
IMO, and I'm primarily a Windows developer mind you and spend a lot of
time in Visual Studio, the primary is to support *compiling* git with
VC, which is easily done with a few changes to the current Makefile.
The full IDE support is secondary, first because you *can* use the IDE
already, and second because it'll be harder to whip something up which
guarantees that the vcproj support stays in-sync at all times and
won't lag behind.
If you want, you can even use Qt Creator's Makefile support on any
platform to build and debug git, and get tab completion, code
refactoring support, 'quick open' navigation etc. So, I still think
the primary focus should be to simply add the VC support in the
current setup, and ensure that the patch series is up to scratch; and
when that's all done, *then* add the effort of properly supporting the
various IDEs.
Of course, if someone has a huge itch to restructure the current
Makefile; factoring out the files into a file which can simply be
included in the current Makefile, and easily parsed by a script, or
included by CMake, then that can be done in parallel and possible
added to git mainline before the MSVC support patches from Frank.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johannes Schindelin @ 2009-08-19 7:16 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: Marius Storm-Olsen, Johan 't Hart, Junio C Hamano, msysgit,
git, lznuaa, bonzini
In-Reply-To: <40aa078e0908181548t5df05b1ct8013b99ea703ebba@mail.gmail.com>
Hi,
On Wed, 19 Aug 2009, Erik Faye-Lund wrote:
> On Wed, Aug 19, 2009 at 12:38 AM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> >> Nope, you're still able to skip through the erros (with F4) as ususal.
> >> I've been using a sed-script to translate gcc-style errors to msvc-style
> >> errors for makefile projects before with great success. In this case,
> >> the errors are already in msvc-style, so that part should really not be
> >> any issue.
> >
> > At this point you are just piling work-around on work-around.
>
> At what point?
At the point where you bolt on a sed script on top of a bolted-on build
procedure.
Using a Makefile from within Visual Studio is just not the intended way to
do things, so you will hit the limitations sooner or later.
For example when the sed script encounters a situation which was not
anticipated by the script author.
So I think if we support Microsoft Visual C++, it should be either through
.vcproj files, or through a procedure that creates them.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] stash: accept options also when subcommand 'save' is omitted
From: Matthieu Moy @ 2009-08-19 7:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0908190035140.8306@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 18 Aug 2009, Matthieu Moy wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > But it is sloppy, in that it blindly accepts options that might be
>> > valid for several subcommands, not just "save".
>>
>> I wouldn't call that sloppy. 'save' is the default command, if you don't
>> provide any command, then 'save' will be used.
>
> 'save' might be the default command, but we don't trigger it with _any_
> crap, for a very good reason. Read the commit log for git-stash.sh to
> know why.
The good reason was people doing a typo when typing a command, like
'git stash aply' or so. And yes, I did find this annoying. The
question of someone omitting the subcommand is very different to me.
On can hardly type 'git stash -q' and claim he explicitely wanted to
run 'pop'.
Your proposal will almost certainly trigger complains from users:
git stash -k => works
git stash -k -q => doesn't work
git stash -k "name of stash" => doesn't work
git stash save -k "name of stash" => works
git stash -p => works with another patch merged in next
git stash -q => doesn't work
git stash --patch --no-keep-index => works
git stash --no-keep-index --patch => doesn't work
You'll have a hard time explaining that to bare mortals.
Look at what's the code's becomming:
+ 0,,|1,-k,|1,--keep-index,|1,-p,|1,--patch,|2,-p,--no-keep-index|2,--patch,--no-keep-index)
when the code starts having to enumerate so many possibilities instead
of having a simple logic, something's going wrong.
--
Matthieu
^ permalink raw reply
* Re: [PATCH 3/3] stash: reject stash name starting with a dash.
From: Matthieu Moy @ 2009-08-19 6:57 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
In-Reply-To: <20090818233535.GB6304@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Aug 18, 2009 at 11:38:43PM +0200, Matthieu Moy wrote:
>
>> This avoids typos like 'git stash save --invalid-option', particularly
>> nasty since one can omit the 'save' subcommand. The syntax
>> 'git stash save -- "-name starting with dash" still allows such stash name.
>
> Aside from the documentation and usage lines, this one is actually
> independent of the other two, and I think makes sense regardless of what
> happens.
I also do (but I'm not sure this is important enough to be in maint,
especially since it'll introduce silly textual conflicts in docs when
merging).
>> +test_expect_success 'stash --invalid-option' '
>> + echo bar5 > file &&
>> + echo bar6 > file2 &&
>> + git add file2 &&
>> + ! git stash --invalid-option &&
>> + test bar5,bar6 = $(cat file),$(cat file2) &&
>> + git stash -- -message-starting-with-dash &&
>> + test bar,bar2 = $(cat file),$(cat file2)
>> +'
>
> Should this actually be "git stash save --invalid-option", since it is
> really testing the actual save option parsing, and not the behavior to
> automatically push options to "git stash save"?
It could be, but the most annoying DWIM would be the "implicit save"
case, so that's the one I'm testing. One could test both, but that'd
probably be a bit overkill.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] graph API: fix bug in graph_is_interesting()
From: Junio C Hamano @ 2009-08-19 6:25 UTC (permalink / raw)
To: Adam Simpkins; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <7vhbw41g3f.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Adam Simpkins <simpkins@facebook.com> writes:
>
>> -enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
>> +enum commit_action get_commit_action(struct rev_info *revs, struct commit *commit)
>> {
>> if (commit->object.flags & SHOWN)
>> return commit_ignore;
>> @@ -1692,12 +1692,21 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
>> if (!commit->parents || !commit->parents->next)
>> return commit_ignore;
>> }
>> - if (want_ancestry(revs) && rewrite_parents(revs, commit) < 0)
>> - return commit_error;
>> }
>> return commit_show;
>> }
>>
>> +enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
>> +{
>> + enum commit_action action = get_commit_action(revs, commit);
>> +
>> + if (action == commit_show && revs->prune && revs->dense && want_ancestry(revs)) {
>> + if (rewrite_parents(revs, commit) < 0)
>> + return commit_error;
>> + }
>> + return action;
>> +}
>
> When simplify_commit() logic (now called get_comit_action()) decides to
> show this commit because revs->show_all was specified, we did not rewrite
> its parents, but now we will?
That is, here is what I meant...
revision.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c
index 15a2010..efa3b7c 100644
--- a/revision.c
+++ b/revision.c
@@ -1700,7 +1700,9 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
{
enum commit_action action = get_commit_action(revs, commit);
- if (action == commit_show && revs->prune && revs->dense && want_ancestry(revs)) {
+ if (action == commit_show &&
+ !revs->show_all &&
+ revs->prune && revs->dense && want_ancestry(revs)) {
if (rewrite_parents(revs, commit) < 0)
return commit_error;
}
We may want to add some tests to demonstrate the breakage this fix
addresses.
^ permalink raw reply related
* Re: [PATCH] graph API: fix bug in graph_is_interesting()
From: Junio C Hamano @ 2009-08-19 6:18 UTC (permalink / raw)
To: Adam Simpkins; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <20090819023433.GP8147@facebook.com>
Adam Simpkins <simpkins@facebook.com> writes:
> -enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
> +enum commit_action get_commit_action(struct rev_info *revs, struct commit *commit)
> {
> if (commit->object.flags & SHOWN)
> return commit_ignore;
> @@ -1692,12 +1692,21 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
> if (!commit->parents || !commit->parents->next)
> return commit_ignore;
> }
> - if (want_ancestry(revs) && rewrite_parents(revs, commit) < 0)
> - return commit_error;
> }
> return commit_show;
> }
>
> +enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
> +{
> + enum commit_action action = get_commit_action(revs, commit);
> +
> + if (action == commit_show && revs->prune && revs->dense && want_ancestry(revs)) {
> + if (rewrite_parents(revs, commit) < 0)
> + return commit_error;
> + }
> + return action;
> +}
When simplify_commit() logic (now called get_comit_action()) decides to
show this commit because revs->show_all was specified, we did not rewrite
its parents, but now we will?
^ permalink raw reply
* Re: Simple commit mechanism for non-technical users
From: Chris Packham @ 2009-08-19 6:09 UTC (permalink / raw)
To: D Sundstrom; +Cc: git
In-Reply-To: <ef72456d0908180905u18593b63tdc850b8552db30b9@mail.gmail.com>
On Wed, Aug 19, 2009 at 4:05 AM, D Sundstrom<sunds@peapod.net> wrote:
> I use git to manage all project artifacts, including documentation,
> proposals, presentations, and so on.
>
> However, I have a hard time convincing non-technical staff to learn
> enough about git or to take the time to go through the effort of
> committing changes to a repository. So the steady stream of email
> attachments with "Acme Specification v3" or "final final spemco
> proprosal" continues.
>
> I'd hoped there was a simple web interface that would allow a user to
> upload and commit a file to a repository, but I've had no luck finding
> one. (I've used cgit for browsing, but it is read-only).
>
> Is anyone aware of a simple way I can have my non-technical users
> manage their documents against a git repository? Ideally this would
> involve no installation of software on their machine (unless it were
> compelling, for example, the Finder plugin for SVN on the mac was a
> great tool for these users; or at least those on a mac...)
>
> -David
> --
Actually this is one situation that I'd say there are better solutions
than git _ducks_.
The solution I've been trying to push people toward at my day job is
using a wiki (we chose mediawiki but all the extra markup might still
scare non-techies). Wiki's are version controlled (in a simple,
centralized fashion) and allow editing from multiple authors and can
be updated quickly. The only client software you need is a web
browser. Plenty of open source projects use wikis for their living
specifications.
You may also want to look around for other content management systems
but the only one I've used kinda sucked. Not sure if there are any
good open source ones (but then again I haven't really looked).
If you still want to use git as your version control system for these
kinds of documents it shouldn't actually be too hard to implement and
simple uploader to complement a viewer like cgit or gitweb.
Unfortunately I don't know of any that exist but maybe someone else on
the list does.
^ permalink raw reply
* Re: Continue git clone after interruption
From: Sitaram Chamarty @ 2009-08-19 4:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nicolas Pitre, Tomasz Kontusz, git
In-Reply-To: <m3fxbpneqe.fsf@localhost.localdomain>
On Wed, Aug 19, 2009 at 12:15 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> There is another way which we can go to implement resumable clone.
> Let's git first try to clone whole repository (single pack; BTW what
> happens if this pack is larger than file size limit for given
> filesystem?). If it fails, client ask first for first half of of
> repository (half as in bisect, but it is server that has to calculate
> it). If it downloads, it will ask server for the rest of repository.
> If it fails, it would reduce size in half again, and ask about 1/4 of
> repository in packfile first.
How about an extension where the user can *ask* for a clone of a
particular HEAD to be sent to him as a git bundle? Or particular
revisions (say once a week) were kept as a single file git-bundle,
made available over HTTP -- easily restartable with byte-range -- and
anyone who has bandwidth problems first gets that, then changes the
origin remote URL and does a "pull" to get uptodate?
I've done this manually a few times when sneakernet bandwidth was
better than the normal kind, heh, but it seems to me the lowest impact
solution.
Yes you'd need some extra space on the server, but you keep only one
bundle, and maybe replace it every week by cron. Should work fine
right now, as is, with a wee bit of manual work by the user, and a
quick cron entry on the server
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Chris Packham @ 2009-08-19 4:14 UTC (permalink / raw)
To: Rob (gmail); +Cc: git
In-Reply-To: <eafc0afe0908181924x60e5dd23vd37711db880ead84@mail.gmail.com>
My $0.02
On Wed, Aug 19, 2009 at 1:52 PM, Rob (gmail)<robvanb@gmail.com> wrote:
> Q1:
> Can I create a single repository (project?) for all my code, knowing
> that there are multiple small, unrelated projects. Or should I create
> a new repository for each project ?
Thats entirely up to you. I prefer keeping lots of little repositories
for unrelated projects. That way I can use cool things like git
archive to generate tarballs if/when I need to. Although I do use the
single repository method sometimes when I'm feeling lazy. One thing
git has over some other VCSes is the ability to track changes past
renames. That way you can start off lazy and just have a fairly flat
code structure and then as you start to group code into logical sets
you can move them into directories without any danger of losing
history (one tip though, do the moving as a commit on its own this
makes the re-name detection work a lot better).
As Changsheng pointed out. You can also have the best of both worlds
and use git submodules to tie together multiple repositories. Although
I've always though of submodules as more of a build tool when you want
to track components of a larger system i.e. a linux distro might track
the kernel, kde, gnome ... and use a submodule setup to track known
stable points where those components work together.
>
> Q2:
> After initalizing my repository, and comitting the 1st batch of code:
> When further working on the code, will the command "git add ." add all
> changed and new files ? Or do I specifically need to list the new
> files ?
You can use 'git add -u' which adds any locally modified (but not
completely new) files to the index (its basically the first half of
'git commit -a'). For the new files either 'git add .' or list the
files.
> Q3: Can I run 'git add x' in any subdirectory, or do I need to issue
> if from the root of the project ?
Yes all the git commands work from subdirectories (well except
init/clone) . This is actually really useful if you want to get the
history of a component in a large code base without getting a lot of
irrelevant changes in other components.
^ permalink raw reply
* Re: [PATCH][resend 3] git-svn: Use GIT_SSH setting if SVN_SSH is not set
From: Eric Wong @ 2009-08-19 3:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Karthik R
In-Reply-To: <4A8B3F40.10803@fastmail.fm>
Karthik R <karthikr@fastmail.fm> wrote:
> If SVN_SSH is defined, it will be used. Else value in
> GIT_SSH is copied to SVN_SSH & then, only on Windows,
> the \s are escaped.
>
> On Windows, the shell-variables must be set as follows
> GIT_SSH="C:\Program Files\PuTTY\plink.exe"
> SVN_SSH="C:\\Program Files\\PuTTY\\plink.exe"
>
> See http://code.google.com/p/msysgit/issues/detail?id=305
>
> Signed-off-by: Karthik Rajagopalan <karthikr@fastmail.fm>
Thanks Karthik,
Acked and pushed out along with a few others I hadn't pushed
to git://yhbt.net/git-svn
Eric Wong (1):
svn: assume URLs from the command-line are URI-encoded
Karthik R (1):
git-svn: Use GIT_SSH setting if SVN_SSH is not set
Tuomas Suutari (1):
git-svn.txt: Fix location of parent argument
--
Eric Wong
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Daniel Barkalow @ 2009-08-19 4:00 UTC (permalink / raw)
To: Rob (gmail); +Cc: git
In-Reply-To: <a2db4dd50908181852s1e2c64fen8b883faf76b3136d@mail.gmail.com>
On Tue, 18 Aug 2009, Rob (gmail) wrote:
> I'm new to git and have some (I think) basic questions that I have not
> been able to find answers to in the documentation.
> It's very possible that these are the result of my lack in
> understanding git / version control, so feel free to point me to
> documentation
> that might contain the answers.
>
> I'm doing ERP development for my job and various 'hobby' development
> in my spare time.
> I'd like to track/store/ version control the code that I write for
> both work and play.
> I am (currently) working by myself, no need to have multiple
> developers working of the same code.
>
> Q1:
> Can I create a single repository (project?) for all my code, knowing
> that there are multiple small, unrelated projects. Or should I create
> a new repository for each project ?
It's much easier to have a new repository for each project. There are two
possible ways to put multiple projects in a single repository: (1) you
could have each one in a subdirectory, which is bad because each commit
records the entire tree, so each project would have commits in its history
that are about other projects; (2) you could have separate branches for
each project; this is fine, but you only get one working directory per
repository, so it's awkward because you can only have one of your projects
checked out at a time.
On the other hand, it's pretty trivial to have lots of repositories, and
there isn't really any disadvantage to it. In fact, you may want to have
more repositories than projects at times, if you use the same project for
multiple purposes and want to extend it in different ways at the same
time.
> Q2:
> After initalizing my repository, and comitting the 1st batch of code:
> When further working on the code, will the command "git add ." add all
> changed and new files ? Or do I specifically need to list the new
> files ?
You can use "git add .", but be aware that this tends to pick up random
cruft you've left in the directory.
> Q3: Can I run 'git add x' in any subdirectory, or do I need to issue
> if from the root of the project ?
You can run almost every git command from subdirectories, and it does what
you'd expect with filenames when you're in a subdirectory. E.g., "git add
x" while in "a/b/" is like being in the project root and running "git add
a/b/x"
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 6/6 (v4)] support for path name caching in rev-cache
From: Nicolas Pitre @ 2009-08-19 3:52 UTC (permalink / raw)
To: Nick Edelen
Cc: Junio C Hamano, Johannes Schindelin, Sam Vilain, Michael J Gruber,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <c77435a80908180431k2f91e1ffye25aa8895908ddb7@mail.gmail.com>
On Tue, 18 Aug 2009, Nick Edelen wrote:
> I'll reply to *these* posts with everything fixed. Then after that
> hopefully I can just make patches for the patchset (yo dawg) and save
> everyone a lot of bandwidth.
We have bandwidth to spare. The bandwidth is cheaper than the time
needed to reconstruct a patch series using a previous series and having
to modify it with additional patches. In other words, always make it
easier for the people willing to review and test your stuff.
Now... testing your latest series looks promising. The speed increase
is really there which is good.
However, there are still some issues:
|$ rm -rf .git/rev-cache/
|$ git rev-list --all --objects > /tmp/l1
|$ git rev-cache add --all
|objects: 115789
|paths: 1535
|f0cb1f09e309ee426c307cb85bb870467877de77
|endpoints:
|S 1cae2b588249e8b45239faebc658c7fa45948932
|S 4aec0d2391eb569776e332d9c15b354cd50a64c5
|S 1ff19ffed62bb581cd8eb635fe6e65ffca7ba1d0
|S fcd8ea7a91ad55d094a78c826083ebac149d81e5
|S 181301656f7a1086adcc41c3661551f190635003
|S 2898400a882bfb3c475fc2b53330912edc8a81f8
|S 7c7f2ebdb98f4844347f68b6e64c4968fa7f38e5
|S 1d9d1698ceb7b553f3cb1fdaa3150f0e85ab9cca
|S 348f73cc1db2d7b1412c40eba72319855e2959ff
|S fedc7d5458bd8e2e9589567041228a24a8d7eb4c
|S 0f57bf3ae8f0000de83907f0a674d70a879f7753
|S 7354ca323e31aa2d469498d06feebdcea137e93a
|S d47e28a143f40ad31b88e6d7b9b18bae60d21b01
|S 991ab5ed8769cd1a425b96b92772c89244bc957c
|S 07827905813bce9cadb9db2faac5848a61c7e69f
|S aff6ae5e2f10c4a8e399bf5aa446a58d74444aba
|S 6849908a55d0e7a95fa715310f739cfab4dd8def
|S f073bf0b423cf6a2ee5a5e9b5e70be3b91897a7f
|S b9376927508a2401c20bdb5c5c0608797f822524
|S 9d412d627575478ffdda4209eca9babde061fe2f
|S d187b5de2c2895f6cb4a544e78fcbc1ecf3ba172
|final return value: 0
|$ git rev-list --all --objects > /tmp/l2
|$ wc -l -c /tmp/l1 /tmp/l2
| 109382 5525988 /tmp/l1
| 109382 5473891 /tmp/l2
Result with the rev-cache populated returns the same number of
revisions, but not the same amount of data.
|$ diff -u /tmp/l1 /tmp/l2
|--- /tmp/l1 2009-08-18 23:22:03.000000000 -0400
|+++ /tmp/l2 2009-08-18 23:25:02.000000000 -0400
|@@ -4,221 +4,38 @@
| ff212f80287ab15162035d39bac511f6edacca00
| 69527b0cc148b5fa320cce68e82216f0ba7117d9
| fdbe5cf05690accc4d701e2e8d8c69baccf76812
|-9d412d627575478ffdda4209eca9babde061fe2f
|-b9376927508a2401c20bdb5c5c0608797f822524
|-f073bf0b423cf6a2ee5a5e9b5e70be3b91897a7f
|-fd31906d2285fb914e51a2fb78de6683b481951b
|-7415dcd3bc6a6103d532d75b77897399af2bc015
|-397b844013068a658e2c4dbea05fb57559433f6e
|-15173bda08b5481c2014f04228b95f90f1e500e6
|-d6758648e1ff1f7ace2ddb3682a8189ec634925b
|-7475ee6d358167e2e4dcdea6c7a67f3619c35315
|-83bf4a2869721ba728c5c8b0bdb8ad9a3a43b94b
|-5f50d92cc49150a83e8fa7b352cb9e14ae4d6570
[...]
The object order appears to be rather different. Why so?
|$ sort /tmp/l1 > /tmp/l1_sorted
|$ sort /tmp/l2 > /tmp/l2_sorted
|$ diff -u /tmp/l1_sorted /tmp/l2_sorted
|--- /tmp/l1_sorted 2009-08-18 23:35:48.000000000 -0400
|+++ /tmp/l2_sorted 2009-08-18 23:36:23.000000000 -0400
|@@ -1,7 +1,7 @@
| 000079a2eaef17b7eae70e1f0f635557ea67b644
| 00013cafe6980411aa6fdd940784917b5ff50f0a man1/git-merge-base.1
| 000147bbe4a00525d68efb1358c013812e10dcca contrib/thunderbird-patch-inline/README
|-0001710072c5f0f708323d99e1bb632d7911c842 Documentation/git-peek-remote.txt
|+0001710072c5f0f708323d99e1bb632d7911c842 git-peek-remote.txt
| 000182eacf99cde27d5916aa415921924b82972c
| 0002d8a2fb6add585184350d11284840293dea4d git-daemon.html
| 0003692409f153dd725b3455dfc2e128276cfbe2
|@@ -29,7 +29,7 @@
| 0012954b6f795d75d442f4c58f29dc194888d022 remote.c
| 0012ba2108aa42947dedf19f3db2de73a67cc4f5
| 00133ed4f910f42ae7aaba32bcda1c1e261bc776 man1/git-update-server-info.1
|-001503205b24d5c20ec10792c4ab6c4c7221bcb7 Documentation/diff-format.txt
|+001503205b24d5c20ec10792c4ab6c4c7221bcb7 diff-format.txt
| 0016a48251abefed11efc919703d980a21c95f2c
| 00183cbb3d0f60852d7286e766c9b631c0c1f952
| 00188e33e825c8000dee8e3f4209a264615ce8a1
[...]
So... Why is the leading path component dropped sometimes? That
explains the output size difference. And the drop is not coherent
either:
|$ grep "diff-format.txt" /tmp/l2
|b71712473ed13020bca3f133ea4a28c5081b7f9e diff-format.txt
|1eeb1c76838c1911fc4d57b36a16dece0538809a diff-format.txt
|aafd3a394126e4718b593eb5727412e16d2334e4 diff-format.txt
|400cbb3b1c120b93278472678ee7bdb87a74f95b diff-format.txt
|2c3a4c433b2a6d2b0846243a4f1dbebeed45236e diff-format.txt
|9709c35c98bc678d1f2e339c8e2d4bbcd7e6231f diff-format.txt
|001503205b24d5c20ec10792c4ab6c4c7221bcb7 diff-format.txt
|18d49d2c3baa81983b19a938598eb091fb7809ef diff-format.txt
|e38a1f14056b2e3cfe3c281eb7df7e5b44d520db diff-format.txt
|378e72f38f37eef50135c3907ccd605652f4fd96 diff-format.txt
|883c1bb0a638d97278cdb66e288bc766a32626af diff-format.txt
|e4520e28e53661159454e02c703be772d43bbc09 diff-format.txt
|ed4ebcbab76c23e599a3f3d62072e16d2cbe7cb1 diff-format.txt
|617d8f526f914360c612d2e2822f1c883c9f5115 diff-format.txt
|0398b408c05d2dccb9806c0add6d1acd13871d74 diff-format.txt
|97756ec03086614051d5780b00825e24ee5ef56f diff-format.txt
|2060ae2fcb9935ed11ecb71a093ad22c661339bf Documentation/diff-format.txt
|174d63a1ee4238aac88c76daee6f3f1bead0d6b5 Documentation/diff-format.txt
|b426a14f5e5fa29bfdb8f026d995dc182930073d Documentation/diff-format.txt
|d1d0d2d3dc8760a8030313de3dd14a942d0fc2bf Documentation/diff-format.txt
|bfe634dcd3664d0e3b18b212db2f3f16b63a385b Documentation/diff-format.txt
|dacd8fb53488fadd7ebb6c1964e60a60072eae80 Documentation/diff-format.txt
|6e9fa8cdb70faead4649f71aea4fff8f50d17271 Documentation/diff-format.txt
|424e75a1c2d4747226ac1b55caac90b544f8f273 Documentation/diff-format.txt
|811d143808a13034de41c1cdcc834ef838d01ce8 Documentation/diff-format.txt
|9298d79e51bf87ccff66357227c7df4db4c820c4 Documentation/diff-format.txt
|d6ce035419081e3fbfc2375ac667517f5f52c980 Documentation/diff-format.txt
|6748761ef61cf35473ee304bc8bd44134cdccaf4 Documentation/diff-format.txt
|1d92a01a02543e55d0feb3541ee594fbc638136c Documentation/diff-format.txt
|f85a605f0a336f506cf5cf46476a43e4c56b3e66 Documentation/diff-format.txt
|7e9a515ad74b16c3f82eba71a9503c6696c77503 Documentation/diff-format.txt
|9e645399752e9b18f097840906fc640a1121d982 Documentation/diff-format.txt
|1a99e85ee58bfc47192e3e3cd409af948c989f80 Documentation/diff-format.txt
|3af197cd2c62f990f7a67ac52277ccf0521d268e Documentation/diff-format.txt
I think you'll have to fix those issues.
Nicolas
^ permalink raw reply
* Re: [PATCH] graph API: fix bug in graph_is_interesting()
From: Adam Simpkins @ 2009-08-19 2:34 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Santi Béjar
In-Reply-To: <20090819022918.GO8147@facebook.com>
Previously, graph_is_interesting() did not behave quite the same way as
the code in get_revision(). As a result, it would sometimes think
commits were uninteresting, even though get_revision() would return
them. This resulted in incorrect lines in the graph output.
This change creates a get_commit_action() function, which
graph_is_interesting() and simplify_commit() both now use to determine
if a commit will be shown. It is identical to the old simplify_commit()
behavior, except that it never calls rewrite_parents().
This problem was reported by Santi Béjar. The following command
would exhibit the problem before, but now works correctly:
git log --graph --simplify-by-decoration --oneline v1.6.3.3
Previously git graph did not display the output for this command
correctly between f29ac4f and 66996ec, among other places.
Signed-off-by: Adam Simpkins <simpkins@facebook.com>
---
graph.c | 5 +++--
revision.c | 15 ++++++++++++---
revision.h | 1 +
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/graph.c b/graph.c
index e466770..9087f65 100644
--- a/graph.c
+++ b/graph.c
@@ -286,9 +286,10 @@ static int graph_is_interesting(struct git_graph *graph, struct commit *commit)
}
/*
- * Uninteresting and pruned commits won't be printed
+ * Otherwise, use get_commit_action() to see if this commit is
+ * interesting
*/
- return (commit->object.flags & (UNINTERESTING | TREESAME)) ? 0 : 1;
+ return get_commit_action(graph->revs, commit) == commit_show;
}
static struct commit_list *next_interesting_parent(struct git_graph *graph,
diff --git a/revision.c b/revision.c
index 8ffb661..fe7d522 100644
--- a/revision.c
+++ b/revision.c
@@ -1664,7 +1664,7 @@ static inline int want_ancestry(struct rev_info *revs)
return (revs->rewrite_parents || revs->children.name);
}
-enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
+enum commit_action get_commit_action(struct rev_info *revs, struct commit *commit)
{
if (commit->object.flags & SHOWN)
return commit_ignore;
@@ -1692,12 +1692,21 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
if (!commit->parents || !commit->parents->next)
return commit_ignore;
}
- if (want_ancestry(revs) && rewrite_parents(revs, commit) < 0)
- return commit_error;
}
return commit_show;
}
+enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
+{
+ enum commit_action action = get_commit_action(revs, commit);
+
+ if (action == commit_show && revs->prune && revs->dense && want_ancestry(revs)) {
+ if (rewrite_parents(revs, commit) < 0)
+ return commit_error;
+ }
+ return action;
+}
+
static struct commit *get_revision_1(struct rev_info *revs)
{
if (!revs->commits)
diff --git a/revision.h b/revision.h
index b10984b..9d0dddb 100644
--- a/revision.h
+++ b/revision.h
@@ -168,6 +168,7 @@ enum commit_action {
commit_error
};
+extern enum commit_action get_commit_action(struct rev_info *revs, struct commit *commit);
extern enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit);
#endif
--
1.6.4.314.g0a482.dirty
^ permalink raw reply related
* Re: [PATCH] graph API: fix bug in graph_is_interesting()
From: Adam Simpkins @ 2009-08-19 2:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Santi Béjar
In-Reply-To: <7vk5103chi.fsf@alter.siamese.dyndns.org>
On Tue, Aug 18, 2009 at 04:53:45PM -0700, Junio C Hamano wrote:
> Adam Simpkins <simpkins@facebook.com> writes:
>
> > - return (commit->object.flags & (UNINTERESTING | TREESAME)) ? 0 : 1;
> > + return simplify_commit(graph->revs, commit) == commit_show;
>
> If you do this after revision.c finished the traversal (e.g. "limited"
> case), I think it should be Ok.
>
> But calling simplify_commit() while the traversal is still in progress is
> asking for trouble. I do not recall the details anymore but when I tried
> to make the "simplify-merges" algorithm incremental, I had seen funny
> breakage caused by calling simplify_commit() twice on the same commit.
>
> I suspect that this change will break the primary traversal.
The --graph option always enables revs->topo_order, which in turn
enables revs->limited, so this should always be after limit_list() has
already been called.
However, it looks like the call to rewrite_parents() is the only
modifying operation in simplify_commit(), and all the rest can easily
be split out into a separate helper function. I'll submit another
version of the patch that makes the non-modifying simplify_commit()
behavior available as a separate function.
--
Adam Simpkins
simpkins@facebook.com
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Changsheng Jiang @ 2009-08-19 2:24 UTC (permalink / raw)
To: Rob (gmail); +Cc: git
In-Reply-To: <a2db4dd50908181852s1e2c64fen8b883faf76b3136d@mail.gmail.com>
I am not that familiar with git too, but see the answers below
questions, respectively, and fix me if i am wrong.
On Wed, Aug 19, 2009 at 09:52, Rob (gmail) <robvanb@gmail.com> wrote:
>
> I'm new to git and have some (I think) basic questions that I have not
> been able to find answers to in the documentation.
> It's very possible that these are the result of my lack in
> understanding git / version control, so feel free to point me to
> documentation
> that might contain the answers.
>
> I'm doing ERP development for my job and various 'hobby' development
> in my spare time.
> I'd like to track/store/ version control the code that I write for
> both work and play.
> I am (currently) working by myself, no need to have multiple
> developers working of the same code.
>
> Q1:
> Can I create a single repository (project?) for all my code, knowing
> that there are multiple small, unrelated projects. Or should I create
> a new repository for each project ?
git-submodule
>
> Q2:
> After initalizing my repository, and comitting the 1st batch of code:
> When further working on the code, will the command "git add ." add all
> changed and new files ? Or do I specifically need to list the new
> files ?
=git status= or =git ls-files= will list the files in different statuses.
If there are no other files, such as backup file produced by editor,
you can run =git add .=. If there are, try to configure in file
=.git/info/exclude= or =.gitignore=.
Changed files can be committed automatically by =git commit -a=
>
> Q3: Can I run 'git add x' in any subdirectory, or do I need to issue
> if from the root of the project ?
You can.
>
> Thanks,
>
> Rob.
>
> --
> When in trouble or in doubt, run in circles, scream and shout
> --
> 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
Changsheng Jiang
^ permalink raw reply
* New to Git / Questions about single user / multiple projects
From: Rob (gmail) @ 2009-08-19 1:52 UTC (permalink / raw)
To: git
I'm new to git and have some (I think) basic questions that I have not
been able to find answers to in the documentation.
It's very possible that these are the result of my lack in
understanding git / version control, so feel free to point me to
documentation
that might contain the answers.
I'm doing ERP development for my job and various 'hobby' development
in my spare time.
I'd like to track/store/ version control the code that I write for
both work and play.
I am (currently) working by myself, no need to have multiple
developers working of the same code.
Q1:
Can I create a single repository (project?) for all my code, knowing
that there are multiple small, unrelated projects. Or should I create
a new repository for each project ?
Q2:
After initalizing my repository, and comitting the 1st batch of code:
When further working on the code, will the command "git add ." add all
changed and new files ? Or do I specifically need to list the new
files ?
Q3: Can I run 'git add x' in any subdirectory, or do I need to issue
if from the root of the project ?
Thanks,
Rob.
--
When in trouble or in doubt, run in circles, scream and shout
^ permalink raw reply
* [RFC/PATCH 2/6] Add selftest for 'git submodule foreach'
From: Johan Herland @ 2009-08-19 1:45 UTC (permalink / raw)
To: git; +Cc: Johan Herland, gitster, mlevedahl, hjemli
In-Reply-To: <1250646324-961-1-git-send-email-johan@herland.net>
The selftest verifies that:
- only checked out submodules are visited by 'git submodule foreach'
- the $path, and $sha1 variables are set correctly for each submodule
Signed-off-by: Johan Herland <johan@herland.net>
---
t/t7407-submodule-foreach.sh | 79 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 79 insertions(+), 0 deletions(-)
create mode 100755 t/t7407-submodule-foreach.sh
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
new file mode 100755
index 0000000..76e0734
--- /dev/null
+++ b/t/t7407-submodule-foreach.sh
@@ -0,0 +1,79 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Johan Herland
+#
+
+test_description='Test "git submodule foreach"
+
+This test verifies that "git submodule foreach" correctly visits all submodules
+that are currently checked out.
+'
+
+. ./test-lib.sh
+
+
+test_expect_success 'setup a submodule tree' '
+ echo file > file &&
+ git add file &&
+ test_tick &&
+ git commit -m upstream
+ git clone . super &&
+ git clone super submodule &&
+ (
+ cd super &&
+ git submodule add ../submodule sub1 &&
+ git submodule add ../submodule sub2 &&
+ git submodule add ../submodule sub3 &&
+ git config -f .gitmodules --rename-section \
+ submodule.sub1 submodule.foo1 &&
+ git config -f .gitmodules --rename-section \
+ submodule.sub2 submodule.foo2 &&
+ git config -f .gitmodules --rename-section \
+ submodule.sub3 submodule.foo3 &&
+ git add .gitmodules
+ test_tick &&
+ git commit -m "submodules" &&
+ git submodule init sub1 &&
+ git submodule init sub2 &&
+ git submodule init sub3
+ ) &&
+ (
+ cd submodule &&
+ echo different > file &&
+ git add file &&
+ test_tick &&
+ git commit -m "different"
+ ) &&
+ (
+ cd super &&
+ (
+ cd sub3 &&
+ git pull
+ ) &&
+ git add sub3 &&
+ test_tick &&
+ git commit -m "update sub3"
+ )
+'
+
+sub1sha1=$(cd super/sub1 && git rev-parse HEAD)
+sub3sha1=$(cd super/sub3 && git rev-parse HEAD)
+
+cat > expect <<EOF
+Entering 'sub1'
+sub1-$sub1sha1
+Entering 'sub3'
+sub3-$sub3sha1
+EOF
+
+test_expect_success 'test basic "submodule foreach" usage' '
+ git clone super clone &&
+ (
+ cd clone &&
+ git submodule update --init -- sub1 sub3 &&
+ git submodule foreach "echo \$path-\$sha1" > ../actual
+ ) &&
+ test_cmp expect actual
+'
+
+test_done
--
1.6.4.304.g1365c.dirty
^ permalink raw reply related
* [RFC/PATCH 6/6] git submodule status: Add --recursive to recurse into nested submodules
From: Johan Herland @ 2009-08-19 1:45 UTC (permalink / raw)
To: git; +Cc: Johan Herland, gitster, mlevedahl, hjemli
In-Reply-To: <1250646324-961-1-git-send-email-johan@herland.net>
In very large and hierarchically structured projects, one may encounter
nested submodules. In these situations, it is valuable to not only show
status for all the submodules in the current repo (which is what is
currently done by 'git submodule status'), but also to show status for
all submodules at all levels (i.e. recursing into nested submodules as
well).
This patch teaches the new --recursive option to the 'git submodule status'
command. The patch also includes documentation and selftests.
Signed-off-by: Johan Herland <johan@herland.net>
---
Documentation/git-submodule.txt | 7 +++++--
git-submodule.sh | 24 ++++++++++++++++++++----
t/t7407-submodule-foreach.sh | 26 ++++++++++++++++++++++++++
3 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index cd74da9..5ccdd18 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git submodule' [--quiet] add [-b branch]
[--reference <repository>] [--] <repository> <path>
-'git submodule' [--quiet] status [--cached] [--] [<path>...]
+'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
[--reference <repository>] [--merge] [--recursive] [--] [<path>...]
@@ -100,6 +100,9 @@ status::
initialized and `+` if the currently checked out submodule commit
does not match the SHA-1 found in the index of the containing
repository. This command is the default command for 'git-submodule'.
++
+If '--recursive' is specified, this command will recurse into nested
+submodules, and show their status as well.
init::
Initialize the submodules, i.e. register each submodule name
@@ -225,7 +228,7 @@ OPTIONS
for linkgit:git-clone[1]'s --reference and --shared options carefully.
--recursive::
- This option is only valid for foreach and update commands.
+ This option is only valid for foreach, update and status commands.
Traverse submodules recursively. The operation is performed not
only in the submodules of the current repo, but also
in any nested submodules inside those submodules (and so on).
diff --git a/git-submodule.sh b/git-submodule.sh
index e48c309..bfbd36b 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -6,7 +6,7 @@
dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="[--quiet] add [-b branch] [--reference <repository>] [--] <repository> <path>
- or: $dashless [--quiet] status [--cached] [--] [<path>...]
+ or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
@@ -703,6 +703,7 @@ cmd_summary() {
cmd_status()
{
# parse $args after "submodule ... status".
+ orig_args="$@"
while test $# -ne 0
do
case "$1" in
@@ -712,6 +713,9 @@ cmd_status()
--cached)
cached=1
;;
+ --recursive)
+ recursive=1
+ ;;
--)
shift
break
@@ -731,22 +735,34 @@ cmd_status()
do
name=$(module_name "$path") || exit
url=$(git config submodule."$name".url)
+ displaypath="$prefix$path"
if test -z "$url" || ! test -d "$path"/.git -o -f "$path"/.git
then
- say "-$sha1 $path"
+ say "-$sha1 $displaypath"
continue;
fi
set_name_rev "$path" "$sha1"
if git diff-files --quiet -- "$path"
then
- say " $sha1 $path$revname"
+ say " $sha1 $displaypath$revname"
else
if test -z "$cached"
then
sha1=$(unset GIT_DIR; cd "$path" && git rev-parse --verify HEAD)
set_name_rev "$path" "$sha1"
fi
- say "+$sha1 $path$revname"
+ say "+$sha1 $displaypath$revname"
+ fi
+
+ if test -n "$recursive"
+ then
+ (
+ prefix="$displaypath/"
+ unset GIT_DIR
+ cd "$path" &&
+ cmd_status $orig_args
+ ) ||
+ die "Failed to recurse into submodule path '$path'"
fi
done
}
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index 9122bfe..de1730d 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -194,4 +194,30 @@ test_expect_success 'use "update --recursive" to checkout all submodules' '
)
'
+nested1sha1=$(cd clone3/nested1 && git rev-parse HEAD)
+nested2sha1=$(cd clone3/nested1/nested2 && git rev-parse HEAD)
+nested3sha1=$(cd clone3/nested1/nested2/nested3 && git rev-parse HEAD)
+submodulesha1=$(cd clone3/nested1/nested2/nested3/submodule && git rev-parse HEAD)
+sub1sha1=$(cd clone3/sub1 && git rev-parse HEAD)
+sub2sha1=$(cd clone3/sub2 && git rev-parse HEAD)
+sub3sha1=$(cd clone3/sub3 && git rev-parse HEAD)
+
+cat > expect <<EOF
+ $nested1sha1 nested1 (heads/master)
+ $nested2sha1 nested1/nested2 (heads/master)
+ $nested3sha1 nested1/nested2/nested3 (heads/master)
+ $submodulesha1 nested1/nested2/nested3/submodule (heads/master)
+ $sub1sha1 sub1 (${sub1sha1:0:7})
+ $sub2sha1 sub2 (${sub1sha1:0:7})
+ $sub3sha1 sub3 (heads/master)
+EOF
+
+test_expect_success 'test "status --recursive"' '
+ (
+ cd clone3 &&
+ git submodule status --recursive > ../actual
+ ) &&
+ test_cmp expect actual
+'
+
test_done
--
1.6.4.304.g1365c.dirty
^ permalink raw reply related
* [RFC/PATCH 5/6] git submodule update: Introduce --recursive to update nested submodules
From: Johan Herland @ 2009-08-19 1:45 UTC (permalink / raw)
To: git; +Cc: Johan Herland, gitster, mlevedahl, hjemli
In-Reply-To: <1250646324-961-1-git-send-email-johan@herland.net>
In very large and hierarchically structured projects, one may encounter
nested submodules. In these situations, it is valuable to not only update
the submodules in the current repo (which is what is currently done by
'git submodule update'), but also to operate on all submodules at all
levels (i.e. recursing into nested submodules as well).
This patch teaches the new --recursive option to the 'git submodule update'
command. The patch also includes documentation and selftests.
Signed-off-by: Johan Herland <johan@herland.net>
---
Documentation/git-submodule.txt | 7 +++++--
git-submodule.sh | 13 ++++++++++++-
t/t7407-submodule-foreach.sh | 19 +++++++++++++++++++
3 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index c604550..cd74da9 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -14,7 +14,7 @@ SYNOPSIS
'git submodule' [--quiet] status [--cached] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
- [--reference <repository>] [--merge] [--] [<path>...]
+ [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
'git submodule' [--quiet] foreach [--recursive] <command>
'git submodule' [--quiet] sync [--] [<path>...]
@@ -122,6 +122,9 @@ update::
If the submodule is not yet initialized, and you just want to use the
setting as stored in .gitmodules, you can automatically initialize the
submodule with the --init option.
++
+If '--recursive' is specified, this command will recurse into the
+registered submodules, and update any nested submodules within.
summary::
Show commit summary between the given commit (defaults to HEAD) and
@@ -222,7 +225,7 @@ OPTIONS
for linkgit:git-clone[1]'s --reference and --shared options carefully.
--recursive::
- This option is only valid for the foreach command.
+ This option is only valid for foreach and update commands.
Traverse submodules recursively. The operation is performed not
only in the submodules of the current repo, but also
in any nested submodules inside those submodules (and so on).
diff --git a/git-submodule.sh b/git-submodule.sh
index dbfc483..e48c309 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -8,7 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="[--quiet] add [-b branch] [--reference <repository>] [--] <repository> <path>
or: $dashless [--quiet] status [--cached] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
- or: $dashless [--quiet] update [--init] [-N|--no-fetch] [--rebase] [--reference <repository>] [--merge] [--] [<path>...]
+ or: $dashless [--quiet] update [--init] [-N|--no-fetch] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: $dashless [--quiet] foreach [--recursive] <command>
or: $dashless [--quiet] sync [--] [<path>...]"
@@ -353,6 +353,7 @@ cmd_init()
cmd_update()
{
# parse $args after "submodule ... update".
+ orig_args="$@"
while test $# -ne 0
do
case "$1" in
@@ -385,6 +386,10 @@ cmd_update()
shift
update="merge"
;;
+ --recursive)
+ shift
+ recursive=1
+ ;;
--)
shift
break
@@ -471,6 +476,12 @@ cmd_update()
die "Unable to $action '$sha1' in submodule path '$path'"
say "Submodule path '$path': $msg '$sha1'"
fi
+
+ if test -n "$recursive"
+ then
+ (unset GIT_DIR; cd "$path" && cmd_update $orig_args) ||
+ die "Failed to recurse into submodule path '$path'"
+ fi
done
}
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index be122c7..9122bfe 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -175,4 +175,23 @@ test_expect_success 'test "foreach --quiet --recursive"' '
test_cmp expect actual
'
+test_expect_success 'use "update --recursive" to checkout all submodules' '
+ git clone super clone3 &&
+ (
+ cd clone3 &&
+ test ! -d sub1/.git &&
+ test ! -d sub2/.git &&
+ test ! -d sub3/.git &&
+ test ! -d nested1/.git &&
+ git submodule update --init --recursive &&
+ test -d sub1/.git &&
+ test -d sub2/.git &&
+ test -d sub3/.git &&
+ test -d nested1/.git &&
+ test -d nested1/nested2/.git &&
+ test -d nested1/nested2/nested3/.git &&
+ test -d nested1/nested2/nested3/submodule/.git
+ )
+'
+
test_done
--
1.6.4.304.g1365c.dirty
^ permalink raw reply related
* [RFC/PATCH 4/6] git submodule foreach: Add --recursive to recurse into nested submodules
From: Johan Herland @ 2009-08-19 1:45 UTC (permalink / raw)
To: git; +Cc: Johan Herland, gitster, mlevedahl, hjemli
In-Reply-To: <1250646324-961-1-git-send-email-johan@herland.net>
In very large and hierarchically structured projects, one may encounter
nested submodules. In these situations, it is valuable to not only operate
on all the submodules in the current repo (which is what is currently done
by 'git submodule foreach'), but also to operate on all submodules at all
levels (i.e. recursing into nested submodules as well).
This patch teaches the new --recursive option to the 'git submodule foreach'
command. The patch also includes documentation and selftests.
Signed-off-by: Johan Herland <johan@herland.net>
---
Documentation/git-submodule.txt | 10 ++++-
git-submodule.sh | 19 ++++++-
t/t7407-submodule-foreach.sh | 99 +++++++++++++++++++++++++++++++++++++++
3 files changed, 124 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index cfa8d73..c604550 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -16,7 +16,7 @@ SYNOPSIS
'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
[--reference <repository>] [--merge] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
-'git submodule' [--quiet] foreach <command>
+'git submodule' [--quiet] foreach [--recursive] <command>
'git submodule' [--quiet] sync [--] [<path>...]
@@ -142,6 +142,8 @@ foreach::
Any submodules defined in the superproject but not checked out are
ignored by this command. Unless given --quiet, foreach prints the name
of each submodule before evaluating the command.
+ If --recursive is given, submodules are traversed recursively (i.e.
+ the given shell command is evaluated in nested submodules as well).
A non-zero return from the command in any submodule causes
the processing to terminate. This can be overridden by adding '|| :'
to the end of the command.
@@ -219,6 +221,12 @@ OPTIONS
*NOTE*: Do *not* use this option unless you have read the note
for linkgit:git-clone[1]'s --reference and --shared options carefully.
+--recursive::
+ This option is only valid for the foreach command.
+ Traverse submodules recursively. The operation is performed not
+ only in the submodules of the current repo, but also
+ in any nested submodules inside those submodules (and so on).
+
<path>...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/git-submodule.sh b/git-submodule.sh
index 6163d01..dbfc483 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -10,7 +10,7 @@ USAGE="[--quiet] add [-b branch] [--reference <repository>] [--] <repository> <p
or: $dashless [--quiet] init [--] [<path>...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [--rebase] [--reference <repository>] [--merge] [--] [<path>...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
- or: $dashless [--quiet] foreach <command>
+ or: $dashless [--quiet] foreach [--recursive] <command>
or: $dashless [--quiet] sync [--] [<path>...]"
OPTIONS_SPEC=
. git-sh-setup
@@ -24,6 +24,7 @@ cached=
files=
nofetch=
update=
+prefix=
# Resolve relative url by appending to parent's url
resolve_relative_url ()
@@ -250,6 +251,9 @@ cmd_foreach()
-q|--quiet)
GIT_QUIET=1
;;
+ --recursive)
+ recursive=1
+ ;;
-*)
usage
;;
@@ -265,9 +269,18 @@ cmd_foreach()
do
if test -e "$path"/.git
then
- say "Entering '$path'"
+ say "Entering '$prefix$path'"
name=$(module_name "$path")
- (cd "$path" && eval "$@") ||
+ (
+ prefix="$prefix$path/"
+ unset GIT_DIR
+ cd "$path" &&
+ eval "$@" &&
+ if test -n "$recursive"
+ then
+ cmd_foreach "--recursive" "$@"
+ fi
+ ) ||
die "Stopping at '$path'; script returned non-zero status."
fi
done
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index 991aa80..be122c7 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -76,4 +76,103 @@ test_expect_success 'test basic "submodule foreach" usage' '
test_cmp expect actual
'
+test_expect_success 'setup nested submodules' '
+ git clone submodule nested1 &&
+ git clone submodule nested2 &&
+ git clone submodule nested3 &&
+ (
+ cd nested3 &&
+ git submodule add ../submodule submodule &&
+ test_tick &&
+ git commit -m "submodule" &&
+ git submodule init submodule
+ ) &&
+ (
+ cd nested2 &&
+ git submodule add ../nested3 nested3 &&
+ test_tick &&
+ git commit -m "nested3" &&
+ git submodule init nested3
+ ) &&
+ (
+ cd nested1 &&
+ git submodule add ../nested2 nested2 &&
+ test_tick &&
+ git commit -m "nested2" &&
+ git submodule init nested2
+ ) &&
+ (
+ cd super &&
+ git submodule add ../nested1 nested1 &&
+ test_tick &&
+ git commit -m "nested1" &&
+ git submodule init nested1
+ )
+'
+
+test_expect_success 'use "submodule foreach" to checkout 2nd level submodule' '
+ git clone super clone2 &&
+ (
+ cd clone2 &&
+ test ! -d sub1/.git &&
+ test ! -d sub2/.git &&
+ test ! -d sub3/.git &&
+ test ! -d nested1/.git &&
+ git submodule update --init &&
+ test -d sub1/.git &&
+ test -d sub2/.git &&
+ test -d sub3/.git &&
+ test -d nested1/.git &&
+ test ! -d nested1/nested2/.git &&
+ git submodule foreach "git submodule update --init" &&
+ test -d nested1/nested2/.git &&
+ test ! -d nested1/nested2/nested3/.git
+ )
+'
+
+test_expect_success 'use "foreach --recursive" to checkout all submodules' '
+ (
+ cd clone2 &&
+ git submodule foreach --recursive "git submodule update --init" &&
+ test -d nested1/nested2/nested3/.git &&
+ test -d nested1/nested2/nested3/submodule/.git
+ )
+'
+
+cat > expect <<EOF
+Entering 'nested1'
+Entering 'nested1/nested2'
+Entering 'nested1/nested2/nested3'
+Entering 'nested1/nested2/nested3/submodule'
+Entering 'sub1'
+Entering 'sub2'
+Entering 'sub3'
+EOF
+
+test_expect_success 'test messages from "foreach --recursive"' '
+ (
+ cd clone2 &&
+ git submodule foreach --recursive "true" > ../actual
+ ) &&
+ test_cmp expect actual
+'
+
+cat > expect <<EOF
+nested1-nested1
+nested2-nested2
+nested3-nested3
+submodule-submodule
+foo1-sub1
+foo2-sub2
+foo3-sub3
+EOF
+
+test_expect_success 'test "foreach --quiet --recursive"' '
+ (
+ cd clone2 &&
+ git submodule foreach -q --recursive "echo \$name-\$path" > ../actual
+ ) &&
+ test_cmp expect actual
+'
+
test_done
--
1.6.4.304.g1365c.dirty
^ permalink raw reply related
* [RFC/PATCH 3/6] git submodule foreach: Provide access to submodule name, as '$name'
From: Johan Herland @ 2009-08-19 1:45 UTC (permalink / raw)
To: git; +Cc: Johan Herland, gitster, mlevedahl, hjemli
In-Reply-To: <1250646324-961-1-git-send-email-johan@herland.net>
The argument to 'git submodule foreach' already has access to the variables
'$path' (the path to the submodule, relative to the superproject) and '$sha1'
(the submodule commit recorded by the superproject).
This patch adds another variable - '$name' - which contains the name of the
submodule, as recorded in the superproject's .gitmodules file.
Verification of the behaviour of '$name' is also added to the git submodule
foreach selftest.
Signed-off-by: Johan Herland <johan@herland.net>
---
This patch was initially sent stand-alone on 2009-08-16.
...Johan
Documentation/git-submodule.txt | 3 ++-
git-submodule.sh | 1 +
t/t7407-submodule-foreach.sh | 6 +++---
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index bb7d159..cfa8d73 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -135,7 +135,8 @@ summary::
foreach::
Evaluates an arbitrary shell command in each checked out submodule.
- The command has access to the variables $path and $sha1:
+ The command has access to the variables $name, $path and $sha1:
+ $name is the name of the relevant submodule section in .gitmodules,
$path is the name of the submodule directory relative to the
superproject, and $sha1 is the commit as recorded in the superproject.
Any submodules defined in the superproject but not checked out are
diff --git a/git-submodule.sh b/git-submodule.sh
index c58eca4..6163d01 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -266,6 +266,7 @@ cmd_foreach()
if test -e "$path"/.git
then
say "Entering '$path'"
+ name=$(module_name "$path")
(cd "$path" && eval "$@") ||
die "Stopping at '$path'; script returned non-zero status."
fi
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index 76e0734..991aa80 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -61,9 +61,9 @@ sub3sha1=$(cd super/sub3 && git rev-parse HEAD)
cat > expect <<EOF
Entering 'sub1'
-sub1-$sub1sha1
+foo1-sub1-$sub1sha1
Entering 'sub3'
-sub3-$sub3sha1
+foo3-sub3-$sub3sha1
EOF
test_expect_success 'test basic "submodule foreach" usage' '
@@ -71,7 +71,7 @@ test_expect_success 'test basic "submodule foreach" usage' '
(
cd clone &&
git submodule update --init -- sub1 sub3 &&
- git submodule foreach "echo \$path-\$sha1" > ../actual
+ git submodule foreach "echo \$name-\$path-\$sha1" > ../actual
) &&
test_cmp expect actual
'
--
1.6.4.304.g1365c.dirty
^ permalink raw reply related
* [RFC/PATCH 1/6] git submodule: Cleanup usage string and add option parsing to cmd_foreach()
From: Johan Herland @ 2009-08-19 1:45 UTC (permalink / raw)
To: git; +Cc: Johan Herland, gitster, mlevedahl, hjemli
In-Reply-To: <1250646324-961-1-git-send-email-johan@herland.net>
Signed-off-by: Johan Herland <johan@herland.net>
---
git-submodule.sh | 28 +++++++++++++++++++++++++---
1 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 9bdd6ea..c58eca4 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -4,9 +4,14 @@
#
# Copyright (c) 2007 Lars Hjemli
-USAGE="[--quiet] [--cached|--files] \
-[add [-b branch] <repo> <path>]|[status|init|update [-i|--init] [-N|--no-fetch] [--rebase|--merge]|summary [-n|--summary-limit <n>] [<commit>]] \
-[--] [<path>...]|[foreach <command>]|[sync [--] [<path>...]]"
+dashless=$(basename "$0" | sed -e 's/-/ /')
+USAGE="[--quiet] add [-b branch] [--reference <repository>] [--] <repository> <path>
+ or: $dashless [--quiet] status [--cached] [--] [<path>...]
+ or: $dashless [--quiet] init [--] [<path>...]
+ or: $dashless [--quiet] update [--init] [-N|--no-fetch] [--rebase] [--reference <repository>] [--merge] [--] [<path>...]
+ or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
+ or: $dashless [--quiet] foreach <command>
+ or: $dashless [--quiet] sync [--] [<path>...]"
OPTIONS_SPEC=
. git-sh-setup
. git-parse-remote
@@ -238,6 +243,23 @@ cmd_add()
#
cmd_foreach()
{
+ # parse $args after "submodule ... foreach".
+ while test $# -ne 0
+ do
+ case "$1" in
+ -q|--quiet)
+ GIT_QUIET=1
+ ;;
+ -*)
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+ done
+
module_list |
while read mode sha1 stage path
do
--
1.6.4.304.g1365c.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox