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
next prev parent 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).