* Advanced aliases with arguments (?)
From: Mike Hommey @ 2007-11-04 0:40 UTC (permalink / raw)
To: git
Hi,
I read on http://git.or.cz/gitwiki/Aliases that
Starting with version 1.5.3, git supports appending the
arguments to commands prefixed with "!", too. If you need to
perform a reordering, or to use an argument twice, you can use
this trick:
[alias]
example = !sh -c "ls $1 $0"
AFAICT, it doesn't work with the 1.5.3.5 I use. Is it false advertising
or was there some regression ?
Mike
^ permalink raw reply
* Re: Advanced aliases with arguments (?)
From: Mike Hommey @ 2007-11-04 0:45 UTC (permalink / raw)
To: git
In-Reply-To: <20071104004020.GA30487@glandium.org>
On Sun, Nov 04, 2007 at 01:40:20AM +0100, Mike Hommey wrote:
> Hi,
>
> I read on http://git.or.cz/gitwiki/Aliases that
>
> Starting with version 1.5.3, git supports appending the
> arguments to commands prefixed with "!", too. If you need to
> perform a reordering, or to use an argument twice, you can use
> this trick:
>
> [alias]
> example = !sh -c "ls $1 $0"
>
>
> AFAICT, it doesn't work with the 1.5.3.5 I use. Is it false advertising
> or was there some regression ?
Aaaah it does work, but you need to use single quotes, not double
quotes.
Mike
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: Johannes Schindelin @ 2007-11-04 0:54 UTC (permalink / raw)
To: Mike Hommey
Cc: Linus Torvalds, Nicolas Pitre, Junio C Hamano, git,
Shawn O. Pearce, Jeff King
In-Reply-To: <20071103233144.GA16734@glandium.org>
Hi,
On Sun, 4 Nov 2007, Mike Hommey wrote:
> On Sat, Nov 03, 2007 at 03:48:42PM -0700, Linus Torvalds wrote:
> >
> >
> > On Sat, 3 Nov 2007, Mike Hommey wrote:
> > >
> > > How many grams in a kilogram ? How many meters in a kilometer ? How many
> > > joule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait...
> >
> > How many 'u's in the word "colour"?
> >
> > Oh, wait - it depends on context, doesn't it?
> >
> > kB is 1024 bytes. The fact that "k" means something else in other
> > contexts is simply irrelevant.
>
> What about the fact that "kB" means different things depending whether
> it's used for bandwidth or memory capacity ?
>
> Does your brain have base 2 hard-coded so that you instantly know
> 50000000 bytes are 47.68MB ? Are people unable to do so pondscum ?
Get over it. kB is not the same as km. It really means something
different. And all all people who actually _understand_ something of the
matter know what a kilobyte is.
Just because some _wankers_^Wbureaucrats decided to make life hard on
those people who have actually a _clue_ on real life, does not mean that
we have to accept it.
1kB = 1024 bytes.
1MB = 1024*1024 bytes.
Everybody who claims anything else is just an annoyance to the rest of the
world, who is not clueless, thank you very much.
And hard disk manufacturers be damned, and should burn in hell.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: Junio C Hamano @ 2007-11-04 1:03 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Mike Hommey, Linus Torvalds, Nicolas Pitre, git, Shawn O. Pearce,
Jeff King
In-Reply-To: <Pine.LNX.4.64.0711040050430.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 1kB = 1024 bytes.
>
> 1MB = 1024*1024 bytes.
>
> Everybody who claims anything else is just an annoyance to the rest of the
> world, who is not clueless, thank you very much.
>
> And hard disk manufacturers be damned, and should burn in hell.
Don't blame the hard disk people too harshly. The insanity
dates back to floppy disk days, where they marketted 1440kB
disks as 1.44MB.
I wonder if 700MB CD-ROM and 4.7GB DVD-R are also in decimal
bytes. I am too lazy to check ;-)
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: David Brown @ 2007-11-04 1:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Mike Hommey, Linus Torvalds, Nicolas Pitre,
git, Shawn O. Pearce, Jeff King
In-Reply-To: <7v1wb6yg8d.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 03, 2007 at 06:03:14PM -0700, Junio C Hamano wrote:
>I wonder if 700MB CD-ROM and 4.7GB DVD-R are also in decimal
>bytes. I am too lazy to check ;-)
Of course. A certain magneto optical manufacturer created a 605MB drive,
which they marked as 640MB, trying to make it sound like it had the same
capacity as a CD. Even with 1,000 bytes 634,388,480 is quite a stretch to
call 640MB. I never found the footnote "____ defines megabyte to be 991232
bytes".
Dave
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: Robin Rosenberg @ 2007-11-04 2:14 UTC (permalink / raw)
To: David Brown
Cc: Junio C Hamano, Johannes Schindelin, Mike Hommey, Linus Torvalds,
Nicolas Pitre, git, Shawn O. Pearce, Jeff King
In-Reply-To: <20071104014930.GA27392@old.davidb.org>
söndag 04 november 2007 skrev David Brown:
> On Sat, Nov 03, 2007 at 06:03:14PM -0700, Junio C Hamano wrote:
>
> >I wonder if 700MB CD-ROM and 4.7GB DVD-R are also in decimal
> >bytes. I am too lazy to check ;-)
>
> Of course. A certain magneto optical manufacturer created a 605MB drive,
> which they marked as 640MB, trying to make it sound like it had the same
> capacity as a CD. Even with 1,000 bytes 634,388,480 is quite a stretch to
> call 640MB. I never found the footnote "____ defines megabyte to be 991232
> bytes".
They may have used the term "unformatted" capacity.
-- robin
^ permalink raw reply
* Re: [RFC PATCH] Make gitk use --early-output
From: Michael J. Cohen @ 2007-11-04 2:07 UTC (permalink / raw)
To: Paul Mackerras, Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <18221.2285.259487.655684@cargo.ozlabs.ibm.com>
On Nov 3, 2007, at 7:49 PM, Paul Mackerras wrote:
> This makes gitk use the --early-output flag on the git log command.
On Nov 3, 2007, at 2:11 PM, Linus Torvalds wrote:
> Try it out, with
>
> git log --early-output=2
>
> and look at what happens
This is awesome, guys.
I was initially doing some research to see what makes gitk/qgit slow
over samba, but this seems to have solved it. :P
-mjc
^ permalink raw reply
* [PATCH] builtin-fetch: Add "-q" as a synonym for "--quiet"
From: Steven Grimm @ 2007-11-04 2:26 UTC (permalink / raw)
To: git; +Cc: Steven Grimm
"-q" is the very first option described in the git-fetch manpage, and it
isn't supported.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
builtin-fetch.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 003ed76..8e79055 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -517,7 +517,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
depth = argv[i];
continue;
}
- if (!strcmp(arg, "--quiet")) {
+ if (!strcmp(arg, "--quiet") || !strcmp(arg, "-q")) {
quiet = 1;
continue;
}
--
1.5.3.5.529.ge3d6d-dirty
^ permalink raw reply related
* Re: [REPLACEMENT PATCH 2/2] Add "--early-output" log flag for interactive GUI use
From: Paul Mackerras @ 2007-11-04 3:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Marco Costalba, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0711031103340.3342@woody.linux-foundation.org>
Linus Torvalds writes:
> When the full list is generated, there will be a "Final output:" string
> prepended to it, regardless of whether any early commits were shown or
> not, so that the consumer can always know the difference between early
> output and the final list.
How hard would it be to put the total number of commits on that "Final
output" line? That would be useful for me.
Paul.
^ permalink raw reply
* [PATCH] format-patch: Add configuration and off switch for --numbered
From: Brian Gernhardt @ 2007-11-04 3:38 UTC (permalink / raw)
To: git
format.numbered is a tri-state variable. Boolean values enable or
disable numbering by default and "auto" enables number when outputting
more than one patch.
--no-numbered (short: -N) will disable numbering.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
Pick your own numbering adventure. Should make everyone happy, but
will probably do the exact opposite. So it goes.
Documentation/config.txt | 6 ++++++
Documentation/git-format-patch.txt | 12 ++++++++----
builtin-log.c | 19 ++++++++++++++++++-
3 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index edf50cd..c2f9f14 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -432,6 +432,12 @@ fetch.unpackLimit::
pack from a push can make the push operation complete faster,
especially on slow filesystems.
+format.numbered::
+ A boolean which can enable sequence numbers in patch subjects.
+ Seting this option to "auto" will enable it only if there is
+ more than one patch. See --numbered option in
+ gitlink:git-format-patch[1].
+
format.headers::
Additional email headers to include in a patch to be submitted
by mail. See gitlink:git-format-patch[1].
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index f0617ef..92c0ab6 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,7 +9,7 @@ git-format-patch - Prepare patches for e-mail submission
SYNOPSIS
--------
[verse]
-'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--thread]
+'git-format-patch' [-n | -N | -k] [-o <dir> | --stdout] [--thread]
[--attach[=<boundary>] | --inline[=<boundary>]]
[-s | --signoff] [<common diff options>]
[--start-number <n>] [--numbered-files]
@@ -77,6 +77,9 @@ include::diff-options.txt[]
-n|--numbered::
Name output in '[PATCH n/m]' format.
+-N|--no-numbered::
+ Name output in '[PATCH]' format.
+
--start-number <n>::
Start numbering the patches at <n> instead of 1.
@@ -142,15 +145,16 @@ not add any suffix.
CONFIGURATION
-------------
-You can specify extra mail header lines to be added to each
-message in the repository configuration. You can also specify
-new defaults for the subject prefix and file suffix.
+You can specify extra mail header lines to be added to each message
+in the repository configuration, new defaults for the subject prefix
+and file suffix, and number patches when outputting more than one.
------------
[format]
headers = "Organization: git-foo\n"
subjectprefix = CHANGE
suffix = .txt
+ numbered = auto
------------
diff --git a/builtin-log.c b/builtin-log.c
index e8b982d..22afa1a 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -273,6 +273,8 @@ static int istitlechar(char c)
static char *extra_headers = NULL;
static int extra_headers_size = 0;
static const char *fmt_patch_suffix = ".patch";
+static int numbered = 0;
+static int auto_number = 0;
static int git_format_config(const char *var, const char *value)
{
@@ -297,6 +299,15 @@ static int git_format_config(const char *var, const char *value)
if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
return 0;
}
+ if (!strcmp(var, "format.numbered")) {
+ if (!strcasecmp(value, "auto")) {
+ auto_number = 1;
+ return 0;
+ }
+
+ numbered = git_config_bool(var, value);
+ return 0;
+ }
return git_log_config(var, value);
}
@@ -466,7 +477,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
struct rev_info rev;
int nr = 0, total, i, j;
int use_stdout = 0;
- int numbered = 0;
int start_number = -1;
int keep_subject = 0;
int numbered_files = 0; /* _just_ numbers */
@@ -503,6 +513,11 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
else if (!strcmp(argv[i], "-n") ||
!strcmp(argv[i], "--numbered"))
numbered = 1;
+ else if (!strcmp(argv[i], "-N") ||
+ !strcmp(argv[i], "--no-numbered")) {
+ numbered = 0;
+ auto_number = 0;
+ }
else if (!prefixcmp(argv[i], "--start-number="))
start_number = strtol(argv[i] + 15, NULL, 10);
else if (!strcmp(argv[i], "--numbered-files"))
@@ -642,6 +657,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
list[nr - 1] = commit;
}
total = nr;
+ if (!keep_subject && auto_number && total > 1)
+ numbered = 1;
if (numbered)
rev.total = total + start_number - 1;
rev.add_signoff = add_signoff;
--
1.5.3.5.529.ge3d6d-dirty
^ permalink raw reply related
* Why is --pretty=format: so slow?
From: Paul Mackerras @ 2007-11-04 3:42 UTC (permalink / raw)
To: Junio C Hamano, git
For some reason, using --pretty=format:... with git log is much slower
than other formats. For example, on the kernel tree (on my quad G5):
$ time git log --pretty=oneline >/dev/null
real 0m2.165s
user 0m2.092s
sys 0m0.070s
$ time git log --pretty=raw >/dev/null
real 0m2.426s
user 0m2.358s
sys 0m0.068s
$ time git log --pretty="format:%H" >/dev/null
real 0m7.843s
user 0m6.282s
sys 0m1.557s
$ time git log --pretty="format:%H {%P} %ct" >/dev/null
real 0m7.950s
user 0m6.374s
sys 0m1.573s
Strace seems to indicate that git log is doing at least one sequence
of open, fstat64, fcntl64, getdents64 and close for each line of
output in the --pretty=format: cases, but not in the other cases.
This seems rather unnecessary - could it be fixed? I'd like to use
the last format listed above with gitk, but not if it is going to make
things 3 times slower.
Paul.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-11-04 3:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vodeecyni.fsf@gitster.siamese.dyndns.org>
* The 'maint' branch has these fixes since the last announcement.
Brad King (1):
cvsexportcommit: fix for commits that do not have parents
Jakub Narebski (1):
gitweb: Update config file example for snapshot feature in
gitweb/INSTALL
Jonas Fonseca (1):
Remove escaping of '|' in manpage option sections
Jonathan del Strother (1):
Fixing path quoting in git-rebase
Kristian Høgsberg (1):
Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test
suites.
Ralf Wildenhues (1):
git-clone.txt: Improve --depth description.
Sergei Organov (3):
git-filter-branch.txt: fix a typo.
git-format-patch.txt: fix explanation of an example.
Documentation: quote commit messages consistently.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above. Notable topics are:
- fork-exec removal from MinGW work.
- the first batch of parse-options.
- terse progress display.
Short log follows.
Alex Riesen (2):
Rework make_usage to print the usage message immediately
Do no colorify test output if stdout is not a terminal
Blake Ramsdell (1):
transport.c: squelch a gcc 4.0.1 complaint about an uninitialized
variable
Emil Medve (1):
Fixed a command line option type for builtin-fsck.c
Gerrit Pape (1):
git-diff.txt: add section "output format" describing the diff
formats
James Bowes (1):
gc: use parse_options
Johannes Schindelin (2):
Add tests for parse-options.c
parse-options: Allow abbreviated options when unambiguous
Johannes Sixt (14):
Change git_connect() to return a struct child_process instead of a
pid_t.
Use start_command() in git_connect() instead of explicit fork/exec.
Use start_command() to run content filters instead of explicit
fork/exec.
Use run_command() to spawn external diff programs instead of
fork/exec.
Use start_comand() in builtin-fetch-pack.c instead of explicit
fork/exec.
Have start_command() create a pipe to read the stderr of the child.
upload-pack: Use start_command() to run pack-objects in
create_pack_file().
Add infrastructure to run a function asynchronously.
Use the asyncronous function infrastructure in
builtin-fetch-pack.c.
upload-pack: Move the revision walker into a separate function.
upload-pack: Run rev-list in an asynchronous function.
t0021-conversion.sh: Test that the clean filter really cleans
content.
Avoid a dup2(2) in apply_filter() - start_command() can do it for
us.
Use the asyncronous function infrastructure to run the content
filter.
Jonas Fonseca (1):
Update manpages to reflect new short and long option aliases
Kristian Høgsberg (5):
Enable wt-status output to a given FILE pointer.
Enable wt-status to run against non-standard index file.
Introduce entry point add_interactive and add_files_to_cache
Export rerere() and launch_editor().
Port builtin-add.c to use the new option parser.
Nicolas Pitre (16):
more compact progress display
cope with multiple line breaks within sideband progress messages
pack-objects: no delta possible with only one object in the list
pack-objects.c: fix some global variable abuse and memory leaks
fix const issues with some functions
fix for more minor memory leaks
prune-packed: don't call display_progress() for every file
make struct progress an opaque type
relax usage of the progress API
add throughput to progress display
add throughput display to index-pack
add some copyright notice to the progress display code
add throughput display to git-push
return the prune-packed progress display to the inner loop
make sure throughput display gets updated even if progress doesn't
move
Show total transferred as part of throughput progress
Pierre Habouzit (17):
Add a simple option parser.
parse-options: be able to generate usages automatically
parse-options: make some arguments optional, add callbacks.
Add shortcuts for very often used options.
parse-options: allow callbacks to take no arguments at all.
Make builtin-rm.c use parse_options.
Make builtin-mv.c use parse-options
Make builtin-branch.c use parse_options.
Make builtin-describe.c use parse_options
Make builtin-revert.c use parse_options.
Make builtin-update-ref.c use parse_options
Make builtin-symbolic-ref.c use parse_options.
Make builtin-for-each-ref.c use parse-opts.
Make builtin-fsck.c use parse_options.
Make builtin-count-objects.c use parse_options.
Make builtin-name-rev.c use parse_options.
Make builtin-pack-refs.c use parse_options.
Scott R Parish (7):
"git" returns 1; "git help" and "git help -a" return 0
remove unused/unneeded "pattern" argument of list_commands
"current_exec_path" is a misleading name, use "argv_exec_path"
list_commands(): simplify code by using chdir()
use only the $PATH for exec'ing git commands
include $PATH in generating list of commands for "help -a"
shell should call the new setup_path() to setup $PATH
Shawn O. Pearce (3):
Change 'Deltifying objects' to 'Compressing objects'
Teach prune-packed to use the standard progress meter
Stop displaying "Pack pack-$ID created." during git-gc
Steffen Prohaska (3):
mergetool: use path to mergetool in config var
mergetool.<tool>.path
mergetool: add support for ECMerge
mergetool: avoid misleading message "Resetting to default..."
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-11-04 4:14 UTC (permalink / raw)
To: git
In-Reply-To: <7vmytycykt.fsf@gitster.siamese.dyndns.org>
(Note. I haven't dealt with the patch queue from today yet)
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* cp/p4 (Thu Nov 1 20:43:14 2007 -0700) 2 commits
+ git-p4: Detect changes to executable bit and include them in p4
submit.
+ git-p4: Add a helper function to parse the full git diff-tree
output.
I would like to get success stories from p4 users before pushing
this out.
* rr/cvsexportcommit-w (Wed Oct 31 23:12:20 2007 +0100) 1 commit
+ cvsexportcommit: Add switch to specify CVS workdir
I would like to get success stories from CVS users before
pushing this out.
* db/remote-builtin (Mon Oct 29 22:03:42 2007 -0400) 4 commits
+ Use built-in send-pack.
+ Build-in send-pack, with an API for other programs to call.
+ Build-in peek-remote, using transport infrastructure.
+ Miscellaneous const changes and utilities
Looked Ok. Hopefully will be in 'master' shortly.
* np/fetch (Sat Nov 3 01:32:48 2007 -0400) 1 commit
+ git-fetch: more terse fetch output
Will merge to 'master'.
* jn/gitweb (Sat Nov 3 00:41:20 2007 +0100) 9 commits
+ gitweb: Use config file for repository description and URLs
+ gitweb: Read repo config using 'git config -z -l'
+ gitweb: Add tests for overriding gitweb config with repo config
+ gitweb: Use href(-replay=>1, action=>...) to generate alternate
views
+ gitweb: Use href(-replay=>1, page=>...) to generate pagination
links
+ gitweb: Easier adding/changing parameters to current URL
+ gitweb: Remove CGI::Carp::set_programname() call from t9500 gitweb
test
+ gitweb: Add 'status_str' to parse_difftree_raw_line output
+ gitweb: Always set 'from_file' and 'to_file' in
parse_difftree_raw_line
Will push these out to 'master' over the weekend.
* jc/format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
+ test format-patch -s: make sure MIME content type is shown as
needed
+ format-patch -s: add MIME encoding header if signer's name
requires so
This hopefully fixes a real issue we had at vger recently.
http://article.gmane.org/gmane.comp.version-control.git/62689
Will merge to 'master' shortly, and then cherry-pick to 'maint'.
* np/pack (Thu Nov 1 23:43:24 2007 -0400) 2 commits
+ pack-objects: get rid of an ugly cast
+ make the pack index version configurable
Will merge to 'master'.
* ss/mailsplit (Thu Nov 1 23:57:45 2007 +0100) 1 commit
+ Make mailsplit and mailinfo strip whitespace from the start of the
input
Will merge to 'master'.
* lt/rev-list-replay (Fri Nov 2 13:35:17 2007 -0700) 2 commits
- Support "history replay" for git log commands
- Simplify topo-sort logic
Need to drop the second one and replace it with today's "Final
output" patch. The first one should be mergeable to 'master'
immediately and independently.
* dz/color-addi (Mon Oct 22 16:08:01 2007 -0500) 2 commits
- Let git-add--interactive read colors from .gitconfig
- Added basic color support to git add --interactive
Further comments on minor issues sent back to the author.
* jc/revert-merge (Fri Nov 2 17:25:24 2007 -0700) 2 commits
+ cherry-pick/revert -m: add tests
+ revert/cherry-pick: work on merge commits as well
Will merge to 'master'.
* jc/stash-create (Thu Nov 1 14:30:30 2007 -0700) 4 commits
+ git-merge: no reason to use cpio anymore
+ Revert "rebase: allow starting from a dirty tree."
+ rebase: allow starting from a dirty tree.
+ stash: implement "stash create"
Dropped the unconditional auto-stash-unstash, but "stash create"
turns out to be a useful alternative to cpio in the git-merge
implementation.
* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits
+ core.whitespace: add test for diff whitespace error highlighting
+ git-diff: complain about >=8 consecutive spaces in initial indent
+ War on whitespace: first, a bit of retreat.
I actually like the idea of tying this to gitattributes by J
Bruce Fields. We would want to have such an update before
pushing this out to 'master'. "diff" alone would not do any
harm but "apply" can reject and/or munge the user input, and we
really would want to get the semantics right with the first
version that appears on 'master'.
* kh/commit (Fri Nov 2 11:33:09 2007 -0400) 3 commits
- Implement git commit and status as a builtin commands.
- Export launch_editor() and make it accept ':' as a no-op editor.
- Add testcase for ammending and fixing author in git commit.
There may be still some glitches left, but it is hopefully
gettng into a "testable without breaking things too much" shape
(which is the definition of 'next').
* ph/parseopt-sh (Fri Nov 2 23:39:52 2007 +0100) 5 commits
- Migrate git-am.sh to use git-rev-parse --parseopt
- Migrate git-clone to use git-rev-parse --parseopt
- Migrate git-clean.sh to use git-rev-parse --parseopt.
- Update git-sh-setup(1) to allow transparent use of git-rev-parse -
-parseopt
- Add a parseopt mode to git-rev-parse to bring parse-options to
shell scripts.
Together with today's batch which is missing from the above
list, hopefully merge to 'next' over the weekend.
* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
- Make git-svn rebase --dirty pass along --dirty to git-rebase.
- Implement --dirty for git-rebase--interactive.
- Introduce --dirty option to git-rebase, allowing you to start from
a dirty state.
This needs tests to primarily make sure that it does not regress
non --dirty case.
* sp/push-refspec (Sun Oct 28 18:46:20 2007 +0100) 6 commits
- push: teach push to pass --verbose option to transport layer
- push: teach push to accept --verbose option
- push: use same rules as git-rev-parse to resolve refspecs
- add ref_abbrev_matches_full_with_rev_parse_rules() comparing
abbrev with full ref name
- rename ref_matches_abbrev() to
ref_abbrev_matches_full_with_fetch_rules()
- push: support pushing HEAD to real branch name
Will need to review first.
* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
+ Teach "git reflog" a subcommand to delete single entries
* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
- merge-nu: a new merge backend without using unpack_trees()
- read_tree: take an explicit index structure
- gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix
* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
- pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
- ls-tree.c: refactor show_recursive() and rename it.
- tree-diff.c: split out a function to match a single pattern.
* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
- handle renames using similarity engine
- introduce generic similarity library
- change hash table calling conventions
Unchanged.
^ permalink raw reply
* Re: Why is --pretty=format: so slow?
From: Junio C Hamano @ 2007-11-04 4:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Johannes Schindelin
In-Reply-To: <18221.16318.785162.44769@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Strace seems to indicate that git log is doing at least one sequence
> of open, fstat64, fcntl64, getdents64 and close for each line of
> output in the --pretty=format: cases, but not in the other cases.
I bet that is coming from doing find_unique_abbrev() to fill
fields %h, %t and %p, even when the output format does not ask
for any of them.
Dscho, can we stop calling find_unique_abbrev() unconditionally
before being asked?
^ permalink raw reply
* [PATCH] fix display overlap between remote and local progress
From: Nicolas Pitre @ 2007-11-04 4:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
It is possible for the remote summary line to be displayed over the
local progress display line, and therefore that local progress gets
bumped to the next line. However, if the progress line is long enough,
it might not be entirely overwritten by the remote summary line. This
creates a messed up display such as:
remote: Total 310 (delta 160), reused 178 (delta 112)iB/s
Receiving objects: 100% (310/310), 379.98 KiB | 136 KiB/s, done.
So we have to clear the screen line before displaying the remote message
to make sure the local progress is not visible anymore on the first
line.
Yet some Git versions on the remote side might be sending updates to the
same line and terminate it with \r, and a separate packet with a single
\n might be sent later when the progress display is done. This means
the screen line must *not* be cleared in that case.
Since the sideband code already has to figure out line breaks in the
received packet to properly prepend the "remote:" prefix, we can easily
determine if the remote line about to be displayed is empty. Only when
it is not then a proper suffix is inserted before the \r or \n to clear
the end of the screen line.
Also some magic constants related to the prefix length have been
replaced with a variable, making it similar to the suffix length
handling. Since gcc is smart enough to detect that the variable is
constant there is no impact on the generated code.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/sideband.c b/sideband.c
index ab8a1e9..66385ad 100644
--- a/sideband.c
+++ b/sideband.c
@@ -11,13 +11,19 @@
* stream, aka "verbose"). A message over band #3 is a signal that
* the remote died unexpectedly. A flush() concludes the stream.
*/
+
+#define PREFIX "remote:"
+#define SUFFIX "\e[K" /* change to " " if ANSI sequences don't work */
+
int recv_sideband(const char *me, int in_stream, int out, int err)
{
- char buf[7 + LARGE_PACKET_MAX + 1];
- strcpy(buf, "remote:");
+ unsigned pf = strlen(PREFIX);
+ unsigned sf = strlen(SUFFIX);
+ char buf[pf + LARGE_PACKET_MAX + sf + 1];
+ memcpy(buf, PREFIX, pf);
while (1) {
int band, len;
- len = packet_read_line(in_stream, buf+7, LARGE_PACKET_MAX);
+ len = packet_read_line(in_stream, buf + pf, LARGE_PACKET_MAX);
if (len == 0)
break;
if (len < 1) {
@@ -25,35 +31,52 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
safe_write(err, buf, len);
return SIDEBAND_PROTOCOL_ERROR;
}
- band = buf[7] & 0xff;
+ band = buf[pf] & 0xff;
len--;
switch (band) {
case 3:
- buf[7] = ' ';
- buf[8+len] = '\n';
- safe_write(err, buf, 8+len+1);
+ buf[pf] = ' ';
+ buf[pf+1+len] = '\n';
+ safe_write(err, buf, pf+1+len+1);
return SIDEBAND_REMOTE_ERROR;
case 2:
- buf[7] = ' ';
- len += 8;
+ buf[pf] = ' ';
+ len += pf+1;
while (1) {
- int brk = 8;
+ int brk = pf+1;
+
+ /* Break the buffer into separate lines. */
while (brk < len) {
brk++;
if (buf[brk-1] == '\n' ||
buf[brk-1] == '\r')
break;
}
- safe_write(err, buf, brk);
+
+ /*
+ * Let's insert a suffix to clear the end
+ * of the screen line, but only if current
+ * line data actually contains something.
+ */
+ if (brk > pf+1 + 1) {
+ char save[sf];
+ memcpy(save, buf + brk, sf);
+ buf[brk + sf - 1] = buf[brk - 1];
+ memcpy(buf + brk - 1, SUFFIX, sf);
+ safe_write(err, buf, brk + sf);
+ memcpy(buf + brk, save, sf);
+ } else
+ safe_write(err, buf, brk);
+
if (brk < len) {
- memmove(buf + 8, buf + brk, len - brk);
- len = len - brk + 8;
+ memmove(buf + pf+1, buf + brk, len - brk);
+ len = len - brk + pf+1;
} else
break;
}
continue;
case 1:
- safe_write(out, buf+8, len);
+ safe_write(out, buf + pf+1, len);
continue;
default:
len = sprintf(buf,
^ permalink raw reply related
* Re: [PATCH] Add missing inside_work_tree setting in setup_git_directory_gently
From: Junio C Hamano @ 2007-11-04 4:33 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Johannes Schindelin
In-Reply-To: <20071103131806.GA25109@laptop>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> When both GIT_DIR and GIT_WORK_TREE are set, and
> setup_git_directory_gently() changes the current working
> directory accordingly, it should also set inside_work_tree = 1.
>
> Without this, work_tree handling code in setup_git_directory()
> will be activated. If you stay in root work tree (no prefix),
> it does not harm. It does if you work from a subdirectory though.
Please add automated test script for this, thanks.
^ permalink raw reply
* Re: [PATCH] format-patch: Add configuration and off switch for --numbered
From: Junio C Hamano @ 2007-11-04 4:40 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <20071104033824.GA56097@Hermes.local>
The change looks good. Tests needed.
^ permalink raw reply
* Re: [PATCH] format-patch: Add configuration and off switch for --numbered
From: Brian Gernhardt @ 2007-11-04 4:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejf6vd17.fsf@gitster.siamese.dyndns.org>
On Nov 4, 2007, at 12:40 AM, Junio C Hamano wrote:
> The change looks good. Tests needed.
Thought so. Somebody's not happy. ;-)
I was going to modify the existing tests for --numbered, but
discovered that there were none. Having nothing to start with, I
didn't add.
That said, I'll try to hack something up.
~~ Brian
^ permalink raw reply
* Re: [PATCH 1/2] Added basic color support to git add --interactive
From: Jeff King @ 2007-11-04 4:57 UTC (permalink / raw)
To: Dan Zwell
Cc: Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071102224100.71665182@paradox.zwell.net>
On Fri, Nov 02, 2007 at 10:41:00PM -0500, Dan Zwell wrote:
> +sub print_colored {
> + my $color = shift;
> + my $string = join("", @_);
> +
> + if ($use_color) {
> + # Put a color code at the beginning of each line, a reset at the end
> + # color after newlines that are not at the end of the string
> + $string =~ s/(\n+)(.)/$1$color$2/g;
> + # reset before newlines
> + $string =~ s/(\n+)/$normal_color$1/g;
> + # codes at beginning and end (if necessary):
> + $string =~ s/^/$color/;
> + $string =~ s/$/$normal_color/ unless $string =~ /\n$/;
> + }
> + print $string;
> +}
This would probably be a bit more readable by marking the regex as
multline using /m. Something like:
$string =~ s/^/$color/mg;
$string =~ s/.$/$&$normal_color/mg;
which covers both the "start/end of line" and "start/end" of string
cases.
Also, if there is to be pager support for showing diffs, perhaps
print_colored needs to take a filehandle argument (or, even simpler,
change "print_colored(...)" to "print color(...), so the caller can use
print as usual).
-Peff
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: Jeff King @ 2007-11-04 4:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <alpine.LFD.0.9999.0711030101340.21255@xanadu.home>
On Sat, Nov 03, 2007 at 01:32:48AM -0400, Nicolas Pitre wrote:
> This makes the fetch output much more terse and prettier on a 80 column
> display, based on a consensus reached on the mailing list. Here's an
> example output:
Thank you for this; it was at the end of a very long todo list for me.
> Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.
> Resolving deltas: 100% (4604/4604), done.
> From git://git.kernel.org/pub/scm/git/git
> ! [rejected] html -> origin/html (non fast forward)
> 136e631..f45e867 maint -> origin/maint (fast forward)
> 9850e2e..44dd7e0 man -> origin/man (fast forward)
> 3e4bb08..e3d6d56 master -> origin/master (fast forward)
> fa3665c..536f64a next -> origin/next (fast forward)
> + 4f6d9d6...768326f pu -> origin/pu (forced update)
> * [new branch] todo -> origin/todo
One nice thing about this format is that it works equally well for
"push" (changing "From" to "To" and reversing the order of the
branches). Comments?
-Peff
^ permalink raw reply
* Re: [PATCH] Allow 'git blame rev path' to work on bare repository
From: Junio C Hamano @ 2007-11-04 5:21 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <1194092575-7133-2-git-send-email-mh@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> While 'git blame rev -- path' works, 'git blame rev path' didn't.
>
> Signed-off-by: Mike Hommey <mh@glandium.org>
> ---
> builtin-blame.c | 4 ----
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/builtin-blame.c b/builtin-blame.c
> index aedc294..141287e 100644
> --- a/builtin-blame.c
> +++ b/builtin-blame.c
> @@ -2294,10 +2294,6 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
> }
> else if (i != argc - 1)
> usage(blame_usage); /* garbage at end */
> -
> - if (!has_path_in_work_tree(path))
> - die("cannot stat path %s: %s",
> - path, strerror(errno));
> }
> }
>
Sorry but a NAK; at least limit the removal of the test only to a bare
repository case.
^ permalink raw reply
* Re: [RFC PATCH] Make gitk use --early-output
From: Linus Torvalds @ 2007-11-04 5:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18221.2285.259487.655684@cargo.ozlabs.ibm.com>
On Sun, 4 Nov 2007, Paul Mackerras wrote:
>
> This makes gitk use the --early-output flag on the git log command.
>
> When gitk sees the "Final output:" line from git log, it goes into a
> mode where it basically just checks that it is getting the commits
> again in the same order as before. If they are, well and good; if
> not, it truncates its internal list at the point of difference and
> proceeds to read in the commits in the new order from there on, and
> re-does the graph layout if necessary.
>
> This gives a much more immediate feel to the startup; gitk shows its
> window with the first screenful of commits displayed very quickly this
> way.
Goodie. Seems to work for me. I'll tweak the behaviour of --early-output a
bit more, because right now if things are really cold in the cache, the
"--early-output" logic will often trigger with just a single commit in the
list (because the timeout is so short), but it already seems to work
pretty well.
Linus
^ permalink raw reply
* Re: [PATCH 1/2] Added basic color support to git add --interactive
From: Junio C Hamano @ 2007-11-04 5:36 UTC (permalink / raw)
To: Jeff King
Cc: Dan Zwell, Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071104045735.GA12359@segfault.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 02, 2007 at 10:41:00PM -0500, Dan Zwell wrote:
>
>> +sub print_colored {
>> + my $color = shift;
>> + my $string = join("", @_);
>> +
>> + if ($use_color) {
>> + # Put a color code at the beginning of each line, a reset at the end
>> + # color after newlines that are not at the end of the string
>> + $string =~ s/(\n+)(.)/$1$color$2/g;
>> + # reset before newlines
>> + $string =~ s/(\n+)/$normal_color$1/g;
>> + # codes at beginning and end (if necessary):
>> + $string =~ s/^/$color/;
>> + $string =~ s/$/$normal_color/ unless $string =~ /\n$/;
>> + }
>> + print $string;
>> +}
>
> This would probably be a bit more readable by marking the regex as
> multline using /m. Something like:
>
> $string =~ s/^/$color/mg;
> $string =~ s/.$/$&$normal_color/mg;
>
> which covers both the "start/end of line" and "start/end" of string
> cases.
I think you would end up spitting out:
COLOR something RESET LF COLOR RESET LF
instead of:
COLOR something RESET LF LF
when you get "something\n\n" if you did that. Not a big deal,
though, as at this point we would be human I/O bound.
> Also, if there is to be pager support for showing diffs, perhaps
> print_colored needs to take a filehandle argument (or, even simpler,
> change "print_colored(...)" to "print color(...), so the caller can use
> print as usual).
Making it take a FH would be useful. With that, my
proof-of-concept patch to add print_diff_hunk would become:
sub print_diff_hunk {
my ($text) = @_;
my $pager;
if ($use_pager) {
open($pager, "| less");
} else {
$pager = \*STDOUT;
}
for (@$text) {
print_colored $pager $color ...
}
close($pager);
}
^ permalink raw reply
* Re: [REPLACEMENT PATCH 2/2] Add "--early-output" log flag for interactive GUI use
From: Linus Torvalds @ 2007-11-04 5:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Marco Costalba, Junio C Hamano, Git Mailing List
In-Reply-To: <18221.14113.498416.396006@cargo.ozlabs.ibm.com>
On Sun, 4 Nov 2007, Paul Mackerras wrote:
>
> Linus Torvalds writes:
>
> > When the full list is generated, there will be a "Final output:" string
> > prepended to it, regardless of whether any early commits were shown or
> > not, so that the consumer can always know the difference between early
> > output and the final list.
>
> How hard would it be to put the total number of commits on that "Final
> output" line? That would be useful for me.
Not hard. I think we basically have it anyway. The reason I didn't do it
is that there's actually multiple numbers: there's the number of primary
("interesting") commits, and then there are the "others", ie the edge
things etc. So the number I'd pick would be the number of actual
interesting commits, no edges, no nothing. Or what?
One other thing I was thinking of was also to perhaps allow multiple
partial early-output things, in case we get just 5 commits in the first
0.1 seconds, then 50 in the first second, and 200 after 2 seconds.. I can
well imagine getting the full list taking a long time over a network
filesystem (somebody mentioned samba), and maybe having just a single
trigger is too inflexible.
Linus
^ permalink raw reply
* Re: [PATCH 1/2] Added basic color support to git add --interactive
From: Jeff King @ 2007-11-04 5:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dan Zwell, Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <7v640ivagv.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 03, 2007 at 10:36:00PM -0700, Junio C Hamano wrote:
> I think you would end up spitting out:
>
> COLOR something RESET LF COLOR RESET LF
>
> instead of:
>
> COLOR something RESET LF LF
>
> when you get "something\n\n" if you did that. Not a big deal,
> though, as at this point we would be human I/O bound.
Yes, though I wonder if the former is "more correct" in the sense that
we don't know what the attributes are doing, and maybe it matters for
them to apply to each line, whether it has text or not.
But I don't think it's possible for a blank line to actually do anything
with the attributes we're currently allowing, and we don't have any
plans to allow arbitrary terminal control codes in the color specs, so
it probably doesn't matter.
-Peff
^ 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