* Re: [PATCH] Make use of stat.ctime configurable
From: Junio C Hamano @ 2008-07-27 19:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, Linus Torvalds, Johannes Sixt, git
In-Reply-To: <20080726153802.GA16868@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> because there are situations where it produces too much false
> positives. Like when file system crawlers keep changing it when
> scanning and using the ctime for marking scanned files.
This justification is good and I am very inclined to advocate for its
inclusion in 1.6.0, but any new configuration needs to be in the
documentation.
It appears there is "gui.trustmtime"; shouldn't this be called
"core.trustctime" or something?
^ permalink raw reply
* Re: [PATCH 2/7] builtin-help: change the current directory back in list_commands_in_dir()
From: Junio C Hamano @ 2008-07-27 20:02 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <4f2b03391e3f85cf2224f97a2a7765d08707bd73.1217037178.git.vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> That function used to do a chdir() without switching back to the
> original directory. That was not a problem till this function was used
> only inside builtin-help, but once other builtins use it as well, this
> is a problem, for example when the object database path is relative.
Why does it even need to chdir() around to begin with? Doesn't opendir()
work just fine with relative path as an input?
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Sverre Rabbelier @ 2008-07-27 20:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Junio C Hamano, Scott Chacon, git
In-Reply-To: <alpine.DEB.1.00.0807271744180.5526@eeepc-johanness>
On Sun, Jul 27, 2008 at 17:53, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Maybe I should start my mails with "Disclaimer: I only reply to you
> because I am interested in your patch."
That might actually be a good idea, maybe add it as your signature ;). *ducks*
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Cleaning up log messages
From: Johannes Schindelin @ 2008-07-27 20:16 UTC (permalink / raw)
To: Jon Smirl; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <9e4733910807271231s7ff6acf8rf5848cc1a31f3afc@mail.gmail.com>
Hi,
On Sun, 27 Jul 2008, Jon Smirl wrote:
> How do you do it with git log? --pretty overrides the default of medium
>
> --pretty[=<format>]
>
> Pretty-print the contents of the commit logs in a given format,
> where <format> can be one of oneline, short, medium, full, fuller,
> email, raw and format:<string>. When omitted, the format defaults to
> medium.
You get it _almost_ with
$ f='commit %H%nAuthor: %aN <%ae>%nDate: %ad%n%n%s%n%n%b'
$ git log --pretty="format:$f"
The only difference being that the commit message is not indented. If you
really need that, it is easy to add.
But I rather doubt that you need it, as you want to make statistics, and
therefore need to pipe the output into a script anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/7] builtin-help: change the current directory back in list_commands_in_dir()
From: Johannes Schindelin @ 2008-07-27 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vwsj7yu1q.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 27 Jul 2008, Junio C Hamano wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > That function used to do a chdir() without switching back to the
> > original directory. That was not a problem till this function was used
> > only inside builtin-help, but once other builtins use it as well, this
> > is a problem, for example when the object database path is relative.
>
> Why does it even need to chdir() around to begin with? Doesn't
> opendir() work just fine with relative path as an input?
It is a consequence of list_commands_in_dir() trying to be cute, and not
having to construct the full path for the is_executable() check.
Will post a fix in a few minutes.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Avoid chdir() in list_commands_in_dir()
From: Johannes Schindelin @ 2008-07-27 20:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <alpine.DEB.1.00.0807272219350.5526@eeepc-johanness>
The function list_commands_in_dir() tried to be lazy and just chdir()
to the directory which entries it listed, so that the check if the
file is executable could be done on dir->d_name.
However, there is no good reason to jump around wildly just to find
all Git commands.
Instead, have a strbuf and construct the full path dynamically.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
help.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/help.c b/help.c
index 480befe..7af6582 100644
--- a/help.c
+++ b/help.c
@@ -426,17 +426,24 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
int prefix_len = strlen(prefix);
DIR *dir = opendir(path);
struct dirent *de;
+ struct strbuf buf = STRBUF_INIT;
+ int len;
- if (!dir || chdir(path))
+ if (!dir)
return 0;
+ strbuf_addf(&buf, "%s/", path);
+ len = buf.len;
+
while ((de = readdir(dir)) != NULL) {
int entlen;
if (prefixcmp(de->d_name, prefix))
continue;
- if (!is_executable(de->d_name))
+ strbuf_setlen(&buf, len);
+ strbuf_addstr(&buf, de->d_name);
+ if (!is_executable(buf.buf))
continue;
entlen = strlen(de->d_name) - prefix_len;
@@ -449,6 +456,7 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
add_cmdname(cmds, de->d_name + prefix_len, entlen);
}
closedir(dir);
+ strbuf_release(&buf);
return longest;
}
--
1.6.0.rc0.97.ge2309
^ permalink raw reply related
* Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Johannes Schindelin @ 2008-07-27 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git, Miklos Vajna
In-Reply-To: <7vljzn2o51.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 27 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > BTW I seem to recall that get_merge_bases_many() was _not_ the same as
> > get_merge_octopus(). Could you please remind me what _many() does?
>
> I explained what merge-bases-many gives in a separate message last night
> with pictures.
I missed that, alright.
> get_merge_octopus() is a more or less useless function. It is there
> only because the protocol between "merge" and strategies requires that
> the former have to pass _some_ bases to the latter.
Does it? I thought that e.g. merge-recursive accepts an empty set of
merge bases? AFAIR that was the reason why gitk could be merged so well.
> In fact, the octopus strategy implementation completely ignores the
> heads given by "merge"; a single set of merge base given from outside is
> not even useful when you build octopus by repeatedly running pairwise
> three-way merges.
>
> With Christian's git-merge-base enhancement, the big comment at the end
> of git-merge-octopus's main loop can go with a much improved "next"
> merge base computation.
Okay.
Ciao,
Dscho
^ permalink raw reply
* Re* [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Junio C Hamano @ 2008-07-27 20:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Christian Couder, git, Miklos Vajna
In-Reply-To: <7vljzn2o51.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> BTW I seem to recall that get_merge_bases_many() was _not_ the same as
>> get_merge_octopus(). Could you please remind me what _many() does?
>
> I explained what merge-bases-many gives in a separate message last night
> with pictures.
>
> get_merge_octopus() is a more or less useless function. It is there only
> because the protocol between "merge" and strategies requires that the
> former have to pass _some_ bases to the latter. In fact, the octopus
> strategy implementation completely ignores the heads given by "merge";
> a single set of merge base given from outside is not even useful when you
> build octopus by repeatedly running pairwise three-way merges.
This part may benefit from a bit of clarification, so I'll borrow the
picture from my other message.
o---o---o---o---C
/
/ o---o---o---B
/ /
---1---2---o---o---o---A
Suppose you have this topology, and you are trying to make an octopus
across A, B and C (you are at C and merging A and B into your branch).
The protoccol between "git merge" and merge strategies is for the former
to pass common ancestor(s), '--' and then commits being merged.
I think "merge", both in scripted version and Miklos's C version, gives
"1" because that is the common across all the heads. This choice of merge
base in itself is correct (that is why I said that git_merge_octopus() is
"more or less useless", not "totally pointless"). If an implementation of
strategy that is capable of producing an octopus wanted to merge arbitrary
number of trees using a single merge base in one-go, that is the merge
base it would want to use.
HOWEVER.
The particular implementation of git-merge-octopus does not produce the
final merge in one-go. It iteratively produces pairwise merges. So the
first step might be to come up with a merge between B and C:
o---o---o---o---C
/ :
/ o---o---o---B..(M)
/ /
---1---2---o---o---o---A
and for that, "1" is used as the merge base, not because it is the base
across A, B and C but because it is the base between B and C. For this
merge, A does not matter.
I drew M in parentheses and lines between B and C to it in dotted line
because we actually do _not_ create a real commit --- the only thing we
need is a tree object, in order to proceed to the next step.
Then the final merge result is obtained by merging tree of (M) and A using
their common ancestor. For that, we _could_ still use "1" as the merge
base.
But if you imagine a case where you started from A and M, you would _not_
pick "1" as the merge base; you would rather use "2" which is a better
base for this merge.
That is why git-merge-octopus ignores the merge base given by "merge" but
computes its own.
Side note. If your first step merge is between A and B, then you
would also use "2" as the merge base.
o---o---o---o---C
/
/ o---o---o---B..(M)
/ / :
---1---2---o---o---o---A
The comment at the end of git-merge-octopus talks about "merge reference
commit", that we used to update it to common found in this round, and that
that updating was pointless. After the first round of merge to produce
the tree for M (but without actually creating the commit object M itself),
in order to figure out the merge base used to merge that with A in the
second round, we used to use A and "1" (which was merge base between B and
C). That was pointless --- "merge-base A 1" is guaranteed to give a base
that is no better than either "merge-base A B" or "merge-base A C". So
the current code keeps using the original head (iow, MRC=Ci, because n
this case we are starting from C and merging B and then A into it).
This trickerly was necessary only because we avoided creating the extra
merge commit object M.
Side note. An alternative implementation could have been to
actually record it as a real merge commit M, and then let the
two-commit merge-base compute the base between A and M when
merging A to the result of the previous round, but we avoided
creating M, at the expense of potentially using suboptimal base in
the later rounds.
But we do not have to be that pessimistic. We can instead accumulate the
commits we have merged so far in MRC, and have merge_bases_many() compute
the merge base for the new head being merged and the heads we have
processed so far, which can give a better base than what we currently do.
That is what Christian's patch enables us to do.
In other words, we can do something like this.
git-merge-octopus.sh | 11 ++---------
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh
index 645e114..1dadbb4 100755
--- a/git-merge-octopus.sh
+++ b/git-merge-octopus.sh
@@ -61,7 +61,7 @@ do
exit 2
esac
- common=$(git merge-base --all $MRC $SHA1) ||
+ common=$(git merge-base --all $SHA1 $MRC) ||
die "Unable to find common commit with $SHA1"
case "$LF$common$LF" in
@@ -100,14 +100,7 @@ do
next=$(git write-tree 2>/dev/null)
fi
- # We have merged the other branch successfully. Ideally
- # we could implement OR'ed heads in merge-base, and keep
- # a list of commits we have merged so far in MRC to feed
- # them to merge-base, but we approximate it by keep using
- # the current MRC. We used to update it to $common, which
- # was incorrectly doing AND'ed merge-base here, which was
- # unneeded.
-
+ MRC="$MRC $SHA1"
MRT=$next
done
^ permalink raw reply related
* Re: Cleaning up log messages
From: Jon Smirl @ 2008-07-27 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vsktv17wc.fsf@gitster.siamese.dyndns.org>
On 7/27/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Jon Smirl" <jonsmirl@gmail.com> writes:
>
> > I was playing around with git log for the kernel and observed that
> > there is a lot of noise when trying to do statistics on the number of
> > commits.
> >
> > For example:
> >
> > Author: Greg K-H <gregkh@suse.de>
> > Author: Greg KH <gregkh@suse.de>
> > ...
>
> > Author: Greg Kroah-Hartman <greg@kroah.com>
>
>
> We have had .mailmap since a24e658 (git-shortlog: make the mailmap
> configurable., 2005-10-06); maybe the kernel tree wants a maintainer for
> the .mailmap file?
This seems to be the main problem. There are so many missing entries
from the .mailmap file that I didn't think this feature was
implemented. I'd guestimate that 300-400 needed entries are missing.
I've made a few attempts at writing a script to fix the easy ones but
I don't have a good solution yet.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 1/3] git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
From: Shawn O. Pearce @ 2008-07-27 21:24 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Johannes Sixt
In-Reply-To: <1217177383-25272-2-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> The new execdir has is two levels below the root directory, while
> the old execdir 'bin' was only one level below. This commit
> adapts the discovery of oguilib that uses relative paths
> accordingly.
...
> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
> index 940677c..baccd57 100755
> --- a/git-gui/git-gui.sh
> +++ b/git-gui/git-gui.sh
> @@ -52,7 +52,9 @@ catch {rename send {}} ; # What an evil concept...
> set oguilib {@@GITGUI_LIBDIR@@}
> set oguirel {@@GITGUI_RELATIVE@@}
> if {$oguirel eq {1}} {
> - set oguilib [file dirname [file dirname [file normalize $argv0]]]
> + set oguilib [file dirname \
> + [file dirname \
> + [file dirname [file normalize $argv0]]]]
> set oguilib [file join $oguilib share git-gui lib]
Hmmph. This actually comes up incorrectly on my system. The issue
appears to be `git --exec-path` gives me $prefix/libexec/git-core,
and git-gui installs its library into $prefix/libexec/share, which
is wrong. It should have gone to $prefix/share.
I wonder if this is better. Your other two patches seem fine.
--8<--
[PATCH] git-gui: Correct installation of library to be $prefix/share
We always wanted the library for git-gui to install into the
$prefix/share directory, not $prefix/libexec/share. All of
the files in our library are platform independent and may
be reused across systems, like any other content stored in
the share directory.
Our computation of where our library should install to was broken
when git itself started installing to $prefix/libexec/git-core,
which was one level down from where we expected it to be.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Makefile | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index b19fb2d..f72ab6c 100644
--- a/Makefile
+++ b/Makefile
@@ -32,6 +32,9 @@ endif
ifndef gitexecdir
gitexecdir := $(shell git --exec-path)
endif
+ifeq (git-core,$(notdir $(gitexecdir)))
+ gitexecdir := $(patsubst %/,%,$(dir $(gitexecdir)))
+endif
ifndef sharedir
sharedir := $(dir $(gitexecdir))share
--
1.6.0.rc0.182.gb96c7
--
Shawn.
^ permalink raw reply related
* Re: git-scm.com
From: Junio C Hamano @ 2008-07-27 22:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: Scott Chacon, git
In-Reply-To: <7v3alv2n46.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Petr Baudis <pasky@suse.cz> writes:
> ...
>> The point here is that the list is awfully long and also can contain
>> a lot of duplicates or people with broken unicode, etc. - it gets hard
>> to maintain, and it makes the about page too long. I would be of course
>> fine with a tiny link at the bottom "(show all contributors)".
>
> Your "incentive to move up" argument suggests otherwise. Even if it takes
> efforts to maintain on somebody's part, it is worth to be inclusive, *IF*
> the purpose of that bottom list is to give credits to people.
>
> The list on the site originally was not utilizing .mailmap and I asked
> Scott to use it to merge duplicate entries, which he did. People whose
> names are misspelled and/or split will now have incentive to tell Scott
> about the problem so that they can clean up *their* own names, and Scott
> can help maintaining .mailmap and feed the changes to me.
>
> This is my ulterior motive behind this suggestion; I can outsource the
> maintenance of .mailmap to people who care about it more than myself.
By the way, earlier Scott gave as explanation why he and others around
GitHub, people who are not very visible on this list, are not interacting
with us very much --- because they are not "C coders".
But maintenance of .mailmap (and Documentation/ area, too, of course) is a
good example of how involvement from non "C coders" would be a helpful and
healthy thing to have in the development process, and why we do not want
to fracture the user community in two.
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Roman Zippel @ 2008-07-27 23:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807271144520.3486@nehalem.linux-foundation.org>
Hi,
On Sun, 27 Jul 2008, Linus Torvalds wrote:
> > > > Is there a way to change that default?
> > >
> > > Use an alias or something.
> >
> > This doesn't help with the graphical front ends and they only use what git
> > gives them.
>
> And the graphical front-ends is exactly why --full-history cannot be the
> default.
If you mean current gitk style --full-history I agree, the problem is
still that git is hiding too much history with the simplified history...
> > Let's take a different example.
>
> No, let's not.
>
> Unless you can solve that _one_ example efficiently, nothing else matters.
>
> The above example is all you ever need. Make that one work right (and
> efficiently), and everything is fine.
>
> And no, some random ruby code doesn't make any difference what-so-ever.
> There are efficiency constraints here that make any ruby solution be
> unrealistic to begin with.
Why are you dismissing what I wrote without even giving it a second
thought? I didn't bother with the initial example, because it's so
simple, that it's no real challenge.
Did I say anywhere it had to be done in ruby? All I tried was to
demonstrate a possible algorithm to solve the problem. I did time the
execution and compared to the time it took to extract the history it
wasn't significant for such a simple script.
What did I do wrong that you rebuff me based on this secondary problem
(which I'm quite aware of, because it was me who mentioned in first place)
and giving the primary problem (which is the missing history) no
attention?
If you had any questions, I'd be happy to answer them. If you think that
the demonstrated algorithm doesn't work, I'd be glad to know why. If the
algorithm might work, any hint what could be do done to try it for real,
would be great. But I don't get any of this. Why?
bye, Roman
^ permalink raw reply
* Re: git-scm.com
From: Martin Langhoff @ 2008-07-27 23:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Scott Chacon, git
In-Reply-To: <7vd4kzyoj1.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 10:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
> By the way, earlier Scott gave as explanation why he and others around
> GitHub, people who are not very visible on this list, are not interacting
> with us very much --- because they are not "C coders".
Well, I'm not a C coder either ;-) -- plenty of the large contributors
do their work in Perl Python and shell. Granted, I am not very active
lately, but that's because I'm busy on non-git-related (but
git-using!) projects.
And the choice of language has nothing to do with helping people
around. If they care about getting recommendations from list regulars,
anyway. Maintaining a great user-facing website might be their way of
engaging and interacting with us.
cheers,
martin
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-27 23:18 UTC (permalink / raw)
To: Roman Zippel; +Cc: Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807272101470.6791@localhost.localdomain>
On Mon, 28 Jul 2008, Roman Zippel wrote:
>
> Why are you dismissing what I wrote without even giving it a second
> thought? I didn't bother with the initial example, because it's so
> simple, that it's no real challenge.
Did you try it? It really shouldn't be any simpler than anything else. And
I dismissed what you wrote because the example you _did_ state was about
something else entirely (ie apparently some giggle bug that simplifies
things incorrectly).
> What did I do wrong that you rebuff me based on this secondary problem
> (which I'm quite aware of, because it was me who mentioned in first place)
> and giving the primary problem (which is the missing history) no
> attention?
It's not missing history. It's all there in --full-history. The default is
to give a reasonable simplification, and I told you what the
simplification was, and it's perfectly conceptually fine - AND IT IS MUCH
MORE EFFICIENT than the alternatives.
So I'm not seeing your point what-so-ever.
My point is:
- with full-history, you have it all, but it's useless in practice
- without full-history, it's useful in practice
You never gave any examples otherwise.
Linus
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Martin Langhoff @ 2008-07-27 23:25 UTC (permalink / raw)
To: Roman Zippel; +Cc: Linus Torvalds, Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807272101470.6791@localhost.localdomain>
On Mon, Jul 28, 2008 at 11:14 AM, Roman Zippel <zippel@linux-m68k.org> wrote:
> Why are you dismissing what I wrote without even giving it a second
> thought? I didn't bother with the initial example, because it's so
> simple, that it's no real challenge.
I can't speak for anyone else, but you do have to keep in mind that a
solution to this has to be rather fast - and I mean fast in git terms,
not in scripting-language-fast terms.
That you can do it Ruby - and I may be able to do it Perl - has little
bearing on what can be done inside the git log machinery with a small
performance penalty.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Roman Zippel @ 2008-07-28 0:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807271613440.3486@nehalem.linux-foundation.org>
Hi,
On Sun, 27 Jul 2008, Linus Torvalds wrote:
> > Why are you dismissing what I wrote without even giving it a second
> > thought? I didn't bother with the initial example, because it's so
> > simple, that it's no real challenge.
>
> Did you try it? It really shouldn't be any simpler than anything else. And
Of course I did:
$ git log --parents --name-only --full-history lib/vsprintf.c | grep -e ^commit | wc -l
5929
This is same amount of commits as for gitk.
$ /usr/bin/time git log --parents --name-only --full-history lib/vsprintf.c | grep -e ^commit -e ^lib | /usr/bin/time ruby ../filter.rb
3.08user 0.14system 0:03.54elapsed 91%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+48230minor)pagefaults 0swaps
20
["72fd4a35a824331d7a0f4168d7576502d95d34b3", ["0a6047eef1c465c38aacfbdab193161b3f0cd144"]]
["06b2a76d25d3cfbd14680021c1d356c91be6904e", ["96e3e18eed3b48f6d4377dee0326a106e8a04569"]]
["1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", []]
["e905914f96e11862b130dd229f73045dad9a34e8", ["f796937a062c7aeb44cd0e75e1586c8543634a7d"]]
["4e57b6817880946a3a78d5d8cad1ace363f7e449", ["8032230694ec56c168a1404c67a54d281536cbed"]]
["4f9d5f4a353440f2265781bfa641587964901861", ["9b706aee7d92d6ac3002547aea12e3eaa0a750ae"]]
["0a6047eef1c465c38aacfbdab193161b3f0cd144", ["e905914f96e11862b130dd229f73045dad9a34e8"]]
["c6b40d16d1cfa1a01158049bb887a9bbe48ef7ba", ["11443ec7d9286dd25663516436a14edfb5f43857"]]
["ea6f3281a145d16ed53e88b0627f78d5cde6068f", ["72fd4a35a824331d7a0f4168d7576502d95d34b3"]]
["11443ec7d9286dd25663516436a14edfb5f43857", ["ea6f3281a145d16ed53e88b0627f78d5cde6068f"]]
["b39a734097d5095d63eb9c709a6aaf965633bb01", ["c6b40d16d1cfa1a01158049bb887a9bbe48ef7ba"]]
["78a8bf69b32980879975f7e31d30386c50bfe851", ["0f9bfa569d46f2346a53a940b2b9e49a38635732"]]
["4d8a743cdd2690c0bc8d1b8cbd02cffb1ead849f", ["78a8bf69b32980879975f7e31d30386c50bfe851"]]
["0fe1ef24f7bd0020f29ffe287dfdb9ead33ca0b2", ["4d8a743cdd2690c0bc8d1b8cbd02cffb1ead849f"]]
["9b706aee7d92d6ac3002547aea12e3eaa0a750ae", ["06b2a76d25d3cfbd14680021c1d356c91be6904e"]]
["0f9bfa569d46f2346a53a940b2b9e49a38635732", ["4f9d5f4a353440f2265781bfa641587964901861"]]
["4277eedd7908a0ca8b66fad46ee76b0ad96e6ef2", ["b39a734097d5095d63eb9c709a6aaf965633bb01"]]
["8032230694ec56c168a1404c67a54d281536cbed", ["1da177e4c3f41524e886b7f1b8a0c1fc7321cac2"]]
["f796937a062c7aeb44cd0e75e1586c8543634a7d", ["4e57b6817880946a3a78d5d8cad1ace363f7e449"]]
["96e3e18eed3b48f6d4377dee0326a106e8a04569", ["4277eedd7908a0ca8b66fad46ee76b0ad96e6ef2"]]
0.12user 0.02system 0:03.64elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+7252minor)pagefaults 0swaps
These are the same 20 commits (with parents) from a simple git-log.
> I dismissed what you wrote because the example you _did_ state was about
> something else entirely (ie apparently some giggle bug that simplifies
> things incorrectly).
I'm trying to get back things to the topic and it's not just giggle, every
tool presents a different version of the history.
> > What did I do wrong that you rebuff me based on this secondary problem
> > (which I'm quite aware of, because it was me who mentioned in first place)
> > and giving the primary problem (which is the missing history) no
> > attention?
>
> It's not missing history. It's all there in --full-history. The default is
> to give a reasonable simplification, and I told you what the
> simplification was, and it's perfectly conceptually fine - AND IT IS MUCH
> MORE EFFICIENT than the alternatives.
>
> So I'm not seeing your point what-so-ever.
That's why I gave you an alternative example, where history is missing.
> - with full-history, you have it all, but it's useless in practice
Could you please specify which full-history you mean, gitk --full-history
or git-log --full-history?
> - without full-history, it's useful in practice
>From a VCS I would still expect nevertheless to present a correct
history not some approximation.
bye, Roman
^ permalink raw reply
* GIT 1.6.0-rc1
From: Junio C Hamano @ 2008-07-28 0:09 UTC (permalink / raw)
To: git
Ok, so I tagged and pushed it out. There still is the "git mv" bugfix
from Pasky that is parked in 'next' but other than that I think this is
pretty much "it" for 1.6.0 feature-wise.
Major parts of the changes since 1.6.0-rc0 consists of documentation and
tests portability; there is nothing surprising nor scary.
Test tarballs and RPMs are also there. Please give it a good beating.
----------------------------------------------------------------
Changes since v1.6.0-rc0 are as follows:
Abhijit Menon-Sen (2):
git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
Clarify that "git log x.c y.h" lists commits that touch either file
Alex Riesen (1):
Allow pager of diff command be enabled/disabled
Alexander Gavrilov (4):
Fix pre-commit hooks under MinGW/MSYS
Add options to control the search for copies in blame.
Kill the blame back-end on window close.
Add a menu item to invoke full copy detection in blame.
Anders Melchiorsen (1):
Documentation: fix diff.external example
Björn Steinbrink (2):
index-pack.c: correctly initialize appended objects
rev-parse: Add support for the ^! and ^@ syntax
Brad King (1):
git-svn: teach dcommit about svn auto-props
Brandon Casey (7):
t/: Replace diff [-u|-U0] with test_cmp to allow compilation with old diff
t4116-apply-reverse.sh: use $TAR rather than tar
t3200,t7201: replace '!' with test_must_fail
t7502-commit.sh: rearrange test to make more portable
t/t4202-log.sh: add newline at end of file
Teach fsck and prune about the new location of temporary objects
perl/Makefile: update NO_PERL_MAKEMAKER section
Cesar Eduardo Barros (1):
Documentation/git-submodule.txt: fix doubled word
Daniel Barkalow (1):
In perforce, RCS keywords are case-sensitive
Jakub Narebski (1):
gitweb: More about how gitweb gets 'owner' of repository
Johannes Schindelin (9):
Rename .git/rebase to .git/rebase-apply
Rename path_list to string_list
Fix two leftovers from path_list->string_list
Ignore dirty submodule states in "git pull --rebase"
Add test to show that show-branch misses out the 8th column
sort_in_topological_order(): avoid setting a commit flag
builtin-commit: Two trivial style-cleanups
git daemon: avoid waking up too often
Avoid chdir() in list_commands_in_dir()
Johannes Sixt (12):
rebase -i: When an 'edit' stops, mention the commit
Makefile: Do not install a copy of 'git' in $(gitexecdir)
Makefile: Normalize $(bindir) and $(gitexecdir) before comparing
Record the command invocation path early
Fix relative built-in paths to be relative to the command invocation
Allow the built-in exec path to be relative to the command invocation path
Allow add_path() to add non-existent directories to the path
Windows: Make $(gitexecdir) relative
Windows: Make sure argv[0] has a path
Windows: Do not compile git-shell
git-gui: Fix "Stage/Unstage Line" with one line of context.
git-gui: "Stage Line": Treat independent changes in adjacent lines better
Jonathan Nieder (3):
git-diff(1): "--c" -> "--cc" typo fix
document that git-tag can tag more than heads
t6030 (bisect): work around Mac OS X "ls"
Junio C Hamano (13):
Update my e-mail address
Revert "make git-status use a pager"
tests: do not rely on external "patch"
stash save: fix parameter handling
builtin-branch.c: remove unused code in append_ref() callback function
builtin-branch.c: optimize --merged and --no-merged
Documentation: clarify diff --cc
ignore non-existent refs in dwim_log()
tests: propagate $(TAR) down from the toplevel Makefile
Makefile: fix shell quoting
Documentation: clarify how to disable elements in core.whitespace
make sure parsed wildcard refspec ends with slash
GIT 1.6.0-rc1
Lars Hjemli (3):
builtin-branch: remove duplicated code
builtin-branch: factor out merge_filter matching
builtin-branch: fix -v for --[no-]merged
Lee Marlow (2):
bash completion: Add long options for 'git rm'
bash completion: Add completion for 'git help'
Miklos Vajna (2):
builtin-merge: give a proper error message for invalid strategies in config
t7601: extend the 'merge picks up the best result' test
Nikolaj Schumacher (1):
Don't cut off last character of commit descriptions.
Olivier Marin (4):
git-am: remove dash from help message
parse-options: fix segmentation fault when a required value is missing
git am --skip: clean the index while preserving local changes
update test case to protect am --skip behaviour
P. Christeas (1):
svnimport: newer libsvn wants us to ask for the root with "", not "/"
Peter Valdemar Mørch (1):
send-email: find body-encoding correctly
Petr Baudis (4):
git-filter-branch.sh: Allow running in bare repositories
Documentation/git-filter-branch: teach "rm" instead of "update-index --remove"
git-mv: Remove dead code branch
git-mv: Keep moved index entries inact
Philippe Bruhat (1):
mailinfo: better parse email adresses containg parentheses
Pierre Habouzit (4):
builtin-merge: add missing structure initialization
git-submodule: move ill placed shift.
git-checkout: fix command line parsing.
git-checkout: improve error messages, detect ambiguities.
René Scharfe (5):
archive: add write_archive()
archive: move parameter parsing code to archive.c
archive: define MAX_ARGS where it's needed
archive: declare struct archiver where it's needed
archive: allow --exec and --remote without equal sign
SZEDER Gábor (2):
checkout: mention '--' in the docs
bash: offer only paths after '--' for 'git checkout'
Shawn O. Pearce (2):
git-gui: Correct 'Visualize Branches' on Mac OS X to start gitk
fsck: Don't require tmp_obj_ file names are 14 bytes in length
Stephan Beyer (7):
git-am: Add colon before the subject that is printed out as being applied
am --abort: Add to bash-completion and mention in git-rerere documentation
Make non-static functions, that may be static, static
Move launch_editor() from builtin-tag.c to editor.c
editor.c: Libify launch_editor()
git-am: Mention --abort in usage string part of OPTIONS_SPEC
git-reset: Let -q hush "locally modified" messages
Steve Haslam (2):
Propagate -u/--upload-pack option of "git clone" to transport.
Remove references to git-fetch-pack from "git clone" documentation.
Thomas Rast (2):
git-completion.bash: provide completion for 'show-branch'
bash completion: Add long options for 'git describe'
^ permalink raw reply
* Re: [PATCH 1/9] Makefile: Do not install a copy of 'git' in $(gitexecdir)
From: A Large Angry SCM @ 2008-07-28 0:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <1216667998-8879-2-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt wrote:
[...]
>
> diff --git a/Makefile b/Makefile
> index 551bde9..cbab4f9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1335,6 +1335,7 @@ endif
> '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
> fi
> $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
> + $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'
> ifneq (,$X)
> $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
> endif
This new action needs to be in a conditional to keep it from removing
the ONLY git executable when bindir and execdir are the same dir.
^ permalink raw reply
* Update to "Peer Wire Guidelines" on GitTorrent RFC
From: Sam Vilain @ 2008-07-28 0:30 UTC (permalink / raw)
To: git; +Cc: gittorrent
During the development of GitTorrent, I was being asked questions that
led me to realise that there wasn't a very good overall view of how the
various proposed GitTorrent messages fit together to make fetches work.
So, I've written a whole lot more on this with a few paragraphs which I
hope will pull it all together. If you found the RFC previously
indigestable, try reading:
http://gittorrent.utsl.gen.nz/rfc.html#peer-wire-guidelines
If there are parts which still aren't clear, please ask questions and I
will aim to write more clarification to the specification.
Cheers!
Sam.
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Petr Baudis @ 2008-07-28 0:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy73myim5.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, Jul 27, 2008 at 05:09:38PM -0700, Junio C Hamano wrote:
> Ok, so I tagged and pushed it out. There still is the "git mv" bugfix
> from Pasky that is parked in 'next' but other than that I think this is
> pretty much "it" for 1.6.0 feature-wise.
BTW, it seems that in the end, the bugfix made it to -rc1's master.
(Which is cool. :-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] Documentation/git-ls-tree.txt: Add a caveat about prefixing pathspec
From: Petr Baudis @ 2008-07-28 0:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20080722224759.GJ32184@machine.or.cz>
On Wed, Jul 23, 2008 at 12:47:59AM +0200, Petr Baudis wrote:
> On Mon, Jul 21, 2008 at 05:32:20PM -0700, Junio C Hamano wrote:
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > >> commit. E.g.
> > >>
> > >> $ cd some/deep/path
> > >> $ git ls-tree --name-only -r HEAD~20
> > >>
> > >> will list the files in some/deep/path (i.e. where you are) 20
> > >> commits ago, just like running "/bin/ls" there will give you the
> > >> list of files you have right now.
> > >
> > > Frankly, I think this is overdoing it. I'm all for being positive, but
> > > it is obvious why this is good thing when you inspect a root tree and
> > > there's no need to be too wordy about it...
> >
> > I mildly disagree.
>
> We may throw a dice or go with your version, I don't care *that* much
> about this change, I just wouldn't make it personally.
What is the status of this patch? :-) Dropped altogether?
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] t/t7001-mv.sh: Propose ability to use git-mv on conflicting entries
From: Junio C Hamano @ 2008-07-28 1:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, gitster
In-Reply-To: <20080727134704.27534.86520.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> I don't really know if it is ok to make "feature requests" like this by
> adding failing testcases...
Of course it depends on who you are. It's not Ok for somebody like you,
who is known to be competent, and certainly it is not Ok to do it on a
command that you know you care more about than I do.
I've neglected builtin-mv.c since its introduction, mostly because I never
say "git mv" myself (in other words, I haven't cared very much how broken
it was. For one thing, its indentation style is peculiar and is hard to
read and maintain).
> +# Rationale: I cannot git mv around a conflicted file. This is unnecessary
> +# restriction in case another part of conflict resolution requires me to
> +# move the file around.
Yes, I would agree this is a reasonable thing to support. Something like
this patch, perhaps.
---
builtin-mv.c | 21 ++++++++++++++-------
t/t7001-mv.sh | 21 +++++++++++++++++++++
2 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/builtin-mv.c b/builtin-mv.c
index 4f65b5a..cc9e505 100644
--- a/builtin-mv.c
+++ b/builtin-mv.c
@@ -96,7 +96,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
/* Checking */
for (i = 0; i < argc; i++) {
const char *src = source[i], *dst = destination[i];
- int length, src_is_dir;
+ int length, src_is_dir, pos;
const char *bad = NULL;
if (show_only)
@@ -177,7 +177,8 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
} else
bad = "Cannot overwrite";
}
- } else if (cache_name_pos(src, length) < 0)
+ } else if (((pos = cache_name_pos(src, length)) < 0) &&
+ strcmp(active_cache[-1 - pos]->name, src))
bad = "not under version control";
else if (string_list_has_string(&src_for_dst, dst))
bad = "multiple sources for the same target";
@@ -202,7 +203,6 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
for (i = 0; i < argc; i++) {
const char *src = source[i], *dst = destination[i];
enum update_mode mode = modes[i];
- int pos;
if (show_only || verbose)
printf("Renaming %s to %s\n", src, dst);
if (!show_only && mode != INDEX &&
@@ -212,10 +212,17 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
if (mode == WORKING_DIRECTORY)
continue;
- pos = cache_name_pos(src, strlen(src));
- assert(pos >= 0);
- if (!show_only)
- rename_cache_entry_at(pos, dst);
+ if (!show_only) {
+ while (1) {
+ int pos = cache_name_pos(src, strlen(src));
+ if (pos < 0)
+ pos = -1 - pos;
+ if ((active_nr <= pos) ||
+ strcmp(active_cache[pos]->name, src))
+ break;
+ rename_cache_entry_at(pos, dst);
+ }
+ }
}
if (active_cache_changed) {
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index b0fa407..d538f88 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -173,6 +173,27 @@ test_expect_success 'git mv should not change sha1 of moved cache entry' '
rm -f dirty dirty2
+cat >expect <<\EOT
+100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 1 staged
+100755 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 2 staged
+100755 d00491fd7e5bb6fa28c517a0bb32b8b506539d4d 3 staged
+EOT
+
+test_expect_success 'git mv should move all stages of cache entry' '
+ rm -fr .git &&
+ git init &&
+ >staged &&
+ git update-index --index-info <expect &&
+ git ls-files --stage >actual &&
+ test_cmp expect actual &&
+ git mv staged staged-mv &&
+ sed "s/staged/staged-mv/" <expect >expect-2 &&
+ git ls-files --stage >actual &&
+ test_cmp expect-2 actual
+'
+
+rm -f expect expect-2 staged actual staged-mv
+
test_expect_success 'git mv should overwrite symlink to a file' '
rm -fr .git &&
^ permalink raw reply related
* Re: [PATCH 1/7] Make is_git_command() usable outside builtin-help
From: Miklos Vajna @ 2008-07-28 1:18 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <Pine.GSO.4.62.0807261301300.15728@harper.uchicago.edu>
[-- Attachment #1: Type: text/plain, Size: 707 bytes --]
On Sat, Jul 26, 2008 at 01:12:36PM -0500, Jonathan Nieder <jrnieder@uchicago.edu> wrote:
> On Sat, 26 Jul 2008, Miklos Vajna wrote:
>
> > + if (!prefix)
> > + prefix = "git-";
> > + prefix_len = strlen(prefix);
>
> The whitespace gave me a start: the diff markup moved the prefix_len
> line to the next tab stop, so at first glance it seems there are missing
> braces here. But it is an illusion. (I mention this so others might
> avoid wasting time worrying about it.)
In fact it was a whitespace problem: somehow I used spaces there instead
of a tab. I fixed it locally. (Will send an updated series soon.)
> I like the patch so far. Thanks for the pleasant reading.
:-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 0/6] Allow custom merge strategies, take 2
From: Miklos Vajna @ 2008-07-28 1:21 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217037178.git.vmiklos@frugalware.org>
Hi,
This is just a resend of my series, on top of Dscho's "Avoid chdir() in
list_commands_in_dir()" (f5d600e), including the suggestions I received
from Jonathan Nieder and Dscho.
Miklos Vajna (6):
builtin-help: make is_git_command() usable outside builtin-help
builtin-help: make list_commands() a bit more generic
builtin-help: make it possible to exclude some commands in
list_commands()
builtin-merge: allow using a custom strategy
builtin-merge: avoid non-strategy git-merge commands in error message
Add a new test for using a custom merge strategy
Makefile | 1 +
builtin-merge.c | 32 +++++++++++++++++++++------
help.c | 55 ++++++++++++++++++++++++-----------------------
help.h | 19 ++++++++++++++++
t/t7606-merge-custom.sh | 45 ++++++++++++++++++++++++++++++++++++++
5 files changed, 118 insertions(+), 34 deletions(-)
create mode 100644 help.h
create mode 100755 t/t7606-merge-custom.sh
^ permalink raw reply
* [PATCH 5/6] builtin-merge: avoid non-strategy git-merge commands in error message
From: Miklos Vajna @ 2008-07-28 1:21 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217207602.git.vmiklos@frugalware.org>
If an invalid strategy is supplied, like -s foobar, then git-merge
listed all git-merge-* commands. This is not perfect, since for example
git-merge-index is not a valid strategy.
These are now removed from the output by scanning the list of main
commands; if the git-merge-foo command is listed in the all_strategy
list, then it's shown, otherwise excluded. This does not exclude
commands somewhere else in the PATH, where custom strategies are
expected.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-merge.c | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index cdbc692..29826b1 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -88,8 +88,21 @@ static struct strategy *get_strategy(const char *name)
return &all_strategy[i];
if (!is_git_command(name, "git-merge-")) {
+ struct cmdnames not_strategies;
+
+ memset(¬_strategies, 0, sizeof(struct cmdnames));
+ for (i = 0; i < main_cmds.cnt; i++) {
+ int j, found = 0;
+ struct cmdname *ent = main_cmds.names[i];
+ for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
+ if (!strncmp(ent->name, all_strategy[j].name, ent->len)
+ && !all_strategy[j].name[ent->len])
+ found = 1;
+ if (!found)
+ add_cmdname(¬_strategies, ent->name, ent->len);
+ }
fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
- list_commands("git-merge-", "strategies");
+ list_commands("git-merge-", "strategies", ¬_strategies);
exit(1);
}
--
1.6.0.rc0.14.g95f8.dirty
^ 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