git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Fick <mfick@codeaurora.org>
To: Carl Baldwin <carl@ecbaldwin.net>
Cc: Theodore Ts'o <tytso@mit.edu>, Git Mailing List <git@vger.kernel.org>
Subject: Re: Bring together merge and rebase
Date: Thu, 04 Jan 2018 13:06:27 -0700	[thread overview]
Message-ID: <45915667.ye9M3CbBo5@mfick-lnx> (raw)
In-Reply-To: <20171226203153.GA21429@Carl-MBP.ecbaldwin.net>

On Tuesday, December 26, 2017 01:31:55 PM Carl Baldwin 
wrote:
...
> What I propose is that gerrit and github could end up more
> robust, featureful, and interoperable if they had this
> feature to build from.

I agree (assuming we come up with a well defined feature)

> With gerrit specifically, adopting this feature would make
> the "change" concept richer than it is now because it
> could supersede the change-id in the commit message and
> allow a change to evolve in a distributed non-linear way
> with protection against clobbering work.

We (the Gerrit maintainers) would like changes to be able to 
evolve non-linearly so that we can eventually support 
distributed Gerrit reviews, and the amended-commit pointer 
is one way I have thought to resolve this.

> I have no intention to disparage either tool. I love them
> both. They've both made my career better in different
> ways. I know there is no guarantee that github, gerrit,
> or any other tool will do anything to adopt this. But,
> I'm hoping they are reading this thread and that they
> recognize how this feature can make them a little bit
> better and jump in and help. I know it is a lot to hope
> for but I think it could be great if it happened.

We (the Gerrit maintainers) do recognize it, and I am glad 
that someone is pushing for solutions in this space.  I am 
not sure what the right solution is, and how to modify 
workflows to deal better with this.  I do think that starting 
by making your local repo track pointers to amended-commits, 
likely with various git hooks and notes (as also proposed by 
Johannes Schindelin), would be a good start.   With that in 
place, then you can attack various specific workflows.

If you want to then attack the Gerrit workflow, it would be 
good if you could prevent pushing new patchests that are 
amended versions of patchsets that are out of date.  While 
it would be great if Gerrit could reject such pushes, I 
wonder if to start, git could detect and it prevent the push 
in this situation?  Could a git push hook analyze the ref 
advertisements and figure this out (all the patchsets are in 
the advertisement)?  Can a git hook look at the ref 
advertisement?

-Martin


-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation


  reply	other threads:[~2018-01-04 20:06 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-23  6:10 Bring together merge and rebase Carl Baldwin
2017-12-23 18:59 ` Ævar Arnfjörð Bjarmason
2017-12-23 21:01   ` Carl Baldwin
2017-12-23 22:09     ` Ævar Arnfjörð Bjarmason
2017-12-26  0:16       ` Carl Baldwin
2017-12-26  1:28         ` Jacob Keller
2017-12-26 23:30           ` Igor Djordjevic
2017-12-26 17:49         ` Ævar Arnfjörð Bjarmason
2017-12-26 19:44           ` Carl Baldwin
2017-12-26 20:19             ` Paul Smith
2017-12-26 21:07               ` Carl Baldwin
2017-12-23 22:19     ` Randall S. Becker
2017-12-25 20:05       ` Carl Baldwin
2017-12-23 23:01     ` Johannes Schindelin
2017-12-24 14:13       ` Alexei Lozovsky
2018-01-04 15:44         ` Johannes Schindelin
2017-12-25 23:43       ` Carl Baldwin
2017-12-26  0:01         ` Randall S. Becker
2018-01-04 19:49       ` Martin Fick
2017-12-23 22:30   ` Johannes Schindelin
2017-12-25  3:52 ` Theodore Ts'o
2017-12-26  1:16   ` Carl Baldwin
2017-12-26  1:47     ` Jacob Keller
2017-12-26  6:02       ` Carl Baldwin
2017-12-26  8:40         ` Jacob Keller
2018-01-04 19:19           ` Martin Fick
2018-01-05  0:31             ` Martin Fick
2018-01-05  5:09             ` Carl Baldwin
2018-01-05  5:20               ` Carl Baldwin
2017-12-26 18:04     ` Theodore Ts'o
2017-12-26 20:31       ` Carl Baldwin
2018-01-04 20:06         ` Martin Fick [this message]
2018-01-05  5:06           ` Carl Baldwin
2018-01-04 19:54     ` Martin Fick
2018-01-05  4:08       ` Carl Baldwin
2018-01-05 20:14       ` Junio C Hamano
2018-01-06 17:29         ` Carl Baldwin
2018-01-06 17:32           ` Carl Baldwin
2018-01-06 21:38           ` Theodore Ts'o
2017-12-27  4:35   ` Carl Baldwin
2017-12-27 13:35     ` Alexei Lozovsky
2017-12-28  5:23       ` Carl Baldwin
2017-12-26  4:08 ` Mike Hommey
2017-12-27  2:44   ` Carl Baldwin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45915667.ye9M3CbBo5@mfick-lnx \
    --to=mfick@codeaurora.org \
    --cc=carl@ecbaldwin.net \
    --cc=git@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).