Date: Mon, 4 Apr 2022 07:48:06 +0200
From: Stefano Brivio <sbrivio@redhat.com>
To: Sevinj Aghayeva <sevinj.aghayeva@gmail.com>
Cc: Roopa Prabhu <roopa.prabhu@gmail.com>, outreachy linux kernel
 <outreachy@lists.linux.dev>
Subject: Re: [PATCH v3 1/3] staging: rtl8723bs: remove redundant braces in
 if statements
Message-ID: <20220404074806.739c9fc3@elisabeth>
In-Reply-To: <CAGe6so8TdMGFzuGGwR9n5KS1iQjPsxq+VUMp1HgGBn5=eC4b-g@mail.gmail.com>
References: <cover.1648840991.git.sevinj.aghayeva@gmail.com>
	<1a9f181f7f30f71c03e6e88df9fb8c17a298a192.1648840991.git.sevinj.aghayeva@gmail.com>
	<Ykl/4mIsSzaPRr+y@kroah.com>
	<CAMWRUK4BpTFf8fGoANjjOEZ2dxCws=QPLPJ166JPgnsdsy+pmg@mail.gmail.com>
	<CAMWRUK43UO-nT3-8G1GBt9ZzTqGo_j2=_YyE686-8H01ub3meQ@mail.gmail.com>
	<CAGe6so8TdMGFzuGGwR9n5KS1iQjPsxq+VUMp1HgGBn5=eC4b-g@mail.gmail.com>
Organization: Red Hat
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Sevinj,

On Sun, 3 Apr 2022 08:40:08 -0700
Roopa Prabhu <roopa.prabhu@gmail.com> wrote:

> On Sun, Apr 3, 2022 at 7:25 AM Sevinj Aghayeva
> <sevinj.aghayeva@gmail.com> wrote:
> >
> > (Sending this only to outreachy.)
> >
> > I just did "git fetch origin" and then "git rebase origin" while I was
> > in the branch that didn't apply to Greg's tree. I got a merge conflict
> > in ext4/super.c. None of my changes have modified ext4/super.c, so why
> > do I get a conflict on this file? Can someone please explain?  
> 
> The file on your branch is still different from the one on
> master/origin even if you have not changed it and git is not able to
> merge the file automatically.

...this can happen, in turn, for (at least?) two reasons:

- true, you didn't modify ext4/super.c, but another commit (not
  yours) touching ext4/super.c also affects one of the files that are
  modified by any of your commits, or anything you have in your local
  tree. This is probably the case here.

- the upstream tree, itself, was rebased. Most kernel trees upstream
  have a no-rebase policy, that is, once a commit (including merge
  commits) has been published (pushed) by the maintainer to that tree,
  that commit will never disappear from the history. This should be the
  case for the staging tree as well, as far as I know.

  So you can pull, at any moment, and that will just "add" commits to
  your history, never modify one. The rationale is somewhat explained
  by:

	https://lwn.net/Articles/328438/

  ...but not all kernel trees follow this policy, for some (such as
  linux-next, or nf-next) it would be impractical and of little value:
  they're not trees people are expected to do significant work on.

  In that case, contributors can expect some small disruptions in their
  workflow: at some point, their local trees might have commits based
  on a former upstream commit that doesn't exist anymore.

-- 
Stefano