* Re: What's in git.git
From: Alexandre Julliard @ 2006-03-05 10:47 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <46a038f90603050215v7afcbd4crc145e85a4da416a7@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> So I should use a combination of both? Hmmm. Worth exploring, can you
> give us a quick guide on getting started with it? (Or where should I
> read? I'm not that good with emacs)...
To get started with the VC backend, make sure vc-git.el is somewhere
on your emacs load-path, and add GIT to the vc-handled-backends
variable; the easiest is with customize, something like
`M-x customize-variable [RET] vc-handled-backends'.
Once you have done that, when you open a file that's under git
control, the vc-git mode should automatically be turned on, and you
should see a "GIT" indicator in the modeline. Then you can use the
standard VC backend commands (the ones that start with the C-x v
prefix). The Emacs VC mode is documented at:
http://www.gnu.org/software/emacs/manual/html_node/Version-Control.html
For the git-status mode, simply do a `M-x load-file [RET] git.el', and
then `M-x git-status'. This will prompt you for the directory to view,
and display a list of modified files. From there you can mark files
and perform actions on group of files, like diff, commit, revert, etc.
There isn't a lot of documentation at this point, but a `C-h m' will
show you the list of key bindings, so you can try them all and see
what happens ;-)
> Oh. Ah. Ok! I'll have to try this! So far, I've had good luck
> following this guide:
>
> http://wiki.gnuarch.org/Process_20_2a_2erej_20files
>
> which is targetted pretty much at dumb emacs users. Like me ;-)
smerge mode is a very simple mode to edit files that contain conflict
markers, in my experience it works pretty well. The nice thing is that
it works directly from the file buffer, so you don't need to jump back
and forth between file and diff.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* [PATCH] git-blame: Kill warning "print_map defined but not used"
From: Fredrik Kuivinen @ 2006-03-05 11:16 UTC (permalink / raw)
To: git; +Cc: junkio
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
blame.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
aebef8969d11b04634b9ab7a6ae85a0844b2e4c7
diff --git a/blame.c b/blame.c
index 6dccae5..0fb30ee 100644
--- a/blame.c
+++ b/blame.c
@@ -235,6 +235,7 @@ static void print_patch(struct patch *p)
}
/* For debugging only */
+#if DEBUG
static void print_map(struct commit *cmit, struct commit *other)
{
struct util_info *util = cmit->object.util;
@@ -267,6 +268,7 @@ static void print_map(struct commit *cmi
printf("\n");
}
}
+#endif
// p is a patch from commit to other.
static void fill_line_map(struct commit *commit, struct commit *other,
--
1.2.4.g4644-dirty
^ permalink raw reply related
* [PATCH] avoid asciidoc warning in git-cvsserver.txt
From: Francis Daly @ 2006-03-05 11:41 UTC (permalink / raw)
To: git
Manually renumber to keep asciidoc happy
---
Documentation/git-cvsserver.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
9809de6594b8e11261ca5f18bb2eadb913fb33ae
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 19c9c51..0c4948d 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -44,13 +44,13 @@ INSTALLATION
n.b. you need to ensure each user that is going to invoke server.pl has
write access to the log file.
-5. On each client machine you need to set the following variables.
+3. On each client machine you need to set the following variables.
CVSROOT should be set as per normal, but the directory should point at the
appropriate git repo.
CVS_SERVER should be set to the server.pl script that has been put on the
remote machine.
-6. Clients should now be able to check out modules (where modules are the names
+4. Clients should now be able to check out modules (where modules are the names
of branches in git).
$ cvs co -d mylocaldir master
--
1.2.GIT
--
Francis Daly francis@daoine.org
^ permalink raw reply related
* Re: [PATCH] git-blame: Make the output human readable
From: Junio C Hamano @ 2006-03-05 12:10 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, Johannes Schindelin, Ryan Anderson
In-Reply-To: <20060305110351.GA23448@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> The default output mode is slightly different from git-annotate's.
> However, git-annotate's output mode can be obtained by using the
> '-c' flag.
It might be better to default to human readable and make the
script consumption format an option, if only to reduce typing.
> diff --git a/Makefile b/Makefile
> index b6d8804..eb1887d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -534,6 +534,10 @@ git-rev-list$X: rev-list.o $(LIB_FILE)
> $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> $(LIBS) $(OPENSSL_LIBSSL)
>
> +git-blame$X: blame.o $(LIB_FILE)
> + $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> + $(LIBS) -lm
> +
I wonder what it is about to link this binary different from others...
> +char* format_time(unsigned long time, const char* tz)
> +{
> + static char time_buf[128];
> + time_t t = time;
> +
> + strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S ", gmtime(&t));
> + strcat(time_buf, tz);
> + return time_buf;
> +}
I think this shows GMT with time offset, which is compatible
with the human readable time Johannes did to git-annotate. I do
not know what timezone CVS annotate shows its dates offhand (it
seems to only show dates). Johannes, is this an attempt to
match what CVS does?
I am wondering if we want to be in line with the date formatting
convention used for our commits and tags, that is, to show local
timestamp with timezone. The code to use would be show_date()
from date.c if we go that route.
^ permalink raw reply
* Re: [PATCH] avoid asciidoc warning in git-cvsserver.txt
From: Francis Daly @ 2006-03-05 12:11 UTC (permalink / raw)
To: git
Oops, I missed
Subject: [PATCH] cvsserver: updated documentation
which makes this one redundant.
Sorry,
f
--
Francis Daly francis@daoine.org
^ permalink raw reply
* [PATCH] gitignore: Ignore some more boring things.
From: Mark Wooding @ 2006-03-05 12:25 UTC (permalink / raw)
To: git
From: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
.gitignore | 1 +
t/.gitignore | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 5be239a..abbc509 100644
--- a/.gitignore
+++ b/.gitignore
@@ -130,3 +130,4 @@ libgit.a
*.o
*.py[co]
config.mak
+git-blame
diff --git a/t/.gitignore b/t/.gitignore
new file mode 100644
index 0000000..fad67c0
--- /dev/null
+++ b/t/.gitignore
@@ -0,0 +1 @@
+trash
^ permalink raw reply related
* Re: [PATCH] git-blame: Make the output human readable
From: Fredrik Kuivinen @ 2006-03-05 12:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git, Johannes Schindelin, Ryan Anderson
In-Reply-To: <7vbqwlgkhk.fsf@assigned-by-dhcp.cox.net>
On Sun, Mar 05, 2006 at 04:10:47AM -0800, Junio C Hamano wrote:
> Fredrik Kuivinen <freku045@student.liu.se> writes:
>
> > The default output mode is slightly different from git-annotate's.
> > However, git-annotate's output mode can be obtained by using the
> > '-c' flag.
>
> It might be better to default to human readable and make the
> script consumption format an option, if only to reduce typing.
>
The default output format is human readable, but it is different from
the output format used by git-annotate. By default, (when the patch is
applied) git-blame outputs lines with on the following form:
<eight first digits of commit SHA1> (<first 15 letters of committer's name> YYYY-MM-DD HH:MM:SS TZ <line number, right justified>) file contents
where as git-annotate uses
<eight first digits of commit SHA1>\t(<committer's name, right justified, padded to 10 characters> YYYY-MM-DD HH:MM:SS TZ\t<line number>)file contents
I find the first format easier to read since everything is aligned (we
always output 15 characters for the committer's name padded with
spaces if necessary and the line numbers are padded appropriately). It
also takes up less space on screen since it doesn't use tabs.
However, I wanted to use the tests for git-annotate to test git-blame
too and the tests do, of course, expect the output to be in
git-annotate's format. Hence, the '-c' switch.
We may want to add an output format suitable for scripts too, which
just lists the SHA1. But I don't think it is much more difficult to
parse the format above, at least not if you just want the SHA1s.
> > diff --git a/Makefile b/Makefile
> > index b6d8804..eb1887d 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -534,6 +534,10 @@ git-rev-list$X: rev-list.o $(LIB_FILE)
> > $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> > $(LIBS) $(OPENSSL_LIBSSL)
> >
> > +git-blame$X: blame.o $(LIB_FILE)
> > + $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> > + $(LIBS) -lm
> > +
>
> I wonder what it is about to link this binary different from others...
>
It uses log(3) to compute the number of digits needed to represent the
last line number. It is probably better to this some other way
though...
> > +char* format_time(unsigned long time, const char* tz)
> > +{
> > + static char time_buf[128];
> > + time_t t = time;
> > +
> > + strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S ", gmtime(&t));
> > + strcat(time_buf, tz);
> > + return time_buf;
> > +}
>
> I think this shows GMT with time offset, which is compatible
> with the human readable time Johannes did to git-annotate. I do
> not know what timezone CVS annotate shows its dates offhand (it
> seems to only show dates). Johannes, is this an attempt to
> match what CVS does?
>
> I am wondering if we want to be in line with the date formatting
> convention used for our commits and tags, that is, to show local
> timestamp with timezone. The code to use would be show_date()
> from date.c if we go that route.
>
I think it is a good idea. Consistency is good.
- Fredrik
^ permalink raw reply
* Re: [PATCH] git-blame: Make the output human readable
From: Johannes Schindelin @ 2006-03-05 14:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git, Ryan Anderson
In-Reply-To: <7vbqwlgkhk.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 5 Mar 2006, Junio C Hamano wrote:
> Fredrik Kuivinen <freku045@student.liu.se> writes:
>
> > +char* format_time(unsigned long time, const char* tz)
> > +{
> > + static char time_buf[128];
> > + time_t t = time;
> > +
> > + strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S ", gmtime(&t));
> > + strcat(time_buf, tz);
> > + return time_buf;
> > +}
>
> I think this shows GMT with time offset, which is compatible
> with the human readable time Johannes did to git-annotate. I do
> not know what timezone CVS annotate shows its dates offhand (it
> seems to only show dates). Johannes, is this an attempt to
> match what CVS does?
CVS only shows the date, something like
strftime("%Y-%b-%d", gmtime($timestamp));
> I am wondering if we want to be in line with the date formatting
> convention used for our commits and tags, that is, to show local
> timestamp with timezone. The code to use would be show_date()
> from date.c if we go that route.
I like that approach. Sometimes imitating CVS can be overdone.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-blame: Make the output human readable
From: Johannes Schindelin @ 2006-03-05 14:23 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Junio C Hamano, git
In-Reply-To: <20060305123800.GD23448@c165.ib.student.liu.se>
Hi,
On Sun, 5 Mar 2006, Fredrik Kuivinen wrote:
> On Sun, Mar 05, 2006 at 04:10:47AM -0800, Junio C Hamano wrote:
> > Fredrik Kuivinen <freku045@student.liu.se> writes:
> >
> > > +git-blame$X: blame.o $(LIB_FILE)
> > > + $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> > > + $(LIBS) -lm
> > > +
> >
> > I wonder what it is about to link this binary different from others...
> >
>
> It uses log(3) to compute the number of digits needed to represent the
> last line number. It is probably better to this some other way
> though...
How about this:
- max_digits = 1 + log(num_blame_lines+1)/log(10);
+ for (i = 10, max_digits = 1; i <= num_blame_lines + 1;
+ i *= 10, max_digits++);
(Totally untested)
Hth,
Dscho
^ permalink raw reply
* [PATCH] contrib/emacs/Makefile: Provide tool for byte-compiling files.
From: Mark Wooding @ 2006-03-05 16:14 UTC (permalink / raw)
To: git
From: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
contrib/emacs/.gitignore | 1 +
contrib/emacs/Makefile | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/.gitignore b/contrib/emacs/.gitignore
new file mode 100644
index 0000000..c531d98
--- /dev/null
+++ b/contrib/emacs/.gitignore
@@ -0,0 +1 @@
+*.elc
diff --git a/contrib/emacs/Makefile b/contrib/emacs/Makefile
new file mode 100644
index 0000000..d3619db
--- /dev/null
+++ b/contrib/emacs/Makefile
@@ -0,0 +1,20 @@
+## Build and install stuff
+
+EMACS = emacs
+
+ELC = git.elc vc-git.elc
+INSTALL = install
+INSTALL_ELC = $(INSTALL) -m 644
+prefix = $(HOME)
+emacsdir = $(prefix)/share/emacs/site-lisp
+
+all: $(ELC)
+
+install: all
+ $(INSTALL) -d $(emacsdir)
+ $(INSTALL_ELC) $(ELC) $(emacsdir)
+
+%.elc: %.el
+ $(EMACS) --batch --eval '(byte-compile-file "$<")'
+
+clean:; rm -f $(ELC)
^ permalink raw reply related
* [PATCH] gitk: Fix size saving for diff and file list panes
From: Sergey Vlasov @ 2006-03-05 17:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
The splitter between diff and file list panes was moving to the left
after every restart of gitk.
---
This patch applies both to the stable and new gitk versions.
gitk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
1e43530dc79f176507e5ad2fd57f4c9ba6cea46a
diff --git a/gitk b/gitk
index f4c6624..a5331f1 100755
--- a/gitk
+++ b/gitk
@@ -676,10 +676,10 @@ proc savestuff {w} {
puts $f "set geometry(canv2) [expr {[winfo width $canv2]-2}]"
puts $f "set geometry(canv3) [expr {[winfo width $canv3]-2}]"
puts $f "set geometry(canvh) [expr {[winfo height $canv]-2}]"
- set wid [expr {([winfo width $ctext] - 8) \
+ set wid [expr {([winfo width $ctext]) \
/ [font measure $textfont "0"]}]
puts $f "set geometry(ctextw) $wid"
- set wid [expr {([winfo width $cflist] - 11) \
+ set wid [expr {([winfo width $cflist]) \
/ [font measure [$cflist cget -font] "0"]}]
puts $f "set geometry(cflistw) $wid"
close $f
--
1.2.GIT
^ permalink raw reply related
* Re: What's in git.git
From: Linus Torvalds @ 2006-03-05 17:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfylxigxc.fsf@assigned-by-dhcp.cox.net>
On Sat, 4 Mar 2006, Junio C Hamano wrote:
>
> At this point commit is revs->commits->item. It cannot be
> UNINTERESTING because you make it sure with !revs->limited and
> friends, but I wonder if it can be SHOWN already for some
> reason, in which case returning it is wrong.
>
> Unlike the earlier special case in rev-list, this special case
> kicks in for the last iteration of repeated calls to
> get_revision() (e.g. third iteration of "rev-list -3")...
Good point. Yes, it needs to check that it's not SHOWN. Might as well
check against interesting too. Maybe something like this instead?
Linus
---
diff --git a/revision.c b/revision.c
index a3df810..2a33637 100644
--- a/revision.c
+++ b/revision.c
@@ -684,13 +684,11 @@ static void rewrite_parents(struct commi
struct commit *get_revision(struct rev_info *revs)
{
struct commit_list *list = revs->commits;
- struct commit *commit;
if (!list)
return NULL;
/* Check the max_count ... */
- commit = list->item;
switch (revs->max_count) {
case -1:
break;
@@ -701,22 +699,28 @@ struct commit *get_revision(struct rev_i
}
do {
- commit = pop_most_recent_commit(&revs->commits, SEEN);
+ struct commit *commit = revs->commits->item;
+
if (commit->object.flags & (UNINTERESTING|SHOWN))
- continue;
+ goto next;
if (revs->min_age != -1 && (commit->date > revs->min_age))
- continue;
+ goto next;
if (revs->max_age != -1 && (commit->date < revs->max_age))
return NULL;
if (revs->no_merges && commit->parents && commit->parents->next)
- continue;
+ goto next;
if (revs->paths && revs->dense) {
if (!(commit->object.flags & TREECHANGE))
- continue;
+ goto next;
rewrite_parents(commit);
}
+ /* More to go? */
+ if (revs->max_count)
+ pop_most_recent_commit(&revs->commits, SEEN);
commit->object.flags |= SHOWN;
return commit;
+next:
+ pop_most_recent_commit(&revs->commits, SEEN);
} while (revs->commits);
return NULL;
}
^ permalink raw reply related
* Re: What's in git.git
From: Linus Torvalds @ 2006-03-05 18:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603050946280.13139@g5.osdl.org>
On Sun, 5 Mar 2006, Linus Torvalds wrote:
>
> Good point. Yes, it needs to check that it's not SHOWN. Might as well
> check against interesting too. Maybe something like this instead?
Actually, thinking more about it, I think we could get rid of SHOWN.
We only ever insert a commit _once_ onto the list, using the SEEN logic,
so we can never pull the same commit off the list more than once. I think
SHOWN was for merge-order.
But I might be wrong. I was thinking about SHOWN a bit when I did the
re-organization, but didn't dare to actually touch it, so I left it alone.
Linus
^ permalink raw reply
* Re: [PATCH] git-blame: Kill warning "print_map defined but not used"
From: Linus Torvalds @ 2006-03-05 18:58 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, junkio
In-Reply-To: <20060305111650.GC23448@c165.ib.student.liu.se>
Fredrik,
Three comments on "git-blame":
- you should use "-u -U 0" instead of "-u0" to avoid warnings from some
versions of GNU diff
- Please default to HEAD so that you don't need to say it.
- What I'd actually want to see is blame for a certain group of lines.
Ie, I'd like to see
git-blame --line=50-56 filename
which only shows those 7 lines. That would be wonderful for a visual
interface where you could mark off a few lines and say "follow these
backwards" kind of thing, and should make it more efficient than trying
to resolve the _whole_ file.
Hmm?
Linus
^ permalink raw reply
* Re: [PATCH] avoid asciidoc warning in git-cvsserver.txt
From: Martin Langhoff @ 2006-03-05 19:22 UTC (permalink / raw)
To: Francis Daly; +Cc: git
In-Reply-To: <20060305121131.GA20503@craic.sysops.org>
On 3/6/06, Francis Daly <francis@daoine.org> wrote:
> Oops, I missed
>
> Subject: [PATCH] cvsserver: updated documentation
>
> which makes this one redundant.
Thanks anyway to you and Mark for the fixes. Seems we were all working
at the same time on the file!
cheers,
martin
^ permalink raw reply
* Re: [PATCH] contrib/emacs/Makefile: Provide tool for byte-compiling files.
From: Junio C Hamano @ 2006-03-05 19:28 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git, Mark Wooding
In-Reply-To: <20060305161431.23622.20032.stgit@metalzone.distorted.org.uk>
Alexandre, this looks good to me, so I'll be applying it.
-jc
Mark Wooding <mdw@distorted.org.uk> writes:
> From: Mark Wooding <mdw@distorted.org.uk>
>
> Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
> ---
>
> contrib/emacs/.gitignore | 1 +
> contrib/emacs/Makefile | 20 ++++++++++++++++++++
> 2 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/contrib/emacs/.gitignore b/contrib/emacs/.gitignore
> new file mode 100644
> index 0000000..c531d98
> --- /dev/null
> +++ b/contrib/emacs/.gitignore
> @@ -0,0 +1 @@
> +*.elc
> diff --git a/contrib/emacs/Makefile b/contrib/emacs/Makefile
> new file mode 100644
> index 0000000..d3619db
> --- /dev/null
> +++ b/contrib/emacs/Makefile
> @@ -0,0 +1,20 @@
> +## Build and install stuff
> +
> +EMACS = emacs
> +
> +ELC = git.elc vc-git.elc
> +INSTALL = install
> +INSTALL_ELC = $(INSTALL) -m 644
> +prefix = $(HOME)
> +emacsdir = $(prefix)/share/emacs/site-lisp
> +
> +all: $(ELC)
> +
> +install: all
> + $(INSTALL) -d $(emacsdir)
> + $(INSTALL_ELC) $(ELC) $(emacsdir)
> +
> +%.elc: %.el
> + $(EMACS) --batch --eval '(byte-compile-file "$<")'
> +
> +clean:; rm -f $(ELC)
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-03-05 19:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603051027400.13139@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Actually, thinking more about it, I think we could get rid of SHOWN.
>
> We only ever insert a commit _once_ onto the list, using the SEEN logic,
> so we can never pull the same commit off the list more than once. I think
> SHOWN was for merge-order.
>
> But I might be wrong. I was thinking about SHOWN a bit when I did the
> re-organization, but didn't dare to actually touch it, so I left it alone.
I abused SHOWN when I did --objects-edge with
mark_edge_parents_uninteresting modification in
eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4, but probably it can be
modified to use SEEN.
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-03-05 19:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603051027400.13139@g5.osdl.org>
I was going through 'whatchanged rev-list.c' but was half-way
when I sent the previous message. -S'UNINTERESTING|SHOWN' found
this one.
51b1e1713b1ed8e962e994cd0850ea439ad8c3de
Author: Jon Seymour <jon.seymour@gmail.com>
Date: Mon Jun 20 12:29:38 2005 +1000
[PATCH] Prevent git-rev-list without --merge-order producing
dupicates in output
If b is reachable from a, then:
git-rev-list a b
argument would print one of the commits twice.
This patch fixes that problem. A previous problem fixed it
for the --merge-order switch.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-03-05 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtf8fzvb.fsf@assigned-by-dhcp.cox.net>
On Sun, 5 Mar 2006, Junio C Hamano wrote:
>
> I abused SHOWN when I did --objects-edge with
> mark_edge_parents_uninteresting modification in
> eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4, but probably it can be
> modified to use SEEN.
Ahh, no. SEEN is different from SHOWN. SHOWN means that we've actually
shown that commit, while SEEN just means that we've added it to the list
(but it might be uninteresting, for example). I think you did exactly the
right thing wrt SHOWN.
That said, the revision list walker should never see a SHOWN commit on the
list, because it is the thing that sets SHOWN as it removes the entry from
the list (and it should never get re-added, due to SEEN).
Linus
^ permalink raw reply
* [PATCH] documentation: add 'see also' sections to git-rm and git-add
From: Jeff Muizelaar @ 2006-03-05 21:18 UTC (permalink / raw)
To: git
Pair up git-add and git-rm by adding a 'see also' section that
references the opposite command to each of their documentation files.
---
Documentation/git-add.txt | 3 +++
Documentation/git-rm.txt | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
aedd49a31816736b244b9f61303e112431eff80c
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 7e29383..5b7c354 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -65,6 +65,9 @@ git-add git-*.sh::
(i.e. you are listing the files explicitly), it does not
add `subdir/git-foo.sh` to the index.
+See Also
+--------
+gitlink:git-rm[1]
Author
------
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 401bfb2..d8a5afa 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -74,6 +74,9 @@ git-rm -f git-*.sh::
shell expand the asterisk (i.e. you are listing the files
explicitly), it does not remove `subdir/git-foo.sh`.
+See Also
+--------
+gitlink:git-add[1]
Author
------
--
1.2.4.g8bc6
^ permalink raw reply related
* Re: [PATCH] git-blame: Make the output human readable
From: Junio C Hamano @ 2006-03-05 21:28 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, Johannes Schindelin, Ryan Anderson
In-Reply-To: <20060305123800.GD23448@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> I find the first format easier to read since everything is aligned (we
> always output 15 characters for the committer's name padded with
> spaces if necessary and the line numbers are padded appropriately). It
> also takes up less space on screen since it doesn't use tabs.
Careful. The convention for names is to encode them in UTF-8,
so if you mean 15 "characters" that might be OK but if it can
truncate in the middle of a multibyte sequence of UTF-8 encoded
single character it is a no-no.
We are talking about "casual" aligning, so I would not bring up
"proportional fonts", but even on a monospace terminal and
line-printer output, there still is the issue of byte count not
matching columns. In an i18nized environment, aligning columns
by counting bytes is a lost battle.
In any case, please make sure you do not chop a character in the
middle at least [*1*].
> We may want to add an output format suitable for scripts too, which
> just lists the SHA1. But I don't think it is much more difficult to
> parse the format above, at least not if you just want the SHA1s.
Fair enough.
> It uses log(3) to compute the number of digits needed to represent the
> last line number. It is probably better to this some other way
> though...
Yup.
[Footnote]
*1* I was kind of impressed that Linus was careful about this
issue when I saw the commit log chopping is only done at line
boundaries. A very careful coder would have chopped the last
line in the middle at character boundary, but if you do not want
to bother that much, chopping at line boundary is better than
chopping the last line in the middle of a character ;-).
^ permalink raw reply
* any problems with new branch of gitk?
From: Paul Mackerras @ 2006-03-05 22:09 UTC (permalink / raw)
To: git
I'm planning to pull the `new' branch of the gitk repository into the
master branch, making the new version of gitk the standard version
that will go into the git.git repository. As far as I know the new
version does everything the old version does. Does anyone know of any
problems with the new gitk that weren't in the old one?
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH] git-blame: Kill warning "print_map defined but not used"
From: Junio C Hamano @ 2006-03-05 22:45 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0603051054330.13139@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> - you should use "-u -U 0" instead of "-u0" to avoid warnings from some
> versions of GNU diff
One liner here.
> - Please default to HEAD so that you don't need to say it.
Fredrik's latest patch already does.
-- >8 --
Subject: [PATCH] blame: avoid "diff -u0".
As Linus suggests, use "diff -u -U 0" instead.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
blame.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
1f7d9585190c22a4c019487444d9e461e08baa0e
diff --git a/blame.c b/blame.c
index a3a8ddc..141e4c6 100644
--- a/blame.c
+++ b/blame.c
@@ -92,7 +92,7 @@ static struct patch *get_patch(struct co
die("write failed: %s", strerror(errno));
close(fd);
- sprintf(diff_cmd, "diff -u0 %s %s", tmp_path1, tmp_path2);
+ sprintf(diff_cmd, "diff -u -U 0 %s %s", tmp_path1, tmp_path2);
fin = popen(diff_cmd, "r");
if (!fin)
die("popen failed: %s", strerror(errno));
--
1.2.4.gee5c7
^ permalink raw reply related
* [PATCH] blame: avoid -lm by not using log().
From: Junio C Hamano @ 2006-03-05 22:46 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen, Johannes Schindelin
In-Reply-To: <20060305123800.GD23448@c165.ib.student.liu.se>
... as suggested on the list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 4 ----
blame.c | 6 ++++--
2 files changed, 4 insertions(+), 6 deletions(-)
e0539773df17e5f8410850b8ffcfe8d2fa14ab7a
diff --git a/Makefile b/Makefile
index eb1887d..b6d8804 100644
--- a/Makefile
+++ b/Makefile
@@ -534,10 +534,6 @@ git-rev-list$X: rev-list.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(OPENSSL_LIBSSL)
-git-blame$X: blame.o $(LIB_FILE)
- $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
- $(LIBS) -lm
-
init-db.o: init-db.c
$(CC) -c $(ALL_CFLAGS) \
-DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"' $*.c
diff --git a/blame.c b/blame.c
index 168b1f5..59146fa 100644
--- a/blame.c
+++ b/blame.c
@@ -589,7 +589,7 @@ int main(int argc, const char **argv)
usage(blame_usage);
else if(!strcmp(argv[i], "-l") ||
!strcmp(argv[i], "--long")) {
- sha1_len = 20;
+ sha1_len = 40;
continue;
} else if(!strcmp(argv[i], "-c") ||
!strcmp(argv[i], "--compability")) {
@@ -651,7 +651,9 @@ int main(int argc, const char **argv)
process_commits(&rev, filename, &initial);
buf = blame_contents;
- max_digits = 1 + log(num_blame_lines+1)/log(10);
+ for (max_digits = 1, i = 10; i <= num_blame_lines; max_digits++)
+ i *= 10;
+
for (i = 0; i < num_blame_lines; i++) {
struct commit *c = blame_lines[i];
if (!c)
--
1.2.4.gee5c7
^ permalink raw reply related
* [PATCH] blame and annotate: show localtime with timezone.
From: Junio C Hamano @ 2006-03-05 22:48 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen, Ryan Anderson
In-Reply-To: <20060305123800.GD23448@c165.ib.student.liu.se>
Earlier they showed gmtime and timezone, which was inconsistent
with the way our commits and tags are pretty-printed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
blame.c | 15 ++++++++++++---
git-annotate.perl | 8 +++++++-
2 files changed, 19 insertions(+), 4 deletions(-)
e29f298a17ee898fd0d191d448ba4fc202175896
diff --git a/blame.c b/blame.c
index 59146fa..a3a8ddc 100644
--- a/blame.c
+++ b/blame.c
@@ -550,13 +550,22 @@ static void get_commit_info(struct commi
*tmp = 0;
}
-char* format_time(unsigned long time, const char* tz)
+static const char* format_time(unsigned long time, const char* tz_str)
{
static char time_buf[128];
time_t t = time;
+ int minutes, tz;
+ struct tm *tm;
- strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S ", gmtime(&t));
- strcat(time_buf, tz);
+ tz = atoi(tz_str);
+ minutes = tz < 0 ? -tz : tz;
+ minutes = (minutes / 100)*60 + (minutes % 100);
+ minutes = tz < 0 ? -minutes : minutes;
+ t = time + minutes * 60;
+ tm = gmtime(&t);
+
+ strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S ", tm);
+ strcat(time_buf, tz_str);
return time_buf;
}
diff --git a/git-annotate.perl b/git-annotate.perl
index d93ee19..b113def 100755
--- a/git-annotate.perl
+++ b/git-annotate.perl
@@ -418,7 +418,13 @@ sub format_date {
return $_[0];
}
my ($timestamp, $timezone) = split(' ', $_[0]);
- return strftime("%Y-%m-%d %H:%M:%S " . $timezone, gmtime($timestamp));
+ my $minutes = abs($timezone);
+ $minutes = int($minutes / 100) * 60 + ($minutes % 100);
+ if ($timezone < 0) {
+ $minutes = -$minutes;
+ }
+ my $t = $timestamp + $minutes * 60;
+ return strftime("%Y-%m-%d %H:%M:%S " . $timezone, gmtime($t));
}
# Copied from git-send-email.perl - We need a Git.pm module..
--
1.2.4.gee5c7
^ permalink raw reply related
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