>
> Which brings us back to your "git checkout-files " use case
> above. It should be treat the same way in my opinion, so we either do
>
> git checkout-files --from=tree-ish :/
>
> or
>
> git checkout-files --from=tree-ish .
>
> But "git checkout-files --from=tree-ish" alone is rejected.
More thoughts:
git switch-branch should never detach HEAD unless asked to do so
explicitly. That also means that "git switch-branch" shouldn't accept
any of the non-branch tree-ish arguments that would have caused "git
checkout" to do so.
On Wed, Nov 28, 2018 at 3:26 PM
n alias for this
functionality for some time.
- Stefan
On Wed, Nov 28, 2018 at 3:22 PM Stefan Xenos wrote:
>
> > Since the other one is already "checkout-files", maybe this one could just
> > be "checkout-branch".
>
> I rather like switch-branch and dislik
> Since the other one is already "checkout-files", maybe this one could just be
> "checkout-branch".
I rather like switch-branch and dislike the word "checkout" since it
has been overloaded in git for so long (does it mean moving HEAD or
copying files to my working tree?)
> nobody will become
detach
git detach
git switch-branch HEAD
- Stefan
On Wed, Nov 28, 2018 at 2:48 PM Stefan Xenos wrote:
>
> I think users have problems with detached heads for several reasons:
>
> 1. Users often enter the detached head state unexpectedly (for example, by
> mistyping a "checkout
commit to deliverables.
- Stefan
On Tue, Nov 20, 2018 at 5:33 PM Jonathan Nieder wrote:
>
> Stefan Xenos wrote:
> > Jonathan Nieder wrote:
>
> >> putting it in the commit message is a way to
> >> experiment with the workflow without changing the object format
&
change graphs that are produced
during that temporary state of affairs, I'm fine with using the commit
message. We can move it to the header prior to enabling the feature by
default.
- Stefan
On Tue, Nov 20, 2018 at 2:06 PM Jonathan Nieder wrote:
>
> Stefan Xenos wrote:
> > On Tue, Nov 2
e, Nov 20, 2018 at 5:03 AM Phillip Wood wrote:
>
> On 15/11/2018 00:55, sxe...@google.com wrote:
> > From: Stefan Xenos
> >
> > +Obsolescence across cherry-picks
> > +
> > +By default the evolve command will treat cherry-picks an
> This explains why we have 'origin' fields in the meta commits, it might
> be worth putting a forward reference or note earlier on to explain why
> recording the origin is useful. (I didn't find gerrit needs it very
> convincing on its own but it is actually more general than gerrit's
> specific
;> tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
> >> parent aa7ce55545bf2c14bef48db91af1a74e2347539a
> >> parent-type content
> >> parent d64309ee51d0af12723b6cb027fc9f195b15a5e9
> >> parent-type obsolete
> >> parent 7e1bbcd3a0fa854a7a9eac9
> I was trying to see if this is something we can leave out to limit the
> initial scope.
Oh, in that case, "yes". :-) If there's a need to cut something,
origin parents would be a viable candidate.
I was thinking that this file could document the final goal so that if
anyone else wanted to
bove, I'm thinking #5 may make sense.
- Stefan
On Mon, Nov 19, 2018 at 7:55 AM SZEDER Gábor wrote:
>
> On Sat, Nov 17, 2018 at 12:30:58PM -0800, Stefan Xenos wrote:
> > > Further, I see that this document tries to suggest a proliferation of new
> > > commands
> >
&
tion in gerrit.
- Stefan
On Sun, Nov 18, 2018 at 8:15 PM Junio C Hamano wrote:
>
> Stefan Xenos writes:
>
> > The scenario you describe would not produce an origin edge in the
> > metacommit graph. If the user amended X, there would be no origin
> > edges - just a replac
> I meant the project's history, not the meta-graph thing.
In that case, we agree. The proposal suggests that "origin" should be
reachable from the meta-graph for the cherry-picked commit, NOT the
cherry-picked commit itself. Does that resolve our disagreement, or is
reachability from the
again.
On Sun, Nov 18, 2018 at 6:02 PM wrote:
>
> From: Stefan Xenos
>
> This document describes what a change graph for
> git would look like, the behavior of the evolve command,
> and the changes planned for other commands.
>
> Signed-off-by: Stefan Xenos
> ---
>
> Am I correct to understand that the reason why a commit object is
> (ab|re)used to represent a meta-commit is because by doing so we
> would get connectivity (i.e. fetching & pushing would transfer all
> the associated objects along) for free, and by not representing it
> as a new and different
e previous one that regarding the "git change" command.
On Sun, Nov 18, 2018 at 2:27 PM Stefan Xenos wrote:
>
> > I don't think this counts as a typical modification and is probably hard to
> > detect automatically.
>
> Clever use of commands! (side: wouldn't it just be easi
in metas/this_is_a_test:refs/for/master
> > +# Share the lastest commit for “Unrelated change”, without history
> > +$ git push origin HEAD:refs/for/master
>
> How do we group changes of a topic together? I think branch-diff could
> take advantage of that.
>
> > +Detailed design
the change graph, the closest merge base would be C.
> If we GC'd commit A but still have the newer A', I can either thinkthat
I'm not sure I followed that. Are you suggesting a change to the
proposal or asking for a clarification?
On Fri, Nov 16, 2018 at 1:36 PM Derrick Stolee wrote:
>
&
xpected behavior when the "branch" you
think you're manipulating turns out to be a change.
- Stefan
On Thu, Nov 15, 2018 at 4:52 AM Johannes Schindelin
wrote:
>
> Hi Stefan,
>
> On Wed, 14 Nov 2018, sxe...@google.com wrote:
>
> > From: Stefan Xenos
> >
>
resets back to the original,
and then amends it again.
> Count me in to review the technical details.
Will do!
On Mon, Oct 1, 2018 at 5:37 AM, Derrick Stolee wrote:
> On 9/29/2018 7:00 PM, Stefan Xenos wrote:
>>
>> Hello, List!
>
>
> Hello! Welcome.
>
>> I'm interes
Gerrit uses notes and branches of meta-commits internally for its
database, but it still uses the change-id footers to associate an
uploaded commit with a change within its database.
On Thu, Oct 4, 2018 at 9:05 AM, Jakub Narebski wrote:
> Junio C Hamano writes:
>> Stefan Xeno
2 2018, Taylor Blau wrote:
>
>> Hi Stefan,
>>
>> On Sat, Sep 29, 2018 at 04:00:04PM -0700, Stefan Xenos wrote:
>>> Hello, List!
>>>
>>> I'm interested in porting something like Mercurial's evolve command to
>>> Git.
>>
>> Welcome
ff a user is actively
working on, but we could discard it (with 0 cost) for commits they're
done with or were never interested in editing.
On Sat, Sep 29, 2018 at 5:55 PM, Junio C Hamano wrote:
> Stefan Xenos writes:
>
>> What is the evolve command?
>> ...
>> - Systems like ge
Hello, List!
I'm interested in porting something like Mercurial's evolve command to
Git. I'll be following up with a formal proposal shortly, but before I
do I thought I'd introduce myself to the list and find out if anyone
else is interested in this topic.
What is the evolve command?
Imagine
25 matches
Mail list logo
