* Re: [PATCH] Add 'ours' merge strategy.
From: Johannes Schindelin @ 2005-11-02 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vll071ug5.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 1 Nov 2005, Junio C Hamano wrote:
> This can be used to terminate an old maintenance branch without
> leaving people's repositories behind.
How about optionally do something similar when git-rebase'ing? Especially
"pu"?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/4] Server-side support for user-relative paths.
From: Junio C Hamano @ 2005-11-02 9:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43687914.6080906@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> I went with this implementation because...
> Perhaps it should be enter_repo() or some such? Optionally with
> is_git_repo() as a separate function?
I agree with you that splitting this into three separate
functions does not make much sense. I was just unsure about
that name; enter_repo() sounds more sensible.
^ permalink raw reply
* Re: [PATCH 4/4] git-daemon support for user-relative paths.
From: Andreas Ericsson @ 2005-11-02 9:39 UTC (permalink / raw)
To: git
In-Reply-To: <7v1x1zv1ln.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>Junio C Hamano wrote:
>>
>>>>-static int log_syslog;
>>>>+static int log_syslog = 0;
>>>
>>>I'd drop this.
>>
>>No can do. It has to be set either here or down in main. It's nice to
>>have the default in the declaration.
>
>
> Isn't "static int log_syslog" in BSS to be initialized to zero anyway?
>
I would have thought so, but it wasn't when I tested it. This could be a
compiler-bug in my end, I suppose, but spelling it out enhances
readability and leaves no room for doubt which is always nice.
>>
>>Ok. I'll take that to mean "hold off on the --server-root and --userdir
>>patch for a while" then.
>
>
> I do not mind keeping it in the proposed updates branch for
> people to see and experiment with, but not in the master branch,
> at least for now.
>
I'll cook it up then.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 4/4] git-daemon support for user-relative paths.
From: Junio C Hamano @ 2005-11-02 9:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4368760E.6030208@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>>> -static int log_syslog;
>>>+static int log_syslog = 0;
>> I'd drop this.
>
> No can do. It has to be set either here or down in main. It's nice to
> have the default in the declaration.
Isn't "static int log_syslog" in BSS to be initialized to zero anyway?
>> I like the general direction this set is taking, but let's let
>> it simmer for a while.
>
> Ok. I'll take that to mean "hold off on the --server-root and --userdir
> patch for a while" then.
I do not mind keeping it in the proposed updates branch for
people to see and experiment with, but not in the master branch,
at least for now.
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Junio C Hamano @ 2005-11-02 9:26 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43687EAF.4060505@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Incidentally though, is there any way to make a commit completely go
> away without resetting the files?
I am not sure if this is what you are looking for, but after I
make a commit and find a mistake (either in the checked-in files
or commit log message), I do this:
$ git reset --soft HEAD^
... fix the checked-in files, maybe do git-add files that
... I forgot to add when I made the last commit.
$ git commit -a -c ORIG_HEAD ;# edit commit log, too.
Soft reset leaves the working tree files intact and just rewinds
the .git/HEAD to whatever commit you specify, and as a side
effect stores the original .git/HEAD in .git/ORIG_HEAD. The
lowercase -c flag to git-commit is "bring the commit log editor,
initialized with the commit log message from that commit".
^ permalink raw reply
* Re: Clone a repository with only the objects needed for a single tag
From: Junio C Hamano @ 2005-11-02 9:20 UTC (permalink / raw)
To: Ben Lau; +Cc: git
In-Reply-To: <43687869.7060104@ust.hk>
Ben Lau <benlau@ust.hk> writes:
> However, it has a problem when involves the gitk/git-log.
That's why I said anything that requires you to have a complete
history would not work.
The shallow repository is by definition a *broken* repository;
the refs are supposed to mean the repository has everything
reachable from them, and many tools rely on that assumption, but
the shallow setup deliberately breaks that assumption, so you
need to be aware of what operations you can and cannot do
without having the full history. Although using grafts to
cauterize somewhat helps as you discovered, you are operating in
"do it at your own risk" territory.
Having said that, here are the things that *should* work without
having full history (not many):
. git diff between your index, working tree, and commits
your shallow setup happens to have.
. git commit on top of any of the tip of branches your
shallow copy started out with, including git am and git
applymbox.
. git fetch/pull over commit walker from a remote
repository.
. git push to send the work done in the shallow repository
back into your mothership repository (running git pull on
the mothership to fetch from the shallow copy probably
would not work, unless you use commit walkers).
. git whatchanged, git log, and gitk to view the work
you did in your shallow repository.
Creating packs in the mothership repository is certainly
possible. You could instead do this:
$ git-shallow-pack --all ;# in mothership
$ mkdir -p /var/tmp/shallow
$ tar cf - .git/HEAD .git/refs/ |
(cd /var/tmp/shallow; git-init-db; tar xf -)
$ mv pack-* /var/tmp/shallow/.git/objects/pack
If you want a bit deeper history, instead of giving '--all' to
git-shallow-pack, you could probably say something silly like
this:
$ (git-rev-parse --all; git-rev-list --max-count=20 HEAD) |
xargs git-shallow-pack
The shallow-pack script I sent earlier is probably not very
useful in practice. To polish it to be somewhat more useful, it
would probably need the following enhancements, at least:
. Instead of taking 'git-rev-parse' arguments, take the
names of refs;
. Instead of packing the objects contained in the
commits and trees the named refs reference, include
all blobs/trees/commits between the given refs and
their common ancestor to create a pack;
. Create a tarball that contains:
(1) the pack file created by the above procedure,
stored in .git/objects/pack/.;
(2) .git/refs/ to be used in the shallow copy; this
should include only the refs given to the command
to create the above pack.
(3) .git/info/grafts to cauterize the common ancestor
commit and side branches merged into the lines you
are taking (computing the latter may be somewhat
expensive).
Then the command can be run in the mothership repository like
this:
$ cd linux-2.6
$ git-shallow-pack v2.6.14 v2.6.14-rc2 master
to produce a tarball, which can be taken to another location.
When extracted, it would contain all commits between the three
named refs, and you could view the history across them.
^ permalink raw reply
* Re: GIT 0.99.9b
From: Martin Langhoff @ 2005-11-02 9:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbr13y0hk.fsf@assigned-by-dhcp.cox.net>
On 11/2/05, Junio C Hamano <junkio@cox.net> wrote:
> The second maintenance release of 0.99.9 series is found at the
> usual place. 0.99.9a was purely to work around RPM build
> issues; this one contains all the good changes in the master
> branch -- mostly documentation updates, with some cvsimport
> fixes from Martin.
Great! Thanks and kudos for the swift merge. *Really* looking forward for 1.0
cheers,
martin
^ permalink raw reply
* Re: Clone a repository with only the objects needed for a single tag
From: Ben Lau @ 2005-11-02 9:10 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43687DAE.2010604@op5.se>
Andreas Ericsson wrote:
> Ben Lau wrote:
>
>> Hi Junio,
>>
>> It works! Thanks a lot.
>>
>> However, it has a problem when involves the gitk/git-log.
>
>
>
> Both those programs use the history, which you don't have. With a
> shallow repository like this some commands just won't work. git-*log
> and gitk are among those.
yes, it is expected. However, I just think with a fake parent like what
.git/info/grafts could provide may solve the issue. At least it make
git-log be happy to show the only log message in the shallow repository
without any error.
The rest of problem is gitk could not show any item like what git-log shown.
I am not sure is it right to have a pair of same ID into
.git/info/grafts or it should be solved by a little patch to gitk.
>
>>
>> git-log/gitk do not complains afterward, but it also make gitk shows
>> nothing during run. Any solution?
>>
>
> * Get a second machine with more disk-space and run the history tools
> there. If you use it as mothership and push your commits to it you'll
> be able to track your changes from the laptop as well.
>
> * Get a larger disk. They're not terribly expensive now adays.
>
> * Check out one tag (i.e. release) more than you need. Then you'll get
> history back to that tag.
>
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Andreas Ericsson @ 2005-11-02 8:54 UTC (permalink / raw)
To: git
In-Reply-To: <200511012356.jA1NuPBd004502@inti.inf.utfsm.cl>
Horst von Brand wrote:
> Martin Langhoff <martin.langhoff@gmail.com> wrote:
>
> [...]
>
>
>>In practice, a new developer will often roll up commits to avoid
>>sending a string of shameful patches and corrections on top -- I often
>>do that ;-) . Developers with more "mana" will have published repos
>>where Junio pulls directly from -- and they get merged with full
>>history. Of course -- they don't have brown-paper-bag commits like I
>>do...
>
>
> I bet they have a scratchpad on their laptop (full of brown-paper-bag
> commits and backtracking) from which they push into a cleaned up repository
> for public consumption.
I just do a lot of branches.
Incidentally though, is there any way to make a commit completely go
away without resetting the files?
It'd be a nice feature even if it can only do it from the top down,
unlike git-revert which can do it anywhere in the middle as well.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Clone a repository with only the objects needed for a single tag
From: Andreas Ericsson @ 2005-11-02 8:49 UTC (permalink / raw)
To: git
In-Reply-To: <43687869.7060104@ust.hk>
Ben Lau wrote:
> Hi Junio,
>
> It works! Thanks a lot.
>
> However, it has a problem when involves the gitk/git-log.
Both those programs use the history, which you don't have. With a
shallow repository like this some commands just won't work. git-*log and
gitk are among those.
>
> git-log/gitk do not complains afterward, but it also make gitk shows
> nothing during run. Any solution?
>
* Get a second machine with more disk-space and run the history tools
there. If you use it as mothership and push your commits to it you'll be
able to track your changes from the laptop as well.
* Get a larger disk. They're not terribly expensive now adays.
* Check out one tag (i.e. release) more than you need. Then you'll get
history back to that tag.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/4] Library code for user-relative paths.
From: Andreas Ericsson @ 2005-11-02 8:40 UTC (permalink / raw)
To: git
In-Reply-To: <7vk6fr6h3j.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>+ if((slash = strchr(dir, '/'))) {
>>+ *slash = '\0';
>>+ pw = getpwnam(dir);
>>+ *slash = '/';
>
>
> Should you be writing into *slash when dir and path are const
> char *? I know strchr returns "char *" and the compiler would
> not complain but this sounds somewhat yucky.
>
True. Although path isn't, strictly speaking, const char *, so perhaps
that's what needs fixing. It's only ever called with path coming from
argv, which isn't const. I can't really imagine anywhere where the
repo-path might be const char * now that I think of it.
>
>>+ if(slash && *slash + 1)
>
>
> I think you mean "if (slash && slash[1])" here. While we are at
> it, please have a SP betweeen if and open parenthesis.
>
Actually *(slash + 1), but it amounts to the same thing I suppose. ;)
I looked around for indentation guide-lines but didn't found any, and
the current code isn't exactly consistent about it. Perhaps it needs adding?
>
>>+ dir = slash + 1;
>>+ else
>>+ dir = current_dir();
>>+ }
>>+
>>+ /* ~foo/path/to/repo is now path/to/repo and we're in foo's homedir */
>>+ if(chdir(dir) < 0)
>>+ return NULL;
>
>
> Hmm. It's not wrong, but "dir = current_dir()" immediately
> followed by "chdir(dir)" does not feel right.
>
It could be "return current_dir();" immediately, I suppose. Would that
be satisfactory?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 3/4] Server-side support for user-relative paths.
From: Andreas Ericsson @ 2005-11-02 8:30 UTC (permalink / raw)
To: git
In-Reply-To: <7vek5z6h3f.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>Remove the redundant code from {receive,upload}-pack.c in favour of the
>>library code in path.c (previous patch) with documentation of the changes
>>to the affected programs.
>
>
> I like the simplification of these two calling sites, but it
> makes me feel uneasy to see the workhorse named is_git_repo().
>
> The name implies a check to see if the given path is a git repo
> or not (i.e. side-effect free predicate), while what it actually
> does are three things: (1) resolve and check, (2) chdir to it,
> (3) set up GIT_DIR environment. Not that I have a better name
> in mind...
>
I went with this implementation because when I tried to break it up I
had to add the chdir() and putenv() calls in the three callers. No
programs in the git-suite tries to resolve the canonical path of a repo
without subsequently entering it and using it.
Perhaps it should be enter_repo() or some such? Optionally with
is_git_repo() as a separate function?
>
>>+ SSH Is the default transport protocol and also supports an
>
>
> Just a typo ("Is")?
>
Yes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Clone a repository with only the objects needed for a single tag
From: Ben Lau @ 2005-11-02 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy847y1m2.fsf@assigned-by-dhcp.cox.net>
Hi Junio,
It works! Thanks a lot.
However, it has a problem when involves the gitk/git-log. Because the
parent commit is missed in the shallow repository, gitk would complain
the object is missed and exit immediately. To solve the problem, i added
a pair of
ID of the new root object into .git/info/grafts.
Example:
$ cat .git/info/grafts
741b2252a5e14d6c60a913c77a6099abe73a854a
741b2252a5e14d6c60a913c77a6099abe73a854a
git-log/gitk do not complains afterward, but it also make gitk shows
nothing during run. Any solution?
By the way, although I am not sure do any other people also require
this feature, I wish the process could be more smooth. As the
git-shallow-pack script do not destroy and modify any thing in the
cloned repository beside the newly created pack file, I would suggest it
can run the script in the 'monthership' repository, take out
the pack file to another directory or remote machine. And then build a
new git repository based on the pack file.
To achieve the process, it need another script that could create a git
repository from pack file. Do any similar script existed?
Junio C Hamano wrote:
>Ben Lau <benlau@ust.hk> writes:
>
>
>
>> Is there any method to clone/copy a repository with only the
>>objects needed for a single tag in order to save disk space?
>> For example, if I want to start a new project based on a
>>specific version of kernel like v2.6.14. I would run
>>`git-clone` and then checkout a new branch based on the tag.
>>
>>
>
>Depends on what you want to do in that shallow copy.
>
>If the only thing you would want to do is to build it, then you
>could 'git-tar-tree v2.6.14' and extract that on your notebook.
>The output is just a tar so there will no history, though.
>
>If you want to develop while on the road, but do not
>particularly need to be able to inspect the history beyond the
>point you started, you could create a deliberately broken
>repository, using the git-shallow-clone script (attached), like
>this:
>
> $ git clone -n $mothership satellite
> $ cd satellite
> $ git-shallow-pack --all
> $ rm -f .git/objects/pack/pack-*
> $ mv pack-* .git/objects/pack/.
>
>If the original repository you are cloning from is local, you
>could instead do:
>
> $ git clone -l -s -n $mothership satellite
> $ cd satellite
> $ git-shallow-pack --all
> $ rm .git/objects/info/alternates
> $ mv pack-* .git/objects/pack/.
>
>You could develop in this repository, even build up your own
>commit chains, and when you come back you could push from this
>repository back to your 'mothership' repository. In essense,
>any operation that does not require you to have full history
>should work.
>
>One important thing that would not always work would be to pull
>into this repository over git-aware protocols, although pulling
>from your 'mothership' repository would probably work most of
>the time.
>
>One case that would probably break is if the mothership side
>reverted a commit beyond this shallow-pack boundary and then you
>try to pull from there. After the revert, the trees and blobs
>in that new commit you will be pulling from the mothership are
>likely to be the same as the ones contained in commits before
>the shallow clone is made. Because your satellite repo would
>claim to have everything that is reachable from the tip (as of
>the time the clone was made) of the branch, you cannot complain
>if the mothership side assumes you must have those blobs and
>trees and did not send them to you when you pull.
>
>---
>#!/bin/sh
># git-shallow-pack
>
>git-rev-parse --revs-only --no-flags --default HEAD "$@" |
>while read sha1
>do
> echo "$sha1"
> while type=`git-cat-file -t "$sha1"` &&
> case "$type" in tag) ;; *) break ;; esac
> do
> next=`git-cat-file tag "$sha1" |
> sed -ne 's/^object //p' -e q`
> echo "$next"
> sha1="$next"
> done
> git-rev-parse --verify "$sha1^{tree}" 2>/dev/null &&
> git-ls-tree -r "$sha1" | sed -e 's/^[0-7]* [^ ]* //'
>done |
>sort -k 1,1 -u |
>git-pack-objects pack
>
>
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH 4/4] git-daemon support for user-relative paths.
From: Andreas Ericsson @ 2005-11-02 8:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvezb6h4c.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>+ [--timeout=n] [--init-timeout=n] [--strict-paths] [directory...]
>
>
> Why not just --strict?
>
It's a bit clearer what it is that's strict, and allows for future
--strict-* options to be added without breaking anyones init-scripts.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 1/4] Client side of user-relative paths, take two.
From: Andreas Ericsson @ 2005-11-02 8:19 UTC (permalink / raw)
To: git
In-Reply-To: <7vpspj6h3n.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>+ if (protocol == PROTO_SSH && colon && (!path || colon < path)) {
>>+ *colon = 0;
>>+ path = colon + 1;
>>+ }
>
>
> I think "colon < path" is to cover "git://host.xz/foo/bar:baz"
> case (i.e. funny directory name with an embedded colon); I think
> you should reset colon to NULL if you do things differently
> later depending on colon is set or not, like this part:
>
>
>>+ /* null-terminate host part and point path to ~ for URL's like this:
>>+ * ssh://host.xz/~user/repo
>>+ */
>>+ if(!colon && *(path + 1) == '~')
>>+ *path++ = '\0';
>>+ else {
>>+ colon = path;
>>+ path = strdup(path);
>>+ *colon = '\0';
>
>
True. Should I update this patch or submit a new one fixing only this
specific issue?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 4/4] git-daemon support for user-relative paths.
From: Andreas Ericsson @ 2005-11-02 8:17 UTC (permalink / raw)
To: git
In-Reply-To: <7vvezb6h4c.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>+ [--timeout=n] [--init-timeout=n] [--strict-paths] [directory...]
>
>
> Why not just --strict?
>
>
>>@@ -10,16 +10,18 @@
>> #include "pkt-line.h"
>> #include "cache.h"
>>
>>-static int log_syslog;
>>+static int log_syslog = 0;
>
>
> I'd drop this.
>
No can do. It has to be set either here or down in main. It's nice to
have the default in the declaration.
>
>> /* If this is set, git-daemon-export-ok is not required */
>> static int export_all_trees = 0;
>>
>>@@ -81,69 +83,49 @@ static void loginfo(const char *err, ...
>> va_end(params);
>> }
>>
>>-static int path_ok(const char *dir)
>>+static const char *path_ok(const char *dir)
>> {
>>+ const char *path = is_git_repo(dir, strict_paths);
>>+ /* No such directory or not a git archive */
>>+ if(!path) {
>>+ logerror("'%s': unable to chdir or not a git archive", dir);
>>+ return NULL;
>> }
>>
>> if ( ok_paths && *ok_paths ) {
>>+ char **pp = NULL;
>>+ int dirlen = strlen(path);
>>
>> for ( pp = ok_paths ; *pp ; pp++ ) {
>> int len = strlen(*pp);
>>+ if ( len <= dirlen && !strncmp(*pp, path, len) ) {
>>+ if( path[len] == '\0' || (!strict_paths && path[len] == '/') )
>>+ return path;
>> }
>> }
>
>
> Sorry, but I am a bit confused. Does this mean that you need to
> list all directories under --strict-paths, instead of saying
> "/pub/scm and everything under it is OK"?
>
Only if --strict-paths is set, otherwise it works as usual. It's
documented in the man-page, but perhaps it's a bit too paranoid.
> I like the general direction this set is taking, but let's let
> it simmer for a while.
>
Ok. I'll take that to mean "hold off on the --server-root and --userdir
patch for a while" then.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Andreas Ericsson @ 2005-11-02 8:08 UTC (permalink / raw)
To: git
In-Reply-To: <20051101234302.GD1431@pasky.or.cz>
Petr Baudis wrote:
>
> Another possibility is to make the height dynamic and in proportion with
> the number of affected files. Or combine both the color and dynamic
> height. I believe changing the color to red would make it appear as
> black for the red-color-blind people?
>
Color-blindness doesn't work like that. There are no "red-color-blind"
people. It's either red-blue, red-green or blue-green and the problem
lies in differing those colors from each other when they're close
together (and, usually, intermixed). Red-green color-blindness is by far
the most common so it would be wise not to use those.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* GIT 0.99.9b
From: Junio C Hamano @ 2005-11-02 7:25 UTC (permalink / raw)
To: git; +Cc: linux-kernel, hpa
The second maintenance release of 0.99.9 series is found at the
usual place. 0.99.9a was purely to work around RPM build
issues; this one contains all the good changes in the master
branch -- mostly documentation updates, with some cvsimport
fixes from Martin.
The workaround for building RPMs has not changed since 0.99.9a,
mainly because I haven't heard back if it was good enough for
kernel.org consumption, or otherwise what changes are needed.
Note that package split we discussed earlier is not something I
consider "needed"; it is more like "nice to have before 1.0". I
am hoping 0.99.9b to hit kernel.org machines soon, so people do
not have to be bitten by 0.99.8f glitches as reported for the
last couple of days.
That is, provided if the RPM workaround in 0.99.9a and this one
is good enough to produce an installable package, of course.
^ permalink raw reply
* Re: Clone a repository with only the objects needed for a single tag
From: Junio C Hamano @ 2005-11-02 7:01 UTC (permalink / raw)
To: Ben Lau; +Cc: git
In-Reply-To: <43681E47.4010203@ust.hk>
Ben Lau <benlau@ust.hk> writes:
> Is there any method to clone/copy a repository with only the
> objects needed for a single tag in order to save disk space?
> For example, if I want to start a new project based on a
> specific version of kernel like v2.6.14. I would run
> `git-clone` and then checkout a new branch based on the tag.
Depends on what you want to do in that shallow copy.
If the only thing you would want to do is to build it, then you
could 'git-tar-tree v2.6.14' and extract that on your notebook.
The output is just a tar so there will no history, though.
If you want to develop while on the road, but do not
particularly need to be able to inspect the history beyond the
point you started, you could create a deliberately broken
repository, using the git-shallow-clone script (attached), like
this:
$ git clone -n $mothership satellite
$ cd satellite
$ git-shallow-pack --all
$ rm -f .git/objects/pack/pack-*
$ mv pack-* .git/objects/pack/.
If the original repository you are cloning from is local, you
could instead do:
$ git clone -l -s -n $mothership satellite
$ cd satellite
$ git-shallow-pack --all
$ rm .git/objects/info/alternates
$ mv pack-* .git/objects/pack/.
You could develop in this repository, even build up your own
commit chains, and when you come back you could push from this
repository back to your 'mothership' repository. In essense,
any operation that does not require you to have full history
should work.
One important thing that would not always work would be to pull
into this repository over git-aware protocols, although pulling
from your 'mothership' repository would probably work most of
the time.
One case that would probably break is if the mothership side
reverted a commit beyond this shallow-pack boundary and then you
try to pull from there. After the revert, the trees and blobs
in that new commit you will be pulling from the mothership are
likely to be the same as the ones contained in commits before
the shallow clone is made. Because your satellite repo would
claim to have everything that is reachable from the tip (as of
the time the clone was made) of the branch, you cannot complain
if the mothership side assumes you must have those blobs and
trees and did not send them to you when you pull.
---
#!/bin/sh
# git-shallow-pack
git-rev-parse --revs-only --no-flags --default HEAD "$@" |
while read sha1
do
echo "$sha1"
while type=`git-cat-file -t "$sha1"` &&
case "$type" in tag) ;; *) break ;; esac
do
next=`git-cat-file tag "$sha1" |
sed -ne 's/^object //p' -e q`
echo "$next"
sha1="$next"
done
git-rev-parse --verify "$sha1^{tree}" 2>/dev/null &&
git-ls-tree -r "$sha1" | sed -e 's/^[0-7]* [^ ]* //'
done |
sort -k 1,1 -u |
git-pack-objects pack
^ permalink raw reply
* [PATCH] git-clone: do not forget to create origin branch.
From: Junio C Hamano @ 2005-11-02 6:20 UTC (permalink / raw)
To: git
The newly cloned repository by default had .git/remotes/origin
set up to track the remote master to origin, but forgot to
create the origin branch ourselves. Also it hardcoded the
assumption that the remote HEAD points at "master", which may
not always be true.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Objections?
git-clone.sh | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
applies-to: 9c030fed625268c19d7f0838b26f742745b36085
e125c1a717bb732319596d8b792a67c2b7b15ef7
diff --git a/git-clone.sh b/git-clone.sh
index 18e692a..c27a913 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -196,10 +196,17 @@ cd $D || exit
if test -f ".git/HEAD"
then
- mkdir -p .git/remotes || exit
- echo >.git/remotes/origin \
- "URL: $repo
-Pull: master:origin"
+ head_points_at=`git-symbolic-ref HEAD`
+ case "$head_points_at" in
+ refs/heads/*)
+ head_points_at=`expr "$head_points_at" : 'refs/heads/\(.*\)'`
+ mkdir -p .git/remotes &&
+ echo >.git/remotes/origin \
+ "URL: $repo
+Pull: $head_points_at:origin"
+ cp ".git/refs/heads/$head_points_at" .git/refs/heads/origin
+ esac
+
case "$no_checkout" in
'')
git checkout
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Add 'ours' merge strategy.
From: Junio C Hamano @ 2005-11-02 5:37 UTC (permalink / raw)
To: git
This adds the coolest merge strategy ever, "ours". It can take
arbitrary number of foreign heads and merge them into the
current branch, with the resulting tree always taken from our
branch head, hence its name.
What this means is that you can declare that the current branch
supersedes the development histories of other branches usnig
this merge strategy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
This can be used to terminate an old maintenance branch without
leaving people's repositories behind. The old 0.99.8[a-z]
lettered releases were done from a maintenance branch that
forked off from the master branch at 0.99.8. The maintenance
branch for 0.99.9 has the tip of the last 0.99.8 maintenance
commit as one of the ancestors, as well as 0.99.9 commit, while
content-wise it forks off purely from 0.99.9.
I could have done the current maint branch like this,
immediately after 0.99.9:
$ git commit -m 'GIT 0.99.9'
$ git checkout -b newmaint
$ git pull -s ours . maint ;# still 0.99.8 maintenance
$ git checkout maint
$ git reset --hard newmaint ;# now based on both old maint and 0.99.9
$ git branch -d newmaint
.gitignore | 1 +
Makefile | 2 +-
git-merge-ours.sh | 7 +++++++
git-merge.sh | 2 +-
4 files changed, 10 insertions(+), 2 deletions(-)
create mode 100755 git-merge-ours.sh
applies-to: 9e58de65fa92cce061c8c4064141bc91856097ed
38431c13669432dfeac16a9142aff5a293331e9d
diff --git a/.gitignore b/.gitignore
index 927c89c..3edf6b4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -50,6 +50,7 @@ git-merge-base
git-merge-index
git-merge-octopus
git-merge-one-file
+git-merge-ours
git-merge-recursive
git-merge-resolve
git-merge-stupid
diff --git a/Makefile b/Makefile
index 357cb3e..bda829e 100644
--- a/Makefile
+++ b/Makefile
@@ -89,7 +89,7 @@ SCRIPT_SH = \
git-tag.sh git-verify-tag.sh git-whatchanged.sh git.sh \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
- git-merge-resolve.sh git-grep.sh
+ git-merge-resolve.sh git-merge-ours.sh git-grep.sh
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
diff --git a/git-merge-ours.sh b/git-merge-ours.sh
new file mode 100755
index 0000000..a64704f
--- /dev/null
+++ b/git-merge-ours.sh
@@ -0,0 +1,7 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+# Pretend we resolved the heads, but declare our tree trumps everybody else.
+#
+exit 0
diff --git a/git-merge.sh b/git-merge.sh
index dd104db..b810fce 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -14,7 +14,7 @@ usage () {
# all_strategies='resolve recursive stupid octopus'
-all_strategies='recursive octopus resolve stupid'
+all_strategies='recursive octopus resolve stupid ours'
default_strategies='resolve octopus'
use_strategies=
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] cogito rpm package to include manuals
From: Pavel Roskin @ 2005-11-02 4:30 UTC (permalink / raw)
To: git, Petr Baudis
The cogito rpm package created by "make rpm" lacks manual pages. I can
understand why manuals are not generated for local installations by
default (asciidoc is slow, and the commands are self-documented), but
rpm packages should be closer to perfection.
Since there is no way to install manuals without also installing the
text documentation, so the later is deleted after installation.
Nothing from the Documentation directory except tutorial-script should
be included as documentation.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/cogito.spec.in b/cogito.spec.in
index 080b988..1ed9305 100644
--- a/cogito.spec.in
+++ b/cogito.spec.in
@@ -8,6 +8,7 @@ URL: http://kernel.org/pub/software/sc
Source: http://kernel.org/pub/software/scm/cogito/%{name}-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: git-core >= 0.99.7
+BuildRequires: asciidoc
BuildArch: noarch
%description
@@ -21,11 +22,13 @@ many other version control systems.
%build
-make
+make all doc
%install
rm -rf $RPM_BUILD_ROOT
-make DESTDIR=$RPM_BUILD_ROOT prefix=%{_prefix} libdir=%{_libdir}/cogito install
+make DESTDIR=$RPM_BUILD_ROOT prefix=%{_prefix} libdir=%{_libdir}/cogito mandir=%{_mandir} \
+ install install-doc
+rm -rf $RPM_BUILD_ROOT/%{_prefix}/share/doc/cogito/txt
%clean
rm -rf $RPM_BUILD_ROOT
@@ -35,9 +38,13 @@ rm -rf $RPM_BUILD_ROOT
%{_bindir}/*
%dir %{_libdir}/cogito
%{_libdir}/cogito/*
-%doc README COPYING Documentation/*
+%{_mandir}/man*/*
+%doc README COPYING Documentation/tutorial-script
%changelog
+* Tue Nov 1 2005 Pavel Roskin <proski@gnu.org> 0.15.1-1
+- generate and include manuals
+
* Tue Oct 11 2005 Chris Wright <chrisw@osdl.org> 0.15.1-1
- use %dist
--
Regards,
Pavel Roskin
^ permalink raw reply related
* [PATCH] Add --no-commit to git-merge/git-pull.
From: Junio C Hamano @ 2005-11-02 3:43 UTC (permalink / raw)
To: git
With --no-commit flag, git-pull will perform the merge but pretends as
if the merge needed a hand resolve even if automerge cleanly resolves,
to give the user a chance to add further changes and edit the commit
message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
This turns out to be useful while maintaining the maint branch
for 0.99.9[a-z] lettered maintenance releases. The plan is for
the contents of that branch to match always the tip of the
master branch during 0.99.9 timeframe, and every time a merge
is done from master into maint, only GIT_VERSION in the
Makefile is bumped up. 0.99.8 maintenance branch was done by
pulling from a private branch "fixes", immediately followed by
a separate commit to bump that definition up, but with this, I
could instead do this:
$ git checkout master
$ git am -3 -s ./++patches-from-the-list.mbox
... work work work in master ...
$ git checkout maint
$ git pull --no-commit . master
... update the version in Makefile and debian/changelog ...
$ git commit -a -m 'GIT 0.99.9b'
git-merge.sh | 28 ++++++++++++++++++----------
git-pull.sh | 6 ++++--
2 files changed, 22 insertions(+), 12 deletions(-)
applies-to: 60d390a285756ba840953418954ac05dca40f75b
c575e6d759f2305e5710dae7ac58274db5930de7
diff --git a/git-merge.sh b/git-merge.sh
index 6ad96eb..dd104db 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -9,7 +9,7 @@ LF='
'
usage () {
- die "git-merge [-n] [-s <strategy>]... <merge-message> <head> <remote>+"
+ die "git-merge [-n] [--no-commit] [-s <strategy>]... <merge-message> <head> <remote>+"
}
# all_strategies='resolve recursive stupid octopus'
@@ -63,6 +63,8 @@ do
-n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\
--no-summa|--no-summar|--no-summary)
no_summary=t ;;
+ --no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
+ no_commit=t ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -111,18 +113,18 @@ done
common=$(git-show-branch --merge-base $head "$@")
echo "$head" >"$GIT_DIR/ORIG_HEAD"
-case "$#,$common" in
-*,'')
+case "$#,$common,$no_commit" in
+*,'',*)
# No common ancestors found. We need a real merge.
;;
-1,"$1")
+1,"$1",*)
# If head can reach all the merge then we are up to date.
# but first the most common case of merging one remote
echo "Already up-to-date."
dropsave
exit 0
;;
-1,"$head")
+1,"$head",*)
# Again the most common case of merging one remote.
echo "Updating from $head to $1."
git-update-index --refresh 2>/dev/null
@@ -132,11 +134,11 @@ case "$#,$common" in
dropsave
exit 0
;;
-1,?*"$LF"?*)
+1,?*"$LF"?*,*)
# We are not doing octopus and not fast forward. Need a
# real merge.
;;
-1,*)
+1,*,)
# We are not doing octopus, not fast forward, and have only
# one common. See if it is really trivial.
echo "Trying really trivial in-index merge..."
@@ -210,12 +212,18 @@ do
# Remember which strategy left the state in the working tree
wt_strategy=$strategy
- git-merge-$strategy $common -- "$head_arg" "$@" || {
+ git-merge-$strategy $common -- "$head_arg" "$@"
+ exit=$?
+ if test "$no_commit" = t && test "$exit" = 0
+ then
+ exit=1 ;# pretend it left conflicts.
+ fi
+
+ test "$exit" = 0 || {
# The backend exits with 1 when conflicts are left to be resolved,
# with 2 when it does not handle the given merge at all.
- exit=$?
if test "$exit" -eq 1
then
cnt=`{
@@ -272,4 +280,4 @@ do
done >"$GIT_DIR/MERGE_HEAD"
echo $merge_msg >"$GIT_DIR/MERGE_MSG"
-die "Automatic merge failed; fix up by hand"
+die "Automatic merge failed/prevented; fix up by hand"
diff --git a/git-pull.sh b/git-pull.sh
index d476518..9601627 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -10,13 +10,15 @@ usage () {
die "git pull [-n] [-s strategy]... <repo> <head>..."
}
-strategy_args= no_summary=
+strategy_args= no_summary= no_commit=
while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
do
case "$1" in
-n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\
--no-summa|--no-summar|--no-summary)
no_summary=-n ;;
+ --no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
+ no_commit=--no-commit ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -81,4 +83,4 @@ case "$strategy_args" in
esac
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
-git-merge $no_summary $strategy_args "$merge_name" HEAD $merge_head
+git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
---
0.99.9.GIT
^ permalink raw reply related
* Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: Junio C Hamano @ 2005-11-02 3:36 UTC (permalink / raw)
To: Horst von Brand; +Cc: git
In-Reply-To: <200511012315.jA1NFHbH003838@inti.inf.utfsm.cl>
Horst von Brand <vonbrand@inf.utfsm.cl> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>
>> One thing we could do without breaking much of the current
>> arrangement is to have a team of people to help porting for
>> major packaging formats (RPMs and Debs mostly but I know we have
>> OpenBSD and Darwin people here too), and ask them to feed me the
>> updates to rpm/deb/whatever target in the Makefile as needed.
>> Especially before a major release I could ask them to test
>> things out and generate binary packages, perhaps taken out of
>> the tip of the master branch, or even another "for-porters"
>> branch for this purpose.
>
> Good idea. Will build RPMs regularly then.
Can I take that to mean you are volunteering?
^ permalink raw reply
* Re: GIT 0.99.9
From: Horst von Brand @ 2005-10-31 3:21 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Junio C Hamano, git
In-Reply-To: <20051030202322.A65D2353CD1@atlas.denx.de>
Wolfgang Denk <wd@denx.de> wrote:
> In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:
> > I hate it when somebody tells me "it works for me", but I cannot
> > help you here, sorry. I'm no rpm expert and the "make rpm" rule
> > seems to work for me.
> Which environment (Linux distribution) did you test this on? I tried
> Fedora Core 2 and 4, both with the same result. I get the same
> problem when building from the git source tree or when using the
> source RPM.
In Fedora rawhide it works (I've got asciidoc installed, and git locally in
my account).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ 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