All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: "Catalin Marinas" <catalin.marinas@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Collection of stgit issues and wishes
Date: Mon, 11 Dec 2006 00:37:54 +0100	[thread overview]
Message-ID: <200612110037.54309.jnareb@gmail.com> (raw)
In-Reply-To: <b0943d9e0612101524w3a2cccecqdd12023233e8ec0c@mail.gmail.com>

Catalin Marinas wrote:
> On 10/12/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Catalin Marinas wrote:
>>> Yes, only for updating HEAD. The refs in refs/patches/<branch>/ are
>>> written directly. I initialy wanted to add patch history support using
>>> reflogs and added "git-update-ref -m ..." for the patch commits but I
>>> found slow the pushing operation a bit. Do you only want to track the
>>> reflogs for HEAD?
>>
>> Yes, I want for StGit to provide reasons when updating HEAD. I know that
>> StGit manages it's own versioning of patches not using reflog -- fine.
>> What matters for me is reflog for HEAD after "stg commit; stg clean".
> 
> Just curious, do you run the "stg commit; stg clean" commands together
> and in this order? Neither of them would update the HEAD. The "commit"
> command simply removes the StGIT metadata for the applied patches
> since it no longer needs to track them (permanently stored to the
> repository). It doesn't change HEAD. The "clean" command only affects
> the HEAD if there are empty applied patches but after a "commit" there
> won't be any patches (only the unapplied ones which do not affect
> HEAD).
> 
> Maybe we could have reflog info for "push", "refresh", some undo
> operations. Are they of any use (I haven't used them so I can't tell)?

Ooops, I haven't been clear enough.

I meant that afer "stg commit; stg clean" I won't have any StGIT metadata,
but I'd have git metadata in reflog.

I'd like to have info in reflog for each command which changes head;
for example "push", "refresh", perhaps "pop", "float", "uncommit".
Just so I don't have long sequence of ref changes in reflog without
description of said changes after some work with StGIT on branch.


BTW. currently I use StGIT to manage a series of commits on feature
branch which implements step-by-step single feature, and would be
later send as a patch series. With StGIT I can work on final patch
in series, notice that underlying feature developed in earlier patch
(earlier commit) needs modification, so I do refresh, pop until
given patch, change patch, push all, and work on patch. Or for example
if I notice that I'd have to implement some basic feature separately,
best at beginning: pop all, create new patch etc. Very nice.

-- 
Jakub Narebski

  reply	other threads:[~2006-12-10 23:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-08 22:17 Collection of stgit issues and wishes Yann Dirson
2006-12-08 22:27 ` Jakub Narebski
2006-12-10  8:55   ` Jakub Narebski
2006-12-10 11:06     ` Jakub Narebski
     [not found]       ` <b0943d9e0612100831t7b79d4b1p436de5dbb813e51a@mail.gmail.com>
2006-12-10 17:01         ` Jakub Narebski
2006-12-10 22:26           ` Catalin Marinas
2006-12-10 23:02             ` Jakub Narebski
2006-12-10 23:24               ` Catalin Marinas
2006-12-10 23:37                 ` Jakub Narebski [this message]
2006-12-11 12:59                   ` Catalin Marinas
2006-12-21 11:39                     ` Jakub Narebski
2006-12-11 18:41               ` Yann Dirson
2006-12-13 22:14                 ` Catalin Marinas
2006-12-21 23:48                   ` Jakub Narebski
2006-12-10 16:25 ` Catalin Marinas
2006-12-17 23:15   ` Yann Dirson
2006-12-12  9:43 ` Catalin Marinas
2006-12-12 10:02   ` Jakub Narebski
2006-12-13  7:22   ` David Kågedal
2006-12-13 10:20     ` Andreas Ericsson
2006-12-13 11:03       ` Karl Hasselström
2006-12-17 23:21         ` Yann Dirson

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=200612110037.54309.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=catalin.marinas@gmail.com \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.