* Re: [PATCH 3/3] Add a few more words to the glossary.
From: Junio C Hamano @ 2006-05-04 5:58 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1FbVJi-0004UJ-59@jdl.com>
Jon Loeliger <jdl@jdl.com> writes:
> ref::
> - A 40-byte hex representation of a SHA1 pointing to a particular
> - object. These may be stored in `$GIT_DIR/refs/`.
> + A 40-byte hex representation of a SHA1 or a name that denotes
> + a particular object. These may be stored in `$GIT_DIR/refs/`.
>
> +symbolic ref::
> + See "ref".
Uum. Not very clear. Do we use that word that often?
I think I used that term to differenciate between HEAD symlink
pointing at refs/heads/master and HEAD being a regular file that
stores a line "ref: refs/heads/master\n"; the latter is the
modern style "textual symref", so in that context it is not
about 40-byte hex at all. And at that level it is really a
jargon to talk about one small implementation detail of HEAD, so
I am not sure it deserves to be in the glossary.
> tracking branch::
> - A regular git branch that is used to follow changes from
> + A regular git branch that is used to follow changes frompointing
> another repository. A tracking branch should not contain
I think this is a typo?
^ permalink raw reply
* [ANNOUNCE] GIT 1.3.2
From: Junio C Hamano @ 2006-05-04 8:01 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.3.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.3.2.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.3.2-1.$arch.rpm (RPM)
Mostly documentation and usability fixes, with no exciting new
features, as the maintenance series ought to be.
----------------------------------------------------------------
Changes since v1.3.1 are as follows:
Huw Davies:
git-format-patch: Use rfc2822 compliant date.
Jon Loeliger:
Alphabetize the glossary.
Added definitions for a few words:
Add a few more words to the glossary.
Junio C Hamano:
rebase: typofix.
commit-tree.c: check_valid() microoptimization.
verify-pack: check integrity in a saner order.
git-am --resolved: more usable error message.
Linus Torvalds:
Fix filename verification when in a subdirectory
Martin Langhoff:
git-send-email: fix version string to be valid perl
Matthias Kestenholz:
annotate: fix warning about uninitialized scalar
annotate: display usage information if no filename was given
fix various typos in documentation
Robert Shearman:
give "what now" hint to users upon git-am failure.
Sean Estabrooks:
Update the git-branch man page to include the "-r" option,
Fix up remaining man pages that use asciidoc "callouts".
Properly render asciidoc "callouts" in git man pages.
Fix trivial typo in git-log man page.
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-05-04 8:14 UTC (permalink / raw)
To: git; +Cc: linux-kernel
* Latest maintenance release 1.3.2 is out from the 'maint' branch.
* The 'master' branch has these since the last announcement, not
counting what is in v1.3.2.
- blame path-pruning fix (Fredrik Kuivinen)
- built-in push (Linus, Johannes Schindelin)
- beginning of "put remotes/ info in config file" (Johannes Schindelin)
- repo-config updates and fixes (Johannes Schindelin)
- built-in count-objects and diff
- core.prefersymlinkrefs can be given to use symlink HEAD;
this may be needed to bisect kernel history before January
2006 whose setlocalversion script depended on HEAD being a
symlink.
- "git-log --parents" fix (Linus)
- use rev-list instead of log in git-cvsserver (Martin Langhoff)
- sha1_to_hex() usage cleanup (Linus)
- Document update-index --unresolve (Matthias Kestenholz)
* The 'next' branch, in addition, has these.
- "put remotes/ info in config file" for fetch side (Johannes Schindelin)
- built-in grep
It now knows all the common grep options I personally use,
including -l, -w, -E, -i, -[ABC]<n>, -v; I am planning to
push this out perhaps mid next week.
- built-in format-patch WIP
I really should resume working on this again...
- cache-tree
Fixed a rather nasty bug; should be safe again to use it now.
- get_sha1(): :path and :[0-3]:path to extract from index.
- diff-delta enhancements (Nicolas Pitre)
* The 'pu' branch, in addition, has these.
- partial tree reading/writing with --prefix option.
- Transitively read alternatives (Martin Waitz)
^ permalink raw reply
* Unresolved issues #2
From: Junio C Hamano @ 2006-05-04 8:15 UTC (permalink / raw)
To: git
In-Reply-To: <7v64lcqz9j.fsf@assigned-by-dhcp.cox.net>
Here is a list of topics in the recent git traffic that I feel
inadequately addressed. I've commented on some of them to give
people a feel for what my priorities are. Somebody might want
to rehash the ones low on my priority list to conclusion with a
concrete proposal if they cared about them enough.
The list is *not* ordered in any way, except that the entries
kept from the previous issue of this message have been pushed
down to the bottom. I will probably start dropping some entries
that did not get any reaction from the list in future issues of
this message, but for now I kept all of them from the first one.
* Message-ID: <4fb292fa0604290630r19edd7ejf88642e33b350d1d@mail.gmail.com>
Content-type charset for send-email (Bertrand Jacquin)
The output from format-patch by default is unmarked, which
means the commit message part is UTF-8 (by strong convention),
and the contents of the diff is whatever the contents of the
file is encoded in.
David Woodhouse did a patch to allow specifying charset on the
command line (and default to UTF-8) which is a move in the
right direction, but Bertrand's system seems to have trouble
with it.
I think if we were to do this we probably need to teach
format-patch to optionally do multi-part. We may not
necessarily want to mark the payload to be in the same
encoding as the commit message (not that git-apply cares -- to
it, the payload is just 8-bit unencoded text, but we would
want to protect it from getting mangled by e-mail transport).
* Message-ID: <Pine.LNX.4.64.0604291006270.3701@g5.osdl.org>
Perhaps "note" field in commit objects are useful?
* Message-ID: <Pine.LNX.4.63.0604301524080.2646@wbgn013.biozentrum.uni-wuerzburg.de>
An optional "git fetch --store newname URL refspecs..." to
create an equivalent of remotes file so newname can then be
used as a short-hand. I still have somewhat negative reaction
to it, but I am willing to apply it if there are enough people
who want this.
-- carried over from the first issue of this list.
* Message-ID: <Pine.LNX.4.64.0604050855080.2550@localhost.localdomain>
Binary diff output? (Nicolas Pitre)
I do not think this is needed for our primary audience (the
kernel project), but I am sure it would be helpful for some
other projects if we allowed them to exchange patches that
describe binary file changes via e-mail, so I am not
dismissing this.
* #irc 2006-04-10
Shallow clones (Carl Worth).
The experiment last round did not work out very well, but as
existing repositories get bigger, and more projects being
migrated from foreign SCM systems, this would become a
must-have from would-be-nice-to-have.
I am beginning to think using "graft" to cauterize history
for this, while it technically would work, would not be so
helpful to users, so the design needs to be worked out again.
* Message-ID: <E1FMH3o-0001B5-Dw@jdl.com>
git status does not distinguish contents changes and mode
changes; it just says "modified" (Jon Loeliger).
Unconditionally changing the status letter would break
Porcelains so we would need an extra option to do this.
An outline patch has been already prepared -- this perhaps has
to wait until we sort out the "option parsing" one.
* Message-ID: <tnxmzf9sh7k.fsf@arm.com>
git could use diff3 instead of merge which is a wrapper around
diff3. (Catalin Marinas)
If having "diff3" is a lot more common than having "merge", I
do not have problem with this; "merge" being a wrapper to
"diff3", people who have been happy with the current code
would certainly have "diff3" installed so changing to "diff3"
would not break them.
* Message-ID: <81b0412b0603020649u99a2035i3b8adde8ddce9410@mail.gmail.com>
Windows problems summary (Alex Riesen)
A good list to keep in mind.
* Message-ID: <Pine.LNX.4.64.0604030730040.3781@g5.osdl.org>
Huge packfiles (Linus Torvalds)
Because I do not think asking users to break up packs to
manageable and mmap()able size is too much to ask, I would not
be advocating for updating the pack idx to 64-bit offset and
mmap()ing parts of a packfile, at least too strongly.
However, we currently lack tool support or recepe for users
with such a repository to easily break up packs.
* Message-ID: <1143856098.3555.48.camel@dv>
Per branch property, esp. where to merge from (Pavel Roskin)
This involves user-level "world model" design, which is more
Porcelainish than Plumbing, and as people know I do not do
Porcelain well; interested parties need to come up with what
they want and how they want to use it.
^ permalink raw reply
* Re: Unresolved issues #2
From: Jakub Narebski @ 2006-05-04 8:32 UTC (permalink / raw)
To: git
In-Reply-To: <7v4q065hq0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> * #irc 2006-04-10
> Shallow clones (Carl Worth).
>
> The experiment last round did not work out very well, but as
> existing repositories get bigger, and more projects being
> migrated from foreign SCM systems, this would become a
> must-have from would-be-nice-to-have.
>
> I am beginning to think using "graft" to cauterize history
> for this, while it technically would work, would not be so
> helpful to users, so the design needs to be worked out again.
Perhaps use comment for marking graft as cauterizing history?
There was also talk about proposed git-splithist, which would move some of
the history to other (historical, archive) repository.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: segfault bug in internal git grep from next (fixed)
From: Marco Roeland @ 2006-05-04 8:44 UTC (permalink / raw)
To: git
In-Reply-To: <20060503083229.GA15579@fiberbit.xs4all.nl>
On Wednesday May 3rd 2006 Marco Roeland wrote:
> I'm using the next branch as of commit 6a40327d242dac9f85c6d63c94d537b45ba86e89
>
> A segfault occurs in using the new builtin grep when using it on a
> binary file, so no regular \n endings.
Fixed by Junio in commit 7ed36f56e33bd838d06521a37a916516397e9e8b.
I really use git grep a lot. It is very powerful, and the builtin version
makes even more possible. Thanks very much,
--
Marco Roeland
^ permalink raw reply
* Re: What's in git.git
From: Petr Baudis @ 2006-05-04 9:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vbque5hq9.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, May 04, 2006 at 10:14:54AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> - core.prefersymlinkrefs can be given to use symlink HEAD;
> this may be needed to bisect kernel history before January
> 2006 whose setlocalversion script depended on HEAD being a
> symlink.
Oh, I expected this to end up in 1.3.2, actually. :-)
Shouldn't this belong to the maint branch? It is "physically" a new
feature but I would consider "cannot bisect kernel before January" a bug
certainly worth fixing and the feature is pretty tiny. (It seems to be
backwards-incompatible but that only means you should provide some
transition path, I think. ;)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Unresolved issues #2
From: Junio C Hamano @ 2006-05-04 9:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e3ce4j$chl$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>> I am beginning to think using "graft" to cauterize history
>> for this, while it technically would work, would not be so
>> helpful to users, so the design needs to be worked out again.
>
> Perhaps use comment for marking graft as cauterizing history?
?
> There was also talk about proposed git-splithist, which would move some of
> the history to other (historical, archive) repository.
I stayed out from that discussion, but my impression was that
you could essentially do the same thing as what Linus did when
he started the recent kernel history since v2.6.12-rc2 without
any tool support.
The older kernel history from BKCVS was resurrected later by
independent parties and Linus's history can be grafted onto it,
but if you have an existing history stored in git, you could do:
(1) take a snapshot of the tip of your development with "git
tar-tree HEAD"; (2) extract it into an empty repository and
start a new history; (3) build on top of the truncated history;
and (4) graft that onto the history that stopped at (1), which
you tentatively abandoned, as needed.
^ permalink raw reply
* Re: Unresolved issues #2
From: Jakub Narebski @ 2006-05-04 9:26 UTC (permalink / raw)
To: git
In-Reply-To: <7vwtd240e0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> I am beginning to think using "graft" to cauterize history
>>> for this, while it technically would work, would not be so
>>> helpful to users, so the design needs to be worked out again.
>>
>> Perhaps use comment for marking graft as cauterizing history?
>
> ?
For example:
# begin shallow clone
<sha1 of commit 1> # no parents... - cut-off commit
<sha1 of commit 2>
...
<sha1 of commmit n>
# end shallow clone
I don't think it is very good idea, though...
>> There was also talk about proposed git-splithist, which would move some
>> of the history to other (historical, archive) repository.
>
> I stayed out from that discussion, but my impression was that
> you could essentially do the same thing as what Linus did when
> he started the recent kernel history since v2.6.12-rc2 without
> any tool support.
>
> The older kernel history from BKCVS was resurrected later by
> independent parties and Linus's history can be grafted onto it,
> but if you have an existing history stored in git, you could do:
> (1) take a snapshot of the tip of your development with "git
> tar-tree HEAD"; (2) extract it into an empty repository and
> start a new history; (3) build on top of the truncated history;
> and (4) graft that onto the history that stopped at (1), which
> you tentatively abandoned, as needed.
I have thought about splitting not at current tip(s), but for example at 1
year ago. Current repository would have history cautherized using grafts
(although it would be nice to have option to omit grafts and reach to
historic repository), and archive/history repository ending with commits up
to (but not including) the cut-off (cauterization) points.
IIRC the problem with 'shallow clone' was telling which commits the clone
has, and how to join commits and recauterize history.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Unresolved issues #2
From: Petr Baudis @ 2006-05-04 9:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, mj
In-Reply-To: <7v4q065hq0.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, May 04, 2006 at 10:15:03AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> * Message-ID: <1143856098.3555.48.camel@dv>
> Per branch property, esp. where to merge from (Pavel Roskin)
>
> This involves user-level "world model" design, which is more
> Porcelainish than Plumbing, and as people know I do not do
> Porcelain well; interested parties need to come up with what
> they want and how they want to use it.
Oh, my holey memory. In Cogito, I have just implemented a solution
suggested by Martin Mares, which is pretty simple, non-obtrusive
and will work equally fine with remotes as well as remote branches:
if [ $branch != master ] && [ -s .git/branches/$branch-origin ]
origin=.git/branches/$branch-origin
else
origin=.git/branches/origin
fi
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: git-unpack-objects
From: Marco Roeland @ 2006-05-04 10:02 UTC (permalink / raw)
To: Josh Boyer; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <625fc13d0605031731v7b65a738r6fc0169958235928@mail.gmail.com>
On Wednesday May 3rd 2006 Josh Boyer wrote:
> >It does. That's what the "-a" (for "all") does.
>
> Odd. On one of my repos, I was seeing the correct behavior. On
> another, there were multiple packs left after doing the 'git repack -a
> -d'. Were there ever some packing bugs in older versions of git that
> would have maybe produced some packs that wouldn't get deleted or
> something?
Have you checked with "git fsck-objects" that maybe the "remaining"
packs contained non-reachable objects like dangling commits from resets
or from following volatile branches like +pu?
--
Marco Roeland
^ permalink raw reply
* Re: [PATCH 1/3] Alphabetize the glossary.
From: Johannes Schindelin @ 2006-05-04 10:41 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1FbVFi-0004Tt-Aw@jdl.com>
Hi,
On Wed, 3 May 2006, Jon Loeliger wrote:
> Yeah, there is a script that also alphabetize the glossary.
> But let's just be explicit and complete here.
The idea of having it not alphabetized, but doing it by a script, was to
let people actually _read_ it. There is nothing more annoying than having
to jump forward and backward and eventually be lost.
glossary, as I started it, was topologically ordered: no Git term was used
before it was described (at least that was the plan).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Be elaborate when specifying the debs on the download page.
From: Martin Atukunda @ 2006-05-04 11:37 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
From: Martin Atukunda <matlads@igloo.ds.co.ug>
Junio hasn't done the debian packages for git in a while, and as
such the location specified on the site is outdated. Incidentally
git-core _is_ packaged for debian and versions of it are in unstable
and testing. There is a version for stable maintained at backports.org.
This commit modifies the downloads page to reflect these changes.
Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
---
download.html | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
e3416893f5aaa3fe464bc1f8a0add75deb3fb0f5
diff --git a/download.html b/download.html
index 3a3d4e6..315dff1 100644
--- a/download.html
+++ b/download.html
@@ -56,7 +56,20 @@
<dd><a href="http://kernel.org/pub/software/scm/git/RPMS/">http://kernel.org/pub/software/scm/git/RPMS/</a></dd>
<dt>Debs</dt>
-<dd><a href="http://kernel.org/pub/software/scm/git/debian/">http://kernel.org/pub/software/scm/git/debian/</a></dd>
+<dd>
+ <dl>
+ <dt>Stable</dt>
+ <dd><a href="http://www.backports.org/debian/pool/g/git-core/">http://www.backports.org/debian/pool/main/g/git-core/</a></dd>
+ </dl>
+ <dl>
+ <dt>Testing</dt>
+ <dd><a href="http://packages.debian.org/testing/devel/git-core/">http://packages.debian.org/testing/devel/git-core/</a></dd>
+ </dl>
+ <dl>
+ <dt>Unstable</dt>
+ <dd><a href="http://packages.debian.org/unstable/devel/git-core/">http://packages.debian.org/unstable/devel/git-core/</a></dd>
+ </dl>
+</dd>
</dl>
--
1.3.1.g7464
^ permalink raw reply related
* Re: git-unpack-objects
From: Josh Boyer @ 2006-05-04 11:58 UTC (permalink / raw)
To: Marco Roeland; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20060504100237.GA10548@fiberbit.xs4all.nl>
On 5/4/06, Marco Roeland <marco.roeland@xs4all.nl> wrote:
> On Wednesday May 3rd 2006 Josh Boyer wrote:
>
> > >It does. That's what the "-a" (for "all") does.
> >
> > Odd. On one of my repos, I was seeing the correct behavior. On
> > another, there were multiple packs left after doing the 'git repack -a
> > -d'. Were there ever some packing bugs in older versions of git that
> > would have maybe produced some packs that wouldn't get deleted or
> > something?
>
> Have you checked with "git fsck-objects" that maybe the "remaining"
> packs contained non-reachable objects like dangling commits from resets
> or from following volatile branches like +pu?
This was on a kernel repo, so no branches. But dangling commits from
resets might have been present. I can't tell now since I undid all
that packs and redid them into a single. Thanks for the suggestion
though, that sounds like a perfectly reasonable explanation.
josh
^ permalink raw reply
* Re: [PATCH] Be elaborate when specifying the debs on the download page.
From: Petr Baudis @ 2006-05-04 13:32 UTC (permalink / raw)
To: Martin Atukunda; +Cc: git, Martin Atukunda
Dear diary, on Thu, May 04, 2006 at 01:37:24PM CEST, I got a letter
where Martin Atukunda <matlads@dsmagic.com> said that...
> From: Martin Atukunda <matlads@igloo.ds.co.ug>
>
> Junio hasn't done the debian packages for git in a while, and as
> such the location specified on the site is outdated. Incidentally
> git-core _is_ packaged for debian and versions of it are in unstable
> and testing. There is a version for stable maintained at backports.org.
>
> This commit modifies the downloads page to reflect these changes.
>
> Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
Thanks, applied.
It would be helpful if you could please at least cc' me on the website
patches, I sometimes do not read all mails on git@ with [PATCH] in
subject...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH 1/3] Alphabetize the glossary.
From: Jon Loeliger @ 2006-05-04 13:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wva9wbe.fsf@assigned-by-dhcp.cox.net>
So, like, the other day Junio C Hamano mumbled:
>
> You alphabetized, _and_ added reference to "dirty" from clean,
> without adding a corresponding reference to "clean" from dirty,
> which is probably OK.
Rats. Would you like a symmetrical patch?
jdl
^ permalink raw reply
* Re: [PATCH 3/3] Add a few more words to the glossary.
From: Jon Loeliger @ 2006-05-04 13:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0868h7a.fsf@assigned-by-dhcp.cox.net>
So, like, the other day Junio C Hamano mumbled:
> Jon Loeliger <jdl@jdl.com> writes:
>
> > ref::
> > - A 40-byte hex representation of a SHA1 pointing to a particular
> > - object. These may be stored in `$GIT_DIR/refs/`.
> > + A 40-byte hex representation of a SHA1 or a name that denotes
> > + a particular object. These may be stored in `$GIT_DIR/refs/`.
> >
> Uum. Not very clear. Do we use that word that often?
Well, I was mystified a bit too, and I tried to clean it up some...
"ref" gets used as half a <refspec>, from pull-fetch-param.txt:
A parameter <ref> without a colon is equivalent to <ref>: when
pulling/fetching, so it merges <ref> into the current branch
without storing the remote branch anywhere locally
So maybe I was confused here.
> > +symbolic ref::
> > + See "ref".
>
> I think I used that term to differenciate between HEAD symlink
> pointing at refs/heads/master and HEAD being a regular file that
> stores a line "ref: refs/heads/master\n"; the latter is the
> modern style "textual symref", so in that context it is not
> about 40-byte hex at all. And at that level it is really a
> jargon to talk about one small implementation detail of HEAD, so
> I am not sure it deserves to be in the glossary.
Given "git-symbolic-ref <name> [<ref>]", clearly I just botched it.
You were right to drop my confused "symbolic ref" entry. :-(
> > tracking branch::
> > - A regular git branch that is used to follow changes from
> > + A regular git branch that is used to follow changes frompointing
> > another repository. A tracking branch should not contain
>
> I think this is a typo?
Yes. Thanks for noticing and cleaning.
jdl
^ permalink raw reply
* cg-commit path handling problem
From: Christian Jaeger @ 2006-05-04 15:12 UTC (permalink / raw)
To: git
Hello
I did create a repository from a directory containing, amongst other
stuff, files starting with a $ sign. E.g.
$ find
./foo
./bar
./var/cache
./var/cache/$foo
./var/cache/$foo::bar
./var/cache/$baz
$ cg-init
...
Now I realized that I didn't want the var directory in the repository and did
$ cg-rm -r var
$ cg-commit var
which worked without warning, but:
$ cg-status
..
D var/cache/$foo
D var/cache/$foo::bar
D var/cache/$baz
So I try again:
$ cg-commit var
will open the editor with the $.. files in the CG: part, I enter a
commit message, exit the editor, it sayys "Refusing to make an empty
commit".
$ cg-commit -f var
says "committed as ....", but cg-status will still show the same files as D
As per suggestion from #git, I did the equivalent of
find var -name '$*' |xargs git commit -m please_go_away --
which worked.
So I guess that the cg-commit shell script isn't protecting file
paths against variable substitution somewhere.
This is cogito-0.17.2 and git 1.2.6 (from Debian unstable rebuilt on Sarge).
Thanks for caring,
Christian.
^ permalink raw reply
* Re: Unresolved issues #2
From: Pavel Roskin @ 2006-05-04 15:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git, mj
In-Reply-To: <20060504095827.GW27689@pasky.or.cz>
Hello, Petr!
On Thu, 2006-05-04 at 11:58 +0200, Petr Baudis wrote:
> Oh, my holey memory. In Cogito, I have just implemented a solution
> suggested by Martin Mares, which is pretty simple, non-obtrusive
> and will work equally fine with remotes as well as remote branches:
>
> if [ $branch != master ] && [ -s .git/branches/$branch-origin ]
> origin=.git/branches/$branch-origin
> else
> origin=.git/branches/origin
> fi
Isn't ".git/branches" obsolete, at least in git? I'm surprised it's
still referenced in git sources.
What is the future of ".git/branches"? Is it becoming a Cogito specific
branch database? Or is it now a database or branch dependencies?
I would prefer to have one single standard for branch origins that could
be used by git, StGIT and Cogito. Using a location that is obsolete
outside Cogito is probably the worst possible approach. I'd rather have
a separate directory, e.g. .git/origins or something.
Alternatively, we could reuse .git/refs by having files with "Pull:" but
without "URI:", e.g.
$ cat .git/refs/branch
Pull: branch-origin:branch
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Be elaborate when specifying the debs on the download page.
From: Jakub Narebski @ 2006-05-04 15:45 UTC (permalink / raw)
To: git
In-Reply-To: <20060504133232.GX27689@pasky.or.cz>
Petr Baudis wrote:
> It would be helpful if you could please at least cc' me on the website
> patches, I sometimes do not read all mails on git@ with [PATCH] in
> subject...
Perhaps it would be nice to mark non-git patches in subject: [web],
[gitweb], [StGIT], [Cogito], etc.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Carl Worth @ 2006-05-04 17:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q065hq0.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]
On Thu, 04 May 2006 01:15:03 -0700, Junio C Hamano wrote:
> * #irc 2006-04-10
> Shallow clones (Carl Worth).
>
> The experiment last round did not work out very well, but as
> existing repositories get bigger, and more projects being
> migrated from foreign SCM systems, this would become a
> must-have from would-be-nice-to-have.
>
> I am beginning to think using "graft" to cauterize history
> for this, while it technically would work, would not be so
> helpful to users, so the design needs to be worked out again.
I've been meaning to follow up with some thoughts on this topic, so
thanks for the tickler.
For the one use case I had, (track latest tree), I had thrown out the
idea of using "faked", parent-less commit objects to point to the tree
of interest. Junio pointed out that there's no protocol to learn the
name of a remote commit's tree from the name of the commit. I worked
around that by simply making the parent-less commit object on the
server side, (branch name of "master-shallow", say).
That seemed to work just fine, and if someone really wanted to do
this, they could use a hook to maintain the master-shallow branch,
and no change to git itself would be needed. But there's a very
minimal amount of interesting functionality in this, and it's not
clear that it's much better than git-tar-tree. So I'm considering that
idea dead.
Meanwhile, a more general ability to use shallow clones would still be
very useful. I think what I'd like to be able to do is to pass
rev-list limiting options (--max-count, --max-age via --since,
etc.). That would limit the expansion of the WANT commits, and then
the existing logic to compute the necessary objects needed to satisfy
the list of desired commits should do the right thing.
Then, in order for this to actually be useful, when returning objects
from a limited fetch like this, the server should provide a list of
commits that should be noted as cauterized, (whether through the
existing grafts mechanism or otherwise).
Additionally, when doing a fetch into a tree that has any such
cauterized commits, the client must also provide its list of
cauterized commits. So the conversation changes from "I WANT
<fetch-heads> and I HAVE <heads>" to one of "I WANT <fetch-heads>, and
I HAVE <heads>, except that I'm MISSING <cauterized-commits>".
Finally, whenever a fetch receives an commit object that is in its
list of cauterized commits, it should remove that commit from the
list. This allows a shallow clone to be naturally migrated to
something unshallow. And the user can do this as incrementally as
desired based on the need to see more history:
get a bit:
git fetch somewhere --since=2.weeks.ago
then a bit more:
git fetch somewhere --since=1.year.ago
then get it all:
git fetch somewhere
Maybe that's no different from Junio's original proposal. If not, what
do you see in the above that wouldn't work?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] cg-admin-rewritehist: fix reappearing files with --filter-tree.
From: Johannes Sixt @ 2006-05-04 19:36 UTC (permalink / raw)
To: git, Petr Baudis
With --filter-tree a working copy is checked out for each commit.
However, if a file is removed by a commit, the file is _not_ removed
from the working copy by git-checkout-index. This must be done explicitly,
otherwise the file becomes added back again.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I'm posting this again, because I haven't received any feedback nor has
the patch been applied.
cg-admin-rewritehist | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
26bb71a2d3d583d9eee10f4e950ff1b7d400e975
diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
index 7dd83cf..13ffb5d 100755
--- a/cg-admin-rewritehist
+++ b/cg-admin-rewritehist
@@ -213,10 +213,13 @@ while read commit; do
if [ "$filter_tree" ]; then
git-checkout-index -f -u -a
+ # files that $commit removed are now still in the working tree;
+ # remove them, else they would be added again
+ git-ls-files -z --others | xargs -0 rm -f
eval "$filter_tree"
git-diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \
xargs -0 git-update-index --add --replace --remove
- git-ls-files --others | tr '\n' '\0' | \
+ git-ls-files -z --others | \
xargs -0 git-update-index --add --replace --remove
fi
--
1.3.1.gaa6b
^ permalink raw reply related
* [PATCH] cg-admin-rewritehist: Seed the commit map with the parents specified with -r.
From: Johannes Sixt @ 2006-05-04 19:36 UTC (permalink / raw)
To: git, Petr Baudis
When the first commit is manufactured, its parents are looked up in the
commit map. However, without this patch the map is always empty at that time.
If the entire history is rewritten, this is no problem because the first
commit does not have any parents anyway. However, if -r is used to constrain
rewriting to only part of the history, this first commit is manufactured
incorrectly without parents because 'cat' fails.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I'm posting this again, because I haven't received any feedback nor has
the patch been applied.
cg-admin-rewritehist | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
977fc81815877a1e72040355b221fe8d62593eb7
diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
index 9fa4c2a..7dd83cf 100755
--- a/cg-admin-rewritehist
+++ b/cg-admin-rewritehist
@@ -141,6 +141,7 @@ _git_requires_root=1
tempdir=.git-rewrite
startrev=
+startrevparents=
filter_env=
filter_tree=
filter_index=
@@ -152,6 +153,7 @@ while optparse; do
tempdir="$OPTARG"
elif optparse -r=; then
startrev="^$OPTARG^ $OPTARG $startrev"
+ startrevparents="$OPTARG^ $startrevparents"
elif optparse --env-filter=; then
filter_env="$OPTARG"
elif optparse --tree-filter=; then
@@ -186,6 +188,12 @@ ret=0
mkdir ../map # map old->new commit ids for rewriting parents
+# seed with identity mappings for the parents where we start off
+for commit in $startrevparents; do
+ commit="$(git-rev-parse $commit)"
+ echo $commit > ../map/$commit
+done
+
git-rev-list --topo-order HEAD $startrev | tac >../revs
commits=$(cat ../revs | wc -l)
--
1.3.1.gaa6b
^ permalink raw reply related
* Re: Unresolved issues #2
From: Daniel Barkalow @ 2006-05-04 20:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q065hq0.fsf@assigned-by-dhcp.cox.net>
On Thu, 4 May 2006, Junio C Hamano wrote:
> * Message-ID: <Pine.LNX.4.63.0604301524080.2646@wbgn013.biozentrum.uni-wuerzburg.de>
>
> An optional "git fetch --store newname URL refspecs..." to
> create an equivalent of remotes file so newname can then be
> used as a short-hand. I still have somewhat negative reaction
> to it, but I am willing to apply it if there are enough people
> who want this.
I was just about to suggest something for this general use. It's currently
kind of a pain to deal with the situation where you've got stuff on your
workstation that you want to version control in a shared repository on a
server.
I think it shouldn't be on fetch, though; I think a "git remote" command
for describing, creating, and modifying remotes would be better, since you
also sometimes want to add a "Push:" line.
Maybe:
git remote <name>: Print info about <name>
git remote add <name> <URL> [<direction> ...]: create a remote
git remote <name> <direction> ...: modify a remote
where <direction> is either:
pull <remote> <local> or
push <local> <remote>
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] builtin-push: --all and --tags _are_ explicit refspecs
From: Johannes Schindelin @ 2006-05-04 21:18 UTC (permalink / raw)
To: git, junkio
... so do not get refspecs from remotes/* or the config if one of them
was specified.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-push.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
42859edd0156479786e5bc4184e462a0307a67eb
diff --git a/builtin-push.c b/builtin-push.c
index 06d06ff..e530022 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -72,7 +72,7 @@ static int get_remotes_uri(const char *r
{
int n = 0;
FILE *f = fopen(git_path("remotes/%s", repo), "r");
- int has_explicit_refspec = refspec_nr;
+ int has_explicit_refspec = refspec_nr || all || tags;
if (!f)
return -1;
@@ -144,7 +144,7 @@ static int get_config_remotes_uri(const
config_repo = repo;
config_current_uri = 0;
config_uri = uri;
- config_get_refspecs = !refspec_nr;
+ config_get_refspecs = !(refspec_nr || all || tags);
git_config(get_remote_config);
return config_current_uri;
--
1.3.2.gec86-dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox