Welcome to the Linux Foundation Forum!

Storing fresh linux-next repository locally with smallest possible effort

Sometimes git pull is as fast as usual, but quite often it deals with inexact rename detection for a long time. After all, there is repo with merge conflicts and I need to re-clone linux-next to feel myself calm, because I'm not familiar with vimdiff or bcompare.
What should I watch for?

Comments

  • https://www.kernel.org/best-way-to-do-linux-clones-for-your-ci.html

    I am unable to understand your question... but this might help you :)
    Why would you be having merge conflicts while making pulls? Try stashing your changes before you fetch linux-next.

  • nkyx
    nkyx Posts: 5

    Why would you be having merge conflicts while making pulls? Try stashing your changes before you fetch linux-next.

    I don't know why it happens, but it happens even without any changes to tree from my side. Steps to reproduce are:
    1. clone linux-next
    2. git pull -> success
    3. git pull # on the next day -> success ("successfull pull" means that git status prints 'nothing to commit, working tree clean', git pull prints 'Already up to date.'
    4. git pull # at some point -> inexact renames, merge conflicts, need to deal with mergetool or smth.

  • Instead of "git pull" try the following to add remote and then fetch and rebase to a tag and see if it works better:

    git remote add next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
    git fetch next
    git rebase tag

    Might work better than "git pull" - next pulls from several repos and could be prone to conflicts

  • It happens to me before. I believe this might be due to the remote having history rewrite ? Sounds a bit crazy though :smiley:

    Anyway what I did was simply git reset --hard origin/master

  • nkyx
    nkyx Posts: 5

    Both hard reset and fetch + rebase works.
    Also
    git config pull.rebase = true # default is false (merge)
    solves problem.

Categories

Upcoming Training