Git-subrepo: Please add an option to --all to do only one commit

[FanchTheSystem]

I am new to git-subrepo ;)

When I run : git subrepo push -a

It push my source code on all my remote repo, Ok ! :)

But it also do a commit on each update on the file .gitrepo

And It look like the second commit use the first one as parent to update .gitrepo file, and the third use the second as parent and ...

So as I use 19 sub repo in my project. I have 19 commit to 19 .gitrepo file, and only one of them contain a parent key which reference a good commit (the first one before the command)

As for all .gitrepo file, the content (parent key) reference another .gitrepo commit, it is not so easy to rebase or squash ...

I would like to be able to have only one commit for the whole work and only one reference as parent in .gitrepo file

(I think it is the same with pull)

ps : I also would like to have an easy way to add something in the commit message (like for example prefix all message with a tag [CI]

[grimmySwe]

Hi @FanchTheSystem and welcome to the git-subrepo!

First I must ask: does it work? except from you getting a lot of different parent commits?

The reason that it works this way is that every subrepo push is an "atomic" operation, so if anything goes wrong you don't end up in strange state.

I have labeled this Enhancement, so it's up for evaluation to future releases.

[grimmySwe]

@FanchTheSystem Could you create a separate issue for the commit message prefix? It's better that you do that so you get notifications if something happens.

[FanchTheSystem]

Yes it work, ok the for the second issue

[ingydotnet]

Hi @FanchTheSystem,

If git subrepo push added 19 commits, I think you can simply do this (for
now):

git reset HEAD~19
git commit -a -m 'Pushed 19 subrepos...'

I agree that push all should probably do this for you after all the pushes are
successful. We'll look into adding that soon.

[ingydotnet]

@grimmySwe, here's a reproduction strategy I worked out:

mkdir tmp
cd tmp
git clone [email protected]:ingydotnet/git-subrepo
cd git-subrepo
for subrepo in foo bar baz; do git clone --bare .git ../$subrepo; done
for subrepo in foo bar baz; do git subrepo clone ../$subrepo; done
for subrepo in foo bar baz; do (echo Hello >> $subrepo/ReadMe.pod); done
git commit -a -m Foo
git subrepo push -a
git reset HEAD~3
git commit -a -m 'Pushed 3 subrepos...'

[ingydotnet]

Note, the strategy is using the release/0.4.0 branch. I am asking the question in #313, why we update the .gitrepo file on a push ever?

[FanchTheSystem]

Thank you @ingydotnet
If I reset HEAD, I think I will also have to update the referenced commit in all the .gitrepo file (as they will not exist in the new git tree)

[grimmySwe]

See #313 for discussion on the necessity of .gitrepo update.
@ingydotnet I think your suggestion with reset after everything is done would be very nice but it will invalidate the "parents" in the .gitrepo files created along the way. You would need to remember this and always set parent to the starting parent.

[ingydotnet]

Yes, I made this comment before getting the more full picture in #313. @FanchTheSystem wait until we figure this out.

[FanchTheSystem]

as #313 may come to disable auto update

-u option should be available with --all

git-subrepo: Can't use '--update' without '--branch' or '--remote'.

[FanchTheSystem]

I read (and try to modify) the code of git subrepo 0.4.0 to see how commit of .gitrepo are handled.

The subrepo:push may be updated to disable commit on each subrepo if $all_wanted is set (to commit only at the end of the " for subdir in ${subrepos[*]}; do" loop.

After this I look for subrepo:pull and the commit is not handled the same way as in push :(
It is in a separate method which does not only the commit as far as I understand it

My conclusion was, if I want to propose a PR for this it will be more work than what I was thinking at first time. (all .gitrepo commit should be done in only one method, and it should be this method which handled the $all_wanted)

I was a little confused, so I try something more easy for my issue inspired by @ingydotnet comment:

git checkout master
git pull
git config branch.master.rebase false

save_ref=$(git rev-parse HEAD)

git subrepo push --all 

git reset --soft $save_ref
for i in $(find . -name '.gitrepo' -exec dirname {} \;)
do
    cd $i
    git config --file=".gitrepo" subrepo.parent $save_ref
    git add .gitrepo
    cd -
done

git commit -m '[CI] Push All Subrepo'

https://github.com/sil-project/Platform/blob/master/bin/git-scripts/push-subrepo.sh

[TravisRothlisberger]

I accidentally did this by rebasing the pull commits without first thinking about how it would impact git-subrepo's tracking. The resulting problem was resolved by editing the individual .gitrepo files to set the parent to the commit prior to the rebase. So then there was two commits - the rebase and the fix of the .gitrepo files. If this was automated, you could commit the changes to the .gitrepo files after confirming successful completion of all the individual subrepo pull commits and then rebase it all into a single commit.