Git handling

[Igor]

Is there any simple way that we automatically produce a patch of changes made to the (kernel / uboot) source? Of course also if files are added.

[zador.blood.stained]

Of course also if files are added.

git add .
git diff --staged > /path/to/file.patch

Or did you mean something else?

[Igor]

What if we dont have clean branch? On the top of our patching?

 

Wrote on mobile phone

[tkaiser]

Well, longsleep suggested using Quilt a while ago (haven't looked into myself yet)

[zador.blood.stained]

@Igor

 

Then you have to commit existing changes before that to create a reference point to differentiate one patch set from another.

 

To make a commit in new git environment you will have to pass some dummy author and email for "git commit" command.

[zador.blood.stained]

Well, longsleep suggested using Quilt a while ago (haven't looked into myself yet)

I saw this. I've read quilt documentation, and if I understood it correctly, quilt requires explicit configuration in order to work, so simple "drop patch file in a directory and it will be picked up automatically in LC_ALL=C sorting order" and overriding base patches by placing file with same name in userpatches will not work without extra configuration. Current stateless patching code is simple but easy to understand and easy to work with IMO.

[wildcat_paris]

probably unrelated

Corentin Labbe told me

 

when he provides a patch with

https://github.com/montjoie/linux/commit/4fe9df6163446eac07e53d1f37c72f4b7a3bcfd3

the cleartext patch is

https://github.com/montjoie/linux/commit/4fe9df6163446eac07e53d1f37c72f4b7a3bcfd3.patch

 

[zador.blood.stained]

when he provides a patch with

https://github.com/montjoie/linux/commit/4fe9df6163446eac07e53d1f37c72f4b7a3bcfd3

the cleartext patch is

https://github.com/montjoie/linux/commit/4fe9df6163446eac07e53d1f37c72f4b7a3bcfd3.patch

This is useful to remember for downloading commits from GitHub 

[martinayotte]

Maybe I've been missing something, but to extract the patches from git only requires to do a "git format-patch" with a revisions range.

[Igor]

I came out with this solution:

# define this @start
git config --global user.name 'John Doe' 
git config --global user.email johndoe@somedomain.com

# at source tree
git add .
git diff --staged > userpatches/$family-$unixtime.patch.disabled

# check if there are changes
if  patch not empty echo "There was changes"
        patch is here ->
        do you want to include it into build?
        yes -> enable ()
fi
# go back 
git reset --soft HEAD~ 

# after each compile execute this at source
find . -name \*.rej | xargs rm -f
git add .
git commit

[zador.blood.stained]

# after each compile execute this at source
find . -name \*.rej | xargs rm -f
git add .
git commit

What is the point of this? Am I missing something? We are resetting sources on each compilation, so this will only add useless commits to git history.

[Igor]

Main point is to create a patch if sources has been changed manually, on the next run.

 

This must be under some switch of course - "developer / debug mode". Now we have this:

 

FORCE_CHECKOUT="yes"                                    # ignore manual changes to source

 

but if set to "NO" it of course does not work if we run patch series once again. And we need to extract our manual change ...

[zador.blood.stained]

Then maybe do something like this

If this new parameter is set

# force checkout sources
# apply usual patches
# commit changes
echo "Now make your changes in $LINUXSOURCEDIR"
echo "Press <Enter> after you are done"
read
cd $LINUXSOURCEDIR
git add .
git diff --staged > $SRC/userpatches/patch/99-$LINUXFAMILY-$(date +'%d.%m.%Y').patch
echo "Grab your patch from $SRC/userpatches/patch/99-$LINUXFAMILY-$(date +'%d.%m.%Y').patch"
# proceed with compilation

[Igor]

Done, if not set, it can't make any damage. 

[zador.blood.stained]

Speaking of git handling - why are we creating new working copy on each update instead of pulling changes into existing tree (I mean in case we are checking out branches, not tags)?

Not only "fetch_from_github" looks unnecessarily complicated, it also appears to be broken at least for sunxi-tools repository.

[Igor]

Updating on shallow clone was not working properly.

 

Many times, when changes was made on remote, git pull was updating / downloading everything with whole history.

 

Perhaps better solution exists?

[zador.blood.stained]

Perhaps better solution exists?

Perhaps: https://stackoverflow.com/a/19528379

 

I will try to rework Git handling either before new Armbian release or after, so there is enough time to test.

 

I would try to split the code for tags (safe to assume they don't need any update from remote logic) and branches (fetch with depth 1 if remote was updated).

[Igor]

OK.

 

It's also a good time to create a new tag before this / any major rework. Current system is building fine / without major flaws.