Re: Request for improved commit tracking between fcoe and scsi trees

2012-10-08 Thread Neil Horman
On Sun, Oct 07, 2012 at 11:59:29AM +0100, James Bottomley wrote:
 On Wed, 2012-10-03 at 15:23 -0400, Neil Horman wrote:
  James, Robert-
  I've been doing lots of backports of FCoE code to the RHEL tree these
  last few months, and I've noticed something fairly irritating, and I was
  wondering if you two could help me out with it (in fact you two are the 
  only two
  which can).  I noticed that commits which are accepted into the FCoE tree 
  that
  get passed upstream through the scsi tree have their commit hashes altered. 
   I
  can't find any examples currently, due to the fact that you, Robert, have
  recently re-cloned your git tree at open-fcoe.org, so all this nastiness has
  been covered up currently, but if things don't change, this issue will 
  quickly
  resurface.
  
  Regardless, This makes it _really_ difficult to track a given patchs' 
  traversal 
  between trees upstream, and makes my life as a distro subsystem maintainer 
  fairly
  painful.  Normally I would just live with it, but I can't see any reason 
  why it
  should be this way, given that git can easily prevent this with a pull.  
  James,
  Robert, could you two please work out a way to provide commit hash 
  consistency
  between your trees?  It would make mine (and I'm sure many other people's)
  lives, much easier.
 
 I'm reluctant to commit to any tracking process that relies on stable
 commit ids simply because they're illusory in git:  if we find a bug in
 a commit (or even worse a bisection failure) in a tree, we fix it there,
 which causes the commit id to change.
 
 The way I do this type of tracking is via the Subject: line ... why
 can't you use that?
 
Because git workflows are rooted in the notion that (illusory or not),
commits are immutable and stable.  Like it or not, its how changes (generally
speaking) get tracked.  Every time you rewrite history, that gets messed up.
And yes, I (and any one else) pulling changes from the scsi tree could track
things based on Subject line, but thats got its own problems, as multiple trees
run the risk of of having the same trivial subject line, which is far more
likely to occur than a sha collision.  It would also require a customization of
my workflow specifically for the scsi tree that differs from any other tree that
I follow.

I think in short, I would far prefer to see a pull/merge strategy from your
downtream contributing trees, with myself handling the risk of having to do a
whole series fixup should you need to fix something during a rewrite in the scsi
tree.  I'd gladly accept that risk in exchange for the ability to handle your
tree like I do others.  It seems from your previous note that you're will to go
that route, and I certainly appreciate that.

Thanks!
Neil

 James
 
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Request for improved commit tracking between fcoe and scsi trees

2012-10-07 Thread James Bottomley
On Wed, 2012-10-03 at 15:23 -0400, Neil Horman wrote:
 James, Robert-
   I've been doing lots of backports of FCoE code to the RHEL tree these
 last few months, and I've noticed something fairly irritating, and I was
 wondering if you two could help me out with it (in fact you two are the only 
 two
 which can).  I noticed that commits which are accepted into the FCoE tree that
 get passed upstream through the scsi tree have their commit hashes altered.  I
 can't find any examples currently, due to the fact that you, Robert, have
 recently re-cloned your git tree at open-fcoe.org, so all this nastiness has
 been covered up currently, but if things don't change, this issue will quickly
 resurface.
 
 Regardless, This makes it _really_ difficult to track a given patchs' 
 traversal 
 between trees upstream, and makes my life as a distro subsystem maintainer 
 fairly
 painful.  Normally I would just live with it, but I can't see any reason why 
 it
 should be this way, given that git can easily prevent this with a pull.  
 James,
 Robert, could you two please work out a way to provide commit hash consistency
 between your trees?  It would make mine (and I'm sure many other people's)
 lives, much easier.

I'm reluctant to commit to any tracking process that relies on stable
commit ids simply because they're illusory in git:  if we find a bug in
a commit (or even worse a bisection failure) in a tree, we fix it there,
which causes the commit id to change.

The way I do this type of tracking is via the Subject: line ... why
can't you use that?

James


--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Request for improved commit tracking between fcoe and scsi trees

2012-10-07 Thread James Bottomley
On Thu, 2012-10-04 at 20:25 +, Love, Robert W wrote:
 On 10/3/2012 12:23 PM, Neil Horman wrote:
  James, Robert-
  I've been doing lots of backports of FCoE code to the RHEL tree these
  last few months, and I've noticed something fairly irritating, and I was
  wondering if you two could help me out with it (in fact you two are the 
  only two
  which can).  I noticed that commits which are accepted into the FCoE tree 
  that
  get passed upstream through the scsi tree have their commit hashes altered. 
   I
  can't find any examples currently, due to the fact that you, Robert, have
  recently re-cloned your git tree at open-fcoe.org, so all this nastiness has
  been covered up currently, but if things don't change, this issue will 
  quickly
  resurface.
 
  Regardless, This makes it _really_ difficult to track a given patchs' 
  traversal
  between trees upstream, and makes my life as a distro subsystem maintainer 
  fairly
  painful.  Normally I would just live with it, but I can't see any reason 
  why it
  should be this way, given that git can easily prevent this with a pull.  
  James,
  Robert, could you two please work out a way to provide commit hash 
  consistency
  between your trees?  It would make mine (and I'm sure many other people's)
  lives, much easier.
 
 I had included pull URLs in the covermails of my updates, but I haven't 
 lately. I will make sure to do that from now on.

Actually, I'm happy to do a pull based process with signed tags going
forwards.  However:

  Bart had a complaint 
 about a misspelling in a commit message of a patch in my last update. I 
 just resent that three patch series with the corrected commit message. I 
 included a signed-tag to pull from in the covermail.

That change changed the commit id and gives a graphic illustration of
why any tracking process based on git commit ids is wrong.

James


--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Request for improved commit tracking between fcoe and scsi trees

2012-10-04 Thread Love, Robert W
On 10/3/2012 12:23 PM, Neil Horman wrote:
 James, Robert-
   I've been doing lots of backports of FCoE code to the RHEL tree these
 last few months, and I've noticed something fairly irritating, and I was
 wondering if you two could help me out with it (in fact you two are the only 
 two
 which can).  I noticed that commits which are accepted into the FCoE tree that
 get passed upstream through the scsi tree have their commit hashes altered.  I
 can't find any examples currently, due to the fact that you, Robert, have
 recently re-cloned your git tree at open-fcoe.org, so all this nastiness has
 been covered up currently, but if things don't change, this issue will quickly
 resurface.

 Regardless, This makes it _really_ difficult to track a given patchs' 
 traversal
 between trees upstream, and makes my life as a distro subsystem maintainer 
 fairly
 painful.  Normally I would just live with it, but I can't see any reason why 
 it
 should be this way, given that git can easily prevent this with a pull.  
 James,
 Robert, could you two please work out a way to provide commit hash consistency
 between your trees?  It would make mine (and I'm sure many other people's)
 lives, much easier.

I had included pull URLs in the covermails of my updates, but I haven't 
lately. I will make sure to do that from now on. Bart had a complaint 
about a misspelling in a commit message of a patch in my last update. I 
just resent that three patch series with the corrected commit message. I 
included a signed-tag to pull from in the covermail.

Consistent commit IDs between linux-fcoe.git and scsi.git would help me 
as well. It would allow me to track commit IDs from my tree all the way 
into the distros, so that I can make sure nothing gets missed.

Thanks, //Rob
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: Request for improved commit tracking between fcoe and scsi trees

2012-10-04 Thread Zou, Yi
 On 10/3/2012 12:23 PM, Neil Horman wrote:
  James, Robert-
  I've been doing lots of backports of FCoE code to the RHEL tree these
  last few months, and I've noticed something fairly irritating, and I was
  wondering if you two could help me out with it (in fact you two are the only
 two
  which can).  I noticed that commits which are accepted into the FCoE tree 
  that
  get passed upstream through the scsi tree have their commit hashes altered. 
   I
  can't find any examples currently, due to the fact that you, Robert, have
  recently re-cloned your git tree at open-fcoe.org, so all this nastiness has
  been covered up currently, but if things don't change, this issue will 
  quickly
  resurface.
 
  Regardless, This makes it _really_ difficult to track a given patchs' 
  traversal
  between trees upstream, and makes my life as a distro subsystem maintainer
 fairly
  painful.  Normally I would just live with it, but I can't see any reason 
  why it
  should be this way, given that git can easily prevent this with a pull.  
  James,
  Robert, could you two please work out a way to provide commit hash
 consistency
  between your trees?  It would make mine (and I'm sure many other people's)
  lives, much easier.
 
 I had included pull URLs in the covermails of my updates, but I haven't
 lately. I will make sure to do that from now on. Bart had a complaint
 about a misspelling in a commit message of a patch in my last update. I
 just resent that three patch series with the corrected commit message. I
 included a signed-tag to pull from in the covermail.
 
 Consistent commit IDs between linux-fcoe.git and scsi.git would help me
 as well. It would allow me to track commit IDs from my tree all the way
 into the distros, so that I can make sure nothing gets missed.
 
 Thanks, //Rob
 --

I definitely share with Neil's comments as I did some backporting before and
had to make sure remember whatever commit id on open-fcoe is gonna change 
later, kind of defeats the commit id's purpose. So I certainly would hope 
linux-fcoe.git always gets pulled directly from scsi.git so we have 
the full true history as reflected by the commit id when Rob commits it.

Of course, James sign-off line on each open-fcoe patch is superseded by the
pull merge commit so no information loss there, except [SCSI] prefix on the 
patch 

yi


--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html