git.vger.kernel.org archive mirror
 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 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).