How to get rid of false dependencies in gerrit

It appears that when using gerrit, by default all changes depend on the previous one. I do not branch for new changes, I simply work off the master branch and then push the commited changes to a remote origin/master. A dependency is created every time even if the two commits have nothing to do with each other.

I’ve run into a few issues which makes me think that I am not using git correctly in combination with gerrit.

  • How do I fix “StrictVersion instance has no attribute 'version'” in git review
  • In Gerrit, how can I prevent a patch set from being submitted that is not completely up-to-date?
  • Jenkins configuration
  • Find out whether a branch contains unmerged changes
  • Gerrit: Fixing commit without change-id in footer
  • Get topic branch from gerrit
  • What should happen differently in my git/gerrit workflow for every commit to not be dependent on the previous commit? I’ve also tried creating a new branch for the change:

    > git pull origin master
    > git checkout -b new_branch
    > #make a change
    > git add -A
    > git commit #with gerrit's commit hook in .git/hooks
    > git push origin <sha1>:refs/for/master
    

    This works, but gerrit still reports a dependency on the previously commited item.

  • Clone repository into existing directory using NGit / JGit
  • Migrating Permissions from Gitolite to GitLab
  • How to do git-svn fetch and retain empty directory?
  • Git Bash Error: could not fork child process
  • How to solve conflicts about project.pbxproj in Xcode use git?
  • Search git history for a change in a merge commit
  • 3 Solutions collect form web for “How to get rid of false dependencies in gerrit”

    This is what Gerrit means by dependencies – A commit which is on top of another commit. If both are in review, the newer one depends on the older one.

    If you don’t want them to depend on each other, don’t create the commits on top of each other. Create one commit, then make a new branch based on master for your next commit

    (git checkout origin/master -b NEW_BRANCH_NAME).

    When you push the second commit up for review, it’s parent will already be published and it won’t depend on anything.

    I’ve been taught to get around this by doing git reset --hard HEAD~1 after each git push.

    As a variant to git reset --hard HEAD~1 I use this instead:

    git reset --hard origin/master
    

    Assuming, I’m working in master for a quick change.

    Otherwise, working in a topic branch is much preferred.

    There are many Git scripts to help manage topic branches:

    • git-flow
    • git extras
    • git create-branch

    I’m sure there are others.

    Git Baby is a git and github fan, let's start git clone.