* [PATCH] gitk - Allow specifying tabstop as other than default 8 characters.
From: Mark Levedahl @ 2007-06-26 2:43 UTC (permalink / raw)
To: gitster, paulus; +Cc: git, Mark Levedahl
In-Reply-To: <11828258013248-git-send-email-mdl123@verizon.net>
Not all projects use the convention that one tabstop = 8 characters, and
a common convention is to use one tabstop = on level of indent. For such
projects, using 8 characters per tabstop often shows too much whitespace
per indent. This allows the user to configure the number of characters
to use per tabstop.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
gitk | 17 +++++++++++++----
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index 62eefd9..06df3bb 100755
--- a/gitk
+++ b/gitk
@@ -395,7 +395,7 @@ proc confirm_popup msg {
proc makewindow {} {
global canv canv2 canv3 linespc charspc ctext cflist
- global textfont mainfont uifont
+ global textfont mainfont uifont tabstop
global findtype findtypemenu findloc findstring fstring geometry
global entries sha1entry sha1string sha1but
global maincursor textcursor curtextcursor
@@ -615,6 +615,7 @@ proc makewindow {} {
pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left
set ctext .bleft.ctext
text $ctext -background $bgcolor -foreground $fgcolor \
+ -tabs "[expr {$tabstop * $charspc}]" \
-state disabled -font $textfont \
-yscrollcommand scrolltext -wrap none
scrollbar .bleft.sb -command "$ctext yview"
@@ -824,7 +825,7 @@ proc click {w} {
}
proc savestuff {w} {
- global canv canv2 canv3 ctext cflist mainfont textfont uifont
+ global canv canv2 canv3 ctext cflist mainfont textfont uifont tabstop
global stuffsaved findmergefiles maxgraphpct
global maxwidth showneartags
global viewname viewfiles viewargs viewperm nextviewnum
@@ -838,6 +839,7 @@ proc savestuff {w} {
puts $f [list set mainfont $mainfont]
puts $f [list set textfont $textfont]
puts $f [list set uifont $uifont]
+ puts $f [list set tabstop $tabstop]
puts $f [list set findmergefiles $findmergefiles]
puts $f [list set maxgraphpct $maxgraphpct]
puts $f [list set maxwidth $maxwidth]
@@ -4696,12 +4698,13 @@ proc redisplay {} {
proc incrfont {inc} {
global mainfont textfont ctext canv phase cflist
+ global charspc tabstop
global stopped entries
unmarkmatches
set mainfont [lreplace $mainfont 1 1 [expr {[lindex $mainfont 1] + $inc}]]
set textfont [lreplace $textfont 1 1 [expr {[lindex $textfont 1] + $inc}]]
setcoords
- $ctext conf -font $textfont
+ $ctext conf -font $textfont -tabs "[expr {$tabstop * $charspc}]"
$cflist conf -font $textfont
$ctext tag conf filesep -font [concat $textfont bold]
foreach e $entries {
@@ -5852,7 +5855,7 @@ proc doprefs {} {
global maxwidth maxgraphpct diffopts
global oldprefs prefstop showneartags
global bgcolor fgcolor ctext diffcolors selectbgcolor
- global uifont
+ global uifont tabstop
set top .gitkprefs
set prefstop $top
@@ -5890,6 +5893,9 @@ proc doprefs {} {
checkbutton $top.ntag.b -variable showneartags
pack $top.ntag.b $top.ntag.l -side left
grid x $top.ntag -sticky w
+ label $top.tabstopl -text "tabstop" -font optionfont
+ spinbox $top.tabstop -from 1 -to 20 -width 4 -textvariable tabstop
+ grid x $top.tabstopl $top.tabstop -sticky w
label $top.cdisp -text "Colors: press to choose"
$top.cdisp configure -font $uifont
@@ -5988,9 +5994,11 @@ proc prefscan {} {
proc prefsok {} {
global maxwidth maxgraphpct
global oldprefs prefstop showneartags
+ global charspc ctext tabstop
catch {destroy $prefstop}
unset prefstop
+ $ctext configure -tabs "[expr {$tabstop * $charspc}]"
if {$maxwidth != $oldprefs(maxwidth)
|| $maxgraphpct != $oldprefs(maxgraphpct)} {
redisplay
@@ -6296,6 +6304,7 @@ if {$tclencoding == {}} {
set mainfont {Helvetica 9}
set textfont {Courier 9}
set uifont {Helvetica 9 bold}
+set tabstop 8
set findmergefiles 0
set maxgraphpct 50
set maxwidth 16
--
1.5.2.2.282.g9826
^ permalink raw reply related
* [PATCH] gitk - Update fontsize in patch / tree list
From: Mark Levedahl @ 2007-06-26 2:43 UTC (permalink / raw)
To: gitster, paulus; +Cc: git, Mark Levedahl
In-Reply-To: <1182825801300-git-send-email-mdl123@verizon.net>
When adjusting fontsize (using ctrl+/-), all panes except the lower right
were updated. This fixes that.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
gitk | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index cd9456e..62eefd9 100755
--- a/gitk
+++ b/gitk
@@ -4695,13 +4695,14 @@ proc redisplay {} {
}
proc incrfont {inc} {
- global mainfont textfont ctext canv phase
+ global mainfont textfont ctext canv phase cflist
global stopped entries
unmarkmatches
set mainfont [lreplace $mainfont 1 1 [expr {[lindex $mainfont 1] + $inc}]]
set textfont [lreplace $textfont 1 1 [expr {[lindex $textfont 1] + $inc}]]
setcoords
$ctext conf -font $textfont
+ $cflist conf -font $textfont
$ctext tag conf filesep -font [concat $textfont bold]
foreach e $entries {
$e conf -font $mainfont
--
1.5.2.2.282.g9826
^ permalink raw reply related
* [PATCH] gitk - Make selection highlight color configurable
From: Mark Levedahl @ 2007-06-26 2:43 UTC (permalink / raw)
To: gitster, paulus; +Cc: git, Mark Levedahl
In-Reply-To: <46807CEF.2010109@verizon.net>
Cygwin's tk by default uses a very dark selection background color that
makes the currently selected text almost unreadable. On linux, the default
selection background is a light gray which is very usable. This makes the
default a light gray everywhere but allows the user to configure the
color as well.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
gitk | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 87c3690..cd9456e 100755
--- a/gitk
+++ b/gitk
@@ -402,7 +402,7 @@ proc makewindow {} {
global rowctxmenu mergemax wrapcomment
global highlight_files gdttype
global searchstring sstring
- global bgcolor fgcolor bglist fglist diffcolors
+ global bgcolor fgcolor bglist fglist diffcolors selectbgcolor
global headctxmenu
menu .bar
@@ -457,15 +457,18 @@ proc makewindow {} {
set cscroll .tf.histframe.csb
set canv .tf.histframe.pwclist.canv
canvas $canv \
+ -selectbackground $selectbgcolor \
-background $bgcolor -bd 0 \
-yscrollincr $linespc -yscrollcommand "scrollcanv $cscroll"
.tf.histframe.pwclist add $canv
set canv2 .tf.histframe.pwclist.canv2
canvas $canv2 \
+ -selectbackground $selectbgcolor \
-background $bgcolor -bd 0 -yscrollincr $linespc
.tf.histframe.pwclist add $canv2
set canv3 .tf.histframe.pwclist.canv3
canvas $canv3 \
+ -selectbackground $selectbgcolor \
-background $bgcolor -bd 0 -yscrollincr $linespc
.tf.histframe.pwclist add $canv3
eval .tf.histframe.pwclist sash place 0 $geometry(pwsash0)
@@ -666,6 +669,7 @@ proc makewindow {} {
set cflist .bright.cfiles
set indent [font measure $mainfont "nn"]
text $cflist \
+ -selectbackground $selectbgcolor \
-background $bgcolor -foreground $fgcolor \
-font $mainfont \
-tabs [list $indent [expr {2 * $indent}]] \
@@ -825,7 +829,7 @@ proc savestuff {w} {
global maxwidth showneartags
global viewname viewfiles viewargs viewperm nextviewnum
global cmitmode wrapcomment
- global colors bgcolor fgcolor diffcolors
+ global colors bgcolor fgcolor diffcolors selectbgcolor
if {$stuffsaved} return
if {![winfo viewable .]} return
@@ -844,6 +848,7 @@ proc savestuff {w} {
puts $f [list set fgcolor $fgcolor]
puts $f [list set colors $colors]
puts $f [list set diffcolors $diffcolors]
+ puts $f [list set selectbgcolor $selectbgcolor]
puts $f "set geometry(main) [wm geometry .]"
puts $f "set geometry(topwidth) [winfo width .tf]"
@@ -5845,7 +5850,7 @@ proc doquit {} {
proc doprefs {} {
global maxwidth maxgraphpct diffopts
global oldprefs prefstop showneartags
- global bgcolor fgcolor ctext diffcolors
+ global bgcolor fgcolor ctext diffcolors selectbgcolor
global uifont
set top .gitkprefs
@@ -5912,6 +5917,10 @@ proc doprefs {} {
"diff hunk header" \
[list $ctext tag conf hunksep -foreground]]
grid x $top.hunksepbut $top.hunksep -sticky w
+ label $top.selbgsep -padx 40 -relief sunk -background $selectbgcolor
+ button $top.selbgbut -text "Select bg" -font optionfont \
+ -command [list choosecolor selectbgcolor 0 $top.selbgsep background setselbg]
+ grid x $top.selbgbut $top.selbgsep -sticky w
frame $top.buts
button $top.buts.ok -text "OK" -command prefsok -default active
@@ -5936,6 +5945,16 @@ proc choosecolor {v vi w x cmd} {
eval $cmd $c
}
+proc setselbg {c} {
+ global bglist cflist
+ foreach w $bglist {
+ $w configure -selectbackground $c
+ }
+ $cflist tag configure highlight \
+ -background [$cflist cget -selectbackground]
+ allcanvs itemconf secsel -fill $c
+}
+
proc setbg {c} {
global bglist
@@ -6292,6 +6311,7 @@ set colors {green red blue magenta darkgrey brown orange}
set bgcolor white
set fgcolor black
set diffcolors {red "#00a000" blue}
+set selectbgcolor gray85
catch {source ~/.gitk}
--
1.5.2.2.282.g9826
^ permalink raw reply related
* Re: Mark Levedahl's gitk patches
From: Mark Levedahl @ 2007-06-26 2:41 UTC (permalink / raw)
To: Johannes Sixt, Paul Mackerras, Junio C Hamano; +Cc: git, Mark Levedahl
In-Reply-To: <467FE7C4.5E421535@eudaptics.com>
Johannes Sixt wrote:
> Is there a chance that we get Mark Levedahl's gitk patches into 1.5.3:
>
>
I found a bug in the highlight patch (the color picker updated the wrong
panel in the chooser but did set the correct color), and updated the
tab-stop patch to use a spin control to enforce entry of small integers
only. As there is possible interest, I am sending the amended series.
Mark
^ permalink raw reply
* Re: [PATCH 3/3] Teach rebase -i about --preserve-merges
From: Johannes Schindelin @ 2007-06-26 2:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f5plgb$uvl$1@sea.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 442 bytes --]
Hi,
[Jakub, it would be really nice if you got into the habit again of Cc'ing,
if not To'ing, the original poster you are replying to. Thank you.]
On Tue, 26 Jun 2007, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > *2*: git-rebase without --interactive is inherently patch based (at
> > least at the moment), and therefore merges cannot be preserved.
>
> What about "git rebase --merge"?
Well, be my guest.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Teach rebase -i about --preserve-merges
From: Jakub Narebski @ 2007-06-26 0:15 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706251859270.4059@racer.site>
Johannes Schindelin wrote:
> *2*: git-rebase without --interactive is inherently patch based (at
> least at the moment), and therefore merges cannot be preserved.
What about "git rebase --merge"?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: gitweb bug?
From: Jakub Narebski @ 2007-06-26 0:05 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: Junio C Hamano, git, John 'Warthog9' Hawley
In-Reply-To: <905315640706242315v3f649ef5w2a0706d0c4c68d8e@mail.gmail.com>
On Mon, 25 June 2007, Tarmigan Casebolt wrote:
>
> I was looking through the kernel source and noticed a difference
> between the git version and the gitweb version here:
> http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=net/netlink
> on gitweb, I only see 4 files, but in git locally on linux I see 71.
>
> This might be because there are files that differ only in case? (I'm
> using OSX, which has problems with case, and in particular that
> directory of the kernel source.)
>
> Am I missing something, or is this a bug?
First of all, this question should be asked IMVHO on git mailing list,
with Cc: sent to Kernel.Org admins or John 'Warthog9' Hawley, author of
the gitweb modification (caching gitweb) used at kernel.org
I cannot help you what the contents of net/netlink should look like,
because I don't have clone of the linux kernel repository. By "in git
locally on linux" you mean in the working area? Or perhaps result of
"git ls-tree HEAD:net/netlink"? You should have provided command used
to get those 71 files, and perhaps even those 71 files list.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 3/3] config: Add --null/-z option for null-delimted output
From: Jakub Narebski @ 2007-06-25 23:29 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <11827802382221-git-send-email-frank@lichtenheld.de>
Frank Lichtenheld wrote:
> else
> - printf("%s", key_);
> + printf("%s",key_);
> }
That is a mistake, I think?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Linus Torvalds @ 2007-06-25 23:16 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0706251536240.8675@woody.linux-foundation.org>
On Mon, 25 Jun 2007, Linus Torvalds wrote:
>
> There's also another issue: regular files really *are* different from
> pipes and sockets and other things. Not because of EPIPE, but because you
> want different buffering behaviour. For a regular file, we really don't
> even care about the line buffering, and we'd actually be better off (from
> a performance angle) without it.
Just for fun, I tried this out.
Doing
time git log > logfile
on the kernel repo with and without the patch I just sent out, I get:
Without:
real 0m1.361s
user 0m1.312s
sys 0m0.040s
With:
real 0m1.687s
user 0m1.392s
sys 0m0.284s
so doing the extra flushing does actually cost us (it's just fundamentally
more expensive to do disk IO on non-block-boundaries).
It would be much nicer if we only did it for sockets and pipes, which
don't have the same block-boundary issues anyway (there's still the system
call cost, but on a pipe/socket, the real costs tend to be elsewhere).
Again, this is something that a non-stdio-based buffering library would
easily handle. You could just test the file descriptor _once_ at the
beginning, to see if it's a regular file or not. And then you could have
the error handling where it belongs (when the IO is actually done, and the
error actually happens) rather than in the callers using a bad interface
that sometimes loses 'errno'.
Btw, to balance the above performance comment: doing the flush_or_die()
obviously *does* mean that you get better performance in the odd cases.
For example, if you do
[torvalds@woody linux]$ trap '' SIGPIPE
[torvalds@woody linux]$ time git log | head
I get get 0.002s, while it used to be:
real 0m1.382s
user 0m1.340s
sys 0m0.028s
just because it did the whole thing regardless of any EPIPE errors.
Of course, that case probably isn't very usual, but I could imagine that
some users of "git blame -C --incremental" could actually cause situations
like this (ie just stop listening when they got the part they're
interested in, and maybe they'd have some strange reason to ignore
SIGPIPE).
So I'm not opposed to the patch I sent out, I just wanted to point out
that this is an area we *could* improve upon if we didn't do that stdio
thing.
Linus
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Linus Torvalds @ 2007-06-25 23:01 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0706251536240.8675@woody.linux-foundation.org>
On Mon, 25 Jun 2007, Linus Torvalds wrote:
>
> Actually, even this is really nasty, and it's a case where the current
> "git.c" code can also fail.
Just to clarify: this is why the git.c code obviously does the fstat(), in
case anybody wondered.
So I didn't mean to imply that the new git.c code in 'next' is wrong, I
just meant to imply that the "ferror()"+"fflush()" sequence that it uses
and that I copied for my example is a very unreliable sequence, and it
basically fails exactly because you can never know what caused the
ferror() to trigger - if it *ever* triggers, you're basically screwed.
I wonder how many applications actually ever use ferror() and friends.
Linus
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Linus Torvalds @ 2007-06-25 22:56 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0706251505570.8675@woody.linux-foundation.org>
On Mon, 25 Jun 2007, Linus Torvalds wrote:
>
> If you really really *must* get that ENOSPC error string output, create a
> helper function like
>
> void flush_or_die(FILE *f, const char *desc)
> {
> if (ferror(f))
> die("write failure on %s", desc)
Actually, even this is really nasty, and it's a case where the current
"git.c" code can also fail.
It's an example of where EPIPE can actually cause a write failure that you
can never figure out what the reason for the error was, because the flush
was caused by something earlier (write too much for the buffer or
whatever), exactly because stdio throws the error away.
So after thinking about it some more, I would suggest just ignoring ferror
entirely, and hoping that any errors are caught by the fflush().
I do hate stdio error checking. In my opinion, there really is only *one*
correct way to use stdio error checking: ignore it. It doesn't work. The
thing is fundamentally mis-designed for error handling.
So I think the right solution would literally be to either not do this
broken error checking at all, or to rewrite the code that cares about
errors to not use stdio.
There's also another issue: regular files really *are* different from
pipes and sockets and other things. Not because of EPIPE, but because you
want different buffering behaviour. For a regular file, we really don't
even care about the line buffering, and we'd actually be better off (from
a performance angle) without it.
But we don't have any sane way to save that kind of information (and we
definitely do *not* want to do the "fstat()" thing on every flush). We
could use the stdio buffering mode, but
- it's too weak (we want not line buffered or block buffered, we want
basically "record buffered")
- I don't think there are any portable ways to read it (only set it,
using "setbuf()" and friends).
Anyway, getting rid of stdio for writes we care about really *would* be a
nice thing. But it's a lot of boring, nasty work.
So here's a patch that I think is acceptable. IT IS NOT PERFECT. Stdio
simply cannot do a good job on errors, but it has a comment about the case
where it just decides to ignore ferror() instead of doing what I suggest
above.
I'm not saying this is great. But doing this right really does require
avoiding stdio entirely.
Does this work for you?
(I pass the "desc" string thing in case there is some future use where we
also want to use stdio, but we use it for something else than just regular
stdout. Dunno).
Linus
---
builtin-rev-list.c | 2 +-
cache.h | 2 ++
log-tree.c | 1 +
write_or_die.c | 20 ++++++++++++++++++++
4 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 813aadf..3980bf4 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -100,7 +100,7 @@ static void show_commit(struct commit *commit)
printf("%s%c", buf, hdr_termination);
free(buf);
}
- fflush(stdout);
+ flush_or_die(stdout, "stdout");
if (commit->parents) {
free_commit_list(commit->parents);
commit->parents = NULL;
diff --git a/cache.h b/cache.h
index ed83d92..aae9e2a 100644
--- a/cache.h
+++ b/cache.h
@@ -532,6 +532,8 @@ extern char git_default_name[MAX_GITNAME];
extern const char *git_commit_encoding;
extern const char *git_log_output_encoding;
+/* IO helper functions */
+extern void flush_or_die(FILE *, const char *);
extern int copy_fd(int ifd, int ofd);
extern int read_in_full(int fd, void *buf, size_t count);
extern int write_in_full(int fd, const void *buf, size_t count);
diff --git a/log-tree.c b/log-tree.c
index 0cf21bc..061ecf7 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -408,5 +408,6 @@ int log_tree_commit(struct rev_info *opt, struct commit *commit)
shown = 1;
}
opt->loginfo = NULL;
+ flush_or_die(stdout, "stdout");
return shown;
}
diff --git a/write_or_die.c b/write_or_die.c
index 5c4bc85..84f411d 100644
--- a/write_or_die.c
+++ b/write_or_die.c
@@ -1,5 +1,25 @@
#include "cache.h"
+/*
+ * Some cases use stdio, but want to flush after the write
+ * to get error handling (and to get better interactive
+ * behaviour - not buffering excessively).
+ *
+ * Of course, if the flush happened within the write itself,
+ * we've already lost the error code, and cannot report it any
+ * more. So we just ignore that case instead (and hope we get
+ * the right error code on the flush).
+ */
+void flush_or_die(FILE *f, const char *desc)
+{
+ if (fflush(f)) {
+ if (errno == EPIPE)
+ exit(0);
+ die("write failure on %s: %s",
+ desc, strerror(errno));
+ }
+}
+
int read_in_full(int fd, void *buf, size_t count)
{
char *p = buf;
^ permalink raw reply related
* Re: [StGIT RFC] Changing patch@branch syntax
From: Catalin Marinas @ 2007-06-25 22:22 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20070624212603.GA6361@nan92-1-81-57-214-146.fbx.proxad.net>
On 24/06/07, Yann Dirson <ydirson@altern.org> wrote:
> Well, currently "stg show <stack>" will just take <stack> as a git
> ref, and will show the top commit, which may well be the base commit
> of the stack - not very exciting, I agree.
Indeed. The 'show' command was meant for patches but I added the
support to fall back to git commits.
> > What might be easier with a complete spec is bash completion. I find
> > this mandatory precise description similar to the Hungarian notation.
> > Since most of the time I work with push/pop commands, I don't like
> > always putting a ":" for every patch
>
> Right, push/pop should only get the local name in the current
> patchset, no ":" whatsoever in there. It is not the same for "show",
> since we often want to look at patches in other stacks.
Yes, but most of the time I look at patches on the current branch.
> I have often wondered if it would be useful to have a given
> patch@stack as a base for another stack, or maybe as one of the
> "heads" of an hydra. Still not sure it would make any sense, however
> - especially, proper use of hydras would possibly suppress the need
> for the former.
There are situations when I want a separate branch but it relies on
patches in other branches. I currently duplicate the patches and use
the 'sync' command to keep them up to date (though this command would
be more useful with support for git-rerere to avoid fixing the same
conflict several times).
Can a patch series be part of multiple pools? This would be useful to
my workflow.
> > >I'd rather having a single name-resolution mechanism, instead of one
> > >for patches and one for branches.
> >
> > I don't see why we couldn't have a single name resolution but without
> > the mandatory ":". An example (but in reverse order) is internet
> > names. I only type "intranet" rather than "intranet." in a browser. To
> > fully qualify, I type "intranet.arm.com".
>
> There is a difference, in that in name resolution there is a
> well-define algorithm to resolve this, and in that "intranet" alone is
> not a valid fully-qualified name.
No, it's not fully qualified but it gets the .arm.com by default. If
it fails, the browser will complain.
> In current StGIT, in cases where
> "name" matches both a local patch a git ref... well, we can still ask
> for refs/heads/name as fully-qualified name - looks like I had
> forgotten that one ;)
StGIT could default to patches and fall back to git commits if no ":"
are found in the name.
> Let's try to find a proper solution.
>
> We have on one hand a number of commands (in the patch/stack sets)
> that act solely within the patchset, and thus have no need for
> referencing stackables outside the current patchset:
>
> new, push, pop, goto, float, sink, clean, uncommit, export,
> import, mail, refresh
>
> Similar commands, but which no technical issue restrain from acting on
> stackables in other patchsets:
>
> delete, hide, unhide, patches, series, files, log, rename, show
>
> Commands that solely refer to patchsets, not stackables:
>
> applied, unapplied, top, branch, rebase
Those that can refer to other patchsets have the '--branch' argument,
otherwise they just use the current series.
> Commands that need to refer to patches in other patchsets:
>
> pick
>
> Commands that don't care:
>
> assimilate, commit, init, pull, fold
>
>
> I consider we have a couple of special cases:
>
> clean currently does not care, but see task #5235
> rebase currently only needs patchets, do we need to extend that to patches ?
'rebase' could only work on the current patchset because of the
possibility of getting conflicts during push (unless you implement the
branch switching as well).
> mail currently does not accept --branch or patch@stack but probably could
Yes.
> new creates a patch in the current stack, we may want to unify
> this with "branch -c" in some way (maybe "stg
> (patch|stack|pool) new" ?)
This might be a possibility once we refactor the command line.
> show is special in that when its arg is not a ref to a patch,
> it falls back to git-show. We may want to change
> that, to be an stgit-only command.
We need the commit id generation for the 'pick' command and 'show'
would use the same code. I don't think we should restrict it.
> sync uses non-standard way to refer to the other stack - do we
> really need to sync several patches in one command ?
I have stacks with more than 10 common patches and it is useful to
update them with only one command (I do this many times only as a
simple check).
> clone is also special, in that it is currently the only one to
> have a use for the repo - it could surely be extended
> to accept a stackable (eg. "stg clone http://this/repo#pool2:stk1")
Yes, it would be nice.
> To summarize, appart from "show" which does not really need to know
> about branches, no current command would have any ambiguity.
If we don't want ambiguities in the UI, we could restrict 'show' only
to the StGIT patches (though I personally don't mind the fall-back to
GIT objects).
> > Also, shourt stgit/git.py be aware of the repository?
>
> I'd rather think that we should have git.Repository (and further
> structurate git.py with more objects, like git.Branch), with
> stgit-specific stuff in the stgit.Repository subclass.
Sounds good.
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Linus Torvalds @ 2007-06-25 22:20 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <878xa7u2gh.fsf@rho.meyering.net>
On Mon, 25 Jun 2007, Jim Meyering wrote:
>
> Remember: I'm trying to improve existing code here.
> You should save some of your ire for the person who wrote that code.
Ehh. Remind me who I should be pissed at when the old code was _better_
before your change?
With the current git.c, we report write errors quite well. We don't give
the exact output you want, but on a scale of 1-10, how important is that?
Pretty damn low on the list.
And the reason I'm really really irritated at you is that you ignore me
when I tell you what your bugs are.
- I *told* you that EPIPE is special. What did you do? Ignore my advice,
and made a broken patch that did exactly the opposite of what I told
you.
- And I *told* you that you shouldn't care about errno for stdio, because
stdio was broken. What did you do? You again ignored my advice, and
made _another_ broken patch, exactly the _opposite_ of what I told you.
If you really really *must* get that ENOSPC error string output, create a
helper function like
void flush_or_die(FILE *f, const char *desc)
{
if (ferror(f))
die("write failure on %s", desc)
if (fflush(f)) {
if (errno == EPIPE)
exit(0);
die("write failure on %s: %s",
desc, strerror(errno));
}
}
and then you can start adding calls to "flush_or_die()" to appropriate
places. You could replace the "fflush()" in builtin-rev-list.c with a
"flush_or_die()".
And then you could add a call to "log_tree_commit()" (in log-tree.c), and
that would probably be an improvement too (especially if we start having
things like gitk parse "git log" output, and try to deprecate the old
really low-level plumbing a bit).
Linus
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Jim Meyering @ 2007-06-25 22:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0706251450240.8675@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, 25 Jun 2007, Jim Meyering wrote:
>>
>> Here's a version of that patch that retains the fflush call
>> and adds a comment explaining why it's needed.
>
> Ok. I will hereby just suggest to Junio that he just not take patches from
> you.
>
> You seem to be totally unable to ever really think or worry about your own
> little uninteresting test-case, and have shown yourself totally
> uninterested in anything anybody ever tells you.
>
> In other words, you now screwed up EPIPE.
>
> AGAIN.
>
> And why? All apparently because you want "disk full" rather than just
> "write error".
>
> Jim, you really need to see past your small test, and think about the
> bigger picture.
No. I don't keep the "small", git-specific, picture in mind
all the time. Git is the only project I contribute to with
this no-EPIPE restriction, and it doesn't come naturally yet.
Here's the patch you seem to want.
---------------------------------------------------------
Without this patch, git-rev-list unnecessarily omits strerror(errno)
from its diagnostic, upon write failure:
$ ./git-rev-list --max-count=1 HEAD > /dev/full
fatal: write failure on standard output
With the patch, git reports the desired ENOSPC diagnostic:
fatal: write failure on standard output: No space left on device
* builtin-rev-list (show_commit): Diagnose a failed fflush call.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
builtin-rev-list.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 813aadf..94f8fca 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -100,7 +100,12 @@ static void show_commit(struct commit *commit)
printf("%s%c", buf, hdr_termination);
free(buf);
}
- fflush(stdout);
+
+ /* Flush regularly.
+ This is especially important for an asynchronous consumer. */
+ if (fflush(stdout) && errno != EPIPE)
+ die("write failure on standard output: %s", strerror(errno));
+
if (commit->parents) {
free_commit_list(commit->parents);
commit->parents = NULL;
^ permalink raw reply related
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Linus Torvalds @ 2007-06-25 21:53 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87bqf3u324.fsf@rho.meyering.net>
On Mon, 25 Jun 2007, Jim Meyering wrote:
>
> Here's a version of that patch that retains the fflush call
> and adds a comment explaining why it's needed.
Ok. I will hereby just suggest to Junio that he just not take patches from
you.
You seem to be totally unable to ever really think or worry about your own
little uninteresting test-case, and have shown yourself totally
uninterested in anything anybody ever tells you.
In other words, you now screwed up EPIPE.
AGAIN.
And why? All apparently because you want "disk full" rather than just
"write error".
Jim, you really need to see past your small test, and think about the
bigger picture.
Linus
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Jim Meyering @ 2007-06-25 21:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0706251349540.8675@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, 25 Jun 2007, Jim Meyering wrote:
>>
>> [this patch depends on the one I posted here:
>> http://marc.info/?l=git&m=118280134031923&w=2 ]
>>
>> Without this patch, git-rev-list unnecessarily omits strerror(errno)
>> from its diagnostic, upon write failure:
>
> And this is a perfect example of what's wrong with the whole thing.
>
> Dammit, how many times do I need to say this:
>
> - If you want reliable errors, don't use stdio!
>
> That fflush is there FOR A REASON. You removed it FOR A MUCH LESS
> IMPORTANT REASON!
Wow. No need to curse and get into ALL_CAPS_MODE every time you
reply to me. It does not advance your cause.
Remember: I'm trying to improve existing code here.
You should save some of your ire for the person who wrote that code.
> That fflush is there exactly because WE DO NOT WANT TO BUFFER the list of
> commits, because that thing is meant very much to be used for pipelines,
> and it's quite common that the receiving end is going to do something
> asynchronous with the result, and can - and does - want the results as
> soon as possible.
That's good to know. I'm glad you pointed it out. It would have been
nice to have a comment. However, wouldn't it be better at least to check
for and report fflush failure? fflush usually does a write, after all.
Most of the rest of the code is careful to diagnose write errors at
the source. Why not here?
I've posted a revised patch.
> IOW, things like "gitk" use git-rev-list exactly to get the list of
> commits, and they want that list *incrementally*. They don't want to wait
> for git-rev-list to have filled up some 8kB buffer of commits. Especially
> since generating those commits can be slow if we're talking about a big
> tree and some path-limited stuff.
>
> So for example, do something like
>
> git rev-list HEAD -- drivers/char/drm/Makefile
>
> and if you don't see the result scroll a line at a time on a slower
> machine, there's something *wrong*.
>
> Junio, I'm NAK'ing this very forcefully!
>
> Jim: I don't know what I'm doing wrong, but I'm apparently not reaching
> you. So let me try one more time:
>
> - stdio really isn't very good with error handling
>
> - if you use stdio, YOU HAD BETTER ACCEPT THAT
Using stdio is fine, as long as you know and respect its limitations.
It's a real shame that you have to intersperse your often-valuable
feedback with such vitriol.
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Jim Meyering @ 2007-06-25 21:39 UTC (permalink / raw)
To: git
In-Reply-To: <87r6nzu666.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> wrote:
> [this patch depends on the one I posted here:
> http://marc.info/?l=git&m=118280134031923&w=2 ]
Here's a version of that patch that retains the fflush call
and adds a comment explaining why it's needed.
Without this patch, git-rev-list unnecessarily omits strerror(errno)
from its diagnostic, upon write failure:
$ ./git-rev-list --max-count=1 HEAD > /dev/full
fatal: write failure on standard output
With the patch, git reports the desired ENOSPC diagnostic:
fatal: write failure on standard output: No space left on device
* builtin-rev-list (show_commit): Diagnose a failed fflush call.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
builtin-rev-list.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 813aadf..f13a594 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -100,7 +100,12 @@ static void show_commit(struct commit *commit)
printf("%s%c", buf, hdr_termination);
free(buf);
}
- fflush(stdout);
+
+ /* Flush regularly.
+ This is especially important for an asynchronous consumer. */
+ if (fflush(stdout))
+ die("write failure on standard output: %s", strerror(errno));
+
if (commit->parents) {
free_commit_list(commit->parents);
commit->parents = NULL;
^ permalink raw reply related
* [StGIT PATCH 7/7] If available, use gitk --argscmd in contrib/stg-gitk.
From: Yann Dirson @ 2007-06-25 21:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070625212229.17189.79919.stgit@gandelf.nowhere.earth>
This allows to ask gitk to recompute the list of patches to show at
every refresh. Before this, we had problems with 'stg-gitk --all':
- deleting a patch that was existing at startup time would trigger an
"unknown ref" error from gitk and force to quit/restart manually;
- patches created since startup were only visible when applied, or
when below one of the startup patches.
Note that --argscmd is not in official gitk yet, so we don't try to
use it if it's not available.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-gitk | 36 +++++++++++++++++++++++++++++-------
1 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/contrib/stg-gitk b/contrib/stg-gitk
index dd01ef0..6ddcfb1 100755
--- a/contrib/stg-gitk
+++ b/contrib/stg-gitk
@@ -7,7 +7,6 @@ set -e
# patch logs.
# LIMITATIONS:
-# - asking gitk to "update" won't detect any new ref
# - no support for spaces in branch names
# Copyright (c) 2007 Yann Dirson <ydirson@altern.org>
@@ -20,11 +19,16 @@ usage()
}
allbranches=0
-case "$1" in
---all) allbranches=1; shift ;;
---*) usage ;;
-*) break ;;
-esac
+refsonly=0
+while [ "$#" -gt 0 ]; do
+ case "$1" in
+ --refs) refsonly=1 ;;
+ --all) allbranches=1 ;;
+ --*) usage ;;
+ *) break ;;
+ esac
+ shift
+done
if [ $allbranches = 1 ] && [ "$#" -gt 0 ]; then
usage
@@ -58,4 +62,22 @@ else
done
fi
-gitk $(find $refdirs -type f -not -name '*.log' | cut -c${GIT_DIR_SPKIPLEN}- )
+printrefs()
+{
+ find $refdirs -type f -not -name '*.log' | cut -c${GIT_DIR_SPKIPLEN}-
+}
+
+if [ $refsonly = 1 ]; then
+ printrefs
+elif grep -q -- --argscmd $(which gitk); then
+ # This gitk supports --argscmd.
+ # Let's use a hack to pass --all, which was consumed during command-line parsing
+ if [ $allbranches = 1 ]; then
+ gitk --argscmd="$0 --refs --all"
+ else
+ gitk --argscmd="$0 --refs $*"
+ fi
+else
+ # This gitk does not support --argscmd, just compute refs onces
+ gitk $(printrefs)
+fi
^ permalink raw reply related
* [StGIT PATCH 6/7] Fix t1200 to catch intermediate errors.
From: Yann Dirson @ 2007-06-25 21:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070625212229.17189.79919.stgit@gandelf.nowhere.earth>
All command sequences in tests should be linked with && or
similar, to guard against potentially missing a regresssion.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
t/t1200-push-modified.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t1200-push-modified.sh b/t/t1200-push-modified.sh
index 6769667..324b3b0 100755
--- a/t/t1200-push-modified.sh
+++ b/t/t1200-push-modified.sh
@@ -21,9 +21,9 @@ test_create_repo foo
test_expect_success \
'Clone tree and setup changes' \
"stg clone foo bar &&
- (cd bar && stg new p1 -m p1
+ (cd bar && stg new p1 -m p1 &&
printf 'a\nc\n' > file && stg add file && stg refresh &&
- stg new p2 -m p2
+ stg new p2 -m p2 &&
printf 'a\nb\nc\n' > file && stg refresh
)
"
^ permalink raw reply related
* [StGIT PATCH 5/7] Changed sync not to use -b which has other semantics.
From: Yann Dirson @ 2007-06-25 21:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070625212229.17189.79919.stgit@gandelf.nowhere.earth>
Using --branch here is confusing from a UI point of view, and
unnecessarily complicates implementation, making it more delicate to
get rid of the crt-series global. We now use --ref-branch (-B)
instead.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/commands/sync.py | 13 ++++++-------
t/t2000-sync.sh | 8 ++++----
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/stgit/commands/sync.py b/stgit/commands/sync.py
index e769602..2ec7427 100644
--- a/stgit/commands/sync.py
+++ b/stgit/commands/sync.py
@@ -38,7 +38,7 @@ The sync operation can be reverted for individual patches with --undo."""
options = [make_option('-a', '--all',
help = 'synchronise all the patches',
action = 'store_true'),
- make_option('-b', '--branch',
+ make_option('-B', '--ref-branch',
help = 'syncronise patches with BRANCH'),
make_option('-s', '--series',
help = 'syncronise patches with SERIES'),
@@ -69,9 +69,9 @@ def func(parser, options, args):
global crt_series
if options.undo:
- if options.branch or options.series:
+ if options.ref_branch or options.series:
raise CmdException, \
- '--undo cannot be specified with --branch or --series'
+ '--undo cannot be specified with --ref-branch or --series'
__check_all()
out.start('Undoing the sync of "%s"' % crt_series.get_current())
@@ -80,12 +80,11 @@ def func(parser, options, args):
out.done()
return
- if options.branch:
+ if options.ref_branch:
# the main function already made crt_series to be the remote
# branch
- remote_series = crt_series
- stgit.commands.common.crt_series = crt_series = stack.Series()
- if options.branch == crt_series.get_name():
+ remote_series = stack.Series(options.ref_branch)
+ if options.ref_branch == crt_series.get_name():
raise CmdException, 'Cannot synchronise with the current branch'
remote_patches = remote_series.get_applied()
diff --git a/t/t2000-sync.sh b/t/t2000-sync.sh
index 69ab1ac..f831df7 100755
--- a/t/t2000-sync.sh
+++ b/t/t2000-sync.sh
@@ -48,7 +48,7 @@ test_expect_success \
test_expect_success \
'Synchronise second patch with the master branch' \
'
- stg sync -b master p2 &&
+ stg sync -B master p2 &&
[ "$(echo $(stg applied))" = "p1 p2 p3" ] &&
[ "$(echo $(stg unapplied))" = "" ] &&
test $(cat foo2.txt) = "foo2"
@@ -57,7 +57,7 @@ test_expect_success \
test_expect_success \
'Synchronise the first two patches with the master branch' \
'
- stg sync -b master -a &&
+ stg sync -B master -a &&
[ "$(echo $(stg applied))" = "p1 p2 p3" ] &&
[ "$(echo $(stg unapplied))" = "" ] &&
test $(cat foo1.txt) = "foo1" &&
@@ -100,7 +100,7 @@ test_expect_success \
test_expect_success \
'Synchronise second patch with the master branch' \
'
- stg sync -b master p2 &&
+ stg sync -B master p2 &&
[ "$(echo $(stg applied))" = "p1 p2 p3" ] &&
[ "$(echo $(stg unapplied))" = "" ] &&
test $(cat bar2.txt) = "bar2"
@@ -109,7 +109,7 @@ test_expect_success \
test_expect_failure \
'Synchronise the first two patches with the master branch (to fail)' \
'
- stg sync -b master -a
+ stg sync -B master -a
'
test_expect_success \
^ permalink raw reply related
* [StGIT PATCH 4/7] Fixed thinko in error message.
From: Yann Dirson @ 2007-06-25 21:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070625212229.17189.79919.stgit@gandelf.nowhere.earth>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/commands/rebase.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stgit/commands/rebase.py b/stgit/commands/rebase.py
index e47772c..c68f8e7 100644
--- a/stgit/commands/rebase.py
+++ b/stgit/commands/rebase.py
@@ -54,7 +54,7 @@ def func(parser, options, args):
# ensure an exception is raised before popping on non-existent target
if git_id(args[0]) == None:
- raise GitException, 'Unknown revision: %s' % git_id
+ raise GitException, 'Unknown revision: %s' % args[0]
applied = prepare_rebase(force=options.force)
rebase(args[0])
^ permalink raw reply related
* [StGIT PATCH 3/7] Revert part of the reverted commit that we want to keep.
From: Yann Dirson @ 2007-06-25 21:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070625212229.17189.79919.stgit@gandelf.nowhere.earth>
- get rid of unused real_rebase parameter
- revive git.all_refs()
This commit can freely be used to demonstrate the usefulness of
_always_ separating different issues in different patches :)
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/commands/common.py | 2 +-
stgit/commands/pull.py | 2 +-
stgit/commands/rebase.py | 2 +-
stgit/git.py | 6 ++++++
4 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index 22c78ae..b05979b 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -318,7 +318,7 @@ def address_or_alias(addr_str):
for addr in addr_str.split(',')]
return ', '.join([addr for addr in addr_list if addr])
-def prepare_rebase(real_rebase, force=None):
+def prepare_rebase(force=None):
if not force:
# Be sure we won't loose results of stg-(un)commit by error.
# Do not require an existing orig-base for compatibility with 0.12 and earlier.
diff --git a/stgit/commands/pull.py b/stgit/commands/pull.py
index 5f72f9b..fe3b67d 100644
--- a/stgit/commands/pull.py
+++ b/stgit/commands/pull.py
@@ -86,7 +86,7 @@ def func(parser, options, args):
else:
raise GitConfigException, 'Unsupported pull-policy "%s"' % policy
- applied = prepare_rebase(real_rebase=must_rebase, force=options.force)
+ applied = prepare_rebase(force=options.force)
# pull the remote changes
if policy == 'pull':
diff --git a/stgit/commands/rebase.py b/stgit/commands/rebase.py
index 2f0e660..e47772c 100644
--- a/stgit/commands/rebase.py
+++ b/stgit/commands/rebase.py
@@ -56,7 +56,7 @@ def func(parser, options, args):
if git_id(args[0]) == None:
raise GitException, 'Unknown revision: %s' % git_id
- applied = prepare_rebase(real_rebase=True, force=options.force)
+ applied = prepare_rebase(force=options.force)
rebase(args[0])
post_rebase(applied, options.nopush, options.merged)
diff --git a/stgit/git.py b/stgit/git.py
index 02590a9..1f57481 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -1070,3 +1070,9 @@ def fetch_head():
# here we are sure to have a single fetch_head
return fetch_head
+
+def all_refs():
+ """Return a list of all refs in the current repository.
+ """
+
+ return [line.split()[1] for line in _output_lines(['git-show-ref'])]
^ permalink raw reply related
* [StGIT PATCH 2/7] stg-cvs: update doc, and use correct setting for parent branch.
From: Yann Dirson @ 2007-06-25 21:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070625212229.17189.79919.stgit@gandelf.nowhere.earth>
This script had not been updated when we moved away from my wrong
interpretation of branch.*.merge.
At the same time, this includes some doc to set up a branch for use
with this command, and propotes design flaws to such, instead of
leaving them hidden among mere limitation of the implementation.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-cvs | 36 +++++++++++++++++++++++++-----------
1 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/contrib/stg-cvs b/contrib/stg-cvs
index 7b968d6..582f4f2 100755
--- a/contrib/stg-cvs
+++ b/contrib/stg-cvs
@@ -14,15 +14,35 @@ set -e
# - you want to add a "CVS" line to .git/info/exclude
# - you may want to add a ".git" line to the top .cvsignore
+# BRANCH INIT
+# - ensure the cvs wc is clean (eg. with "cvsco")
+# $ git init
+# $ echo CVS >> .git/info/exclude
+# $ git add .
+# $ git commit -m "Initial import."
+# $ git branch -m master cvs
+# $ stg branch -c master cvs
+# $ git config branch.master.stgit.parentbranch cvs (0.12.1 and earlier only)
+# $ git config branch.cvs.description "CVS $(cat CVS/Root) $(cat CVS/Repository) $(cat CVS/Tag 2>/dev/null | echo HEAD)"
+# $ git config branch.master.description "Changes for $(cat CVS/Repository) $(cat CVS/Tag 2>/dev/null | echo HEAD)"
+
# LIMITATIONS
# - this is only a proof-of-concept prototype
-# - lacks an "init" command
+# - lacks an "init" command (see above)
# - "commit" does not ensure the base is uptodate before trying to
-# commit (but hey, it's CVS ;)
+# commit (but hey, it's CVS ;): better "stg-cvs pull" first
# - "commit" can only commit a single patch
# - not much robustness here
-# - still bad support for files removed in cvs (should catch "no
+# - still no support for files removed in cvs (should catch "no
# longer in the repository" message)
+# - this only deals with CVS but could surely be extended to any other
+# VCS
+# - lacks synchronisation of .cvsignore <-> .gitignore
+# - no support for filenames with spaces (stg lacks --zero output format)
+# - git-commit is too chatty when it finds nothing to commit
+# - lacks a "quick cvs commit" feature
+
+# DESIGN FLAWS
# - while fetching, if a file change was not git-update-index'd when
# cvs-update'd (eg. because of a stg-cvs bug), it is not seen on further
# fetches until it changes again, since we scan "cvs update" output.
@@ -32,17 +52,11 @@ set -e
# already-existing in working copy, or to directory moves inside the
# cvs repository, or <fill here>) has to be dealt with by hand (although
# the situation is better here: cvs sees the conflict on subsequent tries)
-# - this only deals with CVS but could surely be extended to any other
-# VCS
# - bad/no support for cvsutils:
# - stg push/pop operations confuse cvsu because of timestamp changes
# - cvspurge/cvsco would nuke .git => does not make it easy to ensure
# synchronisation
# - should use a separate workspace for cvs branch like tailor does
-# - lacks synchronisation of .cvsignore <-> .gitignore
-# - no support for filenames with spaces (stg lacks --zero output format)
-# - git-commit is too chatty when it finds nothing to commit
-# - lacks a "quick cvs commit" feature
# - confused by cvs keyword substitution
usage()
@@ -102,8 +116,8 @@ cvs_add_dir()
# get context
branch=$(stg branch)
-parent=$(git-repo-config "branch.${branch}.merge") ||
- usage "no declared parent for '$branch' - set branch.${branch}.merge"
+parent=$(git-config "branch.${branch}.stgit.parentbranch") ||
+ usage "no declared parent for '$branch' - set branch.${branch}.stgit.parentbranch"
# extract command
^ permalink raw reply related
* [StGIT PATCH 1/7] Fix contrib/stg-whatchanged way of identifying a conflict.
From: Yann Dirson @ 2007-06-25 21:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070625212229.17189.79919.stgit@gandelf.nowhere.earth>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-whatchanged | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/stg-whatchanged b/contrib/stg-whatchanged
index d5b6965..a416e97 100755
--- a/contrib/stg-whatchanged
+++ b/contrib/stg-whatchanged
@@ -24,7 +24,7 @@ fi
# Merges via "push" leave top=bottom so we must look at old patch
# in this case (unlike, eg., "pick --fold")
patchdir="$(git-rev-parse --git-dir)/patches/$(stg branch)/patches/$(stg top)"
-if [ $(cat "$patchdir/bottom") = $(cat "$patchdir/top") ];
+if [ -s "$(git-rev-parse --git-dir)/conflicts" ];
then
current_cmd="stg show //top.old"
else
^ permalink raw reply related
* [StGIT PATCH 0/7] My patchqueue for 0.13.
From: Yann Dirson @ 2007-06-25 21:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
The following series contains the fixes that were scattered in the
middle of my refactoring series, but which I target at v0.13.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox