* Re: git-log --follow?
From: Linus Torvalds @ 2007-07-12 17:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl7uvx8v.fsf_-_@assigned-by-dhcp.cox.net>
On Thu, 12 Jul 2007, Junio C Hamano wrote:
>
> I think this is just a testament that "following renames" is not
> as useful in a real project as people seem to believe, not a
> real complaint.
Yeah. That said, what you wanted would have actually worked with my
original strange patch to "git blame", and in particular that also would
allow you to get a "log" for certain lines in the file.
So something like
git blame -C -Lx,y --log
may still make sense to give people.
Here's a new version of that patch (I've long since lost the original one,
plus it probably wouldn't apply anyway, but it was easy to re-generate).
It doesn't set up the revs thing nicely, so trying to add "-p" or "--stat"
etc doesn't really get you what you'd want, and "--decorate" doesn't work
since it doesn't call "cmd_log_init".
So this certainly has some room for improvement, but my point is that "git
blame" actually knows all this, and in many ways does a better job than
"git log" (but a very *different* job!!).
So "git log" gives you the log for a (set of) pathname(s), while with this
patch, "git blame --log" gives you the log for the commits that can be
*blamed* for the current state of that pathname!
Two very different things, but both are valid, and interesting things to
do, I think. And I really think it's worth doing, if only because it's so
simple, and fits so well with the whole "git blame" structure!
Linus
---
diff --git a/builtin-blame.c b/builtin-blame.c
index 0519339..8de06d3 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -18,6 +18,7 @@
#include "cache-tree.h"
#include "path-list.h"
#include "mailmap.h"
+#include "log-tree.h"
static char blame_usage[] =
"git-blame [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [-L n,m] [-S <revs-file>] [-M] [-C] [-C] [--contents <filename>] [--incremental] [commit] [--] file\n"
@@ -34,6 +35,7 @@ static char blame_usage[] =
" -L n,m Process only line range n,m, counting from 1\n"
" -M, -C Find line movements within and across files\n"
" --incremental Show blame entries as we find them, incrementally\n"
+" --log Show blame entries as we find them in 'git log' style\n"
" --contents file Use <file>'s contents as the final image\n"
" -S revs-file Use revisions from revs-file instead of calling git-rev-list\n";
@@ -45,6 +47,7 @@ static int max_score_digits;
static int show_root;
static int blank_boundary;
static int incremental;
+static int blame_log;
static int cmd_is_annotate;
static int xdl_opts = XDF_NEED_MINIMAL;
static struct path_list mailmap;
@@ -1431,11 +1434,22 @@ static void write_filename_info(const char *path)
* The blame_entry is found to be guilty for the range. Mark it
* as such, and show it in incremental output.
*/
-static void found_guilty_entry(struct blame_entry *ent)
+static void found_guilty_entry(struct blame_entry *ent, struct rev_info *rev)
{
if (ent->guilty)
return;
ent->guilty = 1;
+ if (blame_log) {
+ struct origin *suspect = ent->suspect;
+ struct commit *commit = suspect->commit;
+
+ if (commit->object.flags & METAINFO_SHOWN)
+ return;
+ commit->object.flags |= METAINFO_SHOWN;
+ log_tree_commit(rev, commit);
+ maybe_flush_or_die(stdout, "stdout");
+ return;
+ }
if (incremental) {
struct origin *suspect = ent->suspect;
@@ -1505,7 +1519,7 @@ static void assign_blame(struct scoreboard *sb, struct rev_info *revs, int opt)
/* Take responsibility for the remaining entries */
for (ent = sb->ent; ent; ent = ent->next)
if (same_suspect(ent->suspect, suspect))
- found_guilty_entry(ent);
+ found_guilty_entry(ent, revs);
origin_decref(suspect);
if (DEBUG) /* sanity */
@@ -2204,6 +2218,8 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
}
else if (!strcmp("--incremental", arg))
incremental = 1;
+ else if (!strcmp("--log", arg))
+ save_commit_buffer = incremental = blame_log = 1;
else if (!strcmp("--score-debug", arg))
output_option |= OUTPUT_SHOW_SCORE;
else if (!strcmp("-f", arg) ||
@@ -2224,7 +2240,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
argv[unk++] = arg;
}
- if (!incremental)
+ if (blame_log || !incremental)
setup_pager();
if (!blame_move_score)
@@ -2324,7 +2340,14 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
argv[unk] = NULL;
init_revisions(&revs, NULL);
+
+ /* Maybe we should call "cmd_log_init()" here instead? */
+ revs.always_show_header = 1;
+ revs.commit_format = CMIT_FMT_DEFAULT;
+ revs.verbose_header = 1;
+ revs.abbrev = DEFAULT_ABBREV;
setup_revisions(unk, argv, &revs, NULL);
+
memset(&sb, 0, sizeof(sb));
/*
^ permalink raw reply related
* Re: git-svn+cygwin failed fetch
From: Russ Dill @ 2007-07-12 17:49 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20070712054800.GC29676@muzzle>
On 7/11/07, Eric Wong <normalperson@yhbt.net> wrote:
> Russ Dill <russ.dill@gmail.com> wrote:
> > On 7/11/07, Eric Wong <normalperson@yhbt.net> wrote:
> > >Russ Dill <russ.dill@gmail.com> wrote:
> > >> [...]/src $ mkdir foo
> > >> [...]/src $ cd foo
> > >> [...]/src/foo $ git-svn init -t tags -b branches -T trunk
> > >> https://www.[...].com/svn/foo/bar/bla
> > >> Initialized empty Git repository in .git/
> > >> Using higher level of URL: https://www.[...].com/svn/foo/bar/bla =>
> > >> https://www.[...].com/svn/foo
> > >>
> > >> [...]/src/foo $ git-svn fetch
> > >> config --get svn-remote.svn.url: command returned error: 1
> > >>
> > >> [...]/src/foo $ git config --get svn-remote.svn.url
> > >> https://www.[...].com/svn/foo
> > >
> > >Sorry, I can't help here other than recommending a real UNIX with
> > >fork + pipe + exec and all that fun stuff.
> > >
> > >git-svn relies heavily[1] on both input and output pipes of the
> > >safer-but-made-for-UNIX fork + pipe + exec(@list) variety, so I suspect
> > >this is just the tip of the iceberg for Windows incompatibilies with
> > >git-svn...
> >
> > Its actually reading and writing quite a bit of stuff from the config
> > file, so why this one simple command would fail eludes me. Especially
> > since it wrote it there in the first place. If I comment out the
> > command_oneline and hardcode the value I know it should return,
> > git-fetch runs. Its actually been running for several hours now.
>
> Wow. That's a pleasant surprise that anything in git-svn works at all
> on cygwin. I was almost certain git-svn on Windows was a hopeless cause
> from other chatter I had heard on the mailing list.
>
> command_oneline() is used everywhere in that code, so I'm at a total loss
> as to why it would fail in one place. Can you put a the following lines
> right before where it was failing?
>
> print "GIT_CONFIG: $ENV{GIT_CONFIG} | GIT_DIR: $ENV{GIT_DIR}\n";
> system('cat', "$ENV{GIT_DIR}/config");
>
> And tell me what it outputs?
Use of uninitialized value in concatenation (.) or string at
/usr/bin/git-svn line 1189.
GIT_CONFIG: | GIT_DIR: .git
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = https://www.[...].com/svn/foo
fetch = bar/bla/trunk:refs/remotes/trunk
branches = bar/bla/branches/*:refs/remotes/*
tags = bar/bla/tags/*:refs/remotes/tags/*
[gui]
geometry = 864x678+162+162 104 204
If I export GIT_CONFIG, then the problem goes away. Much better work
around then hardcoding svn-remote.svn.url
The git-svn fetch died overnight due to an http error. Its restarted
now. There are dozens of branches and tags in the repo, and each one
seems to take about a half hour to and hour to fully fetch. It takes a
similar amount of time to checkout trunk with tortise SVN. The repo is
local, but I don't have direct access to it.
^ permalink raw reply
* Re: mtimes of working files
From: David Woodhouse @ 2007-07-12 17:27 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Jan Hudec, Johannes Schindelin
In-Reply-To: <200707120857.53090.andyparkins@gmail.com>
On Thu, 2007-07-12 at 08:57 +0100, Andy Parkins wrote:
> The only time you get an unnecessary rebuild is if you do
>
> git checkout branch1
> git checkout branch2
> git checkout branch1
>
> But we can hardly expect git to be responsible for that.
Indeed. That's a user error. Git makes it cheap and easy to have
separate _trees_. Just use them -- branches are just another mental
hangover from CVS which we should try to cure ourselves of :)
--
dwmw2
^ permalink raw reply
* Re: git-svn and renames
From: Rogan Dawes @ 2007-07-12 16:51 UTC (permalink / raw)
To: Eric Wong; +Cc: Git Mailing List
In-Reply-To: <20070712090635.GA18155@mayonaise>
Eric Wong wrote:
>> I've personally noted a rename issue with committing funky characters
>> "#{}" in filenames (I was renaming to get rid of those funky characters of
>> course). Haven't had proper time to look into it.
>>
>> Did any previous successful commits have renames in them? You may want
>> to set similarity to 100% to disable rename detection.
>
> SVN over HTTP is most definitely behaves differently from svn:// and
> file:// wrt strange file names. I'll see if I can work on this again in
> day or two, or if anybody wants to pick up where I left off, my
> work-in-progress test case is below (it's currently failing, of course).
>
> I'll have to look into how (if) svk handles it and also at the svn
> command-line client. I'm fairly sure the command-line svn client
> handles it somehow...
>
> Right now I'm getting sleepy, my vision is blurring and I'm seeing
> "SVN" as "S/M" through my tired eyes...
>
Hi Eric,
This doesn't seem to be my problem. In my case, the filenames are quite
simple and straightforward.
Thanks
Rogan
^ permalink raw reply
* Re: Volume of commits
From: Linus Torvalds @ 2007-07-12 16:46 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: git
In-Reply-To: <m3ps2xu5hc.fsf@pc7.dolda2000.com>
On Thu, 12 Jul 2007, Fredrik Tolf wrote:
>
> I was wondering -- whenever I see Git patches committed to projects
> like the Linux kernel or Git itself, the commits always seems to be
> committing rather large changes and be rather well-defined in terms of
> what they change.
Well, people already talked about how to do it using git, but I'd like to
point out that one of the reasons you see this kind of pattern is that
when you push patches around by email for commentary (which is what both
git and the kernel do a _lot_), that very much inherently encourages a
setup where each patch makes sense on its own, and I think it causes
*much* better code cleanliness behaviour.
When people make changes that they know will be shown as patches, they
just tend to make more sure that the changes make logical sense. Part of
it is cleanups after-the-fact, but part of it is that when you get used to
doing it, after a while you start _thinking_ in those terms when you make
the changes, and that's also a good thing!
When I do any bigger changes, I usually tend to commit at points where it
starts working, but then before I actually would send it to Junio, I'd go
back and clean up the series (by creating a new branch, and
cherry-picking, and doing diffs between the branch and applying the parts
I want to).
But I do that only for stuff where I can't see the end result as a clean
series of steps from the beginning. If I know exactly what I'm doing, I'll
just do it the clean way from the get-go, and I don't need to clean up the
series after-the-fact.
(Most of the time I actually try to get it right the first time. It's
actually become a challenge to me to notice when some change needs a
cleanup first in order to make the later changes much easier, so I really
*like* trying to actually do the actual development in a logical order:
first re-organize the code, and verify that the re-organized code works
identically to the old one, then commit that, then start actually working
on the new feature with the now cleaner code-base).
And no, I didn't start out programming that way. But when you get used to
looking at changes as a nice series of independent commits in emails, you
really start _working_ that way yourself. And I'm 100% convinced that it
actually makes you a better programmer too.
> When I develop for myself, I usually commit incrementally quite a
> bit, if for no other reason because Git won't let me switch between
> branches if I don't commit first. I usually try to keep my commits
> well-defined, but I don't manage to get anywhere close to what I see
> when I look at the history of Linux or Git.
The stuff you see in git or the kernel has mostly been discussed as
emails, or at least been sent out that way (and if it didn't cause any
discussion, it was probably "obviously clean and correct"). And that whole
flow really *does* end up causing people to write cleaner patches.
It's absolutely worth emulating it, but in some respect, if it's just your
own project, I suspect you'll just never have the incentive to have your
history be quite as clean as the kernel/git development itself has.
Linus
^ permalink raw reply
* Re: [PATCH] apply delta depth bias to already deltified objects
From: Brian Downing @ 2007-07-12 16:44 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999.0707121146550.32552@xanadu.home>
On Thu, Jul 12, 2007 at 12:27:02PM -0400, Nicolas Pitre wrote:
> Better yet, the integer truncation error should be compensated for, with
> this:
>
> max_size =
> (trg_entry->delta_size * max_depth + max_depth - trg_entry->depth) /
> (max_depth - trg_entry->depth + 1);
Yep, with this, my degenerate case seems to find the optimum solution
(depth ~ 65) even at crazy maximum depths like 1000.
Looks good to me.
-bcd
^ permalink raw reply
* memory inefficiency in builtin-commit-tree.c - add_buffer() - in git version 1.5.2
From: Tim Stewart @ 2007-07-12 16:35 UTC (permalink / raw)
To: git
In-Reply-To: <23f4d5c70707120933l1d1664adgd12042a35f4629cd@mail.gmail.com>
The function init_buffer allocates 16,384 bytes. This function then
sets the size of the buffer at 0 bytes.
Then when add_buffer is called, it calculates how much memory the
added bytes will take up here:
alloc = (size + 32767) & ~32767;
Since size is 0, alloc will be 0. So the next line:
if (newsize > alloc) {
will always evaluate to true (unless newsize is 0) and then the
function reallocs the buffer at twice it's current size.
This all but guarantees that the memory allocated in init_buffer will
be realloc'ed.
Here is the code for your reference:
static void init_buffer(char **bufp, unsigned int *sizep)
{
*bufp = xmalloc(BLOCKING);
*sizep = 0;
}
static void add_buffer(char **bufp, unsigned int *sizep, const char *fmt, ...)
{
char one_line[2048];
va_list args;
int len;
unsigned long alloc, size, newsize;
char *buf;
va_start(args, fmt);
len = vsnprintf(one_line, sizeof(one_line), fmt, args);
va_end(args);
size = *sizep;
newsize = size + len + 1;
alloc = (size + 32767) & ~32767;
buf = *bufp;
if (newsize > alloc) {
alloc = (newsize + 32767) & ~32767;
buf = xrealloc(buf, alloc);
*bufp = buf;
}
*sizep = newsize - 1;
memcpy(buf + size, one_line, len);
}
^ permalink raw reply
* Re: [PATCH] apply delta depth bias to already deltified objects
From: Nicolas Pitre @ 2007-07-12 16:27 UTC (permalink / raw)
To: Brian Downing; +Cc: Junio C Hamano, git
In-Reply-To: <20070712152016.GB19073@lavos.net>
On Thu, 12 Jul 2007, Brian Downing wrote:
> On Thu, Jul 12, 2007 at 02:38:30AM -0400, Nicolas Pitre wrote:
> > This apparently makes BRian's patological case worse (although better
> > than before his same-size-shallower patch), but I think that the
> > improvement in the general case is worth it. Even Brian's pack gets
> > smaller so...
>
> I've found why this makes my case worse, and I think it's correctable
> and will benefit everything when fixed:
>
> Let's say we've currently got a delta match of 11 bytes at depth 5.
> So trg_entry->delta_size = 11 and trg_entry->depth = 5. max_depth is
> 100.
>
> Now let's say the next object we're comparing against is at depth 2
> (src_entry->depth = 2). Even if we can find a delta of the same size
> we should take it.
>
> Now, with Nico's new patch:
>
> max_size = trg_entry->delta_size * max_depth /
> (max_depth - trg_entry->depth + 1);
>
> max_size is now 11. So far so good.
>
> Now, however, the other bias happens:
>
> max_size = max_size * (max_depth - src_entry->depth) / max_depth;
>
> max_size = 11 * (100 - 2) / 100;
> max_size = 1078 / 100;
> max_size = 10;
Hmmm... Integer truncation errors.
In theory, the allowed max_size should be slightly higher than what we
got in the depth 5 case because this case is less deep. So...
max_size = trg_entry->delta_size * max_depth /
(max_depth - trg_entry->depth + 1);
max_size = 11 * 100 / (100 - 5 + 1) = 11.4583
max_size = max_size * (max_depth - src_entry->depth) / max_depth;
max_size = 11.4583 * (100 - 2) / 100 = 11.2292
So the max_size, because the depth is less, is slightly higher.
> This was okay when max_size was always (trg_size/2 - 20) here, but now
> it's cutting it off too much. max_size is now 10, and we can't make
> a better depth match of the same size anymore.
>
> I think the second bias equation should be scaled so as not to take
> effect unless (src_entry->depth [+ 1?] > trg_entry->depth).
Better yet, the integer truncation error should be compensated for, with
this:
max_size =
(trg_entry->delta_size * max_depth + max_depth - trg_entry->depth) /
(max_depth - trg_entry->depth + 1);
Nicolas
^ permalink raw reply
* Re: Volume of commits
From: Joshua N Pritikin @ 2007-07-12 16:09 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: git
In-Reply-To: <m3ir8pu133.fsf@pc7.dolda2000.com>
On Thu, Jul 12, 2007 at 04:51:44PM +0200, Fredrik Tolf wrote:
> git-rebase is one of those tools I haven't been looking at so far (I'm
> still rather new to Git), so I should probably read through its
> manpage.
I was in your shoes but I recently learned rebase. If you want to edit a
commit then find the SHA-1 in git log. Then assuming you are on master:
1. git checkout -b tmp SHA-1
2. git commit --amend
3. git checkout master
4. git rebase --onto tmp SHA-1
Both times, use the same SHA-1.
^ permalink raw reply
* Re: Volume of commits
From: Karl Hasselström @ 2007-07-12 16:21 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: git
In-Reply-To: <m3ir8pu133.fsf@pc7.dolda2000.com>
On 2007-07-12 16:51:44 +0200, Fredrik Tolf wrote:
> I see. Initially, it sounds like a lot of work, but the more I think
> about it, the more I realize that it probably isn't that bad.
You're right that it isn't that much work, but it still is work. The
point is that just like investing time in making code nice and
readable, investing time in making the history nice and readable is a
net win. Others can follow what you do, which makes reviewing the
changes much cheaper, and you can look back six months and actually
understand what you were thinking back then.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 0/6] Pack window memory limit, take 2
From: Nicolas Pitre @ 2007-07-12 15:46 UTC (permalink / raw)
To: Brian Downing; +Cc: git, Junio C Hamano
In-Reply-To: <1184244952554-git-send-email-bdowning@lavos.net>
On Thu, 12 Jul 2007, Brian Downing wrote:
> This series has my circular buffer errors (hopefully) corrected, and
> the code is a lot cleaner as a bonus. Also, the options are now named
> --window-memory and pack.windowMemory, and both can take {k,m,g} suffixes.
Acked-by: Nicolas Pitre <nico@cam.org>
(including the amended patches).
Nicolas
^ permalink raw reply
* Re: [PATCH] apply delta depth bias to already deltified objects
From: Brian Downing @ 2007-07-12 15:20 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999.0707120049120.32552@xanadu.home>
On Thu, Jul 12, 2007 at 02:38:30AM -0400, Nicolas Pitre wrote:
> This apparently makes BRian's patological case worse (although better
> than before his same-size-shallower patch), but I think that the
> improvement in the general case is worth it. Even Brian's pack gets
> smaller so...
I've found why this makes my case worse, and I think it's correctable
and will benefit everything when fixed:
Let's say we've currently got a delta match of 11 bytes at depth 5.
So trg_entry->delta_size = 11 and trg_entry->depth = 5. max_depth is
100.
Now let's say the next object we're comparing against is at depth 2
(src_entry->depth = 2). Even if we can find a delta of the same size
we should take it.
Now, with Nico's new patch:
max_size = trg_entry->delta_size * max_depth /
(max_depth - trg_entry->depth + 1);
max_size is now 11. So far so good.
Now, however, the other bias happens:
max_size = max_size * (max_depth - src_entry->depth) / max_depth;
max_size = 11 * (100 - 2) / 100;
max_size = 1078 / 100;
max_size = 10;
This was okay when max_size was always (trg_size/2 - 20) here, but now
it's cutting it off too much. max_size is now 10, and we can't make
a better depth match of the same size anymore.
I think the second bias equation should be scaled so as not to take
effect unless (src_entry->depth [+ 1?] > trg_entry->depth).
Other than this flaw I think this patch looks great.
-bcd
^ permalink raw reply
* Re: git-update-server-info may be required,cannot clone and pull from a remote repository
From: Alex Riesen @ 2007-07-12 15:05 UTC (permalink / raw)
To: pradeep singh; +Cc: Johannes Schindelin, Jakub Narebski, Eric Wong, git
In-Reply-To: <a901b49a0707120632m1654733as94839e88bd993bb1@mail.gmail.com>
On 7/12/07, pradeep singh <pradeep.rautela@gmail.com> wrote:
> If i upgrade to git 1.5.x will i loose my earlier git info and all the stuff?
No
> I hope having differnt git versions on different machines does not hurts?
It does not hurt, but you'll find you like the new one.
^ permalink raw reply
* [PATCH] Add missing functions to contrib/emacs/vc-git.el
From: David Kastrup @ 2007-07-12 14:48 UTC (permalink / raw)
To: git
In-Reply-To: <A084830C-F1CD-4EDC-A13D-573DFC68DF77@silverinsanity.com>
This is necessary to make several editing functions work, like
C-u C-x v =
Signed-off-by: David Kastrup <dak@gnu.org>
---
contrib/emacs/vc-git.el | 65 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/vc-git.el b/contrib/emacs/vc-git.el
index e456ab9..b8f6be5 100644
--- a/contrib/emacs/vc-git.el
+++ b/contrib/emacs/vc-git.el
@@ -81,6 +81,71 @@
(match-string 2 str)
str)))
+(defun vc-git-symbolic-commit (commit)
+ "Translate COMMIT string into symbolic form.
+Returns nil if not possible."
+ (and commit
+ (with-temp-buffer
+ (and
+ (zerop
+ (call-process "git" nil '(t nil) nil "name-rev"
+ "--name-only" "--tags"
+ commit))
+ (goto-char (point-min))
+ (= (forward-line 2) 1)
+ (bolp)
+ (buffer-substring-no-properties (point-min) (1- (point-max)))))))
+
+(defun vc-git-previous-version (file rev)
+ "git-specific version of `vc-previous-version'."
+ (let ((default-directory (file-name-directory (expand-file-name file)))
+ (file (file-name-nondirectory file)))
+ (vc-git-symbolic-commit
+ (with-temp-buffer
+ (and
+ (zerop
+ (call-process "git" nil '(t nil) nil "rev-list"
+ "-2" rev "--" file))
+ (goto-char (point-max))
+ (bolp)
+ (zerop (forward-line -1))
+ (not (bobp))
+ (buffer-substring-no-properties
+ (point)
+ (1- (point-max))))))))
+
+(defun vc-git-next-version (file rev)
+ "git-specific version of `vc-next-version'."
+ (let* ((default-directory (file-name-directory
+ (expand-file-name file)))
+ (file (file-name-nondirectory file))
+ (current-rev
+ (with-temp-buffer
+ (and
+ (zerop
+ (call-process "git" nil '(t nil) nil "rev-list"
+ "-1" rev "--" file))
+ (goto-char (point-max))
+ (bolp)
+ (zerop (forward-line -1))
+ (bobp)
+ (buffer-substring-no-properties
+ (point)
+ (1- (point-max)))))))
+ (and current-rev
+ (vc-git-symbolic-commit
+ (with-temp-buffer
+ (and
+ (zerop
+ (call-process "git" nil '(t nil) nil "rev-list"
+ "HEAD" "--" file))
+ (goto-char (point-min))
+ (search-forward current-rev nil t)
+ (zerop (forward-line -1))
+ (buffer-substring-no-properties
+ (point)
+ (progn (forward-line 1) (1- (point))))))))))
+
(defun vc-git-revert (file &optional contents-done)
"Revert FILE to the version stored in the git repository."
(if contents-done
--
1.5.3.rc0.51.gb0b1f
--
David Kastrup
^ permalink raw reply related
* [PATCH] Documentation for git-log --follow
From: Steven Walter @ 2007-07-12 14:52 UTC (permalink / raw)
To: git
After vainly searching the Documentation for how to follow renames, I
finally broke down and grepped the source. It would appear that Linus
didn't add write and docs for this feature when he wrote it. The
following patch rectifies that, hopefully sparing future users from
resorting to the source code.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
---
Documentation/git-log.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 7adcdef..63c1dbe 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -61,6 +61,9 @@ include::pretty-options.txt[]
the specified paths; this means that "<paths>..." limits only
commits, and doesn't limit diff for those commits.
+--follow::
+ Continue listing the history of a file beyond renames.
+
<paths>...::
Show only commits that affect the specified paths.
@@ -91,6 +94,12 @@ git log -r --name-status release..test::
in the "release" branch, along with the list of paths
each commit modifies.
+git log --follow builtin-rev-list.c::
+
+ Shows the commits that changed builtin-rev-list.c, including
+ those commits that occurred before the file was given its
+ present name.
+
Discussion
----------
--
1.5.3.rc0
^ permalink raw reply related
* Re: Volume of commits
From: Fredrik Tolf @ 2007-07-12 14:51 UTC (permalink / raw)
To: git
In-Reply-To: <20070712140304.GB28310@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> On 2007-07-12 15:16:47 +0200, Fredrik Tolf wrote:
>
>> Or do you somehow aggregate the smaller commits into larger patches
>> and recommit them? Or is there some third possibility that I'm
>> missing?
>
> Aggregating commits and recommitting is easy, so that's a common tool,
> I'd say. But it's equally possible to take a large commit and pick it
> apart, for example by editing the patch by hand and reapplying it, or
> by using the hunk selection feature of git-gui.
I see. Initially, it sounds like a lot of work, but the more I think
about it, the more I realize that it probably isn't that bad.
> [...]
> If you need to edit a commit that isn't HEAD, you can use git-reset to
> go back to the commit you want to edit, do the editing, and then use
> git-rebase to reapply the other commits on top of the changed commit.
git-rebase is one of those tools I haven't been looking at so far (I'm
still rather new to Git), so I should probably read through its
manpage.
> In general, there are a thousand ways to use git to rewrite history,
> either "by hand" or by using tools such as StGIT. (StGIT is what I
> personally use most of the time. I find it a good tool for producing
> readable patch series.)
I hadn't heard of StGIT, but it looks interesting.
Thanks for all the suggestions! I'll be needing some time to look them
through. :)
Fredrik Tolf
^ permalink raw reply
* [PATCH] Correct shebang line for contrib/stats/packinfo.pl
From: Brian Downing @ 2007-07-12 14:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Downing, git
"/bin/perl"? What was I thinking?
Signed-off-by: Brian Downing <bdowning@lavos.net>
---
contrib/stats/packinfo.pl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/stats/packinfo.pl b/contrib/stats/packinfo.pl
index 792673a..aab501e 100755
--- a/contrib/stats/packinfo.pl
+++ b/contrib/stats/packinfo.pl
@@ -1,4 +1,4 @@
-#!/bin/perl
+#!/usr/bin/perl
#
# This tool will print vaguely pretty information about a pack. It
# expects the output of "git-verify-pack -v" as input on stdin.
--
1.5.2.GIT
^ permalink raw reply related
* Re: Volume of commits
From: Karl Hasselström @ 2007-07-12 14:03 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: git
In-Reply-To: <m3ps2xu5hc.fsf@pc7.dolda2000.com>
On 2007-07-12 15:16:47 +0200, Fredrik Tolf wrote:
> Or do you somehow aggregate the smaller commits into larger patches
> and recommit them? Or is there some third possibility that I'm
> missing?
Aggregating commits and recommitting is easy, so that's a common tool,
I'd say. But it's equally possible to take a large commit and pick it
apart, for example by editing the patch by hand and reapplying it, or
by using the hunk selection feature of git-gui.
For example, if you have just committed several changes as one big
commit, you can do
$ git reset HEAD^
to undo the commit but retain the changes in your working tree, and
then use git-gui to select a subset of the changes and commit them,
then select another subset and commit that, and so on.
If you need to edit a commit that isn't HEAD, you can use git-reset to
go back to the commit you want to edit, do the editing, and then use
git-rebase to reapply the other commits on top of the changed commit.
In general, there are a thousand ways to use git to rewrite history,
either "by hand" or by using tools such as StGIT. (StGIT is what I
personally use most of the time. I find it a good tool for producing
readable patch series.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Volume of commits
From: Johannes Schindelin @ 2007-07-12 13:59 UTC (permalink / raw)
To: VMiklos; +Cc: Fredrik Tolf, git
In-Reply-To: <20070712132937.GQ19386@genesis.frugalware.org>
Hi,
On Thu, 12 Jul 2007, VMiklos wrote:
> Na Thu, Jul 12, 2007 at 03:16:47PM +0200, Fredrik Tolf <fredrik@dolda2000.com> pisal(a):
> > So what I'm wondering is how you people manage to do this? Do you
> > actually always commit changes this way (and, in that case, how do you
> > switch between branches)? Or do you somehow aggregate the smaller
> > commits into larger patches and recommit them? Or is there some third
> > possibility that I'm missing?
>
> you can cherry-pick the relevan patches to a separate branch and commit
> then at once (cherry-pick -n), or can merge --squash to archive
> something similar
What I do these days is committing early, and often, and then rearrange
with "git rebase -i". Beware: this is a 1.5.3 feature! But IMHO it is
really something you can look forward to.
A little diagram hopefully explains what you can do with it:
- upstream
\
A - B - C - D - E - F - G - HEAD with a messy history
In this case, "messy history" means that there are tiny patches which are
often in the wrong order, or should be squashed into one commit. "git
rebase -i upstream" presents you with the list of A - HEAD, and you can
reorder the patches. If you want to, you can combine ("squash") some
into one commit, or you can skip it, by removing the corresponding line.
The result can look like this:
- upstream
\
B+C+F - A - G+E
Note that D is missing, which can be desirable, for example when you made
a commit only introducing lots and lots of debug output. See, nobody has
to know what you did. The end result will look elegant.
This demonstration of why distributed SCM is good ("it lowers the
embarrasment factor") was brought to you by Git.
Ciao,
Dscho
^ permalink raw reply
* Re: Volume of commits
From: Karl Hasselström @ 2007-07-12 13:49 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: git
In-Reply-To: <m3ps2xu5hc.fsf@pc7.dolda2000.com>
On 2007-07-12 15:16:47 +0200, Fredrik Tolf wrote:
> When I develop for myself, I usually commit incrementally quite a
> bit, if for no other reason because Git won't let me switch between
> branches if I don't commit first.
You can switch branches even if you have local modifications if you
use the -m flag to git-checkout.
> I usually try to keep my commits well-defined, but I don't manage to
> get anywhere close to what I see when I look at the history of Linux
> or Git.
>
> So what I'm wondering is how you people manage to do this? Do you
> actually always commit changes this way (and, in that case, how do
> you switch between branches)? Or do you somehow aggregate the
> smaller commits into larger patches and recommit them? Or is there
> some third possibility that I'm missing?
When it's time to post patches for review on the mailing list, people
clean up the history so that it'll be easier for the reviewers to read
(and to make the permanent history easier to read in case the patches
are accepted). Of course, with practice one can write clean patches to
begin with, at least for simpler changes, but the conceptual workflow
is along the lines of:
1. Do the changes, and make sure everything works.
2. Rewrite your changes as a series of easy-to-read and mostly
independent patches, and make sure that everything compiles and
just generally makes sense at all intermediate steps. The
maintainer might very well accept some of your patches but not
all!
3. Repeat until you're satisfied with the result.
The rationale for spending time making history legible is the same as
for making the end result code legible: stuff is written once by one
person, and read many times by many people.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-update-server-info may be required,cannot clone and pull from a remote repository
From: pradeep singh @ 2007-07-12 13:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Eric Wong, git
In-Reply-To: <Pine.LNX.4.64.0707121411070.4516@racer.site>
On 7/12/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 12 Jul 2007, pradeep singh wrote:
>
> > On 7/12/07, pradeep singh <pradeep.rautela@gmail.com> wrote:
> > > On 7/12/07, Jakub Narebski <jnareb@gmail.com> wrote:
> > > > What information does gitweb/INSTALL lack?
> > >
> > > May be i am running some old version on my Ubuntu Edgy machine
> > > perhaps? I cannot find such a file anywhere?
> > >
> > > Looks like it is available in newer versions. Does it works for
> > > git-1.4.4?
>
> IMHO it is not good to start with anything prior to 1.5.0, if you did not
> have any exposure to older Git. In terms of user friendliness,
> 1.4.4.4->1.5.0 is a leap by an astronomic unit.
thanks for the update.
My question now changes to -
If i upgrade to git 1.5.x will i loose my earlier git info and all the stuff?
I hope having differnt git versions on different machines does not hurts?
Thanks once again for the valuable advice.
regards
>
> Ciao,
> Dscho
>
>
--
Pradeep
^ permalink raw reply
* [PATCH] Add functions for parsing integers with size suffixes
From: Brian Downing @ 2007-07-12 13:32 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nicolas Pitre, Johannes Schindelin, Brian Downing
In-Reply-To: <Pine.LNX.4.64.0707121404450.4516@racer.site>
Split out the nnn{k,m,g} parsing code from git_config_int into
git_parse_long, so command-line parameters can enjoy the same
functionality. Also add get_parse_ulong for unsigned values.
Make git_config_int use git_parse_long, and add get_config_ulong
as well.
Signed-off-by: Brian Downing <bdowning@lavos.net>
---
Good idea!
cache.h | 3 +++
config.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++------------
2 files changed, 49 insertions(+), 12 deletions(-)
diff --git a/cache.h b/cache.h
index e64071e..917a7e3 100644
--- a/cache.h
+++ b/cache.h
@@ -521,7 +521,10 @@ typedef int (*config_fn_t)(const char *, const char *);
extern int git_default_config(const char *, const char *);
extern int git_config_from_file(config_fn_t fn, const char *);
extern int git_config(config_fn_t fn);
+extern int git_parse_long(const char *, long *);
+extern int git_parse_ulong(const char *, unsigned long *);
extern int git_config_int(const char *, const char *);
+extern unsigned long git_config_ulong(const char *, const char *);
extern int git_config_bool(const char *, const char *);
extern int git_config_set(const char *, const char *);
extern int git_config_set_multivar(const char *, const char *, const char *, int);
diff --git a/config.c b/config.c
index 561ee3b..f89a611 100644
--- a/config.c
+++ b/config.c
@@ -233,21 +233,55 @@ static int git_parse_file(config_fn_t fn)
die("bad config file line %d in %s", config_linenr, config_file_name);
}
-int git_config_int(const char *name, const char *value)
+static unsigned long get_unit_factor(const char *end)
+{
+ if (!*end)
+ return 1;
+ else if (!strcasecmp(end, "k"))
+ return 1024;
+ else if (!strcasecmp(end, "m"))
+ return 1024 * 1024;
+ else if (!strcasecmp(end, "g"))
+ return 1024 * 1024 * 1024;
+ die("unknown unit: '%s'", end);
+}
+
+int git_parse_long(const char *value, long *ret)
+{
+ if (value && *value) {
+ char *end;
+ long val = strtol(value, &end, 0);
+ *ret = val * get_unit_factor(end);
+ return 1;
+ }
+ return 0;
+}
+
+int git_parse_ulong(const char *value, unsigned long *ret)
{
if (value && *value) {
char *end;
- int val = strtol(value, &end, 0);
- if (!*end)
- return val;
- if (!strcasecmp(end, "k"))
- return val * 1024;
- if (!strcasecmp(end, "m"))
- return val * 1024 * 1024;
- if (!strcasecmp(end, "g"))
- return val * 1024 * 1024 * 1024;
- }
- die("bad config value for '%s' in %s", name, config_file_name);
+ unsigned long val = strtoul(value, &end, 0);
+ *ret = val * get_unit_factor(end);
+ return 1;
+ }
+ return 0;
+}
+
+int git_config_int(const char *name, const char *value)
+{
+ long ret;
+ if (!git_parse_long(value, &ret))
+ die("bad config value for '%s' in %s", name, config_file_name);
+ return ret;
+}
+
+unsigned long git_config_ulong(const char *name, const char *value)
+{
+ unsigned long ret;
+ if (!git_parse_ulong(value, &ret))
+ die("bad config value for '%s' in %s", name, config_file_name);
+ return ret;
}
int git_config_bool(const char *name, const char *value)
--
1.5.2.GIT
^ permalink raw reply related
* Re: Volume of commits
From: VMiklos @ 2007-07-12 13:29 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: git
In-Reply-To: <m3ps2xu5hc.fsf@pc7.dolda2000.com>
[-- Attachment #1: Type: text/plain, Size: 576 bytes --]
Hello,
Na Thu, Jul 12, 2007 at 03:16:47PM +0200, Fredrik Tolf <fredrik@dolda2000.com> pisal(a):
> So what I'm wondering is how you people manage to do this? Do you
> actually always commit changes this way (and, in that case, how do you
> switch between branches)? Or do you somehow aggregate the smaller
> commits into larger patches and recommit them? Or is there some third
> possibility that I'm missing?
you can cherry-pick the relevan patches to a separate branch and commit
then at once (cherry-pick -n), or can merge --squash to archive
something similar
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Volume of commits
From: Fredrik Tolf @ 2007-07-12 13:16 UTC (permalink / raw)
To: git
Hi List,
I was wondering -- whenever I see Git patches committed to projects
like the Linux kernel or Git itself, the commits always seems to be
committing rather large changes and be rather well-defined in terms of
what they change.
When I develop for myself, I usually commit incrementally quite a
bit, if for no other reason because Git won't let me switch between
branches if I don't commit first. I usually try to keep my commits
well-defined, but I don't manage to get anywhere close to what I see
when I look at the history of Linux or Git.
So what I'm wondering is how you people manage to do this? Do you
actually always commit changes this way (and, in that case, how do you
switch between branches)? Or do you somehow aggregate the smaller
commits into larger patches and recommit them? Or is there some third
possibility that I'm missing?
Fredrik Tolf
^ permalink raw reply
* Re: git-update-server-info may be required,cannot clone and pull from a remote repository
From: Johannes Schindelin @ 2007-07-12 13:13 UTC (permalink / raw)
To: pradeep singh; +Cc: Jakub Narebski, Eric Wong, git
In-Reply-To: <a901b49a0707120552y649fba20p4fa14ca48be4be54@mail.gmail.com>
Hi,
On Thu, 12 Jul 2007, pradeep singh wrote:
> On 7/12/07, pradeep singh <pradeep.rautela@gmail.com> wrote:
> > On 7/12/07, Jakub Narebski <jnareb@gmail.com> wrote:
> > > What information does gitweb/INSTALL lack?
> >
> > May be i am running some old version on my Ubuntu Edgy machine
> > perhaps? I cannot find such a file anywhere?
> >
> > Looks like it is available in newer versions. Does it works for
> > git-1.4.4?
IMHO it is not good to start with anything prior to 1.5.0, if you did not
have any exposure to older Git. In terms of user friendliness,
1.4.4.4->1.5.0 is a leap by an astronomic unit.
Ciao,
Dscho
^ 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