* send an email with logs after push
From: michele @ 2009-11-13 8:46 UTC (permalink / raw)
To: git
Hi guys, I'm using git for a collaborative development and I'm trying to
implement a notification system. I want to automatically send an email
containing the log of each commit after a push. The email should contain
the titles of the commits done between the previous and the last push.
The push action publish the repository on a public_html directory in one
other machine.
Do you have any suggestion to implement this?
Thanks
^ permalink raw reply
* [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-13 8:50 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <4AFD06CD.7090003@gmail.com>
On my slow laptop (P3 600MHz), system-wide bash completions take
too much time to load (> 2s), and a significant fraction of this
time is spent loading git-completion.bash:
$ time bash -c ". ./git-completion.bash" # hot cache, before this patch
real 0m0.509s
user 0m0.310s
sys 0m0.180s
Kirill tracked down that the most time is spent warming up
merge_strategy, all_command & porcelain_command caches.
Since git is not used in each and every interactive xterm, it
seems best to load completion support with cold caches, and then
load each needed thing lazily. This has most of the speed
advantage of pre-generating everything at build time, without the
complication of figuring out at build time what commands will be
available at run time.
The result is that loading completion is significantly faster
now:
$ time bash -c ". ./git-completion.bash" # cold cache, after this patch
real 0m0.171s
user 0m0.060s
sys 0m0.040s
Suggested-by: Kirill Smelkov <kirr@mns.spb.ru>
Cc: Shawn O. Pearce <spearce@spearce.org>
Cc: Stephen Boyd <bebarino@gmail.com>
Cc: Sverre Rabbelier <srabbelier@gmail.com>
Cc: Junio C Hamano <junio@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Stephen Boyd wrote:
> Ah ok. I think this proves even more that pregenerating the
> completion is a bad idea. With dynamic population we don't have
> these problems and it only takes 250ms more to load on a P3 700Mhz.
Hmm, 250 ms is a lot.
Strictly speaking, even with the existing completion script, it might
be nice to provide a "hash -r"-like command to bring the caches up to
date. Such a function could be:
git-completion-rehash ()
{
__git_compute_all_commands
__git_compute_merge_strategies
__git_compute_porcelain_commands
}
But that is a separate topic.
contrib/completion/git-completion.bash | 35 +++++++++++++++++--------------
1 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 9e8b607..7088ec7 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -330,10 +330,9 @@ __git_list_merge_strategies ()
}'
}
-__git_merge_strategies ()
+__git_compute_merge_strategies ()
{
- : ${__git_merge_strategylist:=$(__git_list_merge_strategies)}
- echo "$__git_merge_strategylist"
+ : ${__git_merge_strategies=$(__git_list_merge_strategies)}
}
__git_complete_file ()
@@ -468,15 +467,16 @@ __git_complete_remote_or_refspec ()
__git_complete_strategy ()
{
+ __git_compute_merge_strategies
case "${COMP_WORDS[COMP_CWORD-1]}" in
-s|--strategy)
- __gitcomp "$(__git_merge_strategies)"
+ __gitcomp "$__git_merge_strategies"
return 0
esac
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--strategy=*)
- __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
+ __gitcomp "$__git_merge_strategies" "" "${cur##--strategy=}"
return 0
;;
esac
@@ -495,16 +495,16 @@ __git_list_all_commands ()
done
}
-__git_all_commands ()
+__git_compute_all_commands ()
{
- : ${__git_all_commandlist:=$(__git_list_all_commands)}
- echo "$__git_all_commandlist"
+ : ${__git_all_commands=$(__git_list_all_commands)}
}
__git_list_porcelain_commands ()
{
local i IFS=" "$'\n'
- for i in "help" $(__git_all_commands)
+ __git_compute_all_commands
+ for i in "help" $__git_all_commands
do
case $i in
*--*) : helper pattern;;
@@ -586,10 +586,9 @@ __git_list_porcelain_commands ()
done
}
-__git_porcelain_commands ()
+__git_compute_porcelain_commands ()
{
- : ${__git_porcelain_commandlist:=$(__git_list_porcelain_commands)}
- echo "$__git_porcelain_commandlist"
+ : ${__git_porcelain_commands=$(__git_list_porcelain_commands)}
}
__git_aliases ()
@@ -1082,7 +1081,8 @@ _git_help ()
return
;;
esac
- __gitcomp "$(__git_all_commands)
+ __git_compute_all_commands
+ __gitcomp "__git_all_commands
attributes cli core-tutorial cvs-migration
diffcore gitk glossary hooks ignore modules
repository-layout tutorial tutorial-2
@@ -1438,7 +1438,8 @@ _git_config ()
return
;;
pull.twohead|pull.octopus)
- __gitcomp "$(__git_merge_strategies)"
+ __git_compute_merge_strategies
+ __gitcomp "$__git_merge_strategies"
return
;;
color.branch|color.diff|color.interactive|\
@@ -1539,7 +1540,8 @@ _git_config ()
pager.*)
local pfx="${cur%.*}."
cur="${cur#*.}"
- __gitcomp "$(__git_all_commands)" "$pfx" "$cur"
+ __git_compute_all_commands
+ __gitcomp "__git_all_commands" "$pfx" "$cur"
return
;;
remote.*.*)
@@ -2136,7 +2138,8 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
+ *) __git_compute_porcelain_commands
+ __gitcomp "$__git_porcelain_commands $(__git_aliases)" ;;
esac
return
fi
--
1.6.5.2
^ permalink raw reply related
* Re: git status internals and line endings
From: Marc Strapetz @ 2009-11-13 8:08 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091113001547.GB28836@sigill.intra.peff.net>
> Sounds like the core.autocrlf setting (see "git help config"), which I
> believe is set by default on Windows.
I have checked both $GIT_DIR/config and ~/.gitconfig and autocrlf has
not been set. I have then set autocrlf = false for the Windows
repository and still the file didn't show up as modified. On Linux, I've
added autocrlf = true (resp. autocrlf = input) for the repository and
still the file shows up as modified. Not that I don't like this
behavior, but I don't understand it :) Windows Git version is 1.6.5.1,
Linux version is 1.6.3.3.
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
Jeff King wrote:
> On Thu, Nov 12, 2009 at 09:32:14PM +0100, Marc Strapetz wrote:
>
>> On Linux, file1 and file3 are reported as modified -- as I would expect.
>> The surprise is on Windows: here only file1 is reported as modified. Why
>> not file3? Btw, 'git hash-object file3' reports the same SHA as for the
>> LF-only content in the repository (not so on Linux, as expected).
>>
>> Is this some special handling on Windows (and possibly on Mac OS)? In
>> this case, can someone please point me to the corresponding code part?
>> Thanks for any comments regarding this topic.
>
> Sounds like the core.autocrlf setting (see "git help config"), which I
> believe is set by default on Windows.
>
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: ks/precompute-completion
From: Stephen Boyd @ 2009-11-13 7:12 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <20091113070652.GA3907@progeny.tock>
Jonathan Nieder wrote:
> Stephen Boyd wrote:
>> I'm confused. Shouldn't your distro take care of updating the
>> completion for you? And wouldn't update-git-completion be more
>> suited as part of a makefile if it was needed at all?
>
> The problem is that I have git commands the distro did not install in
> my $PATH. For example, I currently have git-new-workdir in ~/bin, and
> once I bzr-fastexport works a little better, I will install git-bzr.
>
> Even without such commands, in many distributions the completion
> should not be one size fits all, since git-svn (for example) belongs
> to a different package
Ah ok. I think this proves even more that pregenerating the completion
is a bad idea. With dynamic population we don't have these problems and
it only takes 250ms more to load on a P3 700Mhz.
Maybe we should try and speedup 'git help -a' and 'git merge -s help'
instead? Perhaps options for the command/porcelain lists and available
strategies formatted for script consumption? I doubt it will be as fast
as compiling, but every bit helps apparently.
Side Note: Running git merge -s help outside a git repository fails, so
caching of the merge strategies isn't very effective.
^ permalink raw reply
* Re: ks/precompute-completion
From: Jonathan Nieder @ 2009-11-13 7:06 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <4AFCFF50.5080401@gmail.com>
Stephen Boyd wrote:
> Jonathan Nieder wrote:
>>
>>As a distro user, I don't think I would be able to use it until there
>>is a command to update the installed completion, to call after adding
>>a new git command to my $PATH. This could mean:
[...]
> I'm confused. Shouldn't your distro take care of updating the
> completion for you? And wouldn't update-git-completion be more
> suited as part of a makefile if it was needed at all?
The problem is that I have git commands the distro did not install in
my $PATH. For example, I currently have git-new-workdir in ~/bin, and
once I bzr-fastexport works a little better, I will install git-bzr.
Even without such commands, in many distributions the completion
should not be one size fits all, since git-svn (for example) belongs
to a different package.
I would expect the distribution to take care of populating the initial
completion list and updating it on upgrades.
Jonathan
^ permalink raw reply
* error while cloning a remote repository
From: Shameem Ahamed @ 2009-11-13 6:38 UTC (permalink / raw)
To: git
Hi,
I ran in to a warning message while cloning a remote repository.
The message is
warning: remote HEAD refers to nonexistent ref, unable to checkout.
After the cloning i couldn't see any remote files. The .git folder is created successfully.
Regards,
Shameem
^ permalink raw reply
* Re: ks/precompute-completion
From: Stephen Boyd @ 2009-11-13 6:40 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <20091111220832.GA31620@progeny.tock>
Jonathan Nieder wrote:
>
> As a distro user, I don't think I would be able to use it until there
> is a command to update the installed completion, to call after adding
> a new git command to my $PATH. This could mean:
>
> - git-completion.bash.generate learns to read the .in file and
> write the completion script to arbitrary paths (or just always
> uses stdin and stdout?)
>
> - distros install git-completion.bash.{generate,in} to /usr/share/git-core
>
> - distros install a simple completion script to /etc/bash_completion.d
> that passes the buck, e.g.
>
> <snip scripts>
>
> Thoughts?
I'm confused. Shouldn't your distro take care of updating the completion
for you? And wouldn't update-git-completion be more suited as part of a
makefile if it was needed at all?
^ permalink raw reply
* Re: Git in next is broken
From: Nicolas Pitre @ 2009-11-13 4:50 UTC (permalink / raw)
To: Julian Phillips; +Cc: René Scharfe, git
In-Reply-To: <alpine.LNX.2.00.0911122239150.6967@reaper.quantumfyre.co.uk>
On Thu, 12 Nov 2009, Julian Phillips wrote:
> On Thu, 12 Nov 2009, Ren? Scharfe wrote:
>
> > Nicolas Pitre schrieb:
> > > Simply issuing a "git fetch" in my copy of git.git makes glibc complain
> > > with this:
> > >
> > > *** glibc detected *** git: corrupted double-linked list:
> > > 0x0000000000974180 ***
> > >
> > > The gdb backtrace is:
> > >
> > > (gdb) bt
> > > #0 0x0000003c76632f05 in raise () from /lib64/libc.so.6
> > > #1 0x0000003c76634a73 in abort () from /lib64/libc.so.6
> > > #2 0x0000003c76672438 in __libc_message () from /lib64/libc.so.6
> > > #3 0x0000003c76677ec8 in malloc_printerr () from /lib64/libc.so.6
> > > #4 0x0000003c7667a23e in _int_free () from /lib64/libc.so.6
> > > #5 0x0000003c7667a486 in free () from /lib64/libc.so.6
> > > #6 0x0000000000493f3f in ref_remove_duplicates (ref_map=0x7562b0)
> > > at remote.c:756
> > > #7 0x0000000000424afc in get_ref_map () at builtin-fetch.c:165
> > > #8 do_fetch () at builtin-fetch.c:644
> > > #9 cmd_fetch (argc=<value optimized out>, argv=0x7fffffffe6a0,
> > > prefix=<value optimized out>) at builtin-fetch.c:754
> > > #10 0x0000000000403d83 in run_builtin () at git.c:251
> > > #11 handle_internal_command (argc=1, argv=0x7fffffffe6a0) at git.c:396
> > > #12 0x0000000000403f2d in run_argv () at git.c:438
> > > #13 main (argc=1, argv=0x7fffffffe6a0) at git.c:509
> > >
> > > Bisection reveals the following culprit:
> > >
> > > commit 73cf0822b2a4ffa7ad559d1f0772e39718fc7776
> > > Author: Julian Phillips <julian@quantumfyre.co.uk>
> > > Date: Sun Oct 25 21:28:11 2009 +0000
> > >
> > > remote: Make ref_remove_duplicates faster for large numbers of refs
> >
> > Can't reproduce because I don't know how to create duplicate refs, but does
> > the following help?
Nope.
> > remote.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/remote.c b/remote.c
> > index 4f9f0cc..10cc985 100644
> > --- a/remote.c
> > +++ b/remote.c
> > @@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
> > prev->next = ref_map->next;
> > free(ref_map->peer_ref);
> > free(ref_map);
> > + ref_map = next;
>
> You don't need this line (this is taken care of in the for(...)).
>
> > + continue;
>
> Ack. This one however, you do need. Good catch.
Without the "ref_map = next" there is no change: glibc still complains
about corruption and abort the execution. With the "ref_map = next"
then git simply segfaults.
I simply have zero time to investigate the issue myself now
unfortunately.
Nicolas
^ permalink raw reply
* Re: [PATCH v2] git-pull.sh --rebase: overhaul error handling when no candidates are found
From: Jonathan Nieder @ 2009-11-13 4:07 UTC (permalink / raw)
To: Jan Krüger
Cc: Jeff King, Jan Nieuwenhuizen, Tomas Carnecky, git list,
Junio C Hamano
In-Reply-To: <20091112170814.1858aba4@perceptron>
Jan Krüger wrote:
> Subject: [PATCH v2] git-pull.sh --rebase: overhaul error handling when no candidates are found
s/error handling/error message/. :)
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -91,45 +91,56 @@ error_on_no_merge_candidates () {
[...]
> if [ $# -gt 1 ]; then
> - echo "There are no candidates for merging in the refs that you just fetched."
> + echo "There are no candidates for using the refs that you just fetched."
> echo "Generally this means that you provided a wildcard refspec which had no"
> echo "matches on the remote end."
This sounds a little awkward to me, maybe because all the remote refs
are being used to populate the remotes/<remote>/* hierarchy.
I’m trying to come up with an alternative wording, but it is hard:
* Merging and rebasing are about incorporating the remote history
into our own, so how about something like "... no candidates for
incorporating from the refs ..."?
* Maybe one is using 'git pull' to update. "There are no
candidates to use for an update among the refs that you just
fetched."
* Or: "There are no upstreams to local branches among the refs that
you just fetched."
I like the third of these best, but I hope you can do better.
> elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
> echo "You asked to pull from the remote '$1', but did not specify"
> - echo "a branch to merge. Because this is not the default configured remote"
> + echo "a branch to use. Because this is not the default configured remote"
Maybe just "... did not specify a branch."?
> echo "for your current branch, you must specify a branch on the command line."
> elif [ -z "$curr_branch" ]; then
> echo "You are not currently on a branch, so I cannot use any"
> echo "'branch.<branchname>.merge' in your configuration file."
> - echo "Please specify which branch you want to merge on the command"
> + echo "Please specify which branch you want to use on the command"
s/branch/remote branch/? The reader might worry that the command is
going to try to re-attach his HEAD.
The rest of your patch looks good to me. Thanks for working on this.
Jonathan
^ permalink raw reply
* [PATCH] Update 'git remote' usage and man page to match.
From: Tim Henigan @ 2009-11-13 1:15 UTC (permalink / raw)
To: gitster; +Cc: git
This commit:
1) Removes documentation of '--verbose' from the synopsis portion
of the usage string since it is a general option.
2) Removes the 'remote' option from 'git remote update' in the
man page. This option had already been removed from the usage
string in the code, but the man page was not updated to match.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
---
This is a resend of the patch at:
http://article.gmane.org/gmane.comp.version-control.git/132732
I forgot to include 'gitster at pobox dot com' on the original patch.
No changes were made to the patch itself.
Sorry for the noise.
Documentation/git-remote.txt | 4 ++--
builtin-remote.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 82a3d29..32ff95b 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -9,14 +9,14 @@ git-remote - manage set of tracked repositories
SYNOPSIS
--------
[verse]
-'git remote' [-v | --verbose]
+'git remote'
'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
'git remote rename' <old> <new>
'git remote rm' <name>
'git remote set-head' <name> [-a | -d | <branch>]
'git remote show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
-'git remote update' [-p | --prune] [group | remote]...
+'git remote update' [-p | --prune] [group]...
DESCRIPTION
-----------
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..3756e91 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -8,14 +8,14 @@
#include "refs.h"
static const char * const builtin_remote_usage[] = {
- "git remote [-v | --verbose]",
+ "git remote",
"git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
"git remote rename <old> <new>",
"git remote rm <name>",
"git remote set-head <name> [-a | -d | <branch>]",
"git remote show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [-p | --prune] [group]",
+ "git remote update [-p | --prune] [group]",
NULL
};
--
1.6.5.2.180.gc5b3e.dirty
^ permalink raw reply related
* Re: [PATCH 2/2] git-svn: handle SVN merges from revisions past the tip of the branch
From: Toby Allsopp @ 2009-11-13 1:03 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Eric Wong
In-Reply-To: <4AFCAC9C.9020305@vilain.net>
On Fri, Nov 13 2009, Sam Vilain wrote:
> Toby Allsopp wrote:
> > When recording the revisions that it has merged, SVN sets the top
> > revision to be the latest revision in the repository, which is not
> > necessarily a revision on the branch that is being merged from. When
> > it is not on the branch, git-svn fails to add the extra parent to
> > represent the merge because it relies on finding the commit on the
> > branch that corresponds to the top of the SVN merge range.
>
> I thought, "that sounds like he's repeating himself, wait a sec..."
Hmm, it makes perfect sense to me :-) Does the explanation in 1/2 make
more sense?
The first sentence describes what Subversion does, the second what
git-svn does in response.
> Thanks for contributing this. There might be other bugs too, especially
> when upstream has a more complicated merge hierarchy ... apparently svn
> tends to get it wrong, so checking for all commits might not work in
> that case.
Oh yes, SVN gets the merges wrong in an alarming number of cases, it's
really shocking. I only stay sane at work because I tell myself that
SVN is making the case for git for me :-)
> It would be nice if "dcommit" could make these commits, too...
Yes.
Toby.
^ permalink raw reply
* [PATCH 3/3] gitweb: Make 'history' view (re)use git_log_generic()
From: Jakub Narebski @ 2009-11-13 1:02 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1258074134-27011-1-git-send-email-jnareb@gmail.com>
Make git_history use git_log_generic, passing git_history_body as one
of its paramaters. This required changes to git_log_generic, in
particular passing more things as parameters.
While refactoring common code of 'log', 'shortlog' and 'history' view,
we did unify pagination, using always the form used by 'history' view,
namely
first * prev * next
in place of
HEAD * prev * next
used by 'log' and 'shortlog' views.
The 'history' view now supports commit limiting via 'hpb' parameter,
similarly to 'shortlog' (and 'log') view. Performance of 'history'
view got improved a bit, as it doesn't run git_get_hash_by_path for
"current" version in a loop. Error detection and reporting for
'history' view changed a bit.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 146 ++++++++++++++++++++-------------------------------
1 files changed, 57 insertions(+), 89 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 14661cc..5cfa507 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3363,22 +3363,18 @@ sub git_print_page_nav {
}
sub format_paging_nav {
- my ($action, $hash, $head, $page, $has_next_link) = @_;
+ my ($action, $page, $has_next_link) = @_;
my $paging_nav;
- if ($hash ne $head || $page) {
- $paging_nav .= $cgi->a({-href => href(action=>$action)}, "HEAD");
- } else {
- $paging_nav .= "HEAD";
- }
-
if ($page > 0) {
- $paging_nav .= " ⋅ " .
+ $paging_nav .=
+ $cgi->a({-href => href(-replay=>1, page=>undef)}, "first") .
+ " ⋅ " .
$cgi->a({-href => href(-replay=>1, page=>$page-1),
-accesskey => "p", -title => "Alt-p"}, "prev");
} else {
- $paging_nav .= " ⋅ prev";
+ $paging_nav .= "first ⋅ prev";
}
if ($has_next_link) {
@@ -4447,7 +4443,8 @@ sub git_shortlog_body {
sub git_history_body {
# Warning: assumes constant type (blob or tree) during history
- my ($commitlist, $from, $to, $refs, $hash_base, $ftype, $extra) = @_;
+ my ($commitlist, $from, $to, $refs, $extra,
+ $file_name, $file_hash, $ftype) = @_;
$from = 0 unless defined $from;
$to = $#{$commitlist} unless (defined $to && $to <= $#{$commitlist});
@@ -4481,7 +4478,7 @@ sub git_history_body {
$cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff");
if ($ftype eq 'blob') {
- my $blob_current = git_get_hash_by_path($hash_base, $file_name);
+ my $blob_current = $file_hash;
my $blob_parent = git_get_hash_by_path($commit, $file_name);
if (defined $blob_current && defined $blob_parent &&
$blob_current ne $blob_parent) {
@@ -5337,25 +5334,48 @@ sub git_snapshot {
}
sub git_log_generic {
- my ($fmt_name, $body_subr) = @_;
+ my ($fmt_name, $body_subr, $base, $parent, $file_name, $file_hash) = @_;
my $head = git_get_head_hash($project);
- if (!defined $hash) {
- $hash = $head;
+ if (!defined $base) {
+ $base = $head;
}
if (!defined $page) {
$page = 0;
}
my $refs = git_get_references();
- my $commit_hash = $hash;
- if (defined $hash_parent) {
- $commit_hash = "$hash_parent..$hash";
+ my $commit_hash = $base;
+ if (defined $parent) {
+ $commit_hash = "$parent..$base";
+ }
+ my @commitlist =
+ parse_commits($commit_hash, 101, (100 * $page),
+ defined $file_name ? ($file_name, "--full-history") : ());
+
+ my $ftype;
+ if (!defined $file_hash && defined $file_name) {
+ # some commits could have deleted file in question,
+ # and not have it in tree, but one of them has to have it
+ for (my $i = 0; $i < @commitlist; $i++) {
+ $file_hash = git_get_hash_by_path($commitlist[$i]{'id'}, $file_name);
+ last if defined $file_hash;
+ }
+ }
+ if (defined $file_hash) {
+ $ftype = git_get_type($file_hash);
+ }
+ if (defined $file_name && !defined $ftype) {
+ die_error(500, "Unknown type of object");
+ }
+ my %co;
+ if (defined $file_name) {
+ %co = parse_commit($base)
+ or die_error(404, "Unknown commit object");
}
- my @commitlist = parse_commits($commit_hash, 101, (100 * $page));
- my $paging_nav = format_paging_nav($fmt_name, $hash, $head,
- $page, $#commitlist >= 100);
+
+ my $paging_nav = format_paging_nav($fmt_name, $page, $#commitlist >= 100);
my $next_link = '';
if ($#commitlist >= 100) {
$next_link =
@@ -5363,7 +5383,7 @@ sub git_log_generic {
-accesskey => "n", -title => "Alt-n"}, "next");
}
my $patch_max = gitweb_get_feature('patches');
- if ($patch_max) {
+ if ($patch_max && !defined $file_name) {
if ($patch_max < 0 || @commitlist <= $patch_max) {
$paging_nav .= " ⋅ " .
$cgi->a({-href => href(action=>"patches", -replay=>1)},
@@ -5373,15 +5393,23 @@ sub git_log_generic {
git_header_html();
git_print_page_nav($fmt_name,'', $hash,$hash,$hash, $paging_nav);
- git_print_header_div('summary', $project);
+ if (defined $file_name) {
+ git_print_header_div('commit', esc_html($co{'title'}), $base);
+ } else {
+ git_print_header_div('summary', $project)
+ }
+ git_print_page_path($file_name, $ftype, $hash_base)
+ if (defined $file_name);
- $body_subr->(\@commitlist, 0, 99, $refs, $next_link);
+ $body_subr->(\@commitlist, 0, 99, $refs, $next_link,
+ $file_name, $file_hash, $ftype);
git_footer_html();
}
sub git_log {
- git_log_generic('log', \&git_log_body);
+ git_log_generic('log', \&git_log_body,
+ $hash, $hash_parent);
}
sub git_commit {
@@ -5920,70 +5948,9 @@ sub git_patches {
}
sub git_history {
- if (!defined $hash_base) {
- $hash_base = git_get_head_hash($project);
- }
- if (!defined $page) {
- $page = 0;
- }
- my $ftype;
- my %co = parse_commit($hash_base)
- or die_error(404, "Unknown commit object");
-
- my $refs = git_get_references();
- my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
-
- my @commitlist = parse_commits($hash_base, 101, (100 * $page),
- $file_name, "--full-history")
- or die_error(404, "No such file or directory on given branch");
-
- if (!defined $hash && defined $file_name) {
- # some commits could have deleted file in question,
- # and not have it in tree, but one of them has to have it
- for (my $i = 0; $i <= @commitlist; $i++) {
- $hash = git_get_hash_by_path($commitlist[$i]{'id'}, $file_name);
- last if defined $hash;
- }
- }
- if (defined $hash) {
- $ftype = git_get_type($hash);
- }
- if (!defined $ftype) {
- die_error(500, "Unknown type of object");
- }
-
- my $paging_nav = '';
- if ($page > 0) {
- $paging_nav .=
- $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base,
- file_name=>$file_name)},
- "first");
- $paging_nav .= " ⋅ " .
- $cgi->a({-href => href(-replay=>1, page=>$page-1),
- -accesskey => "p", -title => "Alt-p"}, "prev");
- } else {
- $paging_nav .= "first";
- $paging_nav .= " ⋅ prev";
- }
- my $next_link = '';
- if ($#commitlist >= 100) {
- $next_link =
- $cgi->a({-href => href(-replay=>1, page=>$page+1),
- -accesskey => "n", -title => "Alt-n"}, "next");
- $paging_nav .= " ⋅ $next_link";
- } else {
- $paging_nav .= " ⋅ next";
- }
-
- git_header_html();
- git_print_page_nav('history','', $hash_base,$co{'tree'},$hash_base, $paging_nav);
- git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
- git_print_page_path($file_name, $ftype, $hash_base);
-
- git_history_body(\@commitlist, 0, 99,
- $refs, $hash_base, $ftype, $next_link);
-
- git_footer_html();
+ git_log_generic('history', \&git_history_body,
+ $hash_base, $hash_parent_base,
+ $file_name, $hash);
}
sub git_search {
@@ -6247,7 +6214,8 @@ EOT
}
sub git_shortlog {
- git_log_generic('shortlog', \&git_shortlog_body);
+ git_log_generic('shortlog', \&git_shortlog_body,
+ $hash, $hash_parent);
}
## ......................................................................
--
1.6.5
^ permalink raw reply related
* [PATCH 1/3] gitweb: Refactor 'log' action generation, adding git_log_body()
From: Jakub Narebski @ 2009-11-13 1:02 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1258074134-27011-1-git-send-email-jnareb@gmail.com>
Put the main part of 'log' view generation into git_log_body,
similarly how it is done for 'shortlog' and 'history' views (and
also for 'tags' and 'heads' views).
This is preparation for extracting common code between 'log',
'shortlog' and 'history' actions.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is pure refactoring: output should change.
gitweb/gitweb.perl | 81 ++++++++++++++++++++++++++++++---------------------
1 files changed, 48 insertions(+), 33 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e4cbfc3..68dbd9e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4361,6 +4361,46 @@ sub git_project_list_body {
print "</table>\n";
}
+sub git_log_body {
+ # uses global variable $project
+ my ($commitlist, $from, $to, $refs, $extra) = @_;
+
+ $from = 0 unless defined $from;
+ $to = $#{$commitlist} if (!defined $to || $#{$commitlist} < $to);
+
+ for (my $i = 0; $i <= $to; $i++) {
+ my %co = %{$commitlist->[$i]};
+ next if !%co;
+ my $commit = $co{'id'};
+ my $ref = format_ref_marker($refs, $commit);
+ my %ad = parse_date($co{'author_epoch'});
+ git_print_header_div('commit',
+ "<span class=\"age\">$co{'age_string'}</span>" .
+ esc_html($co{'title'}) . $ref,
+ $commit);
+ print "<div class=\"title_text\">\n" .
+ "<div class=\"log_link\">\n" .
+ $cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") .
+ " | " .
+ $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") .
+ " | " .
+ $cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree") .
+ "<br/>\n" .
+ "</div>\n";
+ git_print_authorship(\%co, -tag => 'span');
+ print "<br/>\n</div>\n";
+
+ print "<div class=\"log_body\">\n";
+ git_print_log($co{'comment'}, -final_empty_line=> 1);
+ print "</div>\n";
+ }
+ if ($extra) {
+ print "<div class=\"page_nav\">\n";
+ print "$extra\n";
+ print "</div>\n";
+ }
+}
+
sub git_shortlog_body {
# uses global variable $project
my ($commitlist, $from, $to, $refs, $extra) = @_;
@@ -5309,7 +5349,12 @@ sub git_log {
my @commitlist = parse_commits($hash, 101, (100 * $page));
my $paging_nav = format_paging_nav('log', $hash, $head, $page, $#commitlist >= 100);
-
+ my $next_link;
+ if ($#commitlist >= 100) {
+ $next_link =
+ $cgi->a({-href => href(-replay=>1, page=>$page+1),
+ -accesskey => "n", -title => "Alt-n"}, "next");
+ }
my ($patch_max) = gitweb_get_feature('patches');
if ($patch_max) {
if ($patch_max < 0 || @commitlist <= $patch_max) {
@@ -5328,39 +5373,9 @@ sub git_log {
git_print_header_div('summary', $project);
print "<div class=\"page_body\"> Last change $co{'age_string'}.<br/><br/></div>\n";
}
- my $to = ($#commitlist >= 99) ? (99) : ($#commitlist);
- for (my $i = 0; $i <= $to; $i++) {
- my %co = %{$commitlist[$i]};
- next if !%co;
- my $commit = $co{'id'};
- my $ref = format_ref_marker($refs, $commit);
- my %ad = parse_date($co{'author_epoch'});
- git_print_header_div('commit',
- "<span class=\"age\">$co{'age_string'}</span>" .
- esc_html($co{'title'}) . $ref,
- $commit);
- print "<div class=\"title_text\">\n" .
- "<div class=\"log_link\">\n" .
- $cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") .
- " | " .
- $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") .
- " | " .
- $cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree") .
- "<br/>\n" .
- "</div>\n";
- git_print_authorship(\%co, -tag => 'span');
- print "<br/>\n</div>\n";
- print "<div class=\"log_body\">\n";
- git_print_log($co{'comment'}, -final_empty_line=> 1);
- print "</div>\n";
- }
- if ($#commitlist >= 100) {
- print "<div class=\"page_nav\">\n";
- print $cgi->a({-href => href(-replay=>1, page=>$page+1),
- -accesskey => "n", -title => "Alt-n"}, "next");
- print "</div>\n";
- }
+ git_log_body(\@commitlist, 0, 99, $refs, $next_link);
+
git_footer_html();
}
--
1.6.5
^ permalink raw reply related
* [PATCH 2/3] gitweb: Refactor common parts of 'log' and 'shortlog' views
From: Jakub Narebski @ 2009-11-13 1:02 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1258074134-27011-1-git-send-email-jnareb@gmail.com>
Put the common parts of git_log and git_shortlog into git_log_generic
subroutine: git_log and git_shortlog are now thin wrappers calling
git_log_generic with appropriate arguments.
The unification of code responsible for 'log' and 'shorlog' actions
lead to the following changes in gitweb output
* 'tree' link in page_nav now uses $hash parameter, as was the case
for 'shortlog' but not for 'log'
* 'log' view now respect $hash_parent limiting, like 'shortlog' did
* 'log' view doesn't have special case for empty list anymore, and it
always uses page_header linking to summary view, like 'shortlog'
did.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 72 ++++++++++++++-------------------------------------
1 files changed, 20 insertions(+), 52 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 68dbd9e..14661cc 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5336,7 +5336,9 @@ sub git_snapshot {
close $fd;
}
-sub git_log {
+sub git_log_generic {
+ my ($fmt_name, $body_subr) = @_;
+
my $head = git_get_head_hash($project);
if (!defined $hash) {
$hash = $head;
@@ -5346,16 +5348,21 @@ sub git_log {
}
my $refs = git_get_references();
- my @commitlist = parse_commits($hash, 101, (100 * $page));
+ my $commit_hash = $hash;
+ if (defined $hash_parent) {
+ $commit_hash = "$hash_parent..$hash";
+ }
+ my @commitlist = parse_commits($commit_hash, 101, (100 * $page));
- my $paging_nav = format_paging_nav('log', $hash, $head, $page, $#commitlist >= 100);
- my $next_link;
+ my $paging_nav = format_paging_nav($fmt_name, $hash, $head,
+ $page, $#commitlist >= 100);
+ my $next_link = '';
if ($#commitlist >= 100) {
$next_link =
$cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
}
- my ($patch_max) = gitweb_get_feature('patches');
+ my $patch_max = gitweb_get_feature('patches');
if ($patch_max) {
if ($patch_max < 0 || @commitlist <= $patch_max) {
$paging_nav .= " ⋅ " .
@@ -5365,20 +5372,18 @@ sub git_log {
}
git_header_html();
- git_print_page_nav('log','', $hash,undef,undef, $paging_nav);
-
- if (!@commitlist) {
- my %co = parse_commit($hash);
-
- git_print_header_div('summary', $project);
- print "<div class=\"page_body\"> Last change $co{'age_string'}.<br/><br/></div>\n";
- }
+ git_print_page_nav($fmt_name,'', $hash,$hash,$hash, $paging_nav);
+ git_print_header_div('summary', $project);
- git_log_body(\@commitlist, 0, 99, $refs, $next_link);
+ $body_subr->(\@commitlist, 0, 99, $refs, $next_link);
git_footer_html();
}
+sub git_log {
+ git_log_generic('log', \&git_log_body);
+}
+
sub git_commit {
$hash ||= $hash_base || "HEAD";
my %co = parse_commit($hash)
@@ -6242,44 +6247,7 @@ EOT
}
sub git_shortlog {
- my $head = git_get_head_hash($project);
- if (!defined $hash) {
- $hash = $head;
- }
- if (!defined $page) {
- $page = 0;
- }
- my $refs = git_get_references();
-
- my $commit_hash = $hash;
- if (defined $hash_parent) {
- $commit_hash = "$hash_parent..$hash";
- }
- my @commitlist = parse_commits($commit_hash, 101, (100 * $page));
-
- my $paging_nav = format_paging_nav('shortlog', $hash, $head, $page, $#commitlist >= 100);
- my $next_link = '';
- if ($#commitlist >= 100) {
- $next_link =
- $cgi->a({-href => href(-replay=>1, page=>$page+1),
- -accesskey => "n", -title => "Alt-n"}, "next");
- }
- my $patch_max = gitweb_check_feature('patches');
- if ($patch_max) {
- if ($patch_max < 0 || @commitlist <= $patch_max) {
- $paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>"patches", -replay=>1)},
- "patches");
- }
- }
-
- git_header_html();
- git_print_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);
- git_print_header_div('summary', $project);
-
- git_shortlog_body(\@commitlist, 0, 99, $refs, $next_link);
-
- git_footer_html();
+ git_log_generic('shortlog', \&git_shortlog_body);
}
## ......................................................................
--
1.6.5
^ permalink raw reply related
* [RFC/PATCH 0/3] gitweb: Refactor common parts of log-like views
From: Jakub Narebski @ 2009-11-13 1:02 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
This series extracts common parts of log-like views: 'log', 'shortlog'
and 'history' view, into git_log_generic() subroutine. This
unification of code reduces code duplication, and brings features such
as limiting the list of commits displayed using $hash_parent{,_base}
from 'shortlog' view (added in ec3e97b (gitweb: shortlog now also
obeys $hash_parent, 2008-08-08)).
I have tested this series a bit (it passes both t9500 and t9501 test),
but I didn't test all the corner cases.
This series is preparation for even more refactoring planned, to make
it easier to introduce new log-like action (new log formats). It
doesn't include (for now) the 'search' view, neither in message search
not in pickaxe search form.
Jakub Narebski (3):
gitweb: Refactor 'log' action generation, adding git_log_body()
gitweb: Refactor common parts of 'log' and 'shortlog' views
gitweb: Make 'history' view (re)use git_log_generic()
gitweb/gitweb.perl | 269 +++++++++++++++++++++-------------------------------
1 files changed, 110 insertions(+), 159 deletions(-)
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 2/2] git-svn: handle SVN merges from revisions past the tip of the branch
From: Sam Vilain @ 2009-11-13 0:47 UTC (permalink / raw)
To: Toby Allsopp; +Cc: git, Eric Wong
In-Reply-To: <871vk35o86.fsf@navakl084.mitacad.com>
Toby Allsopp wrote:
> When recording the revisions that it has merged, SVN sets the top
> revision to be the latest revision in the repository, which is not
> necessarily a revision on the branch that is being merged from. When
> it is not on the branch, git-svn fails to add the extra parent to
> represent the merge because it relies on finding the commit on the
> branch that corresponds to the top of the SVN merge range.
I thought, "that sounds like he's repeating himself, wait a sec..."
> -test_expect_failure 'represent svn merges with intervening commits' "
> +test_expect_success 'represent svn merges with intervening commits' "
> [ `git cat-file commit HEAD | grep parent | wc -l` -eq 2 ]
> "
So you made a failing test and then added the implementation for it?
Interesting strategy :). I'd probably not repeat the same sentence
twice though.
Thanks for contributing this. There might be other bugs too, especially
when upstream has a more complicated merge hierarchy ... apparently svn
tends to get it wrong, so checking for all commits might not work in
that case.
It would be nice if "dcommit" could make these commits, too...
Sam
^ permalink raw reply
* Re: git status internals and line endings
From: Jeff King @ 2009-11-13 0:15 UTC (permalink / raw)
To: Marc Strapetz; +Cc: git
In-Reply-To: <4AFC70CE.5020106@syntevo.com>
On Thu, Nov 12, 2009 at 09:32:14PM +0100, Marc Strapetz wrote:
> On Linux, file1 and file3 are reported as modified -- as I would expect.
> The surprise is on Windows: here only file1 is reported as modified. Why
> not file3? Btw, 'git hash-object file3' reports the same SHA as for the
> LF-only content in the repository (not so on Linux, as expected).
>
> Is this some special handling on Windows (and possibly on Mac OS)? In
> this case, can someone please point me to the corresponding code part?
> Thanks for any comments regarding this topic.
Sounds like the core.autocrlf setting (see "git help config"), which I
believe is set by default on Windows.
-Peff
^ permalink raw reply
* [PATCH 1/2] git-svn: add (failing) test for SVN 1.5+ merge with intervening commit
From: Toby Allsopp @ 2009-11-12 20:48 UTC (permalink / raw)
To: git; +Cc: Sam Vilain, Eric Wong
This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo
properties. The problematic case is when there is some commit on an
unrelated branch after the last commit on the merged-from branch.
When SVN records the mergeinfo property, it records the latest
revision in the whole repository, which, in the problematic case, is
not on the branch it is merging from.
To trigger the git-svn bug, we modify t9151 to include two SVN merges,
the second of which has an intervening commit. The SVN dump was
generated using SVN 1.6.6 (on Debian squeeze amd64).
Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz>
---
t/t9151-svn-mergeinfo.sh | 6 +-
t/t9151/make-svnmerge-dump | 32 ++++-
t/t9151/svn-mergeinfo.dump | 386 +++++++++++++++++++++++++++++++++++++-------
3 files changed, 366 insertions(+), 58 deletions(-)
diff --git a/t/t9151-svn-mergeinfo.sh b/t/t9151-svn-mergeinfo.sh
index 9bee516..0d42c84 100755
--- a/t/t9151-svn-mergeinfo.sh
+++ b/t/t9151-svn-mergeinfo.sh
@@ -15,7 +15,11 @@ test_expect_success 'load svn dump' "
git svn fetch --all
"
-test_expect_success 'svn merges were represented coming in' "
+test_expect_success 'represent svn merges without intervening commits' "
+ [ `git cat-file commit HEAD^1 | grep parent | wc -l` -eq 2 ]
+ "
+
+test_expect_failure 'represent svn merges with intervening commits' "
[ `git cat-file commit HEAD | grep parent | wc -l` -eq 2 ]
"
diff --git a/t/t9151/make-svnmerge-dump b/t/t9151/make-svnmerge-dump
index e35d64d..7e3da75 100644
--- a/t/t9151/make-svnmerge-dump
+++ b/t/t9151/make-svnmerge-dump
@@ -28,6 +28,10 @@ svn cp trunk branches/left
echo "Committing BRANCH POINT"
svn commit -m "make left branch"
+svn cp trunk branches/right
+
+echo "Committing other BRANCH POINT"
+svn commit -m "make right branch"
cd branches/left/
#$sm init
@@ -64,7 +68,33 @@ git cat-file blob b51ad431:Makefile > Makefile
svn resolved Makefile
-svn commit -m "Merge trunk"
+svn commit -m "Merge trunk 1"
+
+# create commits on both branches
+
+cd ../branches/left
+git cat-file blob ff5ebe39:Makefile > Makefile
+echo "Committing BRANCH UPDATE 4"
+svn commit -m "left update 4"
+
+cd ../right
+git cat-file blob b5039db6:Makefile > Makefile
+echo "Committing other BRANCH UPDATE 1"
+svn commit -m "right update 1"
+
+# merge to trun again
+
+cd ../..
+svn update
+cd trunk
+
+svn merge ../branches/left --accept postpone
+
+git cat-file blob b51ad431:Makefile > Makefile
+
+svn resolved Makefile
+
+svn commit -m "Merge trunk 2"
cd ../..
diff --git a/t/t9151/svn-mergeinfo.dump b/t/t9151/svn-mergeinfo.dump
index 2153187..11a883f 100644
--- a/t/t9151/svn-mergeinfo.dump
+++ b/t/t9151/svn-mergeinfo.dump
@@ -1,6 +1,6 @@
SVN-fs-dump-format-version: 2
-UUID: 1ce241d1-ba54-4eb9-bded-03057fe48a33
+UUID: 1530d5a2-a1dc-4438-8ad5-d95e96db8945
Revision-number: 0
Prop-content-length: 56
@@ -9,12 +9,12 @@ Content-length: 56
K 8
svn:date
V 27
-2009-10-20T01:33:37.692723Z
+2009-11-12T20:29:38.812226Z
PROPS-END
Revision-number: 1
-Prop-content-length: 123
-Content-length: 123
+Prop-content-length: 127
+Content-length: 127
K 7
svn:log
@@ -22,12 +22,12 @@ V 24
Setup trunk and branches
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:38.159933Z
+2009-11-12T20:29:39.045856Z
PROPS-END
Node-path: branches
@@ -49,8 +49,8 @@ PROPS-END
Revision-number: 2
-Prop-content-length: 106
-Content-length: 106
+Prop-content-length: 110
+Content-length: 110
K 7
svn:log
@@ -58,12 +58,12 @@ V 8
ancestor
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:39.160059Z
+2009-11-12T20:29:40.079587Z
PROPS-END
Node-path: trunk/Makefile
@@ -72,6 +72,7 @@ Node-action: add
Prop-content-length: 10
Text-content-length: 2401
Text-content-md5: bfd8ff778d1492dc6758567373176a89
+Text-content-sha1: 103205ce331f7d64086dba497574734f78439590
Content-length: 2411
PROPS-END
@@ -155,8 +156,8 @@ backup: clean
Revision-number: 3
-Prop-content-length: 115
-Content-length: 115
+Prop-content-length: 119
+Content-length: 119
K 7
svn:log
@@ -164,12 +165,12 @@ V 16
make left branch
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:41.148192Z
+2009-11-12T20:29:42.084439Z
PROPS-END
Node-path: branches/left
@@ -177,27 +178,54 @@ Node-kind: dir
Node-action: add
Node-copyfrom-rev: 1
Node-copyfrom-path: trunk
-Prop-content-length: 34
-Content-length: 34
-K 13
-svn:mergeinfo
-V 0
+Node-path: branches/left/Makefile
+Node-kind: file
+Node-action: add
+Node-copyfrom-rev: 2
+Node-copyfrom-path: trunk/Makefile
+Text-copy-source-md5: bfd8ff778d1492dc6758567373176a89
+Text-copy-source-sha1: 103205ce331f7d64086dba497574734f78439590
+
+
+Revision-number: 4
+Prop-content-length: 120
+Content-length: 120
+
+K 7
+svn:log
+V 17
+make right branch
+K 10
+svn:author
+V 8
+tallsopp
+K 8
+svn:date
+V 27
+2009-11-12T20:29:44.065452Z
PROPS-END
+Node-path: branches/right
+Node-kind: dir
+Node-action: add
+Node-copyfrom-rev: 1
+Node-copyfrom-path: trunk
+
-Node-path: branches/left/Makefile
+Node-path: branches/right/Makefile
Node-kind: file
Node-action: add
Node-copyfrom-rev: 2
Node-copyfrom-path: trunk/Makefile
Text-copy-source-md5: bfd8ff778d1492dc6758567373176a89
+Text-copy-source-sha1: 103205ce331f7d64086dba497574734f78439590
-Revision-number: 4
-Prop-content-length: 112
-Content-length: 112
+Revision-number: 5
+Prop-content-length: 116
+Content-length: 116
K 7
svn:log
@@ -205,12 +233,12 @@ V 13
left update 1
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:42.148773Z
+2009-11-12T20:29:45.066262Z
PROPS-END
Node-path: branches/left/Makefile
@@ -218,6 +246,7 @@ Node-kind: file
Node-action: change
Text-content-length: 2465
Text-content-md5: 16e38d9753b061731650561ce01b1195
+Text-content-sha1: 36da4b84ea9b64218ab48171dfc5c48ae025f38b
Content-length: 2465
# -DCOLLISION_CHECK if you believe that SHA1's
@@ -299,9 +328,9 @@ backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
-Revision-number: 5
-Prop-content-length: 111
-Content-length: 111
+Revision-number: 6
+Prop-content-length: 115
+Content-length: 115
K 7
svn:log
@@ -309,12 +338,12 @@ V 12
trunk update
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:43.159959Z
+2009-11-12T20:29:46.278498Z
PROPS-END
Node-path: trunk/Makefile
@@ -322,6 +351,7 @@ Node-kind: file
Node-action: change
Text-content-length: 2521
Text-content-md5: 0668418a621333f4aa8b6632cd63e2a0
+Text-content-sha1: 4f29afd038e52f45acb5ef8c41acfc70062a741a
Content-length: 2521
# -DCOLLISION_CHECK if you believe that SHA1's
@@ -406,9 +436,9 @@ backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
-Revision-number: 6
-Prop-content-length: 112
-Content-length: 112
+Revision-number: 7
+Prop-content-length: 116
+Content-length: 116
K 7
svn:log
@@ -416,12 +446,12 @@ V 13
left update 2
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:44.164175Z
+2009-11-12T20:29:47.069090Z
PROPS-END
Node-path: branches/left/Makefile
@@ -429,6 +459,7 @@ Node-kind: file
Node-action: change
Text-content-length: 2529
Text-content-md5: f6b197cc3f2e89a83e545d4bb003de73
+Text-content-sha1: 2f656677cfec0bceec85e53036ffb63e25126f8e
Content-length: 2529
# -DCOLLISION_CHECK if you believe that SHA1's
@@ -510,9 +541,9 @@ backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
-Revision-number: 7
-Prop-content-length: 112
-Content-length: 112
+Revision-number: 8
+Prop-content-length: 116
+Content-length: 116
K 7
svn:log
@@ -520,12 +551,12 @@ V 13
left update 3
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:45.144214Z
+2009-11-12T20:29:48.053835Z
PROPS-END
Node-path: branches/left/Makefile
@@ -533,6 +564,7 @@ Node-kind: file
Node-action: change
Text-content-length: 2593
Text-content-md5: 5ccff689fb290e00b85fe18ee50c54ba
+Text-content-sha1: a13de8e23f1483efca3e57b2b64b0ae6f740ce10
Content-length: 2593
# -DCOLLISION_CHECK if you believe that SHA1's
@@ -614,22 +646,22 @@ backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
-Revision-number: 8
-Prop-content-length: 110
-Content-length: 110
+Revision-number: 9
+Prop-content-length: 116
+Content-length: 116
K 7
svn:log
-V 11
-Merge trunk
+V 13
+Merge trunk 1
K 10
svn:author
-V 4
-samv
+V 8
+tallsopp
K 8
svn:date
V 27
-2009-10-20T01:33:48.176135Z
+2009-11-12T20:29:51.098306Z
PROPS-END
Node-path: trunk
@@ -641,7 +673,7 @@ Content-length: 53
K 13
svn:mergeinfo
V 18
-/branches/left:2-7
+/branches/left:2-8
PROPS-END
@@ -650,6 +682,7 @@ Node-kind: file
Node-action: change
Text-content-length: 2713
Text-content-md5: 0afbe34f244cd662b1f97d708c687f90
+Text-content-sha1: 46d9377d783e67a9b581da110352e799517c8a14
Content-length: 2713
# -DCOLLISION_CHECK if you believe that SHA1's
@@ -734,3 +767,244 @@ backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
+Revision-number: 10
+Prop-content-length: 116
+Content-length: 116
+
+K 7
+svn:log
+V 13
+left update 4
+K 10
+svn:author
+V 8
+tallsopp
+K 8
+svn:date
+V 27
+2009-11-12T20:29:52.081644Z
+PROPS-END
+
+Node-path: branches/left/Makefile
+Node-kind: file
+Node-action: change
+Text-content-length: 2529
+Text-content-md5: f6b197cc3f2e89a83e545d4bb003de73
+Text-content-sha1: 2f656677cfec0bceec85e53036ffb63e25126f8e
+Content-length: 2529
+
+# -DCOLLISION_CHECK if you believe that SHA1's
+# 1461501637330902918203684832716283019655932542976 hashes do not give you
+# enough guarantees about no collisions between objects ever hapenning.
+#
+# -DNSEC if you want git to care about sub-second file mtimes and ctimes.
+# Note that you need some new glibc (at least >2.2.4) for this, and it will
+# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
+# break unless your underlying filesystem supports those sub-second times
+# (my ext3 doesn't).
+CFLAGS=-g -O3 -Wall
+
+CC=gcc
+
+
+PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
+ cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
+ check-files ls-tree merge-base
+
+all: $(PROG)
+
+install: $(PROG)
+ install $(PROG) $(HOME)/bin/
+
+LIBS= -lssl -lz
+
+init-db: init-db.o
+
+update-cache: update-cache.o read-cache.o
+ $(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
+
+show-diff: show-diff.o read-cache.o
+ $(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
+
+write-tree: write-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
+
+read-tree: read-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
+
+commit-tree: commit-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
+
+cat-file: cat-file.o read-cache.o
+ $(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
+
+fsck-cache: fsck-cache.o read-cache.o object.o commit.o tree.o blob.o
+ $(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
+
+checkout-cache: checkout-cache.o read-cache.o
+ $(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
+
+diff-tree: diff-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
+
+rev-tree: rev-tree.o read-cache.o object.o commit.o tree.o blob.o
+ $(CC) $(CFLAGS) -o rev-tree rev-tree.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
+
+show-files: show-files.o read-cache.o
+ $(CC) $(CFLAGS) -o show-files show-files.o read-cache.o $(LIBS)
+
+check-files: check-files.o read-cache.o
+ $(CC) $(CFLAGS) -o check-files check-files.o read-cache.o $(LIBS)
+
+ls-tree: ls-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
+
+merge-base: merge-base.o read-cache.o
+ $(CC) $(CFLAGS) -o merge-base merge-base.o read-cache.o $(LIBS)
+
+read-cache.o: cache.h
+show-diff.o: cache.h
+
+clean:
+ rm -f *.o $(PROG)
+
+backup: clean
+ cd .. ; tar czvf dircache.tar.gz dir-cache
+
+
+Revision-number: 11
+Prop-content-length: 117
+Content-length: 117
+
+K 7
+svn:log
+V 14
+right update 1
+K 10
+svn:author
+V 8
+tallsopp
+K 8
+svn:date
+V 27
+2009-11-12T20:29:53.059636Z
+PROPS-END
+
+Node-path: branches/right/Makefile
+Node-kind: file
+Node-action: change
+Text-content-length: 2593
+Text-content-md5: 5ccff689fb290e00b85fe18ee50c54ba
+Text-content-sha1: a13de8e23f1483efca3e57b2b64b0ae6f740ce10
+Content-length: 2593
+
+# -DCOLLISION_CHECK if you believe that SHA1's
+# 1461501637330902918203684832716283019655932542976 hashes do not give you
+# enough guarantees about no collisions between objects ever hapenning.
+#
+# -DNSEC if you want git to care about sub-second file mtimes and ctimes.
+# Note that you need some new glibc (at least >2.2.4) for this, and it will
+# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
+# break unless your underlying filesystem supports those sub-second times
+# (my ext3 doesn't).
+CFLAGS=-g -O3 -Wall
+
+CC=gcc
+
+
+PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
+ cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
+ check-files ls-tree merge-base
+
+all: $(PROG)
+
+install: $(PROG)
+ install $(PROG) $(HOME)/bin/
+
+LIBS= -lssl -lz
+
+init-db: init-db.o
+
+update-cache: update-cache.o read-cache.o
+ $(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
+
+show-diff: show-diff.o read-cache.o
+ $(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
+
+write-tree: write-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
+
+read-tree: read-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
+
+commit-tree: commit-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
+
+cat-file: cat-file.o read-cache.o
+ $(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
+
+fsck-cache: fsck-cache.o read-cache.o object.o commit.o tree.o blob.o
+ $(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
+
+checkout-cache: checkout-cache.o read-cache.o
+ $(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
+
+diff-tree: diff-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
+
+rev-tree: rev-tree.o read-cache.o object.o commit.o tree.o blob.o
+ $(CC) $(CFLAGS) -o rev-tree rev-tree.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
+
+show-files: show-files.o read-cache.o
+ $(CC) $(CFLAGS) -o show-files show-files.o read-cache.o $(LIBS)
+
+check-files: check-files.o read-cache.o
+ $(CC) $(CFLAGS) -o check-files check-files.o read-cache.o $(LIBS)
+
+ls-tree: ls-tree.o read-cache.o
+ $(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS)
+
+merge-base: merge-base.o read-cache.o object.o commit.o tree.o blob.o
+ $(CC) $(CFLAGS) -o merge-base merge-base.o read-cache.o object.o commit.o tree.o blob.o $(LIBS)
+
+read-cache.o: cache.h
+show-diff.o: cache.h
+
+clean:
+ rm -f *.o $(PROG)
+
+backup: clean
+ cd .. ; tar czvf dircache.tar.gz dir-cache
+
+
+Revision-number: 12
+Prop-content-length: 116
+Content-length: 116
+
+K 7
+svn:log
+V 13
+Merge trunk 2
+K 10
+svn:author
+V 8
+tallsopp
+K 8
+svn:date
+V 27
+2009-11-12T20:29:56.083003Z
+PROPS-END
+
+Node-path: trunk
+Node-kind: dir
+Node-action: change
+Prop-content-length: 54
+Content-length: 54
+
+K 13
+svn:mergeinfo
+V 19
+/branches/left:2-11
+PROPS-END
+
+
--
1.6.5.2.155.gbb47.dirty
^ permalink raw reply related
* [PATCH 2/2] git-svn: handle SVN merges from revisions past the tip of the branch
From: Toby Allsopp @ 2009-11-12 20:18 UTC (permalink / raw)
To: git; +Cc: Sam Vilain, Eric Wong
When recording the revisions that it has merged, SVN sets the top
revision to be the latest revision in the repository, which is not
necessarily a revision on the branch that is being merged from. When
it is not on the branch, git-svn fails to add the extra parent to
represent the merge because it relies on finding the commit on the
branch that corresponds to the top of the SVN merge range.
In order to correctly handle this case, we look for the maximum
revision less than or equal to the top of the SVN merge range that is
actually on the branch being merged from.
Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz>
---
git-svn.perl | 7 +++++--
t/t9151-svn-mergeinfo.sh | 2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 6a3b501..27fbe30 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2950,8 +2950,11 @@ sub find_extra_svn_parents {
my $bottom_commit =
$gs->rev_map_get($bottom, $self->ra_uuid) ||
$gs->rev_map_get($bottom+1, $self->ra_uuid);
- my $top_commit =
- $gs->rev_map_get($top, $self->ra_uuid);
+ my $top_commit;
+ for (; !$top_commit && $top >= $bottom; --$top) {
+ $top_commit =
+ $gs->rev_map_get($top, $self->ra_uuid);
+ }
unless ($top_commit and $bottom_commit) {
warn "W:unknown path/rev in svn:mergeinfo "
diff --git a/t/t9151-svn-mergeinfo.sh b/t/t9151-svn-mergeinfo.sh
index 0d42c84..f57daf4 100755
--- a/t/t9151-svn-mergeinfo.sh
+++ b/t/t9151-svn-mergeinfo.sh
@@ -19,7 +19,7 @@ test_expect_success 'represent svn merges without intervening commits' "
[ `git cat-file commit HEAD^1 | grep parent | wc -l` -eq 2 ]
"
-test_expect_failure 'represent svn merges with intervening commits' "
+test_expect_success 'represent svn merges with intervening commits' "
[ `git cat-file commit HEAD | grep parent | wc -l` -eq 2 ]
"
--
1.6.5.2.155.gbb47.dirty
^ permalink raw reply related
* Re: Git in next is broken
From: Julian Phillips @ 2009-11-12 22:45 UTC (permalink / raw)
To: René Scharfe; +Cc: Nicolas Pitre, git
In-Reply-To: <4AFC8960.9090808@lsrfire.ath.cx>
On Thu, 12 Nov 2009, Ren? Scharfe wrote:
> Nicolas Pitre schrieb:
>> Simply issuing a "git fetch" in my copy of git.git makes glibc complain
>> with this:
>>
>> *** glibc detected *** git: corrupted double-linked list: 0x0000000000974180 ***
>>
>> The gdb backtrace is:
>>
>> (gdb) bt
>> #0 0x0000003c76632f05 in raise () from /lib64/libc.so.6
>> #1 0x0000003c76634a73 in abort () from /lib64/libc.so.6
>> #2 0x0000003c76672438 in __libc_message () from /lib64/libc.so.6
>> #3 0x0000003c76677ec8 in malloc_printerr () from /lib64/libc.so.6
>> #4 0x0000003c7667a23e in _int_free () from /lib64/libc.so.6
>> #5 0x0000003c7667a486 in free () from /lib64/libc.so.6
>> #6 0x0000000000493f3f in ref_remove_duplicates (ref_map=0x7562b0)
>> at remote.c:756
>> #7 0x0000000000424afc in get_ref_map () at builtin-fetch.c:165
>> #8 do_fetch () at builtin-fetch.c:644
>> #9 cmd_fetch (argc=<value optimized out>, argv=0x7fffffffe6a0,
>> prefix=<value optimized out>) at builtin-fetch.c:754
>> #10 0x0000000000403d83 in run_builtin () at git.c:251
>> #11 handle_internal_command (argc=1, argv=0x7fffffffe6a0) at git.c:396
>> #12 0x0000000000403f2d in run_argv () at git.c:438
>> #13 main (argc=1, argv=0x7fffffffe6a0) at git.c:509
>>
>> Bisection reveals the following culprit:
>>
>> commit 73cf0822b2a4ffa7ad559d1f0772e39718fc7776
>> Author: Julian Phillips <julian@quantumfyre.co.uk>
>> Date: Sun Oct 25 21:28:11 2009 +0000
>>
>> remote: Make ref_remove_duplicates faster for large numbers of refs
>
> Can't reproduce because I don't know how to create duplicate refs, but does
> the following help?
>
>
> remote.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/remote.c b/remote.c
> index 4f9f0cc..10cc985 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
> prev->next = ref_map->next;
> free(ref_map->peer_ref);
> free(ref_map);
> + ref_map = next;
You don't need this line (this is taken care of in the for(...)).
> + continue;
Ack. This one however, you do need. Good catch.
> }
>
> item = string_list_insert(ref_map->peer_ref->name, &refs);
>
--
Julian
---
Punishment becomes ineffective after a certain point. Men become insensitive.
-- Eneg, "Patterns of Force", stardate 2534.7
^ permalink raw reply
* Re: Git in next is broken
From: René Scharfe @ 2009-11-12 22:17 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Julian Phillips
In-Reply-To: <alpine.LFD.2.00.0911121513470.16711@xanadu.home>
Nicolas Pitre schrieb:
> Simply issuing a "git fetch" in my copy of git.git makes glibc complain
> with this:
>
> *** glibc detected *** git: corrupted double-linked list: 0x0000000000974180 ***
>
> The gdb backtrace is:
>
> (gdb) bt
> #0 0x0000003c76632f05 in raise () from /lib64/libc.so.6
> #1 0x0000003c76634a73 in abort () from /lib64/libc.so.6
> #2 0x0000003c76672438 in __libc_message () from /lib64/libc.so.6
> #3 0x0000003c76677ec8 in malloc_printerr () from /lib64/libc.so.6
> #4 0x0000003c7667a23e in _int_free () from /lib64/libc.so.6
> #5 0x0000003c7667a486 in free () from /lib64/libc.so.6
> #6 0x0000000000493f3f in ref_remove_duplicates (ref_map=0x7562b0)
> at remote.c:756
> #7 0x0000000000424afc in get_ref_map () at builtin-fetch.c:165
> #8 do_fetch () at builtin-fetch.c:644
> #9 cmd_fetch (argc=<value optimized out>, argv=0x7fffffffe6a0,
> prefix=<value optimized out>) at builtin-fetch.c:754
> #10 0x0000000000403d83 in run_builtin () at git.c:251
> #11 handle_internal_command (argc=1, argv=0x7fffffffe6a0) at git.c:396
> #12 0x0000000000403f2d in run_argv () at git.c:438
> #13 main (argc=1, argv=0x7fffffffe6a0) at git.c:509
>
> Bisection reveals the following culprit:
>
> commit 73cf0822b2a4ffa7ad559d1f0772e39718fc7776
> Author: Julian Phillips <julian@quantumfyre.co.uk>
> Date: Sun Oct 25 21:28:11 2009 +0000
>
> remote: Make ref_remove_duplicates faster for large numbers of refs
Can't reproduce because I don't know how to create duplicate refs, but does
the following help?
remote.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index 4f9f0cc..10cc985 100644
--- a/remote.c
+++ b/remote.c
@@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
prev->next = ref_map->next;
free(ref_map->peer_ref);
free(ref_map);
+ ref_map = next;
+ continue;
}
item = string_list_insert(ref_map->peer_ref->name, &refs);
^ permalink raw reply related
* Re: get git not to care about permissions
From: Matt Schoen @ 2009-11-12 21:44 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jay Soffian, git, euguess
In-Reply-To: <200911121710.44314.trast@student.ethz.ch>
On Thu, Nov 12, 2009 at 11:10 AM, Thomas Rast <trast@student.ethz.ch> wrote:
> It prints an absolute path, so the open() also accesses an absolute
> path (though I don't know why it insists on that).
>
> But the above directory listing would indicate that you do not even
> have permission to look inside your $(pwd) by absolute path...
I'm pretty sure I can. How can I test this? I can ls all
subdirectories within the path, and when I navigate to the path, I
usually do it absolutely. After all, this is a network share, so I
have to start with "/ad/eng/...". Although, this is curious. Some of
the directories show "d---------" when I do ls -al. They were created
by root in the same environment (forced 700), but I can still read
their contents, and such.
Does open() strictly require the permissions you give it? Like I
mentioned, the permissions are locked at 700. Even if I try to chmod
777 the directory, I see no error, but the permissions remain
unchanged. I'm thinking of doing a custom compile, removing those
places where specific permissions are needed. My fear is that those
places are many...
^ permalink raw reply
* git status internals and line endings
From: Marc Strapetz @ 2009-11-12 20:32 UTC (permalink / raw)
To: git
I'm trying to figure out under which circumstances changes in line
endings are resulting in 'modified' status (resp. will be committed). I
have three files with the same content, differing only in line endings:
- file1 is committed with CRLF and has LF in working tree
- file2 is committed with CRLF and has CRLF in working tree
- file3 is committed with LF and has CRLF in working tree
On Linux, file1 and file3 are reported as modified -- as I would expect.
The surprise is on Windows: here only file1 is reported as modified. Why
not file3? Btw, 'git hash-object file3' reports the same SHA as for the
LF-only content in the repository (not so on Linux, as expected).
Is this some special handling on Windows (and possibly on Mac OS)? In
this case, can someone please point me to the corresponding code part?
Thanks for any comments regarding this topic.
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
^ permalink raw reply
* Git in next is broken
From: Nicolas Pitre @ 2009-11-12 20:36 UTC (permalink / raw)
To: git; +Cc: Julian Phillips
Simply issuing a "git fetch" in my copy of git.git makes glibc complain
with this:
*** glibc detected *** git: corrupted double-linked list: 0x0000000000974180 ***
The gdb backtrace is:
(gdb) bt
#0 0x0000003c76632f05 in raise () from /lib64/libc.so.6
#1 0x0000003c76634a73 in abort () from /lib64/libc.so.6
#2 0x0000003c76672438 in __libc_message () from /lib64/libc.so.6
#3 0x0000003c76677ec8 in malloc_printerr () from /lib64/libc.so.6
#4 0x0000003c7667a23e in _int_free () from /lib64/libc.so.6
#5 0x0000003c7667a486 in free () from /lib64/libc.so.6
#6 0x0000000000493f3f in ref_remove_duplicates (ref_map=0x7562b0)
at remote.c:756
#7 0x0000000000424afc in get_ref_map () at builtin-fetch.c:165
#8 do_fetch () at builtin-fetch.c:644
#9 cmd_fetch (argc=<value optimized out>, argv=0x7fffffffe6a0,
prefix=<value optimized out>) at builtin-fetch.c:754
#10 0x0000000000403d83 in run_builtin () at git.c:251
#11 handle_internal_command (argc=1, argv=0x7fffffffe6a0) at git.c:396
#12 0x0000000000403f2d in run_argv () at git.c:438
#13 main (argc=1, argv=0x7fffffffe6a0) at git.c:509
Bisection reveals the following culprit:
commit 73cf0822b2a4ffa7ad559d1f0772e39718fc7776
Author: Julian Phillips <julian@quantumfyre.co.uk>
Date: Sun Oct 25 21:28:11 2009 +0000
remote: Make ref_remove_duplicates faster for large numbers of refs
The ref_remove_duplicates function was very slow at dealing with very
large numbers of refs. This is because it was using a linear search
through all remaining refs to find any duplicates of the current ref.
Rewriting it to use a string list to keep track of which refs have
already been seen and removing duplicates when they are found is much
more efficient.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reverting that commit from next does indeed fix the problem.
Note that this problem doesn't show up with all repositoryes.
Nicolas
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Raman Gupta @ 2009-11-12 20:30 UTC (permalink / raw)
To: skillzero; +Cc: git, trast, gitster
In-Reply-To: <2729632a0911121208r1f51cf9ewb0bc23e757275f30@mail.gmail.com>
skillzero@gmail.com wrote:
>> +.Update maint to new release
>> +[caption="Recipe: "]
>> +=====================================
>> +* `git branch -f next master`
>> +* `git merge ai/topic_in_next1`
>> +* `git merge ai/topic_in_next2`
>
> Shouldn't that be something like "Update next to new release" instead
> of "maint"?
Oops. I changed the caption to "Rewind and rebuild next".
> Should it also have 'git checkout next' after the branch command so
> it's on next before merging?
Right, fixed also.
Thanks,
Raman
^ 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