* Re: [PATCH] git-clone: lose the traditional 'no-separate-remote' layout
From: Linus Torvalds @ 2006-12-16 16:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virgci2ux.fsf_-_@assigned-by-dhcp.cox.net>
On Sat, 16 Dec 2006, Junio C Hamano wrote:
>
> And this drops it; modulo bugs, I think this is about it for
> v1.5.0 around this area.
Ahh, you said that yourself, and I hadn't even noticed that you already
merged xdl_merge into master too.
So here's an "AOL high five": <me too>.
^ permalink raw reply
* Re: [PATCH] git-pull: refuse default merge without branch.*.merge
From: Linus Torvalds @ 2006-12-16 16:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3b7gji73.fsf@assigned-by-dhcp.cox.net>
On Sat, 16 Dec 2006, Junio C Hamano wrote:
>
> Everybody hated the pull behaviour of merging the first branch
> listed on remotes/* file (or remote.*.fetch config) into the
> current branch. This finally corrects that UI wart by
> forbidding "git pull" without an explicit branch name on the
> command line or branch.$current.merge for the current branch.
Yay!
May I suggest also just merging the built-in 3-way merge, and just calling
the resulting version 1.5.0?
With all the "git add" and documentation cleanups, and these kinds of
fundamental changes in behaviour (not that anybody will hopefully
_notice_, and if they do they'll hopefully just be grateful, but it's
still conceptually a big step), I think it's definitely worth a new
version number.
Maybe even "2.0", although since we're still backwards compatible in all
ways that really matter, a major number might be too big a step.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Jakub Narebski @ 2006-12-16 16:32 UTC (permalink / raw)
To: Torgil Svensson, git; +Cc: Josef Weidendorfer, R. Steve McKown, Linus Torvalds
In-Reply-To: <e7bda7770612160705l61d1f350n70a8ba91754491c9@mail.gmail.com>
Torgil Svensson wrote:
> On 12/16/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> All fine, but this does not and I think cannot protect us from the
>> fact that we can have <sha1 of tree/blob> which doesn't match
>> <sha1 of commit>.
>
> True, that will be a real problem. Unless we have a bug in git, do you
> see a scenario in which this is likely to happen?
Well, I just rather have than <sha1 of tree/blob> the definition
of sparse checkout (for example subdirectory name, or file name,
or glob pattern).
Besides you need the name of directory (for tree) or file (for blob),
otherwise you would have no way to update it when submodule advances
version, and you want to use new submodule version. And if you have
that, you don't need <sha1 of tree/blob> in repository, in link object.
You might want it in the index, for performance reasons, though.
>> I think it would be better to have sparse/partial checkout first.
>> But that is just my idea. Because with <sha1 of tree/blob> which
>> is not sha1 of commit tree you might loose (I think) the ability
>> to merge, for example your changes to submodule with upstream.
>
> That's correct. I also want a sparse/partial checkout but I don't want
> the full submodule path. I'm also perfectly fine (for my current
> use-cases) with not being able to merge upstream unless we're tracking
> the commit tree (here, we might not want to specify the tree SHA1).
With sparse (for example defined by 'src/*.h') or partial (for example
defined by 'Documentation/') checkout you should be able to merge
upstream... unless conflicts are in the not checked out part.
> I'm not trying to impose a technically fragile solution here [I don't
> believe it is, but I'm not the most competent to say that either], I'm
> trying to find solutions for my use cases and I had problems adapting
> them to the current suggestion.
Have you read http://git.or.cz/gitwiki/SubprojectSupport on GitWiki?
Have you tested the experimental submodule support (proof of concept)
http://git.admingilde.org/tali/git.git/module2
by Martin Waitz?
--
Jakub Narebski
^ permalink raw reply
* [RFC/PATCH (take 3)] gitweb: Add some mod_perl specific support
From: Jakub Narebski @ 2006-12-16 16:12 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11662174851575-git-send-email-jnareb@gmail.com>
Add $r variable which holds Apache2::RequestRec if script is run under
mod_perl (if $ENV{MOD_PERL} is defined). It is used as argument to
constructor of CGI object (needs CGI module version at least 2.93).
It is needed for further mod_perl support, for example adding
headers using Apache2::RequestRec methods instead of making Apache
to have to parse headers (to add it's own HTTP headers like Server:
header).
Following advice from CGI(3pm) man page, precompile all CGI routines
for mod_perl.
All this makes gitweb slightly faster under mod_perl (436 +/- 23.9 ms
for summary of git.git before, 429 +/- 12.0 ms after, according to
'ab -n 10 -k "http://localhost/perl/gitweb/gitweb.cgi?p=git.git"').
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
The idea is to have gitweb run under CGI and under mod_perl 1.0 and 2.0
without modifications, but making use of mod_perl features which make script
faster, like for example adding headers via mod_perl API and not via parsing
headers by Apache. In the future the plan is to be able to run gitweb under
not only current ModPerl::Registry (or Apache::Registry in mod_perl 1.0) but
also as a mod_perl handler, and as a FastCGI script using CGI::Fast.
Current portion of mod_perl cpecific additions is mod_perl version agnostic,
and avoids loading any mod_perl Perl modules.
I'd like to have it (and further mod_perl patches) reviewed by someone
better versed in mod_perl.
gitweb/gitweb.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 902c514..f834c64 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -18,11 +18,18 @@ use File::Find qw();
use File::Basename qw(basename);
binmode STDOUT, ':utf8';
-our $cgi = new CGI;
+# mod_perl request
+my $r;
+$r = shift @_ if $ENV{MOD_PERL};
+
+our $cgi = new CGI($r);
our $version = "++GIT_VERSION++";
our $my_url = $cgi->url();
our $my_uri = $cgi->url(-absolute => 1);
+# speeding up mod_perl and FastCGI (later)
+$cgi->compile() if $r;
+
# core git executable to use
# this can just be "git" if your webserver has a sensible PATH
our $GIT = "++GIT_BINDIR++/git";
--
1.4.4.1
^ permalink raw reply related
* Re: [RFC] Submodules in GIT
From: Torgil Svensson @ 2006-12-16 15:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Josef Weidendorfer, R. Steve McKown, git, Linus Torvalds
In-Reply-To: <e7bda7770612160705l61d1f350n70a8ba91754491c9@mail.gmail.com>
On 12/16/06, Torgil Svensson <torgil.svensson@gmail.com> wrote:
> On 12/16/06, Jakub Narebski <jnareb@gmail.com> wrote:
> > All fine, but this does not and I think cannot protect us from the
> > fact that we can have <sha1 of tree/blob> which doesn't match
> > <sha1 of commit>.
>
> True, that will be a real problem. Unless we have a bug in git, do you
> see a scenario in which this is likely to happen?
>
> I also want a sparse/partial checkout but I don't want
> the full submodule path.
This might not be as problematic as we think. If we do the same
sparse/partial checkout (what's the definition here?) with the <sha1
of tree/blob> as we do with the only <sha1 of commit> case and
consider the <sha1 of tree/blob> to be a _local_ (to the
super-project) shortcut. Then we only track the submodules using the
commit - local conflicts are easier to handle, git would refuse to
commit a <sha1 of tree/blob> not present in the commit tree.
We might even consider two object types:
module: <sha1 of commit> name
link: <sha1 of commit> <sha1 of tree/blob> name
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Torgil Svensson @ 2006-12-16 15:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Josef Weidendorfer, R. Steve McKown, git, Linus Torvalds
In-Reply-To: <em0fpq$45b$1@sea.gmane.org>
On 12/16/06, Jakub Narebski <jnareb@gmail.com> wrote:
> All fine, but this does not and I think cannot protect us from the
> fact that we can have <sha1 of tree/blob> which doesn't match
> <sha1 of commit>.
True, that will be a real problem. Unless we have a bug in git, do you
see a scenario in which this is likely to happen?
> I think it would be better to have sparse/partial checkout first.
> But that is just my idea. Because with <sha1 of tree/blob> which
> is not sha1 of commit tree you might loose (I think) the ability
> to merge, for example your changes to submodule with upstream.
That's correct. I also want a sparse/partial checkout but I don't want
the full submodule path. I'm also perfectly fine (for my current
use-cases) with not being able to merge upstream unless we're tracking
the commit tree (here, we might not want to specify the tree SHA1).
I'm not trying to impose a technically fragile solution here [I don't
believe it is, but I'm not the most competent to say that either], I'm
trying to find solutions for my use cases and I had problems adapting
them to the current suggestion.
> > 3. Super-module development independent of submodules - If we have the
> > tree/blob-object with all it contents in the database many
> > git-operations can act as the link (commit) wasn't there since we have
> > access to all relevant data to work with. This makes it easy to clone
> > the super-project and work on it seamlessly without having to care
> > about submodules or mapping up submodule repository's (unless you want
> > to modify the links or the data underneath it of course).
>
> This is I think irrelevant to the fact if we have only <sha1 of commit>,
> or link object and also <sha1 of tree/blob>
^ permalink raw reply
* Re: [PATCH/RFC] avoid accessing _all_ loose refs in git-show-ref
From: Johannes Schindelin @ 2006-12-16 14:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk60sf0hr.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 16 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This is kind of quick and dirty.
>
> Maybe I am blind, but why don't you just do a resolve_ref()
> regardless of packedness? It only builds the packed refs list
> when it is not found as a loose ref, and never builds the loose
> refs list. You probably would want to reject the ones that says
> REF_ISSYMREF.
But of course!
> > An alternative would be to pack the tags _per default_. I once
> > argued for that, but it appears nobody liked that idea. I even
> > proposed to pack _all_ refs, and I still think this would be
> > a good idea.
>
> I do not think packing all refs is such a good idea. Branches
> are meant to be worked on and extended so the packed ones
> would become stale quickly.
My idea would have been to edit them in-place. Since the hashes all take
the same amount of bytes, it could be done by seeking around in the file.
> Packing all tags by default is something we would want when everybody
> knows how to handle them.
You mean all the scripts? Because if you make it the default, you could
hide that implementation detail away from the user.
> > Isn't it a bug that --verify succeeds, if only _one_ ref passed to
> > the command exists?
>
> I think --verify should insist a single parameter, just like
> rev-parse.
>
> So wouldn't the code be like:
>
> if (verify) {
> int flag;
> if (pattern[1])
> die("Eh?");
> if (resolve_ref(pattern[0], sha1, 1, &flag) &&
> (flag & REF_ISSYMREF) == 0) {
> printf("%s %s\n",
> sha1_to_hex(sha1), pattern[0]);
> exit(0);
> } else
> die("no match");
> }
>
> ???
Ack. Scrap my patch.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 2/2] git-branch: rename config vars branch.<branch>.*, too
From: Johannes Schindelin @ 2006-12-16 14:15 UTC (permalink / raw)
To: git, junkio
When renaming a branch, the corresponding config section should
be renamed, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
refs.c | 10 ++++++++++
t/t3200-branch.sh | 6 ++++++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/refs.c b/refs.c
index a02957c..d911b9e 100644
--- a/refs.c
+++ b/refs.c
@@ -867,6 +867,16 @@ int rename_ref(const char *oldref, const char *newref, const char *logmsg)
goto rollback;
}
+ if (!strncmp(oldref, "refs/heads/", 11) &&
+ !strncmp(newref, "refs/heads/", 11)) {
+ char oldsection[1024], newsection[1024];
+
+ snprintf(oldsection, 1024, "branch.%s", oldref + 11);
+ snprintf(newsection, 1024, "branch.%s", newref + 11);
+ if (git_config_rename_section(oldsection, newsection) < 0)
+ return 1;
+ }
+
return 0;
rollback:
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 5782c30..a6ea0f6 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -94,6 +94,8 @@ test_expect_failure \
git-branch r &&
git-branch -m q r/q'
+git-repo-config branch.s/s.dummy Hello
+
test_expect_success \
'git branch -m s/s s should work when s/t is deleted' \
'git-branch -l s/s &&
@@ -104,6 +106,10 @@ test_expect_success \
git-branch -m s/s s &&
test -f .git/logs/refs/heads/s'
+test_expect_success 'config information was renamed, too' \
+ "test $(git-repo-config branch.s.dummy) = Hello &&
+ ! git-repo-config branch.s/s/dummy"
+
test_expect_failure \
'git-branch -m u v should fail when the reflog for u is a symlink' \
'git-branch -l u &&
--
1.4.4.1.g0604-dirty
^ permalink raw reply related
* [PATCH 1/2] add a function to rename sections in the config
From: Johannes Schindelin @ 2006-12-16 14:14 UTC (permalink / raw)
To: git, junkio
Given a config like this:
# A config
[very.interesting.section]
not
The command
$ git repo-config --rename-section very.interesting.section bla.1
will lead to this config:
# A config
[bla "1"]
not
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-repo-config.c | 14 +++++++++-
cache.h | 1 +
config.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++
t/t1300-repo-config.sh | 48 ++++++++++++++++++++++++++++++++++++
4 files changed, 126 insertions(+), 1 deletions(-)
diff --git a/builtin-repo-config.c b/builtin-repo-config.c
index 7b6e572..a6b99ed 100644
--- a/builtin-repo-config.c
+++ b/builtin-repo-config.c
@@ -3,7 +3,7 @@
#include <regex.h>
static const char git_config_set_usage[] =
-"git-repo-config [ --global ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --unset | --unset-all] name [value [value_regex]] | --list";
+"git-repo-config [ --global ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --list";
static char *key;
static regex_t *key_regexp;
@@ -148,6 +148,18 @@ int cmd_repo_config(int argc, const char **argv, const char *prefix)
} else {
die("$HOME not set");
}
+ } else if (!strcmp(argv[1], "--rename-section")) {
+ int ret;
+ if (argc != 4)
+ usage(git_config_set_usage);
+ ret = git_config_rename_section(argv[2], argv[3]);
+ if (ret < 0)
+ return ret;
+ if (ret == 0) {
+ fprintf(stderr, "No such section!\n");
+ return 1;
+ }
+ return 0;
} else
break;
argc--;
diff --git a/cache.h b/cache.h
index 40afee3..a2ffa23 100644
--- a/cache.h
+++ b/cache.h
@@ -403,6 +403,7 @@ extern int git_config_int(const char *, const char *);
extern int git_config_bool(const char *, const char *);
extern int git_config_set(const char *, const char *);
extern int git_config_set_multivar(const char *, const char *, const char *, int);
+extern int git_config_rename_section(const char *, const char *);
extern int check_repository_format_version(const char *var, const char *value);
#define MAX_GITNAME (1000)
diff --git a/config.c b/config.c
index 1bdef44..663993f 100644
--- a/config.c
+++ b/config.c
@@ -746,4 +746,68 @@ out_free:
return ret;
}
+int git_config_rename_section(const char *old_name, const char *new_name)
+{
+ int ret = 0;
+ const char *config_filename;
+ struct lock_file *lock = xcalloc(sizeof(struct lock_file), 1);
+ int out_fd;
+ char buf[1024];
+
+ config_filename = getenv("GIT_CONFIG");
+ if (!config_filename) {
+ config_filename = getenv("GIT_CONFIG_LOCAL");
+ if (!config_filename)
+ config_filename = git_path("config");
+ }
+ config_filename = xstrdup(config_filename);
+ out_fd = hold_lock_file_for_update(lock, config_filename, 0);
+ if (out_fd < 0)
+ return error("Could not lock config file!");
+
+ if (!(config_file = fopen(config_filename, "rb")))
+ return error("Could not open config file!");
+
+ while (fgets(buf, sizeof(buf), config_file)) {
+ int i;
+ for (i = 0; buf[i] && isspace(buf[i]); i++)
+ ; /* do nothing */
+ if (buf[i] == '[') {
+ /* it's a section */
+ int j = 0, dot = 0;
+ for (i++; buf[i] && buf[i] != ']'; i++) {
+ if (!dot && isspace(buf[i])) {
+ dot = 1;
+ if (old_name[j++] != '.')
+ break;
+ for (i++; isspace(buf[i]); i++)
+ ; /* do nothing */
+ if (buf[i] != '"')
+ break;
+ continue;
+ }
+ if (buf[i] == '\\' && dot)
+ i++;
+ else if (buf[i] == '"' && dot) {
+ for (i++; isspace(buf[i]); i++)
+ ; /* do_nothing */
+ break;
+ }
+ if (buf[i] != old_name[j++])
+ break;
+ }
+ if (buf[i] == ']') {
+ /* old_name matches */
+ ret++;
+ store.baselen = strlen(new_name);
+ store_write_section(out_fd, new_name);
+ continue;
+ }
+ }
+ write(out_fd, buf, strlen(buf));
+ }
+ if (close(out_fd) || commit_lock_file(lock) < 0)
+ return error("Cannot commit config file!");
+ return ret;
+}
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 0de2497..b643cad 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -333,5 +333,53 @@ EOF
test_expect_success '--set in alternative GIT_CONFIG' 'cmp other-config expect'
+cat > .git/config << EOF
+# Hallo
+ #Bello
+[branch "eins"]
+ x = 1
+[branch.eins]
+ y = 1
+ [branch "1 234 blabl/a"]
+weird
+EOF
+
+test_expect_success "rename section" \
+ "git-repo-config --rename-section branch.eins branch.zwei"
+
+cat > expect << EOF
+# Hallo
+ #Bello
+[branch "zwei"]
+ x = 1
+[branch "zwei"]
+ y = 1
+ [branch "1 234 blabl/a"]
+weird
+EOF
+
+test_expect_success "rename succeeded" "diff -u expect .git/config"
+
+test_expect_failure "rename non-existing section" \
+ 'git-repo-config --rename-section branch."world domination" branch.drei'
+
+test_expect_success "rename succeeded" "diff -u expect .git/config"
+
+test_expect_success "rename another section" \
+ 'git-repo-config --rename-section branch."1 234 blabl/a" branch.drei'
+
+cat > expect << EOF
+# Hallo
+ #Bello
+[branch "zwei"]
+ x = 1
+[branch "zwei"]
+ y = 1
+[branch "drei"]
+weird
+EOF
+
+test_expect_success "rename succeeded" "diff -u expect .git/config"
+
test_done
--
1.4.4.1.g0604-dirty
^ permalink raw reply related
* Re: What's in git.git (stable)
From: Jakub Narebski @ 2006-12-16 13:59 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7v4przfpir.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Things that need to be done to complete what have been merged to
> 'master' are:
What about discussed but not implemented moving restriction on non-head refs
from git-checkout (forbidding to checkout tags, remotes, and arbitrary
commits like HEAD~n) to git-commit (allowing commiting only to heads refs)?
Probably non-heads refs should be saved in HEAD as explicit sha1 of a
commit; this way we wont run into situation where HEAD changed under us
(because it was for example to remote branch, and we fetched since).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Avoid accessing a slow working copy during diffcore operations.
From: Junio C Hamano @ 2006-12-16 13:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git, Alex Riesen
In-Reply-To: <Pine.LNX.4.63.0612161253080.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 15 Dec 2006, Junio C Hamano wrote:
>
>> Also I'd prefer doing this without #ifdef;
>>
>> if (defined(NO_FAST_WORKING_DIRECTORY) &&
>> !want_file && has_sha1_pack(sha1, NULL))
>> return 0;
>
> Are you sure? AFAIU it is an OS dependent problem, so it should not be
> configurable at runtime anyway.
Well, defined(SYMBOL) does not seem to be a valid C X-<, and I
rewrote it in what I committed. But the point was that the
whole thing:
if (!FAST_WORKING_DIRECTORY && whatever)
statement;
when FAST_WORKING_DIRECTORY is a compilation time constant,
would be optimized out for sane platforms with a reasonable
compiler.
^ permalink raw reply
* Re: git-fetch fails with error code 128
From: Andy Parkins @ 2006-12-16 13:29 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612151706150.18171@xanadu.home>
On Friday 2006, December 15 22:13, Nicolas Pitre wrote:
> And since patch-delta is really simple, it doesn't have many reasons for
> returning NULL: either the object store on either the remote or local
> side is corrupted in which case a git-fsck-objects --full should catch
> that, or the system ran out of memory.
It's not conclusive, but the system its failing on has more memory than the
system it is working on.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Robin Rosenberg @ 2006-12-16 13:32 UTC (permalink / raw)
To: Pazu; +Cc: git
In-Reply-To: <loom.20061215T223909-156@post.gmane.org>
fredag 15 december 2006 22:49 skrev Pazu:
> Shawn Pearce <spearce <at> spearce.org> writes:
> > identical class file given the same input. I've seen times where
> > it doesn't thanks to the automatic serialVersionUID field being
> > somewhat randomly generated.
>
> Probably offline, but… serialVersionUID isn't randomly generated. It's
> calculated using the types of fields in the class, recursively. The actual
> algorithm is quite arbitrary, but not random. The automatically generated
> serialVersionUID should change only if you add/remove class fields (either
> on the class itself, or to the class of nested objects).
Different java compilers (e.g. SUN's javac and Eclipse) generate slipghtly
different code for some cases, including somee synthetic member fields. that
get involved in the UID calculation. Neither compiler is wrong. The java
specifications don't cover all cases.
^ permalink raw reply
* Re: [RFC/PATCH 2/2] git-svn: rename 'commit' command to 'set-tree'
From: Junio C Hamano @ 2006-12-16 13:26 UTC (permalink / raw)
To: Eric Wong; +Cc: git, seth
In-Reply-To: <11662558902535-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> 'set-tree' probably accurately describes what the command
> formerly known as 'commit' does.
>
> I'm not entirely sure that 'dcommit' should be renamed to 'commit'
> just yet... Perhaps 'push' or 'push-changes'?
I think Pasky did such a three-way rename to avoid breaking
people's fingers. I thought it was a reasonable transition
strategy, but some people might say its only effect was to break
people's fingers not just once but twice, so Pasky himself
and/or Cogito users may have some input on this.
We are talking about major UI change between 1.4 series and
v1.5.0 on the core Porcelain-ish side, so if you feel confident
that things would settle down in a month or so in the git-svn
front, it may be a good idea to roll sweeping changes into the
same timeframe.
^ permalink raw reply
* Re: [PATCH/RFC] avoid accessing _all_ loose refs in git-show-ref
From: Junio C Hamano @ 2006-12-16 13:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612161335140.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This is kind of quick and dirty.
Maybe I am blind, but why don't you just do a resolve_ref()
regardless of packedness? It only builds the packed refs list
when it is not found as a loose ref, and never builds the loose
refs list. You probably would want to reject the ones that says
REF_ISSYMREF.
> An alternative would be to pack the tags _per default_. I once
> argued for that, but it appears nobody liked that idea. I even
> proposed to pack _all_ refs, and I still think this would be
> a good idea.
I do not think packing all refs is such a good idea. Branches
are meant to be worked on and extended so the packed ones
would become stale quickly. Packing all tags by default is
something we would want when everybody knows how to handle
them.
> Isn't it a bug that --verify succeeds, if only _one_ ref passed to
> the command exists?
I think --verify should insist a single parameter, just like
rev-parse.
So wouldn't the code be like:
if (verify) {
int flag;
if (pattern[1])
die("Eh?");
if (resolve_ref(pattern[0], sha1, 1, &flag) &&
(flag & REF_ISSYMREF) == 0) {
printf("%s %s\n",
sha1_to_hex(sha1), pattern[0]);
exit(0);
} else
die("no match");
}
???
^ permalink raw reply
* [PATCH/RFC] avoid accessing _all_ loose refs in git-show-ref
From: Johannes Schindelin @ 2006-12-16 12:36 UTC (permalink / raw)
To: git, junkio
If you want to verify a ref, it is overkill to first read all loose refs
into a linked list, and then check if the desired ref is there.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This is kind of quick and dirty.
An alternative would be to pack the tags _per default_. I once
argued for that, but it appears nobody liked that idea. I even
proposed to pack _all_ refs, and I still think this would be
a good idea.
However, HTTP/FTP transport would have to learn about that long
before, and/or a config option would be needed to allow public
repos to cater for older clients.
Isn't it a bug that --verify succeeds, if only _one_ ref passed to
the command exists?
builtin-show-ref.c | 14 +++++++++++++-
refs.c | 17 +++++++++++------
refs.h | 1 +
3 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/builtin-show-ref.c b/builtin-show-ref.c
index 0739798..b57b074 100644
--- a/builtin-show-ref.c
+++ b/builtin-show-ref.c
@@ -157,7 +157,19 @@ int cmd_show_ref(int argc, const char **argv, const char *prefix)
}
if (show_head)
head_ref(show_ref, NULL);
- for_each_ref(show_ref, NULL);
+ if (verify) {
+ for (i = 0; pattern[i]; i++)
+ if (!access(git_path(pattern[i]), R_OK)) {
+ unsigned char sha1[20];
+ if (resolve_ref(pattern[i], sha1, 1, NULL)) {
+ found_match++;
+ printf("%s %s\n", sha1_to_hex(sha1),
+ pattern[i]);
+ }
+ }
+ for_each_packed_ref(show_ref, NULL);
+ } else
+ for_each_ref(show_ref, NULL);
if (!found_match) {
if (verify && !quiet)
die("No match");
diff --git a/refs.c b/refs.c
index a02957c..7e6a459 100644
--- a/refs.c
+++ b/refs.c
@@ -413,11 +413,11 @@ int peel_ref(const char *ref, unsigned char *sha1)
}
static int do_for_each_ref(const char *base, each_ref_fn fn, int trim,
- void *cb_data)
+ void *cb_data, int packed_only)
{
int retval;
struct ref_list *packed = get_packed_refs();
- struct ref_list *loose = get_loose_refs();
+ struct ref_list *loose = packed_only ? NULL : get_loose_refs();
while (packed && loose) {
struct ref_list *entry;
@@ -456,24 +456,29 @@ int head_ref(each_ref_fn fn, void *cb_data)
return 0;
}
+int for_each_packed_ref(each_ref_fn fn, void *cb_data)
+{
+ return do_for_each_ref("refs/", fn, 0, cb_data, 1);
+}
+
int for_each_ref(each_ref_fn fn, void *cb_data)
{
- return do_for_each_ref("refs/", fn, 0, cb_data);
+ return do_for_each_ref("refs/", fn, 0, cb_data, 0);
}
int for_each_tag_ref(each_ref_fn fn, void *cb_data)
{
- return do_for_each_ref("refs/tags/", fn, 10, cb_data);
+ return do_for_each_ref("refs/tags/", fn, 10, cb_data, 0);
}
int for_each_branch_ref(each_ref_fn fn, void *cb_data)
{
- return do_for_each_ref("refs/heads/", fn, 11, cb_data);
+ return do_for_each_ref("refs/heads/", fn, 11, cb_data, 0);
}
int for_each_remote_ref(each_ref_fn fn, void *cb_data)
{
- return do_for_each_ref("refs/remotes/", fn, 13, cb_data);
+ return do_for_each_ref("refs/remotes/", fn, 13, cb_data, 0);
}
/* NEEDSWORK: This is only used by ssh-upload and it should go; the
diff --git a/refs.h b/refs.h
index 51aab1e..0cfe7b5 100644
--- a/refs.h
+++ b/refs.h
@@ -19,6 +19,7 @@ struct ref_lock {
*/
typedef int each_ref_fn(const char *refname, const unsigned char *sha1, int flags, void *cb_data);
extern int head_ref(each_ref_fn, void *);
+extern int for_each_packed_ref(each_ref_fn, void *);
extern int for_each_ref(each_ref_fn, void *);
extern int for_each_tag_ref(each_ref_fn, void *);
^ permalink raw reply related
* Re: spurious .sp in manpages
From: Junio C Hamano @ 2006-12-16 12:08 UTC (permalink / raw)
To: Tom Prince; +Cc: git
In-Reply-To: <20061216095242.GC13144@socrates.priv>
Tom Prince <tom.prince@ualberta.net> writes:
> On Wed, Dec 13, 2006 at 12:58:28AM -0800, Junio C Hamano wrote:
>> This is just a random hack to work around problems people seem
>> to be seeing in manpage backend of xmlto (it appears we are
>> getting ".sp" at the end of line without line break).
>>
>> Could people test this out?
>>
>
> This fixes the files available in the man branch of git.git.
Thanks.
> P.S. I have this fragment in config.mak to install the manpages without
> asciidoc.
>
> man:
> git-archive --format=tar --prefix=${prefix}/man/ man | tar xP
> install: man
>
> .PHONY: man
It's tempting to take it, but that is chicken and egg for me
;-).
^ permalink raw reply
* Re: [PATCH] Avoid accessing a slow working copy during diffcore operations.
From: Johannes Schindelin @ 2006-12-16 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git, Alex Riesen
In-Reply-To: <7vpsakl6mu.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 15 Dec 2006, Junio C Hamano wrote:
> Also I'd prefer doing this without #ifdef;
>
> if (defined(NO_FAST_WORKING_DIRECTORY) &&
> !want_file && has_sha1_pack(sha1, NULL))
> return 0;
Are you sure? AFAIU it is an OS dependent problem, so it should not be
configurable at runtime anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-clone: lose the artificial "first" fetch refspec
From: Johannes Schindelin @ 2006-12-16 11:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvekci3ds.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Sat, 16 Dec 2006, Junio C Hamano wrote:
> With the recent flurry of UI updates, I think it is sane to do
> that before v1.5.0; opinions?
Answering to all of your recent patches in this direction: I like it.
Originally, I thought that this would require more from me: I often
synchronize my git repository (including topic branches) between different
machines back and forth, via usb stick, and two different central
machines. I use the script I sent in this mail:
http://article.gmane.org/gmane.comp.version-control.git/6956/
However, I just realized that I will not need the script anymore, what
with the recent addition of wildcards to remote.<branch>.fetch. Good job!
Ciao,
Dscho
^ permalink raw reply
* Re: Can git be tweaked to work cross-platform, on FAT32?
From: Johannes Schindelin @ 2006-12-16 11:37 UTC (permalink / raw)
To: Florian v. Savigny; +Cc: git, martin.langhoff
In-Reply-To: <0ML25U-1GvWC81sjR-0001UB@mrelayeu.kundenserver.de>
Hi,
On Sat, 16 Dec 2006, Florian v. Savigny wrote:
> DO your answers imply that it is NOT possible (by "possible", I mean of
> course: possible without re-programming the source code ;-)) to compile
> git in a way that would enable it to work DIRECTLY with a local
> repository on FAT32 from both Windows and Linux (or, perhaps more
> simple: to work directly with a repository on FAT32 under Linux)?
My answer was not so clear...
Question: Is it possible to use git on a FAT32 filesystem?
Answer: Yes.
Question: Is it possible to access such a repository from both Linux and
Windows?
Answer: Yes.
Question: Is there anything that could cause problems?
Answer: Yes. The working directory is a problem.
- Symlinks for example. Don't use them.
- Umlauts: don't use them.
- The index has to be updated, since the stat information is
unlikely to match. A simple "git status" should suffice, though.
- Permissions: the permission handling of Linux and Windows are
quite different. If you initialize the repository with Cygwin,
it automatically sets core.filemode=false, if you initalize(d)
with Linux, you have to adjust manually.
Question: Are there other shortcomings to this approach?
Answer: Definitely. Most are only annoying (like the performance of FAT32,
which literally sucks), but some are different: for example, if you
compile things in the working directory, you will be unhappy.
> 3. ad Johannes: This does sound quite simple and straightforward. If I
> got it right, it would involve having one repository on a, say,
> ext2 partition to work with under Linux, and one on a FAT32
> partition to work with under Windows, and syncing the two after
> booting (fetching from FAT32) and before shutting down (pushing to
> FAT32) Linux.
This is how I'd do it.
> It is quite interesting, BTW, that git can /sync/ with a repository
> on FAT32 under Linux, but not work with it.
You can. But I wouldn't. I like to keep separations clean and obvious.
Ciao,
^ permalink raw reply
* [PATCH] Document git-merge-file
From: Johannes Schindelin @ 2006-12-16 11:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejr0i2lw.fsf@assigned-by-dhcp.cox.net>
Most of this is derived from the documentation of RCS merge.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Sat, 16 Dec 2006, Junio C Hamano wrote:
> >> - 'git-merge-file' needs to be documented and linked from
> >> git.txt.
Documentation/git-merge-file.txt | 92 ++++++++++++++++++++++++++++++++++++++
Documentation/git.txt | 3 +
2 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt
new file mode 100644
index 0000000..0b41d66
--- /dev/null
+++ b/Documentation/git-merge-file.txt
@@ -0,0 +1,92 @@
+git-merge-file(1)
+============
+
+NAME
+----
+git-merge-file - threeway file merge
+
+
+SYNOPSIS
+--------
+[verse]
+'git-merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
+ [-p|--stdout] [-q|--quiet] <current-file> <base-file> <other-file>
+
+
+DESCRIPTION
+-----------
+git-file-merge incorporates all changes that lead from the `<base-file>`
+to `<other-file>` into `<current-file>`. The result ordinarily goes into
+`<current-file>`. git-merge-file is useful for combining separate changes
+to an original. Suppose `<base-file>` is the original, and both
+`<current-file>` and `<other-file>` are modifications of `<base-file>`.
+Then git-merge-file combines both changes.
+
+A conflict occurs if both `<current-file>` and `<other-file>` have changes
+in a common segment of lines. If a conflict is found, git-merge-file
+normally outputs a warning and brackets the conflict with <<<<<<< and
+>>>>>>> lines. A typical conflict will look like this:
+
+ <<<<<<< A
+ lines in file A
+ =======
+ lines in file B
+ >>>>>>> B
+
+If there are conflicts, the user should edit the result and delete one of
+the alternatives.
+
+The exit value of this program is negative on error, and the number of
+conflicts otherwise. If the merge was clean, the exit value is 0.
+
+git-merge-file is designed to be a minimal clone of RCS merge, that is, it
+implements all of RCS merge's functionality which is needed by
+gitlink:git[1].
+
+
+OPTIONS
+-------
+
+-L <label>::
+ This option may be given up to three times, and
+ specifies labels to be used in place of the
+ corresponding file names in conflict reports. That is,
+ `git-merge-file -L x -L y -L z a b c` generates output that
+ looks like it came from files x, y and z instead of
+ from files a, b and c.
+
+-p::
+ Send results to standard output instead of overwriting
+ `<current-file>`.
+
+-q::
+ Quiet; do not warn about conflicts.
+
+
+EXAMPLES
+--------
+
+git merge-file README.my README README.upstream::
+
+ combines the changes of README.my and README.upstream since README,
+ tries to merge them and writes the result into README.my.
+
+git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345::
+
+ merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels
+ `a` and `c` instead of `tmp/a123` and `tmp/c345`.
+
+
+Author
+------
+Written by Johannes Schindelin <johannes.schindelin@gmx.de>
+
+
+Documentation
+--------------
+Documentation by Johannes Schindelin and the git-list <git@vger.kernel.org>,
+with parts copied from the original documentation of RCS merge.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git.txt b/Documentation/git.txt
index b9b1e63..b9fc9ae 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -359,6 +359,9 @@ gitlink:git-init-db[1]::
Creates an empty git object database, or reinitialize an
existing one.
+gitlink:git-merge-file[1]::
+ Runs a threeway merge.
+
gitlink:git-merge-index[1]::
Runs a merge for files needing merging.
--
1.4.4.2.g5dc03
^ permalink raw reply related
* Re: spurious .sp in manpages
From: Tom Prince @ 2006-12-16 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, Dec 13, 2006 at 12:58:28AM -0800, Junio C Hamano wrote:
> This is just a random hack to work around problems people seem
> to be seeing in manpage backend of xmlto (it appears we are
> getting ".sp" at the end of line without line break).
>
> Could people test this out?
>
This fixes the files available in the man branch of git.git.
Tom
P.S. I have this fragment in config.mak to install the manpages without
asciidoc.
man:
git-archive --format=tar --prefix=${prefix}/man/ man | tar xP
install: man
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Junio C Hamano @ 2006-12-16 10:25 UTC (permalink / raw)
To: jnareb
Cc: Torgil Svensson, Josef Weidendorfer, R. Steve McKown, git,
Linus Torvalds
In-Reply-To: <em0fpq$45b$1@sea.gmane.org>
[jc: adding back people on CC list while feeling sick of having
to do so...]
Jakub Narebski <jnareb@gmail.com> writes:
>>>> Now it doesn't looks like trees/blobs anymore so maybe a link object
>>>> is handy:
>>>> README
>>>> 100644 blob <sha1 of blob> REPORTING-BUGS
>>>> 100644 link <sha1 of link> AUTHORS
>>>> 040000 tree <sha1 of tree> arch
>>>> 040000 tree <sha1 of tree> block
>>>> 040000 link <sha1 of link> misc
>
> This would be (using the submodule original proposal)
>
> 140000 link <sha1 of link> misc
If I recall correctly, the original original proposal used
160000 because that is not a bitpattern used in stat.h, and a
link behaves like a directory and a symbolic link at the same
time.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-16 9:58 UTC (permalink / raw)
To: git
In-Reply-To: <7v4przfpir.fsf@assigned-by-dhcp.cox.net>
>> I am hoping that we can start a stabilization cycle for v1.5.0
>> based on what we have in 'master'. The theme is "usability and
>> teachability".
>>
>> Things that need to be done to complete what have been merged to
>> 'master' are:
>>
>> - 'git-rm' needs to be fixed up as Linus outlined; remove
>> working tree file and index entry but have a sanity check to
>> make sure the working tree file match the index and HEAD.
>>
>> - 'git-branch' may need to be taught about renaming the
>> matching per-branch configuration at the same time.
>>
>> - 'git-merge-file' needs to be documented and linked from
>> git.txt.
>>
>> - 'git-clone' probably should be updated to use wild-card in
>> remote.origin.fetch, instead of listing all the branches it
>> found when the clone was made.
>>
>> - tutorials and other Porcelain documentation pages need to be
>> updated to match the updated 'git-add' and 'git-rm' (to be
>> updated), and their description should be made much less
>> about implementation; they should talk in terms of end-user
>> workflows. I will send a draft for 'git diff' out later, but
>> somebody needs a full sweep on Porcelain-ish documentation.
>>
>> - 'git diff --index' patch should be reverted (already done in
>> 'next'), although we may have to come up with a better
>> wording for --cached.
I'm done with 2 out of the above six ("diff --index", and
"clone") and a bit of the "documentation" item so far, and will
go to bed now. Any takers for the remaining tasks while I'll be
sleeping ;-)?
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Jakub Narebski @ 2006-12-16 9:57 UTC (permalink / raw)
To: git
In-Reply-To: <e7bda7770612160040v1a769153p909a8cd40e5ea991@mail.gmail.com>
<opublikowany i wysłany>
Torgil Svensson wrote:
> On 12/16/06, Jakub Narebski <jnareb@gmail.com> wrote:
>>> Now it doesn't looks like trees/blobs anymore so maybe a link object
>>> is handy:
>>> README
>>> 100644 blob <sha1 of blob> REPORTING-BUGS
>>> 100644 link <sha1 of link> AUTHORS
>>> 040000 tree <sha1 of tree> arch
>>> 040000 tree <sha1 of tree> block
>>> 040000 link <sha1 of link> misc
This would be (using the submodule original proposal)
140000 link <sha1 of link> misc
>>> link-object:
>>> <sha1 of commit>
>>> <sha1 of tree/blob>
>>
>> What do you need <sha1 of tree/blob> for in link-object? Wouldn't you
>> use usually the sha1 of top tree of a commit, which is uniquely defined
>> by commit object, so you need only <sha1 of commit>?
>>
>
> 1. "Sparse" repository's - In my example, I want to cherry-pick
> header-files or binary-files from different projects without fetching
> all, potentially huge, submodules in their entirety. Imaging having X,
> kernel, gcc, gtk and libc6 as sub-projects and you really only care
> about some header files.
>
> 2. Super-module directory-hierarchy independent from submodules.
> Super-project want to have the header-files and binaries it's own way.
> This also gives version controlled file-collections, the "release
> case" in my example - collecting different binaries and header-files
> from different submodules together in a new directory-structure, add
> some documentation and configuration files and get the whole thing
> under strong version-control down to the beginning of time for each
> little component.
All fine, but this does not and I think cannot protect us from the
fact that we can have <sha1 of tree/blob> which doesn't match
<sha1 of commit>.
I think it would be better to have sparse/partial checkout first.
But that is just my idea. Because with <sha1 of tree/blob> which
is not sha1 of commit tree you might loose (I think) the ability
to merge, for example your changes to submodule with upstream.
> 3. Super-module development independent of submodules - If we have the
> tree/blob-object with all it contents in the database many
> git-operations can act as the link (commit) wasn't there since we have
> access to all relevant data to work with. This makes it easy to clone
> the super-project and work on it seamlessly without having to care
> about submodules or mapping up submodule repository's (unless you want
> to modify the links or the data underneath it of course).
This is I think irrelevant to the fact if we have only <sha1 of commit>,
or link object and also <sha1 of tree/blob>
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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