git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Lukasz Palczewski <l.palczewski@prevac.pl>
Cc: git@vger.kernel.org, Johan Herland <johan@herland.net>,
	Jens Lehmann <Jens.Lehmann@web.de>,
	Piotrek Pientka <p.pientka@prevac.pl>
Subject: Re: Restart submodule update --recursive
Date: Fri, 29 Oct 2010 11:40:55 -0500	[thread overview]
Message-ID: <20101029164055.GA28934@burratino> (raw)
In-Reply-To: <4CCAB20A.1000408@prevac.pl>

Hi again,

Lukasz Palczewski wrote:
> Jonathan Nieder wrote:

>> [side note: if you use a newsreader, please reply by mail instead of
>> through gmane so the Cc: list can be preserved.]
>
> Sorry, but I do not use it. I will send You a normal email.

Thanks.

> I have added two options to git submodule update:
> --save-progress
> --resume-update
> First one You can use, to save the ./.git/SubmoduleUpdateLog.log the
> progress of updating:
> git submodule update --recursive --save-progress
> The second one is used for skipping updated submodules:
> git submodule update --recursive --resume-update
> 
> The downside of it is, that u can use only one --resume-update.

Does the combination
"git submodule update --recursive --save-progress --resume-update"
work?

> Let me know if this change will be in next version of git.

I will leave that question to the submodule experts.  But note that
there is no need to wait: if you change the ". git-sh-setup" line
to

	. "$(git --exec-path)/git-sh-setup"

then if you install the modified script as git-mysubmodule anywhere on
your $PATH, it will be used to implement

	git mysubmodule update --recursive --save-progress

.  Of course you can run it directly as "git-mysubmodule", too.

diffs are easier to review.  If your change is for inclusion, it will
also need a Signed-off-by: line; see Documentation/SubmittingPatches.

> cmd_update()
> {
[...]
> 		--save-progress)
> 			shift
> 			save_progress=1
> 			if test -e ./.git/SubmoduleUpdateLog.log
> 			then
> 				rm ./.git/SubmoduleUpdateLog.log
> 			fi

Some current temporary files used by git:

	.git/rr-cache/*
	.git/gitk.cache
	.git/rebase-merge/*
	.git/rebase-apply/*

The
	if test -e $foo
	then
		rm $foo
	fi

idiom can be written more simply as

	rm -f $foo

but are you sure that is what you want?  Maybe it would be better
to

	1) destroy progress when the update is completed
	2) always save updated progress when resuming
	3) complain when --save-progress would require clobbering
	   some existing progress
	4) provide an additional --reset-progress option to start
	   over

?

FWIW "git am" and "git rebase" already have the ability to resume
where they left off, using options with these names:

	git <foo> --continue
	git <foo> --skip
	git <foo> --abort

The --abort options undo the effect of the earlier runs.  "git bisect"
also keeps some state on progress.

	git bisect (good|bad); # continue
	git bisect skip
	git bisect reset

> 	module_list "$@" |
> 	while read mode sha1 stage path
> 	do		
> 		name=$(module_name "$path") || exit
> 		url=$(git config submodule."$name".url)
> 		update_module=$(git config submodule."$name".update)
> 		
> 		if test -n "$submodule_resume"
> 		then
> 			SubmodulePathResume=`pwd`
> 			SubmodulePathResume=$SubmodulePathResume/"$name"

It might be more idiomatic to say

	module_list "$@" |
	...
			(
				prefix="$prefix$path/"

Three benefits:

 - local variables tend to get short, lowercase names
 - this variable looks like a path, but using $name makes it not
   one (if foo/bar is a submodule simple named "bar", for example)
 - using relative paths allows an update to be resumed after moving
   a repository or just accessing it via a different path.

The subshell ensures the old prefix is restored when cmd_update
returns.  The same effect could also be achieved by saving the old
prefix (in case it is important to save a few processes).

> 			
> 			#say $SubmodulePathResume
> 			if test -e ./.git/SubmoduleUpdateLog.log

What if I try to resume and there is no progress information?
Would it make sense to keep the progress information at the toplevel,
so one could run commands like "submodule update --recursive
--resumable" in submodules without affecting the superproject state?


> 			then
> 				AFile=`cat "./.git/SubmoduleUpdateLog.log" | grep "$SubmodulePathResume"`
> 				
> 				#say $AFile;			
> 				if test -n "$AFile"

The following could work if each submodule is written to
submodule-update.log only if all its submodules have been updated
(as in your current code):

		if git grep --no-index -q -F "$prefix" "$GIT_DIR/submodule-update.log"
		then
			say "Skip...
			continue
		fi

I'm not sure fgrep is portable, which is why I use "git grep" here.

This is slower than it could be.  Ideally one would only keep
the last updated submodule and chop the module_list output there,
instead of re-reading the list with each iteration (which is O(size of
directory squared)).

Hope that helps,
Jonathan

  reply	other threads:[~2010-10-29 16:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-28  7:25 Restart submodule update --recursive Lukasz Palczewski
2010-10-28 10:35 ` Johan Herland
2010-10-29  7:28   ` Lukasz Palczewski
2010-10-28 18:15 ` Jonathan Nieder
2010-10-29  7:17   ` Lukasz Palczewski
2010-10-29  9:12     ` Jonathan Nieder
2010-10-29 11:37       ` Lukasz Palczewski
2010-10-29 16:40         ` Jonathan Nieder [this message]
2010-10-30  7:17         ` Jens Lehmann
2010-11-02  8:18           ` Lukasz Palczewski
2010-11-02 11:08             ` Jens Lehmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101029164055.GA28934@burratino \
    --to=jrnieder@gmail.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=johan@herland.net \
    --cc=l.palczewski@prevac.pl \
    --cc=p.pientka@prevac.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).