* Re: [PATCH] Add git-imap-send.
From: Linus Torvalds @ 2006-03-09 18:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Mike McCormack
In-Reply-To: <7vmzfz5w2k.fsf@assigned-by-dhcp.cox.net>
On Thu, 9 Mar 2006, Junio C Hamano wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > it's entirely possible that it will load bytes from "string" _past_ the
> > end of the string because of an unrolled inner loop that does things
> > multiple bytes at a time. They won't be used in the eventual result, but
> > just the fact that they are loaded from memory can mean that your program
> > takes a SIGSEGV, for example, becaue it turns out "string" was just a
> > single NUL byte at the end of a page, and there's nothing after it.
>
> Funny. I've seen this exact bug in memcmp and strcmp in earlier
> SunOS (pre Solaris) libc when I was working on something like
> Valgrind in my previous life.
Well, Valgrind actually can complain for no good reason.
System libraries often take advantage of knowing how the CPU and the
system memory layout works. For example, just from knowing that pages are
always aligned to a certain (largish) boundary, you can know that it's
perfectly safe to do certain optimizations and prefetch past the end of an
object, as long as it's in the same page (and the easiest way to verify
that is to just do it when something is aligned).
So Valgrind will sometimes complain about perfectly bug-free code, just
because the bug-free code accesses outside the "strictly allowable"
region because it knows it can.
Valgrind can be taught about system libraries like that, but especially if
it's an early port to a new architecture or OS, valgrind will often
complain unnecessarily.
Linus
^ permalink raw reply
* Re: [PATCH] clone: add refs/remotes/* to Pull: targets when cloning
From: Junio C Hamano @ 2006-03-09 18:23 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060309115535.GB13369@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
> diff --git a/git-clone.sh b/git-clone.sh
> index 4ed861d..a8ab7fd 100755
> --- a/git-clone.sh
> +++ b/git-clone.sh
> @@ -249,6 +249,12 @@ Pull: $head_points_at:$origin" &&
> test "$origin" = "$head" ||
> echo "Pull: ${head}:${head}"
> done >>"$GIT_DIR/remotes/origin"
> + (test -d "$GIT_DIR"/refs/remotes && cd "$GIT_DIR" &&
> + find "refs/remotes" -type f -print | sed -e 's|^refs/||') |
> + while read ref
> + do
> + echo "Pull: $ref:$ref"
> + done >>"$GIT_DIR/remotes/origin"
> esac
I am not sure I agree with what you are doing here. I thought
the idea behind refs/remotes is to migrate away from copying all
the remote heads into refs/heads (so that Linus does not need to
see my "next" and "pu" under his refs/heads), and putting
foreign SCM tracking branches used by SVN and CVS importers in
there instead of in refs/heads naturally falls out from that
pattern.
Now I do not propose to change the current clone that
contaminates the local branch namespace by copying remote
refs/heads into local refs/heads in the middle of v1.3.0
development without laying out a transition plan, but I think
that is a sensible future direction. Instead of copying
everything from refs/heads to refs/heads, we only copy what
remote HEAD points at to refs/heads/master to initialize the
local clone, and copy everything from refs/heads to
refs/remotes, _and_ set up Pull: lines to do the same tracking.
The part of the code you are touching corresponds to the last
part.
We would probably be better off not doing this right now. When
we are sure everybody thinks it is a better approach to use
refs/remotes for remote branch tracking, we would need to change
the part you did not change (I think the clone-pack part is the
hardest to change since it has a built-in "copy refs to matching
locations" logic) alongside with the part you touched with this
patch to make things consistent. At that time also you would
need to remove several lines above the part you touched so that
we do not use local refs/heads/* for tracking.
How does that sound?
^ permalink raw reply
* Re: [PATCH] Add git-imap-send.
From: Junio C Hamano @ 2006-03-09 18:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603091017530.18022@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> > ... They won't be used in the eventual result, but
>> > just the fact that they are loaded from memory can mean that your program
>> > takes a SIGSEGV, for example, becaue it turns out "string" was just a
>> > single NUL byte at the end of a page, and there's nothing after it.
>>
>> Funny. I've seen this exact bug in memcmp and strcmp in earlier
>> SunOS (pre Solaris) libc when I was working on something like
>> Valgrind in my previous life.
>
> Well, Valgrind actually can complain for no good reason.
To clarify, it was _not_ Valgrind I was mucking with. And the
optimization used in the system library was wrong -- it stepped
over the page boundary without checking. I found that it was
fixed in later releases (that was all before Sun started
calling their system Solaris).
^ permalink raw reply
* Re: [PATCH] Allow git-repack to optionally run git-prune-packed.
From: Junio C Hamano @ 2006-03-09 18:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Alex Riesen
In-Reply-To: <81b0412b0603090648w4a3e4e4bwceb0ad19a2a4d15f@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> On 3/9/06, Martin Atukunda <matlads@dsmagic.com> wrote:
>> Your suggestion has merit, though it's different from the behaviour I
>> desired. I _sometimes_ need the pruning, and it felt appropriate to make
>> it an option as opposed to default behaviour.
>>
>> What do you think?
>
> I think that my patch didn't change the default. git-prune-packed is called
> only if -d is given, which is not the default.
I am inclined to say I prefer Alex' one.
^ permalink raw reply
* Re: git-ls-files --unmerged implies --stages: ?
From: Junio C Hamano @ 2006-03-09 18:50 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2006.03.09.15.19.03.286472@smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
> I wonder why git-ls-files --unmerged implies --stages. One nice use case
> for this command is to edit all the conflicting files after a failed
> merge, i.e.
>
> $ vi $(git-ls-files --unmerged)
>
> except I need a pipe to throw out all the cruft in there.
I typically use git diff --name-only for this (yes I probably
need to uniq them out), but you can certainly talk me into
introducing --unmerged --name-only. If nobody objects, even
making --unmerged independent from --stages might be a sensible
thing to do -- if we do so you would need --unmerged --stages to
get the current behaviour.
^ permalink raw reply
* Re: [PATCH] allow double click on current HEAD id after git-pull
From: Petr Baudis @ 2006-03-09 21:02 UTC (permalink / raw)
To: junkio; +Cc: Olaf Hering, git
In-Reply-To: <20060211112630.GA12421@suse.de>
Dear diary, on Sat, Feb 11, 2006 at 12:26:30PM CET, I got a letter
where Olaf Hering <olh@suse.de> said that...
> Double click on to current HEAD commit id is not possible,
> the dot has to go.
>
> olaf@pomegranate:~/kernel/git/linux-2.6> git-pull
> Unpacking 194 objects
> 100% (194/194) done
> * refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
> Updating from 5bc159e6cb7ca8d173195919ee935885c129011e to 25bf368b3d98668c5d5f38e2201d8bca16e52680.
^
Junio, is there any particular reason why this hasn't been applied?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Catalin Marinas @ 2006-03-09 22:00 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060301155043.GA3706@spearce.org>
On 01/03/06, Shawn Pearce <spearce@spearce.org> wrote:
> Speaking of making StGIT faster: earlier we were talking about how
> git-diff|git-apply is faster than a 3 way git-read-tree on large
> merges when there are many structural changes in the tree due to
> the smaller number of process spawns required.
>
> You might want to take a look at pg--merge-all: This is sort of based
> on git-merge-recursive, but I've gotten it down to just a handful
> of process spawns, aside from the stupidity of git-checkout-index.
Trying to implement this, I've just noticed that git-read-tree has a
--aggressive option which takes care of the file removals. Adding this
option lowered the pushing time in StGIT from ~2 min to under 2
seconds (merges between 2.6.14 and the latest kernel). There's
probably no need to deal with file removals in pg--merge-all anymore.
--
Catalin
^ permalink raw reply
* Re: [PATCH] allow double click on current HEAD id after git-pull
From: Junio C Hamano @ 2006-03-09 23:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: junkio, Olaf Hering, git
In-Reply-To: <20060309210250.GY31278@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sat, Feb 11, 2006 at 12:26:30PM CET, I got a letter
> where Olaf Hering <olh@suse.de> said that...
>> Double click on to current HEAD commit id is not possible,
>> the dot has to go.
>>
>> olaf@pomegranate:~/kernel/git/linux-2.6> git-pull
>> Unpacking 194 objects
>> 100% (194/194) done
>> * refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
>> Updating from 5bc159e6cb7ca8d173195919ee935885c129011e to 25bf368b3d98668c5d5f38e2201d8bca16e52680.
> ^
>
> Junio, is there any particular reason why this hasn't been applied?
Well I kind of like ending a sentence with a full stop. Isn't
this something you can do by confuguiring your cut&paste?
But I do not have a _very_ strong feeling either way. If
majority of the list wants it that way I do not mind.
^ permalink raw reply
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Junio C Hamano @ 2006-03-09 23:20 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Shawn Pearce
In-Reply-To: <b0943d9e0603091400o2cd0291h@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> Trying to implement this, I've just noticed that git-read-tree has a
> --aggressive option which takes care of the file removals. Adding this
> option lowered the pushing time in StGIT from ~2 min to under 2
> seconds (merges between 2.6.14 and the latest kernel). There's
> probably no need to deal with file removals in pg--merge-all anymore.
Yup, it was originally done to improve the performance of
resolve merge strategy, but I am glad somebody else has found
use for it.
^ permalink raw reply
* Re: [PATCH] allow double click on current HEAD id after git-pull
From: Carl Worth @ 2006-03-10 0:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Olaf Hering, git
In-Reply-To: <7vy7zj2oom.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
On Thu, 09 Mar 2006 15:17:29 -0800, Junio C Hamano wrote:
> Well I kind of like ending a sentence with a full stop. Isn't
> this something you can do by confuguiring your cut&paste?
If the cut-and-paste configuration is limited to just word characters
vs. word-separating characters, then no. At least not and also
preserve the ability to select numbers of the form 1.25 .
I don't know if an extra space like the above is good style, but it is
what I have sometimes caught myself doing when ending a sentence with
a URL, for example.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add git-imap-send.
From: Mark Wooding @ 2006-03-10 0:38 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0603091445280.21440@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I would be astonished if memcmp has to be timing proof for *all*
> applications, just to keep crypto people happy. I don't *want* a
> slow-down in my super-duper 3d shooter.
Oh, obviously that would be lunatic! ;-) Just making the point that it's
not /completely/ obvious that early stopping is what everyone wants...
-- [mdw]
^ permalink raw reply
* Re: [PATCH] allow double click on current HEAD id after git-pull
From: Mark Wooding @ 2006-03-10 0:49 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7zj2oom.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Well I kind of like ending a sentence with a full stop. Isn't
> this something you can do by confuguiring your cut&paste?
Could do, but since . is a useful filename character it usually seems
like a good idea to include it in the set of characters considered a
`word' by the terminal double-click logic. I've not used xterm for
ages, but a quick check shows that Eterm isn't smart enough to be told
that . followed by a word-constituent is good and should be included in
a word, whereas a trailing . is a different thing which it doesn't want
to include.
So I'm in favour of killing the full-stops. Sorry. :-(
-- [mdw]
^ permalink raw reply
* git-rev-list feature request
From: Paul Mackerras @ 2006-03-10 1:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi,
I'd like to implement a new features in gitk to enable it to show the
relationship of a given commit to the tags and other references. What
I would like is for git-rev-list to be able to output a dense graph
containing only one or more specified commits plus all the commits
that have a reference (i.e. a file under $GIT_DIR/refs that contains
their SHA1 ID), plus the merges that are needed to complete the
graph.
It would be nice also to be able to combine that with the existing
ability to output a dense graph containing the commits that modify a
specified set of files or directories.
In other words, I would like to be able to select any combination of
(a) some explicitly specified commits
(b) commits that have a reference
(c) commits that affect specified files or directories
and have git-rev-list output a graph that shows the relationship of
those commits.
Possible?
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH] allow double click on current HEAD id after git-pull
From: Petr Baudis @ 2006-03-10 1:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Olaf Hering, git
In-Reply-To: <7vy7zj2oom.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Mar 10, 2006 at 12:17:29AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Well I kind of like ending a sentence with a full stop. Isn't
> this something you can do by confuguiring your cut&paste?
I wouldn't think cut'n'paste is usually that flexible and/or easy to
configure.
> But I do not have a _very_ strong feeling either way. If
> majority of the list wants it that way I do not mind.
Being able to easily cut'n'paste is IMHO an important usability thing,
and with that long sha1s, who's going to notice a missing fullstop far
at the right? ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: git-rev-list feature request
From: Linus Torvalds @ 2006-03-10 3:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <17424.53563.622642.738307@cargo.ozlabs.ibm.com>
On Fri, 10 Mar 2006, Paul Mackerras wrote:
>
> It would be nice also to be able to combine that with the existing
> ability to output a dense graph containing the commits that modify a
> specified set of files or directories.
>
> In other words, I would like to be able to select any combination of
> (a) some explicitly specified commits
> (b) commits that have a reference
> (c) commits that affect specified files or directories
>
> and have git-rev-list output a graph that shows the relationship of
> those commits.
>
> Possible?
Yeah. I _think_ what you want is
- phase 1: generate the current graph that we already do for
git-rev-list --all ^cmit
- phase 2: start at "cmit", and mark everything that refers to it as
"show me" (including "cmit" itself, which was originally marked
uninteresting)
So phase 1 already exists and was the hard part. phase 2 is just walking
the graph (that is now all in memory) from "cmit" using the "object->refs"
reverse references that got built up during phase 1.
The only question is how to show the ref-names, or, more properly, what to
do when we have a ref-name, but the commit it points to wasn't interesting
because it didn't change the set of files we used to determine interest...
And where to find the sucker^H^H^H^H^H^Hhelpful soul to actually do the
work.
Linus
^ permalink raw reply
* Re: git-rev-list feature request
From: Junio C Hamano @ 2006-03-10 4:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, git
In-Reply-To: <Pine.LNX.4.64.0603091950360.18022@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> So phase 1 already exists and was the hard part. phase 2 is just walking
> the graph (that is now all in memory) from "cmit" using the "object->refs"
> reverse references that got built up during phase 1.
Eh,... what reverse references???
^ permalink raw reply
* Re: git-rev-list feature request
From: Linus Torvalds @ 2006-03-10 4:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7vhd663owv.fsf@assigned-by-dhcp.cox.net>
On Thu, 9 Mar 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > So phase 1 already exists and was the hard part. phase 2 is just walking
> > the graph (that is now all in memory) from "cmit" using the "object->refs"
> > reverse references that got built up during phase 1.
>
> Eh,... what reverse references???
Heh. Exercise left to the reader. Right now we do only forward references
(and rev-list.c actually turns that off, since it has no use for them).
But doing reverse refs should be easy - in the same place we do the
forward ones. I'd suggest making "track_object_refs == -1" mean "reverse
refs".
(I think the only thing that uses forwards refs is fsck. Nobody else wants
them, or would prefer the reverse kind - since forwards refs you can
just look up yourself anyway).
Linus
^ permalink raw reply
* Re: git-rev-list feature request
From: Paul Mackerras @ 2006-03-10 4:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0603091950360.18022@g5.osdl.org>
Linus Torvalds writes:
> Yeah. I _think_ what you want is
>
> - phase 1: generate the current graph that we already do for
>
> git-rev-list --all ^cmit
>
> - phase 2: start at "cmit", and mark everything that refers to it as
> "show me" (including "cmit" itself, which was originally marked
> uninteresting)
I'm not sure if that's what I want. Is that how "git-rev-list -- foo"
works?
What I want is basically just what "git-rev-list -- foo" does, but
with some extra flexibility in choosing what commits are interesting -
that is, to be able to say that a commit is interesting if it affects
some file, has a reference under .git/refs, or if it is one of a set
of specified commits.
Paul.
^ permalink raw reply
* [PATCH] Document the --attach flag.
From: Mike McCormack @ 2006-03-10 4:47 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 108 bytes --]
---
Documentation/git-format-patch.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
[-- Attachment #2: 2dbe606be2d9fadb7d8e84f5fed0d1c4a34377b7.diff --]
[-- Type: text/x-patch, Size: 711 bytes --]
2dbe606be2d9fadb7d8e84f5fed0d1c4a34377b7
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 7c467c5..bc85a62 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,7 +9,7 @@ git-format-patch - Prepare patches for e
SYNOPSIS
--------
[verse]
-'git-format-patch' [-n | -k] [-o <dir> | --stdout] [-s] [-c]
+'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [-s] [-c]
[--diff-options] <his> [<mine>]
DESCRIPTION
@@ -60,6 +60,9 @@ OPTIONS
standard output, instead of saving them into a file per
patch and implies --mbox.
+--attach::
+ Create attachments instead of inlining patches.
+
EXAMPLES
--------
^ permalink raw reply related
* [PATCH] Describe how to add extra mail header lines in mail generated by git-format-patch.
From: Mike McCormack @ 2006-03-10 4:47 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 112 bytes --]
---
Documentation/git-format-patch.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
[-- Attachment #2: 38fb623a9fe06cb56f96ee1f25a64d576372f997.diff --]
[-- Type: text/x-patch, Size: 547 bytes --]
38fb623a9fe06cb56f96ee1f25a64d576372f997
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index bc85a62..7cc7faf 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -64,6 +64,15 @@ OPTIONS
Create attachments instead of inlining patches.
+CONFIGURATION
+-------------
+You can specify extra mail header lines to be added to each
+message in the repository configuration as follows:
+
+[format]
+ headers = "Organization: git-foo\n"
+
+
EXAMPLES
--------
^ permalink raw reply related
* Re: [PATCH] Add git-imap-send.
From: Mike McCormack @ 2006-03-10 4:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacbz7vod.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>>[imap]
>> Host = imap.server.com
>> User = bob
>> Password = pwd
>> Port = 143
>
> These I am not so sure. It _might_ make sense to have something
> like this under $HOME/. Isn't there an established convention
> for storing something like this for existing MUAs?
It seems better to keep all the configuration in the same place. It's
possible (although unlikely) that somebody uses two different IMAP
servers to send mail... maybe one for work and one for play?
I think it would also be good to be able to specify these as command
line options, as some people might be uncomfortable with having their
password in a file (though it would be better to use an ssh tunnel).
>>+ * As a special exception, mbsync may be linked with the OpenSSL library,
>>+ * despite that library's more restrictive license.
> Hmmm.
I'll remove this, and all the SSL specific code, as it also complicates
the Makefile and adds an extra dependency.
I've fixed all the other issues you pointed out, and will resend the patch.
Mike
^ permalink raw reply
* git-applymbox fails to extract patch.
From: Dave Jones @ 2006-03-10 5:04 UTC (permalink / raw)
To: git
Since my munged versions of Linus' original apply-mbox scripts
no longer work on current git, I figured I'd try and use the
ones provided with it.
I'm totally confused as to what's going on here.
Here's what I'm trying to apply..
http://userweb.kernel.org/~davej/mbox.txt
And here's what happens..
(04:59:42:davej@hera:cpufreq)$ git-applymbox -k ~/Mail/mbox
1 patch(es) to process.
Applying ''
fatal: No changes
What am I missing ?
Dave
^ permalink raw reply
* Re: git-rev-list feature request
From: Linus Torvalds @ 2006-03-10 5:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <17425.1459.786864.172060@cargo.ozlabs.ibm.com>
On Fri, 10 Mar 2006, Paul Mackerras wrote:
> Linus Torvalds writes:
>
> > Yeah. I _think_ what you want is
> >
> > - phase 1: generate the current graph that we already do for
> >
> > git-rev-list --all ^cmit
> >
> > - phase 2: start at "cmit", and mark everything that refers to it as
> > "show me" (including "cmit" itself, which was originally marked
> > uninteresting)
>
> I'm not sure if that's what I want. Is that how "git-rev-list -- foo"
> works?
Nope. "git-rev-list -- foo" will just start from the heads given, and walk
down.
> What I want is basically just what "git-rev-list -- foo" does, but
> with some extra flexibility in choosing what commits are interesting -
> that is, to be able to say that a commit is interesting if it affects
> some file, has a reference under .git/refs, or if it is one of a set
> of specified commits.
Ahh, ok, you actually wanted something simpler than I thought you might.
What you want is (in its most trivial form) really trivial: mark the
special commits you want to save with TREECHANGE, so that they aren't
pruned by the logic that prunes off the "this commit doesn't change the
file, so ignore it" commits.
HOWEVER. That trivial thing has problems. What if the history got
simplified at a merge because one side of the merge changed it, and the
other one did not - in that case we'll follow the history down the leg
that didn't change (since that's the history that ended up being the final
one). Now, that means that we will totally prune out the other parent
info, and the commits you want to remain simply won't be "connected" any
more.
To explain that better, let's say that history looks like this:
a
/ \
b c
| |
d e
\ /
f
and you're following file "foo", which is the same in "a" and "c". The
fact that they are the same there means that the name pruning will decide
that the history that led to "a" through "b" wasn't interesting, so it
will prune that out, and make the whole history be
a
|
c
|
e
|
f
and then after that, it will remove all commits that didn't actually
change foo at all (we know "a" was such a commit since we already
simplified the merge, but let's say that "e" was one too), so you get
c
|
f
as the final simplified history right now.
Now, the problem is that what should you do if you want to tag "d" and "e"
as inherently interesting (perhaps because they are tagged releases)?
Now, the "e" case is the above trivial case: just mark any "inherently
interesting" commit with the TREECHANGE flag, and the history won't be
pruned away. So it now looks like
c
|
e <- faked "interesting"
|
f
however, the fact that you did the same to "d" means that we will have
that too on our list of "interesting" commits, even though we've pruned
away all of the history leading _from_ it, so the trivial algorithm would
actually result in
c
|
d e
\ /
f
in that case. We'd see "d" because it's somehow intrisically interesting,
but it ends up being shown as that "dead tip", because the merge that
would reach it was simplified away.
Is that what you'd want?
If so, then the appended trivial path should effectively do what you ask
for. It keeps all the revs you passed in as "interesting" whether they are
or not, so now you can effectively just pass in all the refs you want, and
it will never remove any of the positive refs you passed it.
If you want a commit that has a ref pointing to it be marked as
interesting only if we see it while parsing the tree, then you need to do
slightly more (in "rewrite_one()", you should look up whether that commit
has a ref pointing to it).
Linus
----
diff --git a/revision.c b/revision.c
index 713f27e..90d3764 100644
--- a/revision.c
+++ b/revision.c
@@ -149,7 +149,8 @@ static struct commit *get_commit_referen
if (flags & UNINTERESTING) {
mark_parents_uninteresting(commit);
revs->limited = 1;
- }
+ } else
+ object->flags |= TREECHANGE;
return commit;
}
^ permalink raw reply related
* Re: git-rev-list feature request
From: Linus Torvalds @ 2006-03-10 5:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0603092056300.18022@g5.osdl.org>
On Thu, 9 Mar 2006, Linus Torvalds wrote:
>
> Ahh, ok, you actually wanted something simpler than I thought you might.
Btw, what I _thought_ you migth want is to do the current "strong
pruning", and then look up - from the stuff left behind - which ones reach
to a ref or a tag. That's where the reverse refs would come in, and it
requires some fundamental surgery (but it shouldn't be hard at all).
Linus
^ permalink raw reply
* Re: git-applymbox fails to extract patch.
From: Linus Torvalds @ 2006-03-10 5:35 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20060310050446.GA20764@redhat.com>
On Fri, 10 Mar 2006, Dave Jones wrote:
>
> What am I missing ?
Do you have "Content-Type:" headers with a multi-part boundary? That can
cause it.
Also, empty X-IMAP messages at the beginning of a mbox (pine does those,
others probably do too) will cause things like that. The extra "email"
will have no patch in it..
Linus
^ 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