* Re: [PATCH 3/9] gitweb: Add option to force version match
From: Jakub Narebski @ 2010-01-24 23:17 UTC (permalink / raw)
To: Petr Baudis
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
git
In-Reply-To: <20100124215924.GA9553@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Wed, Jan 13, 2010 at 05:22:59PM -0800, John 'Warthog9' Hawley wrote:
> > +# Throw an error if git versions does not match, if $git_versions_must_match is true.
> > +if ($git_versions_must_match &&
> > + $git_version ne $version) {
> > + my $admin_contact =
> > + defined $ENV{'SERVER_ADMIN'} ? ", $ENV{'SERVER_ADMIN'}," : '';
> > + my $err_msg = <<EOT;
> > +<h1 align="center">*** Warning ***</h1>
> > +<p>
> > +This version of gitweb was compiled for <b>@{[esc_html($version)]}</b>,
> > +however git version <b>@{[esc_html($git_version)]}</b> was found on server,
> > +and administrator requested strict version checking.
+and administrator requested strict version checking by setting
+\$git_versions_must_match to false value (e.g. to 0) in gitweb configuration file,
+'@{[esc_path(-e $GITWEB_CONFIG ? $GITWEB_CONFIG : $GITWEB_CONFIG_SYSTEM)]}'.
> > +</p>
> > +<p>
> > +Please contact the server administrator${admin_contact} to either configure
> > +gitweb to allow mismatched versions, or update git or gitweb installation.
> > +</p>
> > +EOT
> > + die_error(500, 'Internal server error', $err_msg);
> > +}
> > +
>
> I get very unhappy when *I* am the server administrator and read
> messages like this. ;-) Could you please mention the
> \$git_versions_must_match in the text?
Something like the text (extension) proposed above?
Actually, J.H., if you are changing the default, you should also change the
message to mention that checking versions is the default, and administrator
can turn it off[1]. It is incorrect if $git_versions_must_match defaults
to true.
[1] And you have to take into account that gitweb config file can not
exist, and neither $GITWEB_CONFIG nor $GITWEB_CONFIG_SYSTEM needs to be
non-empty. J.H., are you really, really sure that it is a good idea to
have version check turned on by default, in light of this issue?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Understanding git.git's branch policy
From: Steven E. Harris @ 2010-01-24 23:34 UTC (permalink / raw)
To: git
Radding the maintain-git.txt document¹, there are a few points that I'm
having trouble decoding. Under "The Policy", it notes
,----
| The tips of 'master', 'maint' and 'next' branches will always
| fast-forward, to allow people to build their own customization on top
| of them.
`----
I understand that a "fast-forward merge" means that one's current HEAD
commit is an ancestor of the evolved branch's head, so that the HEAD
pointer can move forward to "catch up" without needing to combine
disparate content.
How does this relate to the prescribed use of the "master", "maint", and
"next" branches? What operations or patterns does it constrain against?
Footnotes:
¹ http://kernel.org/pub/software/scm/git/docs/howto/maintain-git.txt
--
Steven E. Harris
^ permalink raw reply
* Re: git push failed
From: Jay Soffian @ 2010-01-24 23:35 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git
In-Reply-To: <6672d0161001240952s7f7629a6v48f5756c083b95b5@mail.gmail.com>
2010/1/24 Björn Gustavsson <bgustavsson@gmail.com>:
> With git built from master (v1.6.6.1-436-gaba7dea),
> the following commands (run in a script):
>
> git commit --amend -m "Update index.html" index.html
> git push erlang +gh-pages
>
> failed like this:
>
> Counting objects: 4, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (3/3), 3.85 KiB, done.
> Total 3 (delta 0), reused 0 (delta 0)
> error: Ref refs/heads/gh-pages is at
> db10c045e068f12aa2f78377fab31e35a8443ca4 but expected
> 054136d96494979b42524a4dc08ef643bb54cc0e
> error: failed to lock refs/heads/gh-pages
> To git@erlang_github.com:erlang/otp.git
> ! [remote rejected] gh-pages -> gh-pages (failed to lock)
> error: failed to push some refs to 'git@erlang_github.com:erlang/otp.git'
>
> Unfortunately (from the point of view of finding the bug), the
> problem is not reproducible. When I ran my script two more times,
> it worked fine.
>
> We all know how difficult it is to investigate non-reproducible bugs,
> but perhaps someone familiar with the code might have some idea
> about what it could be.
>
> Info about my system:
>
> Mac OS X 10.2.6 (8 cores)
> gcc-4.2.1
As another data point, I've noticed the same issue pushing from one
Mac OS X 10.6.2 system to another. However, the remote end is updated
properly (if you push again you'll see there's nothing to update), so
I've not bothered to dig into what the cause might be.
j.
^ permalink raw reply
* Re: basic question about push
From: Jay Soffian @ 2010-01-24 23:59 UTC (permalink / raw)
To: Jeff King; +Cc: Russ Paielli, git, Junio C Hamano
In-Reply-To: <20100124081513.GA10700@coredump.intra.peff.net>
On Sun, Jan 24, 2010 at 3:15 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Jan 24, 2010 at 07:04:59AM +0000, Russ Paielli wrote:
>
>> warning: updating the current branch
>> [...]
>> What does this mean in English? And what is the correct way to transfer my
>> revisions from my home computer to my work computer? Thanks.
>
> It means your workflow will cause problems as the pusher magically
> changes your repository's concept of "the latest commit" behind the
> pushee's back. The workflow you want is described here:
>
> http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch
Aside, and I think we've discussed this before, but I wonder if it
would make sense to:
a) Add an option to clone such as "-p [<name>] | --push-as[=<name>]"
where <name> defaults to $(uname -n | cut -f1 -d.) This would setup
the cloned repo with a push refspec
"+refs/heads/*:refs/remotes/<name>/*". e.g.:
$ git clone -o host1 -p host2 ssh://host1/~/repo.git
$ cat repo/.git/config
...
[remote "host1"]
url = ssh://host1/~/repo.git
fetch = +refs/heads/*:refs/remotes/host1/*
push = +refs/heads/*:refs/remotes/host2/*
b) The controversial part: make this option the default the default
when cloning from a non-bare repo. There would need to be some way to
turn it off.
Of course, I'm not sure this would be any less confusing for users.
Would they wonder why they have to merge to see their pushed changes
reflected on the pushed-to repo?
It does nicely make push symmetric to fetch between two non-bare repos
though, and I think maybe that makes more sense.
j.
^ permalink raw reply
* Re: [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when regenerating cache (WIP)
From: Jakub Narebski @ 2010-01-25 0:03 UTC (permalink / raw)
To: Petr Baudis
Cc: git, John 'Warthog9' Hawley,
John 'Warthog9' Hawley
In-Reply-To: <20100124222417.GC9553@machine.or.cz>
On Sun, 24 Jan 2010, Petr Baudis wrote:
> I have stupid question, common to both the original patch and this
> RFC.
>
> > [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when
> > regenerating cache (WIP)
>
> Just why is a "Generating..." page appropriate?
>
> I have to admit I hate it; can you please at least make it
> configurable? Why is it needed at all? It generates unnecessary
> redirects, clears my previous page in the browser by a useless
> placeholder, confuses non-interactive HTTP clients and I just can't
> see the real purpose.
>
> What's the gain?
Don't ask me, I am just following original patch by John 'Warthog9'
Hawley (J.H.) here, splitting it into smaller and hopefully easier to
review parts, with each separate feature in a separate patch (so that
features like this one are more visible). I _think_ that in original
patch by J.H. this feature was configurable (at least to some extent).
As this series is more proof of concept than ready to apply patches,
some of configurability is missing currently.
I think that adding the "Generating..." page follows behavior of other
well known web applications, such as for example GMail. Currently
if caching is enabled, and there is no appropriate entry in cache (not
even [slightly] stale entry) the page is shown only when it is generated
in full: there is no streaming (although I planned to add it). So for
example for 'blame' view or for pickaxe search you could wait quite
a bit for a page to be shown. The "Generating..." page is a kind of
activity indicator here.
Note that the JavaScript-using Ajax-y version from the following patch
'[RFC PATCH 11/10] gitweb: Ajax-y "Generating..." page when
regenerating cache (WIP)'
http://permalink.gmane.org/gmane.comp.version-control.git/137896
is not visible in browser history, as it simply replaces "Generating..."
page with the result. So there is no 'unnecessary redirect', and there
is no 'useless placeholder' in browser history.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Understanding git.git's branch policy
From: Petr Baudis @ 2010-01-25 0:17 UTC (permalink / raw)
To: Steven E. Harris; +Cc: git
In-Reply-To: <83pr4znklo.fsf@torus.sehlabs.com>
On Sun, Jan 24, 2010 at 06:34:11PM -0500, Steven E. Harris wrote:
> Radding the maintain-git.txt document¹, there are a few points that I'm
> having trouble decoding. Under "The Policy", it notes
>
> ,----
> | The tips of 'master', 'maint' and 'next' branches will always
> | fast-forward, to allow people to build their own customization on top
> | of them.
> `----
>
> I understand that a "fast-forward merge" means that one's current HEAD
> commit is an ancestor of the evolved branch's head, so that the HEAD
> pointer can move forward to "catch up" without needing to combine
> disparate content.
>
> How does this relate to the prescribed use of the "master", "maint", and
> "next" branches? What operations or patterns does it constrain against?
Rebases or other jumps. New tip of 'master' will always be descendant of
old tip of 'master', never a commit from a parallel commit line. This is
preserved over commits and merges, but not over operations that rewrite
history - rebase, filter-branch and such.
The term "fast-forward" is used commonly in this sense. E.g. git push
will typically deny you to push out a branch that is not fastforwarding
the currently pushed out branch, unless you force it to.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* [PATCH] Handle UNC paths everywhere
From: Robin Rosenberg @ 2010-01-25 0:55 UTC (permalink / raw)
To: git, Johannes Sixt, Junio C Hamano
>From 37a74ccd395d91e5662665ca49d7f4ec49811de0 Mon Sep 17 00:00:00 2001
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Mon, 25 Jan 2010 01:41:03 +0100
Subject: [PATCH] Handle UNC paths everywhere
In Windows paths beginning with // are knows as UNC paths. They are
absolute paths, usually referring to a shared resource on a server.
Examples of legal UNC paths
\\hub\repos\repo
\\?\unc\hub\repos
\\?\d:\repo
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
cache.h | 2 +-
compat/basename.c | 2 +-
compat/mingw.h | 8 +++++++-
connect.c | 2 +-
git-compat-util.h | 9 +++++++++
path.c | 2 +-
setup.c | 2 +-
sha1_file.c | 20 ++++++++++++++++++++
transport.c | 2 +-
9 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/cache.h b/cache.h
index 767a50e..8f63640 100644
--- a/cache.h
+++ b/cache.h
@@ -648,7 +648,7 @@ int safe_create_leading_directories_const(const char
*path);
char *enter_repo(char *path, int strict);
static inline int is_absolute_path(const char *path)
{
- return path[0] == '/' || has_dos_drive_prefix(path);
+ return path[0] == '/' || has_win32_abs_prefix(path);
}
int is_directory(const char *);
const char *make_absolute_path(const char *path);
diff --git a/compat/basename.c b/compat/basename.c
index d8f8a3c..c1d81f6 100644
--- a/compat/basename.c
+++ b/compat/basename.c
@@ -5,7 +5,7 @@ char *gitbasename (char *path)
{
const char *base;
/* Skip over the disk name in MSDOS pathnames. */
- if (has_dos_drive_prefix(path))
+ if (has_win32_abs_prefix(path))
path += 2;
for (base = path; *path; path++) {
if (is_dir_sep(*path))
diff --git a/compat/mingw.h b/compat/mingw.h
index 1b528da..d1aa8be 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -210,7 +210,13 @@ int winansi_fprintf(FILE *stream, const char *format,
...) __attribute__((format
* git specific compatibility
*/
-#define has_dos_drive_prefix(path) (isalpha(*(path)) && (path)[1] == ':')
+#define has_dos_drive_prefix(path) \
+ (isalpha(*(path)) && (path)[1] == ':')
+#define has_unc_prefix(path) \
+ (is_dir_sep((path)[0]) && is_dir_sep((path)[1]))
+#define has_win32_abs_prefix(path) \
+ (has_dos_drive_prefix(path) || has_unc_prefix(path))
+
#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
#define PATH_SEP ';'
#define PRIuMAX "I64u"
diff --git a/connect.c b/connect.c
index 7945e38..9d4556c 100644
--- a/connect.c
+++ b/connect.c
@@ -535,7 +535,7 @@ struct child_process *git_connect(int fd[2], const char
*url_orig,
end = host;
path = strchr(end, c);
- if (path && !has_dos_drive_prefix(end)) {
+ if (path && !has_win32_abs_prefix(end)) {
if (c == ':') {
protocol = PROTO_SSH;
*path++ = '\0';
diff --git a/git-compat-util.h b/git-compat-util.h
index ef60803..0de9dac 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -170,6 +170,15 @@ extern char *gitbasename(char *);
#define has_dos_drive_prefix(path) 0
#endif
+#ifndef has_unc_prefix
+#define has_unc_prefix(path) 0
+#endif
+
+#ifndef has_win32_abs_prefix
+#error no abs
+#define has_win32_abs_prefix(path) 0
+#endif
+
#ifndef is_dir_sep
#define is_dir_sep(c) ((c) == '/')
#endif
diff --git a/path.c b/path.c
index 047fdb0..79451a2 100644
--- a/path.c
+++ b/path.c
@@ -409,7 +409,7 @@ int normalize_path_copy(char *dst, const char *src)
{
char *dst0;
- if (has_dos_drive_prefix(src)) {
+ if (has_win32_abs_prefix(src)) {
*dst++ = *src++;
*dst++ = *src++;
}
diff --git a/setup.c b/setup.c
index 029371e..4f72817 100644
--- a/setup.c
+++ b/setup.c
@@ -342,7 +342,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
die_errno("Unable to read current working directory");
ceil_offset = longest_ancestor_length(cwd, env_ceiling_dirs);
- if (ceil_offset < 0 && has_dos_drive_prefix(cwd))
+ if (ceil_offset < 0 && has_win32_abs_prefix(cwd))
ceil_offset = 1;
/*
diff --git a/sha1_file.c b/sha1_file.c
index 4cc8939..f1ad3f5 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -87,6 +87,26 @@ static inline int offset_1st_component(const char *path)
{
if (has_dos_drive_prefix(path))
return 2 + (path[2] == '/');
+ if (has_unc_prefix(path)) {
+ int p = 2;
+ int skip;
+ if (path[p] == '?') {
+ if (path[p+1] && !has_dos_drive_prefix(path+p+2)) {
+ skip = 3;
+ } else {
+ skip = 2;
+ }
+ } else
+ skip = 2;
+
+ while (skip && path[p]) {
+ if (is_dir_sep(path[p]))
+ --skip;
+ ++p;
+ }
+ printf("Left with %s\n", path+p);
+ return p;
+ }
return *path == '/';
}
diff --git a/transport.c b/transport.c
index 644a30a..9f5b24e 100644
--- a/transport.c
+++ b/transport.c
@@ -797,7 +797,7 @@ static int is_local(const char *url)
const char *colon = strchr(url, ':');
const char *slash = strchr(url, '/');
return !colon || (slash && slash < colon) ||
- has_dos_drive_prefix(url);
+ has_win32_abs_prefix(url);
}
static int is_file(const char *url)
--
1.6.4.msysgit.0.598.g37a74
^ permalink raw reply related
* Re: [PATCH] Handle double slashes in make_relative_path()
From: Robin Rosenberg @ 2010-01-25 1:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Thomas Rast, git, Linus Torvalds
In-Reply-To: <7v8wbn8ie2.fsf@alter.siamese.dyndns.org>
söndagen den 24 januari 2010 19.31.01 skrev Junio C Hamano:
> Johannes Sixt <j6t@kdbg.org> writes:
> > On Samstag, 23. Januar 2010, Johannes Sixt wrote:
> >> On Samstag, 23. Januar 2010, Junio C Hamano wrote:
> >> > What happens if you did this?
> >> >
> >> > git --git-dir=//git/repo/repo.git --work-tree=/git/repo
> >> >
> >> > where "//git/repo" is on the "git server" and you are working in local
> >> > hierarchy "/git/repo"?
> >>
> >> Ah, right, this would not do the right thing. (But I can't verify this
> >> claim right now.)
> >
> > I tested it, and it does the right thing. The reason is that before
> > setup_work_tree() calls make_relative_path(), the --work-tree argument
> > has been processed by make_absolute_path(), which adds the drive prefix.
> >
> > As long as setup_work_tree() remains the only caller of
> > make_relative_path(), we are safe.
>
> Thanks; I think a more correct description of your findings is:
>
> - msysgit's make_absolute_path() does the right thing (i.e. adds "drive
> prefix" to "git/repo" given to --work-tree); and
>
> - as long as the callers feed what the platform considers absolute paths
> in abs and base, make_relative_path() does the right thing.
>
> So I think we are Ok. We _might_ want to add Windows-only test at the
> beginning of make_relative_path() to make sure that the both inputs have
> double-slashes at the beginning to catch future broken callers, but I
> think that is a separate topic, and we don't have to do that as long as
> setup_work_tree(0 remains the only caller, as you said.
Separate patch posted since this problem occurs in more than one place.
-- robin
^ permalink raw reply
* Re: [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when regenerating cache (WIP)
From: Jakub Narebski @ 2010-01-25 1:17 UTC (permalink / raw)
To: Petr Baudis
Cc: git, John 'Warthog9' Hawley,
John 'Warthog9' Hawley
In-Reply-To: <201001250103.38703.jnareb@gmail.com>
Jakub Narebski wrote:
> On Sun, 24 Jan 2010, Petr Baudis wrote:
>
> > I have stupid question, common to both the original patch and this
> > RFC.
> >
> > > [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when
> > > regenerating cache (WIP)
> >
> > Just why is a "Generating..." page appropriate?
> >
> > I have to admit I hate it; can you please at least make it
> > configurable? Why is it needed at all? It generates unnecessary
> > redirects, clears my previous page in the browser by a useless
> > placeholder, confuses non-interactive HTTP clients and I just can't
> > see the real purpose.
> Note that the JavaScript-using Ajax-y version from the following patch
> '[RFC PATCH 11/10] gitweb: Ajax-y "Generating..." page when
> regenerating cache (WIP)'
> http://permalink.gmane.org/gmane.comp.version-control.git/137896
> is not visible in browser history, as it simply replaces "Generating..."
> page with the result. So there is no 'unnecessary redirect', and there
> is no 'useless placeholder' in browser history.
Actually I have checked and the version used on git.kernel.org does show
"Generating..." page, but it does not appear in the history. I guess
that refresh with no URL does not count as redirect.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 8/9] gitweb: Convert output to using indirect file handle
From: Jakub Narebski @ 2010-01-25 1:47 UTC (permalink / raw)
To: Petr Baudis, John 'Warthog9' Hawley
Cc: John 'Warthog9' Hawley, git
In-Reply-To: <20100124221444.GB9553@machine.or.cz>
On Sun, Jan 24, 2010 at 23:14 +0100, Petr Baudis wrote:
> On Fri, Jan 15, 2010 at 04:43:32PM -0800, Jakub Narebski wrote:
> > Third, wouldn't it be better to use shorter variable name, e.g. $out
> > or $oh, instead of $output_handle? We would be able to align print(f)
> > statements without making lines much longer.
>
> I totally agree, I was going to comment on this too. Please use
> something very short, I think even the three characters might be pushing
> it a bit. Having long idiom will make it real pain to both read and
> write gitweb code.
>
> It would still be nice if we could have some way to avoid this hack
> entirely. Couldn't we layer PerlIO::via over STDOUT and continue to use
> argument-less print as before?
First, the original version in v2 series, the one that can be found in
42641b1 (GITWEB - File based caching layer, 2009-12-10) commit in
git://git.kernel.org/pub/scm/git/warthog9/gitweb.git gitweb-ml-v2
http://git.kernel.org/?p=git/warthog9/gitweb.git;a=shortlog;h=refs/heads/gitweb-ml-v2
the change was even larger. It was
print <something>;
replaced by
$output .= <something>;
and of course make functions that printed sth return formatted output
instead.
Also with original version you paid the price even if caching was turned
off (not used): the whole output had to fit in memory, and there was no
streaming, which meant that the whole output had to be generated before
it could be displayed (decreasing latency).
Second, PerlIO::via is not a good solution. One solution would be to
require Capture::Tiny if caching is enabled, and just do
$out = capture {
$actions{$action}->();
}
or even simply (if it is possible with the way 'capture' is prototyped)
$out = capture $actions{$action};
Another solution would be to use PerlIO::Util to redirect output to
scalar:
*STDOUT->push_layer(scalar => \$buffer);
# ...
*STDOUT->pop_layer();
Yet another solution would be to manipulate *STDOUT directly
$stdout = *STDOUT;
*STDOUT = $buffer_fh;
...
*STDOUT = $stdout;
for which, I think, to be done correctly we would have to duplicate
(large?) parts of Capture::Tiny.
So there is a bit of rule of preservation of difficulty at work. Either
we have large patch adding explicit filehandle to all print statements
'print <sth> -> print $out <sth>' but simple code, or have smaller patch
but complicated *STDOUT manipulation, or have small patch but rely on
non-core CPAN modules present.
> I think we (well, in practice, "you" nowadays :) should be less
> perfectionist when accepting gitweb contributions, so if the answer is
> "it's too hard for me to do right now", that's fine I guess; I know I
> can't contribute the code currently. :(
True. At least two series ('categories' which I have copy locally
in http://repo.or.cz/w/git/jnareb-git.git as gitweb/category, and
'committags' by Marcel M. Cary[1]) that are not yet in gitweb because
of that...
[1]: http://thread.gmane.org/gmane.comp.version-control.git/100418/focus=133141
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 06/18] rebase -i: Document how temporary files are used
From: Greg Price @ 2010-01-25 3:38 UTC (permalink / raw)
To: Michael Haggerty; +Cc: gitster, Johannes.Schindelin, git, Greg Price
In-Reply-To: <ec177b9d2b2354c446793df42525b4f7377bc413.1263447037.git.mhagger@alum.mit.edu>
Michael Haggerty wrote:
> Add documentation, inferred by reverse-engineering, about how
> git-rebase--interactive.sh uses many of its temporary files.
Brilliant! I like the 'fixup' command and look forward to using it,
but this is probably my favorite commit in the series. I did the same
reverse-engineering a few months ago and didn't think to write it down
and save you having to do it. Now you have saved the next person from
doing so.
This and your refactoring commits will cause me some annoyance as I
bring the rebase -i -p series up to date, but that just means I should
hurry up and get it in shape for merge rather than continue to have to
resolve conflicts.
Greg
^ permalink raw reply
* What's cooking in git.git (Jan 2010, #08; Sun, 24)
From: Junio C Hamano @ 2010-01-25 4:39 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
--------------------------------------------------
[Graduated to "master"]
* jc/fix-tree-walk (2009-09-14) 7 commits
(merged to 'next' on 2010-01-13 at 1c01b87)
+ read-tree --debug-unpack
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
This is fix for a tricky codepath; I've been using this personally during
the whole cycle up to point, so hopefully it finally have nailed all the
corner cases? Knock wood...
--------------------------------------------------
[New Topics]
* cc/reset-keep (2010-01-19) 5 commits
- reset: disallow using --keep when there are unmerged entries
- reset: disallow "reset --keep" outside a work tree
- Documentation: reset: describe new "--keep" option
- reset: add test cases for "--keep" option
- reset: add option "--keep" to "git reset"
I do not think I'd ever use this, and I am not convinced I can sell this
to users as a great new feature without confusing them unnecessarily, but
perhaps queuing it to pu to give it wider visibility may help somebody
coming up with a better way to defend the feature and introduce it to
users without confusing them than Christan nor I managed to.
* jc/ce-uptodate (2010-01-24) 1 commit
- Make ce_uptodate() trustworthy again
I think this and Jens Lehmann's follow-up patch to avoid calling
is_submodule_modified() are needed before 1.7.0
--------------------------------------------------
[Cooking]
* jh/notes (2010-01-17) 20 commits
- builtin-gc: Teach the new --notes option to garbage-collect notes
- Notes API: gc_notes(): Prune notes that belong to non-existing objects
- t3305: Verify that removing notes triggers automatic fanout consolidation
- builtin-notes: Teach -d option for deleting existing notes
- Teach builtin-notes to remove empty notes
- Teach notes code to properly preserve non-notes in the notes tree
- t3305: Verify that adding many notes with git-notes triggers increased fanout
- t3301: Verify successful annotation of non-commits
- Builtin-ify git-notes
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: write_notes_tree(): Store the notes tree in the database
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: remove_note(): Remove note objects from the notes tree structure
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Add tests for checking correct handling of $GIT_NOTES_REF and core.notesRef
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Minor non-functional fixes to notes.c
The changes to test vector this series makes to t3301 breaks tests that
are in 'master', so 'pu' doesn't pass it.
* jh/gitweb-cached (2010-01-13) 9 commits
- gitweb: File based caching layer (from git.kernel.org)
- gitweb: Convert output to using indirect file handle
- gitweb: cleanup error message produced by undefined $site_header
- gitweb: add a get function to compliment print_sort_th
- gitweb: add a get function to compliment print_local_time
- gitweb: Makefile improvements
- gitweb: Add option to force version match
- gitweb: change die_error to take "extra" argument for extended die information
- gitweb: Load checking
I know there is a series to split the later ones into smaller chunks that
are being discussed on the list, but they don't appear here. I'd prefer
to pick the series up after all the dust from the discussion settles.
* jc/grep-author-all-match-implicit (2010-01-17) 1 commit
- "log --author=me --grep=it" should find intersection, not union
^ permalink raw reply
* Re: [PATCH 0/5] Makefile: add missing header dependency rules
From: Junio C Hamano @ 2010-01-25 4:44 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Junio C Hamano
In-Reply-To: <20100123144201.GA11903@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> These patches are independent of the jn/makefile topic. I sent them
> before, but I screwed up the sender so nobody received them. Anyway,
> perhaps they could be useful.
I found all of them sensible but it seems to be based on version that is a
bit behind...
^ permalink raw reply
* [PATCH] commit-tree: remove unused #define
From: Stephen Boyd @ 2010-01-25 7:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
---
The fixme looks very suspicious too...
builtin-commit-tree.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index ddcb7a4..90dac34 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -9,8 +9,6 @@
#include "builtin.h"
#include "utf8.h"
-#define BLOCKING (1ul << 14)
-
/*
* FIXME! Share the code with "write-tree.c"
*/
--
1.6.6.1.436.gaba7d
^ permalink raw reply related
* [PATCH] rebase: replace antiquated sed invocation
From: Stephen Boyd @ 2010-01-25 7:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Use the modern form of printing a commit subject instead of piping
the output of rev-list to sed.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
git-rebase.sh | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index eddc028..b5d9178 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -85,10 +85,8 @@ continue_merge () {
printf "Already applied: %0${prec}d " $msgnum
fi
fi
- if test -z "$GIT_QUIET"
- then
- git rev-list --pretty=oneline -1 "$cmt" | sed -e 's/^[^ ]* //'
- fi
+ test -z "$GIT_QUIET" &&
+ git log --format=%s -1 "$cmt"
prev_head=`git rev-parse HEAD^0`
# save the resulting commit so we can read-tree on it later
--
1.6.6.1.436.gaba7d
^ permalink raw reply related
* git not adding subdirectories to repository on Windows
From: habilis @ 2010-01-25 7:39 UTC (permalink / raw)
To: git
Hi
I am using netbeans 6.7 with nbgit 0.3 and PHP plugins, on Windows XP.
I create my project in Netbeans, and then initialises git. All the files in
my root directory can by added and committed to my repository, but not any
files in my subfolders. The 'commit' option is greyed out on any files in
subfolders. This happens regardless of whether I added the subdirectory
before or after initialising git, and regardless any editing and saving I do
with files in subdirectories.
Initialising and adding files to the repository via the bash shell picks up
that I edited files in a subdirectory, but, Netbeans still doesnt pick up
the files have been changed, and no history is available.
Status, and Update links on the menu is active, but diff and commit stays
greyed out.
Anyone knows how to fix this?
Thank you
--
View this message in context: http://n2.nabble.com/git-not-adding-subdirectories-to-repository-on-Windows-tp4452655p4452655.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] t5541-http-push: make grep expression check for one line only
From: Tay Ray Chuan @ 2010-01-25 7:42 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Simplify the grep expressions in the non-fast-forward tests to check
only for the first line of the non-fast-forward warning - having that
line should be enough assurance that the full warning is printed.
In the first place, grep can't deal with expressions for multiple
lines.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
t/t5541-http-push.sh | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index 83a8e14..53f54a2 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -105,10 +105,8 @@ test_expect_success 'non-fast-forward push show ref status' '
'
test_expect_success 'non-fast-forward push shows help message' '
- grep \
-"To prevent you from losing history, non-fast-forward updates were rejected
-Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
-section of '"'git push --help'"' for details." output
+ grep "To prevent you from losing history, non-fast-forward updates were rejected" \
+ output
'
test_expect_success 'push fails for non-fast-forward refs unmatched by remote helper' '
@@ -126,10 +124,8 @@ test_expect_success 'push fails for non-fast-forward refs unmatched by remote he
grep "^ + [a-f0-9]*\.\.\.[a-f0-9]* *master -> master (forced update)$" output &&
grep "^ ! \[rejected\] *master -> retsam (non-fast-forward)$" output &&
- grep \
-"To prevent you from losing history, non-fast-forward updates were rejected
-Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
-section of '"'git push --help'"' for details." output
+ grep "To prevent you from losing history, non-fast-forward updates were rejected" \
+ output
'
stop_httpd
--
1.6.6
^ permalink raw reply related
* Re: [PATCH] commit-tree: remove unused #define
From: Daniel @ 2010-01-25 9:17 UTC (permalink / raw)
To: git, Stephen Boyd; +Cc: Junio C Hamano
In-Reply-To: <1264403143-11320-1-git-send-email-bebarino@gmail.com>
> ---
>
> The fixme looks very suspicious too...
According to git blame it belongs to the same revision as BLOCKING
-- initial commit. So probably it can be removed with BLOCKING.
>
> builtin-commit-tree.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
> index ddcb7a4..90dac34 100644
> --- a/builtin-commit-tree.c
> +++ b/builtin-commit-tree.c
> @@ -9,8 +9,6 @@
> #include "builtin.h"
> #include "utf8.h"
>
> -#define BLOCKING (1ul << 14)
> -
> /*
> * FIXME! Share the code with "write-tree.c"
> */
> --
> 1.6.6.1.436.gaba7d
>
-- Daniel
^ permalink raw reply
* Re: [PATCH] Handle UNC paths everywhere
From: Sverre Rabbelier @ 2010-01-25 9:36 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Johannes Sixt, Junio C Hamano, Johannes Schindelin
In-Reply-To: <201001250155.47664.robin.rosenberg@dewire.com>
Heya,
On Mon, Jan 25, 2010 at 01:55, Robin Rosenberg
<robin.rosenberg@dewire.com> wrote:
> In Windows paths beginning with // are knows as UNC paths. They are
> absolute paths, usually referring to a shared resource on a server.
Cute, but will it actually work? I've tried to use them // paths on
windows before with MSysGit, and it's never worked, probably due to
the same reason why it doesn't work in the cmd prompt (whatever reason
that may be).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Handle UNC paths everywhere
From: Robin Rosenberg @ 2010-01-25 9:58 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, Johannes Sixt, Junio C Hamano, Johannes Schindelin
In-Reply-To: <fabb9a1e1001250136n2fb0043av7348db9177f4d096@mail.gmail.com>
måndagen den 25 januari 2010 10.36.59 skrev Sverre Rabbelier:
> Heya,
>
> On Mon, Jan 25, 2010 at 01:55, Robin Rosenberg
>
> <robin.rosenberg@dewire.com> wrote:
> > In Windows paths beginning with // are knows as UNC paths. They are
> > absolute paths, usually referring to a shared resource on a server.
>
> Cute, but will it actually work? I've tried to use them // paths on
> windows before with MSysGit, and it's never worked, probably due to
Works here (tm). Latest msygit + rebuilt git binaries on Windows 2003.
The only program I know in the msysgit installation that didn't accept UNC
paths prior to this patch was in fact git.
> the same reason why it doesn't work in the cmd prompt (whatever reason
> that may be).
Any code of the this form will of course not support UNC paths:
if (!has_drive_letter(path))
boom();
-- robin
^ permalink raw reply
* Re: [PATCH] Handle UNC paths everywhere
From: Erik Faye-Lund @ 2010-01-25 10:11 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Robin Rosenberg, git, Johannes Sixt, Junio C Hamano,
Johannes Schindelin
In-Reply-To: <fabb9a1e1001250136n2fb0043av7348db9177f4d096@mail.gmail.com>
On Mon, Jan 25, 2010 at 10:36 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Mon, Jan 25, 2010 at 01:55, Robin Rosenberg
> <robin.rosenberg@dewire.com> wrote:
>> In Windows paths beginning with // are knows as UNC paths. They are
>> absolute paths, usually referring to a shared resource on a server.
>
> Cute, but will it actually work? I've tried to use them // paths on
> windows before with MSysGit, and it's never worked, probably due to
> the same reason why it doesn't work in the cmd prompt (whatever reason
> that may be).
>
This works for me, Vista 64-bit:
C:\Users\kusma>dir \\mongo\code
The request is not supported.
C:\Users\kusma>explorer \\mongo\code
<login on the gui>
C:\Users\kusma>dir \\mongo\code
Volume in drive \\mongo\code is Code
Volume Serial Number is 04C3-0225
Directory of \\mongo\code
10.01.2010 21:39 <DIR> .
04.01.2010 01:28 <DIR> ..
04.01.2010 00:51 <DIR> qt-rocket
10.01.2010 21:38 <DIR> very_last_64k_ever
11.01.2010 19:57 <DIR> scratch
0 File(s) 0 bytes
5 Dir(s) 958 499 627 008 bytes free
C:\Users\kusma>
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH] Handle UNC paths everywhere
From: Sverre Rabbelier @ 2010-01-25 10:22 UTC (permalink / raw)
To: kusmabite
Cc: Robin Rosenberg, git, Johannes Sixt, Junio C Hamano,
Johannes Schindelin
In-Reply-To: <40aa078e1001250211w2dcc5e97vf89f64f136bd2f0@mail.gmail.com>
Heya,
On Mon, Jan 25, 2010 at 11:11, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> C:\Users\kusma>dir \\mongo\code
> The request is not supported.
>
> C:\Users\kusma>explorer \\mongo\code
> <login on the gui>
>
> C:\Users\kusma>dir \\mongo\code
> Volume in drive \\mongo\code is Code
> Volume Serial Number is 04C3-0225
Ah, that's very interesting. Not sure that will help MSysGit a lot though.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* git status showing phantom modifications
From: Michael Ludwig @ 2010-01-25 10:41 UTC (permalink / raw)
To: git@vger.kernel.org
This is on Cygwin, package git-1.6.4.2-1 [1]:
michael@wladimir:/cygdrive/m/REPOS6.TECH.git :-) git st
# On branch master
nothing to commit (working directory clean)
Note: This repository is a fresh conversion from a subversion repository.
As mentioned, this is Cygwin on XP Home, and the filesystem is NTFS.
michael@wladimir:/cygdrive/m/REPOS6.TECH.git :-) cd comp
Note: The directory I've cd'd into is not a submodule, just a regular part
of the working copy.
michael@wladimir:/cygdrive/m/REPOS6.TECH.git/comp :-) git st
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: mw/wsdl-version.txt
# modified: net/httpsrvr/iis6.wodo
# ... and about 100 more of that ...
I would expect the output of git status to be consistent regardless of my
position in the working directory.
Git bug, Cygwin issue, or some oversight of mine?
[1] http://cygwin.com/packages/git/
--
Michael.Ludwig (#) XING.com
^ permalink raw reply
* Perforce vcs-helper
From: Tor Arvid Lund @ 2010-01-25 10:57 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Git mailing list
Hi, Daniel.
I remember that you posted a vcs-p4 transport helper last year... And
I basically wondered whether or not that is something that you're
still working on. As I understand it, the transport helper framework
will be part of git 1.7, and I thought it would be interesting to test
your code.
The current git-p4 script is nice, of course, but I would much like to
try the "detect branches and integrations" stuff :-)
All the best,
-Tor Arvid-
^ permalink raw reply
* Re: basic question about push
From: Jeff King @ 2010-01-25 11:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Russ Paielli, git
In-Reply-To: <7vzl43723t.fsf@alter.siamese.dyndns.org>
On Sun, Jan 24, 2010 at 11:08:06AM -0800, Junio C Hamano wrote:
> > http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch
>
> I saw somebody referred to this entry and refused to study the entry
> immediately after seeing the word "firewalled", saying "my environment is
> not firewalled", without trying to judge if the description applies to his
> case. This was understandable; the workflow will apply in non-firewalled
> case just as well, even though "firewalled" case may be the easiest to see
> why it is recommended.
>
> Perhaps the title of the entry needs to be rewritten to clarify that this
> is not _limited_ to a firewalled situation?
I agree, and just tweaked the title and text a bit. After doing that, I
realized that you had already done so a few hours ago, too. :) So
between the two of us, hopefully it is better.
-Peff
^ 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