* Re: [PATCH] Documentation: Update information about <format> in git-for-each-ref
From: Junio C Hamano @ 2006-11-01 15:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Jakub Narebski
In-Reply-To: <454875AC.6060300@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> ... For me it's the other
> way around, so I think of the above as "if it doesn't compare to this
> or that, then do this", but the "are equal to" meaning of "compare"
> isn't intuitive to me as I spent the first several years of my
> english-speaking life using "compare" exclusively as a verb.
<offtopic>
I think I should have said that "I force me to pronounce" and I
am trying to say the same thing as you said.
xxxcmp(a, b) literally is "compare a and b and give me the
result"; the result coming back as "true" when a and b are
different is counter-intuitive and I think it is so to
everybody, not limited to non-English speaking people. That's
why I force me to ignore the etymology of the "cmp" in the
function name and call that "a and b differs" or "subtract b
from a" depending on the context.
By the way, I think "a compares to b" is also a verb, not just
"i compare a and b and found these differences".
</offtopic>
^ permalink raw reply
* Re: How to view an old revision?
From: Andy Whitcroft @ 2006-11-01 14:46 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git, Junio C Hamano
In-Reply-To: <3bbc18d20611010637s6d05aecbt98322b62cf7235e8@mail.gmail.com>
Matt McCutchen wrote:
> On 11/1/06, Andy Whitcroft <apw@shadowen.org> wrote:
>> git cat-file -p <commit-ish>:<file>
>
> Nice! Thanks! I had guessed "git cat-file -p <commit-ish>/<file>"
> but didn't try a colon as the separator. The colon syntax ought to be
> mentioned in the git-cat-file man page.
There are some improvements in the documentation in 'next' but nothing
which would make this easier for you to find.
Junio, I wonder if we should be changing the usage for this command
slightly. Currently, it mearly says <object> as the identifier for the
blob. Really this is <object-ish> as it supports symbolic naming in
addition to raw sha1's. I also feel it would be very helpful if
<commit-ish> and family were documented as a glossary section in main
git manpage.
Something like this:
<commit-ish>:: is an sha1 for a commit, or any symbolic name for a
commit (see SPECIFYING REVISIONS in git-rev-parse)
What do people think. I can do the munging about if its seems like a
sane plan.
^ permalink raw reply
* Re: How to view an old revision?
From: Matt McCutchen @ 2006-11-01 14:37 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <4548AFA2.1040606@shadowen.org>
On 11/1/06, Andy Whitcroft <apw@shadowen.org> wrote:
> git cat-file -p <commit-ish>:<file>
Nice! Thanks! I had guessed "git cat-file -p <commit-ish>/<file>"
but didn't try a colon as the separator. The colon syntax ought to be
mentioned in the git-cat-file man page.
^ permalink raw reply
* Re: How to view an old revision?
From: Andy Whitcroft @ 2006-11-01 14:30 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <3bbc18d20611010620m11e40402v44334a8c486a4932@mail.gmail.com>
Matt McCutchen wrote:
> Dear git people,
>
> How do I view an old revision of a file without actually checking it
> out? This would be analogous to "cvs checkout -r <old> -p". I've
> RTMed and STWed and can't seem to find a way.
>
Something like the following:
git cat-file -p <commit-ish>:<file>
For example:
git cat-file -p tags/v1.4.3:git.c
git cat-file -p f5f75c652b9c2347522159a87297820103e593e4:git.c
^ permalink raw reply
* How to view an old revision?
From: Matt McCutchen @ 2006-11-01 14:20 UTC (permalink / raw)
To: git
Dear git people,
How do I view an old revision of a file without actually checking it
out? This would be analogous to "cvs checkout -r <old> -p". I've
RTMed and STWed and can't seem to find a way.
^ permalink raw reply
* Re: [PATCH 9/n] gitweb: Better support for non-CSS aware web browsers
From: Petr Baudis @ 2006-11-01 13:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611011433.22279.jnareb@gmail.com>
Dear diary, on Wed, Nov 01, 2006 at 02:33:21PM CET, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> For people who want to use non-CSS aware browsers, like w3m, elinks, links
> text browsers, for looking at "blob" and "commitdiff"/"blobdiff" views
> of gitweb.
JFYI, ELinks supports CSS. (Well, not completely, but it does handle
white-space: pre.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* [PATCH 10/n] gitweb: New improved formatting of chunk header in diff
From: Jakub Narebski @ 2006-11-01 13:36 UTC (permalink / raw)
To: git
In-Reply-To: <200610301953.01875.jnareb@gmail.com>
If we have provided enough info, and diff is not combined diff,
and if provided diff line is chunk header, then:
* split chunk header into .chunk_info and .section span elements,
first containing proper chunk header, second section heading
(aka. which function), for separate styling: the proper chunk
header is on non-white background, section heading part uses
slightly lighter color.
* hyperlink from-file-range to starting line of from-file, if file
was not created.
* hyperlink to-file-range to starting line of to-file, if file
was not deleted.
Links are of invisible variety (and "list" class).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
As usual, you can check out the new version of gitweb at work at my
web page:
http://roke_._dyndns_._info/cgi-bin/gitweb/gitweb.cgi
The actual formatting is open for discussion.
gitweb/gitweb.css | 13 +++++++++++++
gitweb/gitweb.perl | 18 +++++++++++++++++-
2 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 87dbc52..41c3084 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -327,11 +327,13 @@ div.diff.extended_header {
padding: 2px 0px 2px 0px;
}
+div.diff a.list,
div.diff a.path,
div.diff a.hash {
text-decoration: none;
}
+div.diff a.list:hover,
div.diff a.path:hover,
div.diff a.hash:hover {
text-decoration: underline;
@@ -355,14 +357,25 @@ div.diff.rem {
color: #cc0000;
}
+div.diff.chunk_header a,
div.diff.chunk_header {
color: #990099;
+}
+div.diff.chunk_header {
border: dotted #ffe0ff;
border-width: 1px 0px 0px 0px;
margin-top: 2px;
}
+div.diff.chunk_header span.chunk_info {
+ background-color: #ffeeff;
+}
+
+div.diff.chunk_header span.section {
+ color: #aa22aa;
+}
+
div.diff.incomplete {
color: #cccccc;
}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b8fcafc..a7739af 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -830,6 +830,7 @@ sub format_subject_html {
sub format_diff_line {
my $line = shift;
+ my ($from, $to) = @_;
my $char = substr($line, 0, 1);
my $diff_class = "";
@@ -845,6 +846,21 @@ sub format_diff_line {
$diff_class = " incomplete";
}
$line = untabify($line);
+ if ($from && $to && $line =~ m/^\@{2} /) {
+ my ($from_text, $from_start, $from_lines, $to_text, $to_start, $to_lines, $section) =
+ $line =~ m/^\@{2} (-(\d+),(\d+)) (\+(\d+),(\d+)) \@{2}(.*)$/;
+ if ($from->{'href'}) {
+ $from_text = $cgi->a({-href=>"$from->{'href'}#l$from_start",
+ -class=>"list"}, $from_text);
+ }
+ if ($to->{'href'}) {
+ $to_text = $cgi->a({-href=>"$to->{'href'}#l$to_start",
+ -class=>"list"}, $to_text);
+ }
+ $line = "<span class=\"chunk_info\">@@ $from_text $to_text @@</span>" .
+ "<span class=\"section\">" . esc_html($section, -nbsp=>1) . "</span>";
+ return "<div class=\"diff$diff_class\">$line</div>\n";
+ }
return "<div class=\"diff$diff_class\">" . esc_html($line, -nbsp=>1) . "</div>\n";
}
@@ -2205,7 +2221,7 @@ sub git_patchset_body {
next LINE;
}
- print format_diff_line($patch_line);
+ print format_diff_line($patch_line, \%from, \%to);
}
print "</div>\n" if $patch_found; # class="patch"
--
1.4.3.3
^ permalink raw reply related
* [PATCH 9/n] gitweb: Better support for non-CSS aware web browsers
From: Jakub Narebski @ 2006-11-01 13:33 UTC (permalink / raw)
To: git
In-Reply-To: <200610301953.01875.jnareb@gmail.com>
Add option to replace SPC (' ') with hard (non-breakable) space HTML
entity ' ' in esc_html subroutine.
Replace ' ' with ' ' for the code/diff display part in git_blob
and git_patchset_body; this is to be able to view code and diffs in
web browsers which doesn't understand "white-space: pre;" CSS
declaration.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
For people who want to use non-CSS aware browsers, like w3m, elinks, links
text browsers, for looking at "blob" and "commitdiff"/"blobdiff" views
of gitweb.
HTH.
gitweb/gitweb.perl | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5c82093..b8fcafc 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -554,12 +554,17 @@ sub esc_url {
}
# replace invalid utf8 character with SUBSTITUTION sequence
-sub esc_html {
+sub esc_html ($;%) {
my $str = shift;
+ my %opts = @_;
+
$str = to_utf8($str);
$str = escapeHTML($str);
$str =~ s/\014/^L/g; # escape FORM FEED (FF) character (e.g. in COPYING file)
$str =~ s/\033/^[/g; # "escape" ESCAPE (\e) character (e.g. commit 20a3847d8a5032ce41f90dcc68abfb36e6fee9b1)
+ if ($opts{'-nbsp'}) {
+ $str =~ s/ / /g;
+ }
return $str;
}
@@ -840,7 +845,7 @@ sub format_diff_line {
$diff_class = " incomplete";
}
$line = untabify($line);
- return "<div class=\"diff$diff_class\">" . esc_html($line) . "</div>\n";
+ return "<div class=\"diff$diff_class\">" . esc_html($line, -nbsp=>1) . "</div>\n";
}
## ----------------------------------------------------------------------
@@ -2985,7 +2990,7 @@ sub git_blob {
$nr++;
$line = untabify($line);
printf "<div class=\"pre\"><a id=\"l%i\" href=\"#l%i\" class=\"linenr\">%4i</a> %s</div>\n",
- $nr, $nr, $nr, esc_html($line);
+ $nr, $nr, $nr, esc_html($line, -nbsp=>1);
}
close $fd
or print "Reading blob failed.\n";
--
1.4.3.3
^ permalink raw reply related
* Re: [PATCH] Introduce git-mirror, a tool for exactly mirroring another repository.
From: Jakub Narebski @ 2006-11-01 12:23 UTC (permalink / raw)
To: git
In-Reply-To: <20061101151859.0e984d3f.vsu@altlinux.ru>
Sergey Vlasov wrote:
>> Perhaps just don't remove log when branch is deleted. I tend for example
>> to be careful when reordering commits on a branch, and use git branch -f
>> instead of deleting and recreating branch to not lose reflog.
>
> Keeping the reflog does not help - reflog entries are not refs, and do
> not keep the referenced objects live in the repository. Therefore old
> objects will be lost when the repository is repacked and pruned.
Well, now to reorder and choose which commits on branch to save, and
optionally also rebase, I use
$ git branch tmp
$ git branch -f <branch> <upstream>
$ git checkout <branch>
$ git cherry-pick tmp~<n>
...
$ git branch -D tmp
> Also, the reflog really must be deleted together with the ref itself -
> otherwise it may cause a file/directory conflict when another ref is
> created. Of course, if the ref is renamed instead of deleting, the
> corresponding reflog may be renamed too.
There is currently no command to rename branch (and rename reflog).
It would be nice if git-branch could also rename branch (and reflog).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Introduce git-mirror, a tool for exactly mirroring another repository.
From: Sergey Vlasov @ 2006-11-01 12:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ei8s19$e04$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]
On Wed, 01 Nov 2006 02:08:08 +0100 Jakub Narebski wrote:
> Junio C Hamano wrote:
> > Sergey Vlasov <vsu@altlinux.ru> writes:
> >> BTW, I was thinking about the possibility to save removed refs under,
> >> e.g., refs/old/`date -I`/; maybe even non-fast-forward refs could be
> >> saved there - this will ensure that no object will ever disappear from
> >> the mirror, no matter what is done on the master side. Obviously, in
> >> this case remote refs like refs/old/* should be filtered.
> >
> > I do not think that belongs to git-mirror. It might be better to
> > have that option in update-ref machinery so that you would even
> > be protected from a `git branch -d` ran by mistake.
I agree - this would be even better.
What name format should be used for such saved refs? refs/old/`date -I`
is not unique enough; probably `date --utc +%Y.%m.%d-%H.%M.%S`? And it
would be good if multiple refs which were deleted or modified in a
non-fast-forward way during a single operation (like git-mirror) would
be saved together - which may be tricky if they are saved at the lower
level (in update-ref).
Adding the fast-forward check into update-ref also does not look nice,
but this check is required for full safety.
> Perhaps just don't remove log when branch is deleted. I tend for example
> to be careful when reordering commits on a branch, and use git branch -f
> instead of deleting and recreating branch to not lose reflog.
Keeping the reflog does not help - reflog entries are not refs, and do
not keep the referenced objects live in the repository. Therefore old
objects will be lost when the repository is repacked and pruned.
Also, the reflog really must be deleted together with the ref itself -
otherwise it may cause a file/directory conflict when another ref is
created. Of course, if the ref is renamed instead of deleting, the
corresponding reflog may be renamed too.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Jakub Narebski @ 2006-11-01 11:22 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0611010109t6281a120qeed21e0d3b29ad0c@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> On 11/1/06, Junio C Hamano <junkio@cox.net> wrote:
>> I think at the UI level, the most appropriate place would be
>> "git reset". Checkout is a Porcelainish that is primarily about
>> working tree and it updates the index as a side effect (from the
>> UI point of view); you can update the working tree without
>> modifying index or you can update both index and the working
>> tree, but updating only index and not working tree does not
>> belong there.
>
> Then perhaps git-reset should do "co HEAD path" too if --index is not
specified?
> To sum up:
> - git reset HEAD path -> git checkout HEAD path
> - git reset --index HEAD path -> git-ls-files HEAD path|git
> update-index --index-info
> - git reset HEAD (without path) -> the current behaviour
>
> Because <commit-ish> may be missing, there is some ambiguation here.
Currently "git reset --soft <commit-ish>" updates current head only,
"git reset <commit-ish>" is "git reset --mixed <commit-ish>" and updates
head and index, and "git reset --hard <commit-ish>" updates head, index
and working tree.
The same should be the case for "git reset [--soft|--mixed|--hard]
[<commit-ish>] [--] [paths...]", with the exception that it wouldn't
never update current head. (So --soft with pathspec wouldn't make sense).
On the other hand git-reset is mainly about resetting current head,
so perhaps git-reset isn't the best place to update fragments of index
from HEAD branch.
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: Problem with git-push
From: Johannes Schindelin @ 2006-11-01 11:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Florent Thoumie, git
In-Reply-To: <7v64e0qclo.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 31 Oct 2006, Junio C Hamano wrote:
> So the next thing to see is why adjust_shared_perm() is failing
> for you.
>
> Oops.
>
> I think this function is broken at the concept level. This is
> to work around people's broken umask (when you are working with
> other people, your umask should not be stronger than 007) and
> tries to flip group writability bit on.
>
> First of all, if the necessary bits are already on, it is not
> necessary to run chmod(),
right
> but more importantly, if the directory in question was created by
> somebody else, I do not think this chmod() would succeed even if you are
> in the same group as the owner (i.e. previous creator) of the directory.
But if somebody else created it, it should already have the correct
permissions in the first place (unless the user played around with them,
which is not a pilot error, but a willfull pointing of the barrel in the
general direction of your knee).
> [jc: I am CC'ing Johannes to blame him on commit 457f06d6;
> git-pickaxe is turning out to be quite handy ;-)
I am hating the tool already.
> if (dir) {
> *dir = 0;
> mkdir(filename, 0777);
> - if (adjust_shared_perm(filename))
> + if (adjust_shared_perm(filename)) {
> + *dir = '/';
> return -2;
> + }
How about this instead:
- mkdir(filename, 0777);
- if (adjust_shared_perm(filename))
+ if (!mkdir(filename, 0777) && adjust_shared_perm(filename)) {
+ *dir = '/';
return -2;
+ }
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation: Update information about <format> in git-for-each-ref
From: Andreas Ericsson @ 2006-11-01 10:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vd5877duh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>> Jakub Narebski wrote:
>>
>>> BTW. I had to translate
>>> + if (strcmp(who, "tagger") && strcmp(who, "committer"))
>>> to
>>> + if (strcmp(who, "tagger") == 0 || strcmp(who, "committer") == 0)
>>> to understand it. But this is probably my lack of contact with such
>>> C idioms.
>> But this does the exact opposite....
>> "Compare" (as in "strcmp") also translates to "are equal to" and isn't
>> only a verb. This is unfortunate for people who aren't natively
>> english and has had me confused on many a long night...
>
> Being a non-English speaker, I always pronounce xxxcmp() used as
> boolean 'is different' in my head. The (correct version of the)
> above example expression is read as 'if it is different from
> "tagger" and it is different from "committer", then do this'.
>
Without any slight intended toward your english proficiency, I'd say
your programming is better than your english. For me it's the other way
around, so I think of the above as "if it doesn't compare to this or
that, then do this", but the "are equal to" meaning of "compare" isn't
intuitive to me as I spent the first several years of my
english-speaking life using "compare" exclusively as a verb.
And yes. There was a compliment hidden in there. Soak it up. You've
earned it. ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Andy Parkins @ 2006-11-01 9:53 UTC (permalink / raw)
To: git
In-Reply-To: <7v4ptj7dfg.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2006 November 01 08:56, Junio C Hamano wrote:
> update-index is a plumbing that is about updating index (hence
> its name) and should not care what the HEAD is, and it does not
> even have to have _any_ head to do its work, so in that sense,
> "update-index --reset" is conceptually a layering violation.
Of course; I was really only reporting that git-update-index was the place I
(as a newbie) went looking for this function.
However, from a UI point of view updating the index from HEAD is just as much
of an update to the index as updating it from the working directory. When I
went looking, I had no idea that update-index was plumbing and not porcelain.
In fact, as it's a regularly used command (git-update-index; git-commit) I'm
surprised it's classed as plumbing.
> But these two commands are meant to be used as building blocks,
> so if there are more suitable UI commands at the Porcelain layer
> to implement what we want to do without introducing more special
> cases to these plumbing commands, I would rather not touch them.
As I mentioned in my original email, I was wishing for
git-reset --mixed HEAD oops/file1
But of course, that doesn't make any sense in the context of of git-reset,
which is really only a HEAD manipulator with extras.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Jakub Narebski @ 2006-11-01 9:38 UTC (permalink / raw)
To: git
In-Reply-To: <7vvelz7eg2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Given a commit that is different from the current HEAD, "reset"
> moves the HEAD and depending on hardness of the reset it updates
> the index and the working tree. Currently the command does not
> take paths limiters and means "the whole tree", but asking to
> update only one would logically fall as a natural extension to
> the current command line if we add paths limiters.
>
> As an implementation detail of the new "reset", the ls-tree to
> update-index pipe could be used.
On the other hand "reset" moves the HEAD, and with pathspec it wouldn't
do that. But there is the same case for "checkout" with pathspec. And this
would make "reset" and "checkout" more similar...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Allow deletion of several patches at once
From: Karl Hasselström @ 2006-11-01 9:07 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061023123714.GB10872@diana.vm.bytemark.co.uk>
From: Karl Hasselström <kha@treskal.com>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
This is an updated patch, which uses parse_patches() to support patch
ranges. It replaces patch 2/2 in the series; patch 1/2 (original
delete regression test) is unaffected.
stgit/commands/delete.py | 54 +++++++++++++++++------
t/t1600-delete-one.sh | 109 ++++++++++++++++++++++++++++++++++++++++++++++
t/t1600-delete.sh | 109 ----------------------------------------------
t/t1601-delete-many.sh | 55 +++++++++++++++++++++++
4 files changed, 205 insertions(+), 122 deletions(-)
diff --git a/stgit/commands/delete.py b/stgit/commands/delete.py
index c97d8ed..2f3aece 100644
--- a/stgit/commands/delete.py
+++ b/stgit/commands/delete.py
@@ -24,30 +24,58 @@ from stgit.utils import *
from stgit import stack, git
-help = 'remove the topmost or any unapplied patch'
-usage = """%prog [options] <patch>
+help = 'delete patches'
+usage = """%prog [options] [<patch1>] [<patch2>] [<patch3>..<patch4>]
-Delete the patch passed as argument. The patch to be deleted can only
-be part of the unapplied list or be the topmost one, in the latter
-case the command also popping it from the stack. Note that the
-'delete' operation is irreversible."""
+Delete the patches passed as arguments. If an applied patch is to be
+deleted, all other patches applied on top of it must be deleted too;
+and they must be explicitly specified, since this command will not try
+to delete a patch unless you explicitly ask it to. If any applied
+patches are deleted, they are popped from the stack.
+
+Note that the 'delete' operation is irreversible."""
options = [make_option('-b', '--branch',
help = 'use BRANCH instead of the default one')]
def func(parser, options, args):
- """Deletes a patch
- """
- if len(args) != 1:
- parser.error('incorrect number of arguments')
+ """Deletes one or more patches."""
+ applied_patches = crt_series.get_applied()
+ unapplied_patches = crt_series.get_unapplied()
+ all_patches = applied_patches + unapplied_patches
+
+ if args:
+ patches = parse_patches(args, all_patches)
+ else:
+ parser.error('No patches specified')
+
+ applied = {}
+ unapplied = {}
+ for patch in patches:
+ if patch in unapplied_patches:
+ unapplied[patch] = None
+ else:
+ applied[patch] = None
- if args[0] == crt_series.get_current():
+ while crt_series.get_current() in applied:
+ patch = crt_series.get_current()
check_local_changes()
check_conflicts()
check_head_top_equal()
+ crt_series.delete_patch(patch)
+ del applied[patch]
+ print 'Patch "%s" successfully deleted' % patch
+
+ for patch in unapplied.iterkeys():
+ crt_series.delete_patch(patch)
+ print 'Patch "%s" successfully deleted' % patch
+
+ if applied:
+ print 'Error: failed to delete %s' % ', '.join(applied.iterkeys())
- crt_series.delete_patch(args[0])
- print 'Patch "%s" successfully deleted' % args[0]
+ failed = len(applied)
+ if failed:
+ raise CmdException, 'Failed to delete %d patches' % failed
if not options.branch:
print_crt_patch()
diff --git a/t/t1600-delete-one.sh b/t/t1600-delete-one.sh
new file mode 100644
index 0000000..df03d79
--- /dev/null
+++ b/t/t1600-delete-one.sh
@@ -0,0 +1,109 @@
+#!/bin/sh
+# Copyright (c) 2006 Karl Hasselström
+test_description='Test the delete command (deleting one patch at a time).'
+. ./test-lib.sh
+
+test_expect_success \
+ 'Initialize the StGIT repository' \
+ 'stg init'
+
+test_expect_success \
+ 'Create a patch' \
+ '
+ stg new foo -m foo &&
+ echo foo > foo.txt &&
+ stg add foo.txt &&
+ stg refresh
+ '
+
+test_expect_success \
+ 'Try to delete a non-existing patch' \
+ '
+ [ $(stg applied | wc -l) -eq 1 ] &&
+ ! stg delete bar &&
+ [ $(stg applied | wc -l) -eq 1 ]
+ '
+
+test_expect_success \
+ 'Try to delete the topmost patch while dirty' \
+ '
+ echo dirty >> foo.txt &&
+ [ $(stg applied | wc -l) -eq 1 ] &&
+ ! stg delete foo &&
+ [ $(stg applied | wc -l) -eq 1 ] &&
+ git reset --hard
+ '
+
+test_expect_success \
+ 'Delete the topmost patch' \
+ '
+ [ $(stg applied | wc -l) -eq 1 ] &&
+ stg delete foo &&
+ [ $(stg applied | wc -l) -eq 0 ]
+ '
+
+test_expect_success \
+ 'Create an unapplied patch' \
+ '
+ stg new foo -m foo &&
+ echo foo > foo.txt &&
+ stg add foo.txt &&
+ stg refresh &&
+ stg pop
+ '
+
+test_expect_success \
+ 'Delete an unapplied patch' \
+ '
+ [ $(stg unapplied | wc -l) -eq 1 ] &&
+ stg delete foo &&
+ [ $(stg unapplied | wc -l) -eq 0 ]
+ '
+
+test_expect_success \
+ 'Create two patches' \
+ '
+ stg new foo -m foo &&
+ echo foo > foo.txt &&
+ stg add foo.txt &&
+ stg refresh &&
+ stg new bar -m bar &&
+ echo bar > bar.txt &&
+ stg add bar.txt &&
+ stg refresh
+ '
+
+test_expect_success \
+ 'Try to delete a non-topmost applied patch' \
+ '
+ [ $(stg applied | wc -l) -eq 2 ] &&
+ ! stg delete foo &&
+ [ $(stg applied | wc -l) -eq 2 ]
+ '
+
+test_expect_success \
+ 'Create another branch, and put one patch in each branch' \
+ '
+ stg branch --create br &&
+ stg new baz -m baz &&
+ echo baz > baz.txt &&
+ stg add baz.txt &&
+ stg refresh &&
+ stg branch master &&
+ stg new baz -m baz &&
+ echo baz > baz.txt &&
+ stg add baz.txt &&
+ stg refresh
+ '
+
+test_expect_success \
+ 'Delete a patch in another branch' \
+ '
+ [ $(stg applied | wc -l) -eq 3 ] &&
+ [ $(stg applied -b br | wc -l) -eq 1 ] &&
+ stg delete -b br baz &&
+ [ $(stg applied | wc -l) -eq 3 ] &&
+ [ $(stg applied -b br | wc -l) -eq 0 ]
+ '
+
+test_done
diff --git a/t/t1600-delete.sh b/t/t1600-delete.sh
deleted file mode 100644
index e22e624..0000000
--- a/t/t1600-delete.sh
+++ /dev/null
@@ -1,109 +0,0 @@
-#!/bin/sh
-# Copyright (c) 2006 Karl Hasselström
-test_description='Test the delete command.'
-. ./test-lib.sh
-
-test_expect_success \
- 'Initialize the StGIT repository' \
- 'stg init'
-
-test_expect_success \
- 'Create a patch' \
- '
- stg new foo -m foo &&
- echo foo > foo.txt &&
- stg add foo.txt &&
- stg refresh
- '
-
-test_expect_success \
- 'Try to delete a non-existing patch' \
- '
- [ $(stg applied | wc -l) -eq 1 ] &&
- ! stg delete bar &&
- [ $(stg applied | wc -l) -eq 1 ]
- '
-
-test_expect_success \
- 'Try to delete the topmost patch while dirty' \
- '
- echo dirty >> foo.txt &&
- [ $(stg applied | wc -l) -eq 1 ] &&
- ! stg delete foo &&
- [ $(stg applied | wc -l) -eq 1 ] &&
- git reset --hard
- '
-
-test_expect_success \
- 'Delete the topmost patch' \
- '
- [ $(stg applied | wc -l) -eq 1 ] &&
- stg delete foo &&
- [ $(stg applied | wc -l) -eq 0 ]
- '
-
-test_expect_success \
- 'Create an unapplied patch' \
- '
- stg new foo -m foo &&
- echo foo > foo.txt &&
- stg add foo.txt &&
- stg refresh &&
- stg pop
- '
-
-test_expect_success \
- 'Delete an unapplied patch' \
- '
- [ $(stg unapplied | wc -l) -eq 1 ] &&
- stg delete foo &&
- [ $(stg unapplied | wc -l) -eq 0 ]
- '
-
-test_expect_success \
- 'Create two patches' \
- '
- stg new foo -m foo &&
- echo foo > foo.txt &&
- stg add foo.txt &&
- stg refresh &&
- stg new bar -m bar &&
- echo bar > bar.txt &&
- stg add bar.txt &&
- stg refresh
- '
-
-test_expect_success \
- 'Try to delete a non-topmost applied patch' \
- '
- [ $(stg applied | wc -l) -eq 2 ] &&
- ! stg delete foo &&
- [ $(stg applied | wc -l) -eq 2 ]
- '
-
-test_expect_success \
- 'Create another branch, and put one patch in each branch' \
- '
- stg branch --create br &&
- stg new baz -m baz &&
- echo baz > baz.txt &&
- stg add baz.txt &&
- stg refresh &&
- stg branch master &&
- stg new baz -m baz &&
- echo baz > baz.txt &&
- stg add baz.txt &&
- stg refresh
- '
-
-test_expect_success \
- 'Delete a patch in another branch' \
- '
- [ $(stg applied | wc -l) -eq 3 ] &&
- [ $(stg applied -b br | wc -l) -eq 1 ] &&
- stg delete -b br baz &&
- [ $(stg applied | wc -l) -eq 3 ] &&
- [ $(stg applied -b br | wc -l) -eq 0 ]
- '
-
-test_done
diff --git a/t/t1601-delete-many.sh b/t/t1601-delete-many.sh
new file mode 100644
index 0000000..8648ed1
--- /dev/null
+++ b/t/t1601-delete-many.sh
@@ -0,0 +1,55 @@
+#!/bin/sh
+# Copyright (c) 2006 Karl Hasselström
+test_description='Test the delete command (deleting many patches at once).'
+. ./test-lib.sh
+
+test_expect_success \
+ 'Initialize the StGIT repository' \
+ 'stg init'
+
+test_expect_success \
+ 'Create five applied and five unapplied patches' \
+ '
+ stg new foo0 -m foo0 &&
+ echo foo0 > foo.txt &&
+ stg add foo.txt &&
+ stg refresh &&
+ for i in 1 2 3 4 5 6 7 8 9; do
+ stg new foo$i -m foo$i &&
+ echo foo$i >> foo.txt &&
+ stg refresh;
+ done &&
+ stg pop -n 5
+ '
+
+test_expect_success \
+ 'Delete some patches' \
+ '
+ [ $(stg applied | wc -l) -eq 5 ] &&
+ [ $(stg unapplied | wc -l) -eq 5 ] &&
+ stg delete foo7 foo6 foo3 foo4 &&
+ [ $(stg applied | wc -l) -eq 3 ] &&
+ [ $(stg unapplied | wc -l) -eq 3 ]
+ '
+
+test_expect_success \
+ 'Delete some more patches, some of which do not exist' \
+ '
+ [ $(stg applied | wc -l) -eq 3 ] &&
+ [ $(stg unapplied | wc -l) -eq 3 ] &&
+ ! stg delete foo7 foo8 foo2 foo0 &&
+ [ $(stg applied | wc -l) -eq 3 ] &&
+ [ $(stg unapplied | wc -l) -eq 3 ]
+ '
+
+test_expect_success \
+ 'Delete a range of patches' \
+ '
+ [ $(stg applied | wc -l) -eq 3 ] &&
+ [ $(stg unapplied | wc -l) -eq 3 ] &&
+ stg delete foo1..foo8 &&
+ [ $(stg applied | wc -l) -eq 1 ] &&
+ [ $(stg unapplied | wc -l) -eq 1 ]
+ '
+
^ permalink raw reply related
* Re: Restore a single file in the index back to HEAD
From: Nguyen Thai Ngoc Duy @ 2006-11-01 9:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvelz7eg2.fsf@assigned-by-dhcp.cox.net>
On 11/1/06, Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> >> I would prefer "git update-index --reset frotz" or "git checkout
> >> --index HEAD frotz". git ls-tree|git update-index is too cryptic for
> >> me and too long for my fingers.
> >
> > Then perhaps you can use "git checkout HEAD frotz", which is the
> > simplest?
>
> Sorry, Oops.
>
> One should never respond to a message in an ancient thread
> unless one has enough time to revisit previous messages and
> refresh one's memory.
>
> The original topic was about updating the index entry without
> touching working tree, so "co HEAD path" would not do what was
> wanted.
>
> I think at the UI level, the most appropriate place would be
> "git reset". Checkout is a Porcelainish that is primarily about
> working tree and it updates the index as a side effect (from the
> UI point of view); you can update the working tree without
> modifying index or you can update both index and the working
> tree, but updating only index and not working tree does not
> belong there.
Then perhaps git-reset should do "co HEAD path" too if --index is not specified?
To sum up:
- git reset HEAD path -> git checkout HEAD path
- git reset --index HEAD path -> git-ls-files HEAD path|git
update-index --index-info
- git reset HEAD (without path) -> the current behaviour
Because <commit-ish> may be missing, there is some ambiguation here.
--
^ permalink raw reply
* [PATCH] Allow hand-editing of patches before sending
From: Karl Hasselström @ 2006-11-01 9:00 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
From: Karl Hasselström <kha@treskal.com>
This adds a new flag to 'stg mail', allowing the user to hand-edit
each patch e-mail before it is sent, just like it is currently
possible to edit the cover message.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Intended use is to allow the user to write comments like this, when
there is only one patch and a cover mail would be overkill.
stgit/commands/mail.py | 59 ++++++++++++++++++++++++++++--------------------
1 files changed, 35 insertions(+), 24 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index 970ae3e..26c711d 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -108,6 +108,9 @@ options = [make_option('-a', '--all',
make_option('-e', '--edit',
help = 'edit the cover message before sending',
action = 'store_true'),
+ make_option('-E', '--edit-patches',
+ help = 'edit each patch before sending',
+ action = 'store_true'),
make_option('-s', '--sleep', type = 'int', metavar = 'SECONDS',
help = 'sleep for SECONDS between e-mails sending'),
make_option('--refid',
@@ -276,6 +279,34 @@ def __build_extra_headers():
return headers
+def edit_message(msg):
+ fname = '.stgitmail.txt'
+
+ # create the initial file
+ f = file(fname, 'w')
+ f.write(msg)
+ f.close()
+
+ # the editor
+ if config.has_option('stgit', 'editor'):
+ editor = config.get('stgit', 'editor')
+ elif 'EDITOR' in os.environ:
+ editor = os.environ['EDITOR']
+ else:
+ editor = 'vi'
+ editor += ' %s' % fname
+
+ print 'Invoking the editor: "%s"...' % editor,
+ sys.stdout.flush()
+ print 'done (exit code: %d)' % os.system(editor)
+
+ # read the message back
+ f = file(fname)
+ msg = f.read()
+ f.close()
+
+ return msg
+
def __build_cover(tmpl, total_nr, msg_id, options):
"""Build the cover message (series description) to be sent via SMTP
"""
@@ -326,30 +357,7 @@ def __build_cover(tmpl, total_nr, msg_id
'supported in the patch template'
if options.edit:
- fname = '.stgitmail.txt'
-
- # create the initial file
- f = file(fname, 'w+')
- f.write(msg)
- f.close()
-
- # the editor
- if config.has_option('stgit', 'editor'):
- editor = config.get('stgit', 'editor')
- elif 'EDITOR' in os.environ:
- editor = os.environ['EDITOR']
- else:
- editor = 'vi'
- editor += ' %s' % fname
-
- print 'Invoking the editor: "%s"...' % editor,
- sys.stdout.flush()
- print 'done (exit code: %d)' % os.system(editor)
-
- # read the message back
- f = file(fname)
- msg = f.read()
- f.close()
+ msg = edit_message(msg)
return msg.strip('\n')
@@ -431,6 +439,9 @@ def __build_message(tmpl, patch, patch_n
raise CmdException, 'Only "%(name)s" variables are ' \
'supported in the patch template'
+ if options.edit_patches:
+ msg = edit_message(msg)
+
return msg.strip('\n')
^ permalink raw reply related
* Re: Restore a single file in the index back to HEAD
From: Junio C Hamano @ 2006-11-01 8:56 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611010839.35436.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
>> Then perhaps you can use "git checkout HEAD frotz", which is the
>> simplest?
>
> Doesn't that update the working directory as well as the
> index?
Yes, sorry, see my other mail.
> (imaginary) "git-update-index --reset" would not.
update-index is a plumbing that is about updating index (hence
its name) and should not care what the HEAD is, and it does not
even have to have _any_ head to do its work, so in that sense,
"update-index --reset" is conceptually a layering violation.
Another possibility is read-tree, which is another plumbing that
is about updating index from an existing tree (or three). It
does not take paths limiter, so conceptually that is not too
bad. We _could_ do so if we really wanted to.
But these two commands are meant to be used as building blocks,
so if there are more suitable UI commands at the Porcelain layer
to implement what we want to do without introducing more special
cases to these plumbing commands, I would rather not touch them.
^ permalink raw reply
* Re: [PATCH] Documentation: Update information about <format> in git-for-each-ref
From: Junio C Hamano @ 2006-11-01 8:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Jakub Narebski
In-Reply-To: <45485A0F.3040807@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Jakub Narebski wrote:
>
>> BTW. I had to translate
>> + if (strcmp(who, "tagger") && strcmp(who, "committer"))
>> to
>> + if (strcmp(who, "tagger") == 0 || strcmp(who, "committer") == 0)
>> to understand it. But this is probably my lack of contact with such
>> C idioms.
>
> But this does the exact opposite....
> "Compare" (as in "strcmp") also translates to "are equal to" and isn't
> only a verb. This is unfortunate for people who aren't natively
> english and has had me confused on many a long night...
Being a non-English speaker, I always pronounce xxxcmp() used as
boolean 'is different' in my head. The (correct version of the)
above example expression is read as 'if it is different from
"tagger" and it is different from "committer", then do this'.
Otherwise I pronounce xxxcmp(a,b) "difference"; it's sign
matches (a-b).
if (xxxcmp(a,b) < 0) is similar to if ((a-b) < 0) which is
equivalent to if (a < b).
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Andy Parkins @ 2006-11-01 8:39 UTC (permalink / raw)
To: git
In-Reply-To: <7vpsc78ua3.fsf@assigned-by-dhcp.cox.net>
> > I would prefer "git update-index --reset frotz" or "git checkout
> > --index HEAD frotz". git ls-tree|git update-index is too cryptic for
> > me and too long for my fingers.
>
> Then perhaps you can use "git checkout HEAD frotz", which is the
> simplest?
Doesn't that update the working directory as well as the index? My original
question was addressed perfectly with the point at the "--index-info" switch.
However, before I asked here I was looking at the man page for update-index
looking for something like
git-update-index --reset $FILE
I suppose, if it were being implemented it should be
git-update-index --reset $COMMIT $FILE
Incidentally, this wouldn't be exactly the same as
git-ls-tree $COMMIT $FILE | git-update-index --index-info
because the git-ls-tree version needs to be run from the root of the working
directory (this bit me when I first ran it) while the
(imaginary) "git-update-index --reset" would not.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Junio C Hamano @ 2006-11-01 8:34 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <7vpsc78ua3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> I would prefer "git update-index --reset frotz" or "git checkout
>> --index HEAD frotz". git ls-tree|git update-index is too cryptic for
>> me and too long for my fingers.
>
> Then perhaps you can use "git checkout HEAD frotz", which is the
> simplest?
Sorry, Oops.
One should never respond to a message in an ancient thread
unless one has enough time to revisit previous messages and
refresh one's memory.
The original topic was about updating the index entry without
touching working tree, so "co HEAD path" would not do what was
wanted.
I think at the UI level, the most appropriate place would be
"git reset". Checkout is a Porcelainish that is primarily about
working tree and it updates the index as a side effect (from the
UI point of view); you can update the working tree without
modifying index or you can update both index and the working
tree, but updating only index and not working tree does not
belong there.
Given a commit that is different from the current HEAD, "reset"
moves the HEAD and depending on hardness of the reset it updates
the index and the working tree. Currently the command does not
take paths limiters and means "the whole tree", but asking to
update only one would logically fall as a natural extension to
the current command line if we add paths limiters.
As an implementation detail of the new "reset", the ls-tree to
update-index pipe could be used.
^ permalink raw reply
* Re: [PATCH] Documentation: Update information about <format> in git-for-each-ref
From: Andreas Ericsson @ 2006-11-01 8:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200610282323.57797.jnareb@gmail.com>
Jakub Narebski wrote:
> Junio C Hamano wrote:
>> [PATCH] for-each-ref: epoch and epochdate
>>
>> This adds "epoch" (which is parallel to "tagger" or "committer")
>> and "epochdate" (corresponds to "taggerdate" and
>> "committerdate").
>>
>> As other "date" fields, "epochdate" sorts numerically
>> and displays human readably
>
> I was thinking about having only "epochdate" (corresponding to either
> "taggerdate" or "committerdate"), only named "epoch". There is I think
> no need for field which would be "tagger" or "committer", and
> especially not named "epoch" ;-).
>
> Otherwise looks fine, thanks a lot.
>
>
> BTW. I had to translate
> + if (strcmp(who, "tagger") && strcmp(who, "committer"))
> to
> + if (strcmp(who, "tagger") == 0 || strcmp(who, "committer") == 0)
> to understand it. But this is probably my lack of contact with such
> C idioms.
But this does the exact opposite. The condition will now be true if the
'who' variable holds a pointer to a string that is either "tagger" or
"committer", whereas it used to be true for strings that were anything
*but* any of those.
"Compare" (as in "strcmp") also translates to "are equal to" and isn't
only a verb. This is unfortunate for people who aren't natively english
and has had me confused on many a long night. I once ended up doing a
macro called "string_matches" just to wrap my head around an insanely
long conditional with too many strcmp() with about half of them negated
by !.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* [RFHC] _XOPEN_SOURCE and OpenBSD 3.9
From: Junio C Hamano @ 2006-11-01 8:16 UTC (permalink / raw)
To: git; +Cc: Jason Riedy
I was futzing with an OpenBSD 3.9 bochs today, and it appears
that without __BSD_VISIBILITY we get a complaint from the
compiler that says S_ISLNK() is implicitly declared function
(cache.h has an inline create_ce_mode() that uses this macro).
I do not think this breaks things on Linux boxes, but I do not
have access to other archs, hence this request for help and
comments.
Jason Riedy CC'ed who did the initial _XOPEN_SOURCE=500 for AIX
portability.
Oh, yes, I know OpenBSD 4.0 is very soon coming...
diff --git a/convert-objects.c b/convert-objects.c
index 631678b..2ff19d2 100644
--- a/convert-objects.c
+++ b/convert-objects.c
@@ -1,4 +1,4 @@
-#define _XOPEN_SOURCE 500 /* glibc2 and AIX 5.3L need this */
+#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500; 600 for OBSD */
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#define _GNU_SOURCE
#include <time.h>
^ permalink raw reply related
* Re: Restore a single file in the index back to HEAD
From: Junio C Hamano @ 2006-11-01 8:07 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Andreas Ericsson, git
In-Reply-To: <fcaeb9bf0610312358g1176e4d8q8962b08c2e8ff2c6@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 10/27/06, Junio C Hamano <junkio@cox.net> wrote:
>> On the other hand, I designed --index-info to be compatible with
>> ls-tree output (it is not an accident, it was designed). In
>>
>> git ls-tree HEAD frotz | git update-index --index-info
>>
>> "frotz" part does not have to be the exact path but can be a
>> directory name. It means "revert everything in this directory".
>>
>> This is quite heavy-handed and you would probably want to run
>> update-index --refresh afterwards.
>
> I would prefer "git update-index --reset frotz" or "git checkout
> --index HEAD frotz". git ls-tree|git update-index is too cryptic for
> me and too long for my fingers.
Then perhaps you can use "git checkout HEAD frotz", which is the
simplest?
^ 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