From: Jakub Narebski <hidden> Date: 2016-08-11 20:14:37
Catalin Marinas wrote:
On 10/12/06, Jakub Narebski [off-list ref] wrote:
quoted
quoted
quoted
Here are some issues which are a bit annoying for me:
- make "stg help" (without command name) equivalent to "stg --help"
There was a patch in this area. Doesn't it work correctly now?
I use stgit 0.11
1056:[gitweb/web!git]$ stg help
usage: stg help <command>
while "stg --help" lists all commands.
quoted
quoted
quoted
- stg new lacks --sign option (I have to remember to do this during
"stg refresh").
For that I use the .git/patchdescr.tmpl file to use as the initial
commit message. This has a Signed-off-by line.
Ah. I'm sorry, I haven't noticed this. It is
in /usr/share/stgit/examples/
quoted
And as far as I can see it doe not use git credentials (user.name and
user.email).
StGIT now uses the GIT credentials (and config files).
Hmmm... in stgit 0.11 "stg refresh --sign" once gave me Signed-off-by:
Nobody line instead of using git user.name and user.email.
quoted
And yet another one: better support for reflog, namely giving the "reason"
i.e. the reflog message (like "stg push: <subject>", "stg refresh:
<subject>", "stg pop: <subject>", "stg commit" etc.), like git-rebase,
git-commit --amend and git-am (for example) does.
I had a patch doing this but I haven't included it. I considered it
was taking extra time for the push operation. I eventually added some
patch history support via the "stg log" command.
The git commands StGit uses to perform operations automatically record
changes in branches in reflog. What StGit does not provide is the "reason".
You do use git-update-ref?
--
Jakub Narebski
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:46
[Cc: git@vger.kernel.org]
Catalin Marinas wrote:
BTW, if it's not clear for me how to initially structure a patch
series, I add everything to a patch and create underlying patches
afterwards and pick hunks from the big one (usually manually, though
native support in StGIT for this would be good, as someone pointed out
on this list). If all the hunks in the big patch were added to other
patches, pushing the big one should result in an empty patch
automatically (because of the three-way merging) and can be safely
removed.
Perhaps this calls for "stg duplicate" command, which would result
in duplicating patch (perhaps one would need to provide name for
the first patch, and optionally laso for second patch) in such way
that first copy would be on top of aplied stack, and second copy
(the duplicate, with an old name) would be at the bottom of the deck
of unapplied patches.
This way if you want to for example split patch into two, you would
do
$ stg duplicate new-name
$ edit files
$ stg refresh
$ stg push
And similarly (with more duplicates) if you want to split it more.
What do you think about this?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:46
Catalin Marinas wrote:
I'll try to add a wiki page with todo/wishlist ideas and prioritise
those included before 1.0. Post 1.0, I'll try to look at changing the
repository layout a bit to reduce the amount of metadata and also
facilitate the support for transactions etc.
What about this page? Not found on
http://wiki.procode.org/cgi-bin/wiki.cgi?action=index
By the way, it would be nice to be able to put in cover mail template the
following variables:
* %(patches)s - list of patch names, each in one line, '* ' prefixed
* %(patchesdescr)s - list of patch %(shortdescr)s, the first line
of the patch description, shortlog-like word-wrapped, perhaps with,
perhaps without [PATCH m/n] prefix.
* %(diffstat) - diff statistics of first and last patch, only if
there are no gaps in patches provided nor patch reordering
(single patch, single range, or -a)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
From: Jakub Narebski <hidden> Date: 2016-08-11 19:22:00
Catalin Marinas wrote:
On 10/12/06, Jakub Narebski [off-list ref] wrote:
quoted
The git commands StGit uses to perform operations automatically record
changes in branches in reflog. What StGit does not provide is the "reason".
You do use git-update-ref?
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".
--
Jakub Narebski
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)?
--
Operations just shuffling the stack (eg. "float -s", or "push XXX;
push --undo") would probably require putting the series file itself
under version-control.
It depends on the numver of undos allowed. With only one, you could
have a series.old file or similar.
I'll try to add a wiki page with todo/wishlist ideas and prioritise
those included before 1.0. Post 1.0, I'll try to look at changing the
repository layout a bit to reduce the amount of metadata and also
facilitate the support for transactions etc.
--
Here are some issues which are a bit annoying for me:
- make "stg help" (without command name) equivalent to "stg --help"
There was a patch in this area. Doesn't it work correctly now?
I use stgit 0.11
I was in general referring to the latest HEAD in the StGIT repository.
1056:[gitweb/web!git]$ stg help
usage: stg help <command>
while "stg --help" lists all commands.
Works correctly in the latest snapshot.
quoted
quoted
And as far as I can see it doe not use git credentials (user.name and
user.email).
StGIT now uses the GIT credentials (and config files).
Hmmm... in stgit 0.11 "stg refresh --sign" once gave me Signed-off-by:
Nobody line instead of using git user.name and user.email.
Again, it is different in the latest snapshot (feature added post 0.11).
The git commands StGit uses to perform operations automatically record
changes in branches in reflog. What StGit does not provide is the "reason".
You do use git-update-ref?
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?
--
From: Jakub Narebski <hidden> Date: 2016-08-11 19:47:06
Catalin Marinas wrote:
On 10/12/06, Jakub Narebski [off-list ref] wrote:
quoted
Catalin Marinas wrote:
quoted
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
On Mon, Dec 11, 2006 at 12:02:05AM +0100, Jakub Narebski wrote:
Catalin Marinas wrote:
quoted
On 10/12/06, Jakub Narebski [off-list ref] wrote:
quoted
quoted
The git commands StGit uses to perform operations automatically record
changes in branches in reflog. What StGit does not provide is the "reason".
You do use git-update-ref?
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.
Apart from the use-case you described in a later mail, this could
provide a path to series-level logging (one of the points in my list);
since the meaningful changes in a series involve changing the HEAD, we
would the have most the needed info that way.
Operations just shuffling the stack (eg. "float -s", or "push XXX;
push --undo") would probably require putting the series file itself
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, if you made a modification but you want it committed to an
underlying patch, use "refresh --patch" or "pop --keep; refresh".
BTW, if it's not clear for me how to initially structure a patch
series, I add everything to a patch and create underlying patches
afterwards and pick hunks from the big one (usually manually, though
native support in StGIT for this would be good, as someone pointed out
on this list). If all the hunks in the big patch were added to other
patches, pushing the big one should result in an empty patch
automatically (because of the three-way merging) and can be safely
removed.
--