* Re: HTTP repo referencing stale heads (can't clone)
From: Nick Hengeveld @ 2006-04-04 18:01 UTC (permalink / raw)
To: Daniel Drake; +Cc: Junio C Hamano, git
In-Reply-To: <4431694C.4000007@gentoo.org>
On Mon, Apr 03, 2006 at 07:28:28PM +0100, Daniel Drake wrote:
> Ah, should have known. I am behind a (lame) transparent proxy on port 80.
>
> I opened that file in my web browser and it showed the old heads. After
> a force-refresh (ctrl+F5, which sends some additionally http headers to
> refresh the page from the real server), the old heads disappeared, and
> git now clones successfully.
>
> git-http-fetch should probably send those extra headers too. I'll try to
> find some time to look at this next week.
git-http-fetch uses the "Pragma: no-cache" header when requesting
objects that shouldn't be cached. Is this the additional header you're
referring to?
This patch adds the header to git-ls-remote for the info/refs request.
git-ls-remote: send no-cache header when fetching info/refs
Proxies should not cache this file as it can cause a client to end up with
a stale version, as reported here:
http://marc.theaimsgroup.com/?l=git&m=114407944125389
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
git-ls-remote.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
da9b6fa01f1a8bd6ab5f6d4346584f3f032584aa
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
index 2c9a588..b6882a9 100755
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -53,7 +53,7 @@ http://* | https://* )
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
curl_extra_args="-k"
fi
- curl -nsf $curl_extra_args "$peek_repo/info/refs" ||
+ curl -nsf $curl_extra_args --header "Pragma: no-cache" "$peek_repo/info/refs" ||
echo "failed slurping"
;;
--
1.3.0.rc1.g9aef-dirty
^ permalink raw reply related
* Re: [PATCH] Solaris needs strings.h when using index().
From: Junio C Hamano @ 2006-04-04 18:18 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20060404123603.GA14071@bohr.gbar.dtu.dk>
"Peter Eriksen" <s022018@student.dtu.dk> writes:
> From: Peter Eriksen <s022018@student.dtu.dk>
> Date: Tue Apr 4 14:33:14 2006 +0200
> Subject: [PATCH] Solaris needs strings.h when using index().
>
> Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
I think somebody else noticed this the other day but I'm
undecided if it is easier to replace use of index with strchr,
since we include <string.h> and use strchr() everywhere.
^ permalink raw reply
* Re: Solaris cloning woes partly diagnosed
From: H. Peter Anvin @ 2006-04-04 18:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0604021118210.3050@g5.osdl.org>
Linus Torvalds wrote:
>
> One thing to do might be to make the itimer use a much higher frequency,
> to trigger the problem more easily.
>
> We do, for example, expect that regular file writing not do that. At least
> "write_sha1_from_fd()" will just do a "write()" without testing the error
> return, which is bad (it would silently create a truncated object if the
> /tmp filesystem filled up). If somebody has their filesystem over NFS
> mounted interruptible, partial writes could also happen.
>
There seems to be a whole bunch of places where we use naked write()s
where xwrite or fwrite would be a lot more appropriate. The ssh-* files
seem to be particularly offensive in that way.
There are also a number of places which call xwrite with the apparent
belief that returning short is an error (e.g. blame.c). This as far as
I know the more common definition of xwrite(), but is *not* the one used
in git -- the one in git only guarantees that at least one character is
written.
-hpa
^ permalink raw reply
* Re: [PATCH] Solaris needs strings.h when using index().
From: H. Peter Anvin @ 2006-04-04 18:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Eriksen, git
In-Reply-To: <7vwte56w7n.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "Peter Eriksen" <s022018@student.dtu.dk> writes:
>
>> From: Peter Eriksen <s022018@student.dtu.dk>
>> Date: Tue Apr 4 14:33:14 2006 +0200
>> Subject: [PATCH] Solaris needs strings.h when using index().
>>
>> Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
>
> I think somebody else noticed this the other day but I'm
> undecided if it is easier to replace use of index with strchr,
> since we include <string.h> and use strchr() everywhere.
>
strchr() is definitely more portable. The further away you get from BSD
heritage, the less likely it is that you're going to see bzero, index,
et al whereas anything even remotely modern has memset, strchr, etc.
-hpa
^ permalink raw reply
* Re: [BUG] git-http-fetch segfault
From: Nick Hengeveld @ 2006-04-04 18:49 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: Git Mailing List
In-Reply-To: <4432A8CC.5020200@o2.pl>
On Tue, Apr 04, 2006 at 07:11:40PM +0200, Radoslaw Szkodzinski wrote:
> I have some problems cloning stgit repository (maybe something's broken there).
>
> astralstorm@zen /home/devel $ git clone
> http://homepage.ntlworld.com/cmarinas/stgit.git stgit
> error: Unable to find adad46f365219e9bcc1a212826ca65eaac09729c under
> http://homepage.ntlworld.com/cmarinas/stgit.git/
> Cannot obtain needed blob adad46f365219e9bcc1a212826ca65eaac09729c
> while processing commit 8847a11b3bbf5406f37a360e5466f0e392c56383.
That host name resolves to multiple IP addresses, is it possible that
one of the servers was out of sync? I tried cloning directly from each
address and couldn't reproduce the problem.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [RFH] Solaris cloning woes...
From: Jason Riedy @ 2006-04-04 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Peter Eriksen
In-Reply-To: <7vu099916v.fsf@assigned-by-dhcp.cox.net>
And Junio C Hamano writes:
- Once this is confirmed to fix the problem on Solaris boxes, I'd
- like to include and do an 1.2.5, just in case OpenSolaris folks
- would want to play with it, and also put them in the "master"
- branch.
I haven't run into the problem since, but I almost never saw
it in the first place. Have you been able to trigger it
reliably? Maybe I'm "lucky" that my Sun's so slow...
Jason
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Junio C Hamano @ 2006-04-04 19:00 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4431B60E.3030008@vilain.net>
I was re-reading the hydra stuff and realized I've seen the "a
cap that bundles independent tracks together" pattern somewhere
else in the history of git.
It is very similar to how "bind commit" would have worked.
With hydra, you keep independently mergeable tracks and bundle
their tips together:
---o--+
---o--+--*
---o--+
and advancement of each individual track is bundled together by
uncapping and recapping:
---o--o--+
---o--o--+--*
---o-----+
So a hydra cap would record:
- the result "tree" of the (trivial) merge of the bundled tips;
- the commit object name of the tips.
A "bind commit" proposal was made to support subprojects living
in their own subdirectories. The picture to describe the commit
ancestry chain would be almost the same as the above picture,
except that it did not uncap and recap, but would have built its
own ancestry chain.
It had two different kinds of commit relationships: parenthood
and directory structure binding. The component subprojects
lived in their own subdirectories (so if you are maintaining an
embedded Linux along with matching toolchain, you would have linux/
subdirectory that has the kernel hierarchy, gcc/, libc/, ...),
and commit objects had "bind commit-sha1 subdirectory-name"
lines to express how the components are bundled together. A
commit object would have looked like this:
tree fc9957b0052df6a8248420395bc9febd66194252
parent 052df6a8248420395bc9febd66194252fc9957b0
bind f6a8248420395bc9febd66194252fc9957b0052d linux/
bind 20395bc9febd66194252fc9957b0052df6a82484 gcc/
author A U Thor <author@example.com> 1144111304 -0700
...
The "parent" line is the commit ancestry as usual, and each
"bind" line names a commit object of component project and where
in the directory hierarchy the tree for that commit object would
be checked out. The "tree" line records the result of grafting
the subprojects together. So, for example, ls-tree -d fc9957
linux in the above example would have shown the tree object
f6a824^{tree}.
The structure forbid you from binding two separate projects at
the same directory in order to enforce clean separation of
subprojects, but if you allow multiple commits to be bound at
the root level, that could be used as a hydra cap.
I've done changes to support this at the core level; I think I
still have the code around somewhere (and the net never forgets
;-), so if you are interested you might want to take a look.
The trickest part was to tell rev-list --objects to work
sensibly so that an ancestry chain that contains this kind of
commits can be fetched and pushed. The code unfortunately was
done before recent rev-list renovation so merging it to the
current codebase needs some understanding of how rev-list is
supposed to work, though.
^ permalink raw reply
* Re: [BUG] git-http-fetch segfault
From: Radoslaw Szkodzinski @ 2006-04-04 19:54 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Git Mailing List
In-Reply-To: <20060404184935.GG14967@reactrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 1689 bytes --]
Nick Hengeveld wrote:
> On Tue, Apr 04, 2006 at 07:11:40PM +0200, Radoslaw Szkodzinski wrote:
>
>> I have some problems cloning stgit repository (maybe something's broken there).
>>
>> astralstorm@zen /home/devel $ git clone
>> http://homepage.ntlworld.com/cmarinas/stgit.git stgit
>> error: Unable to find adad46f365219e9bcc1a212826ca65eaac09729c under
>> http://homepage.ntlworld.com/cmarinas/stgit.git/
>> Cannot obtain needed blob adad46f365219e9bcc1a212826ca65eaac09729c
>> while processing commit 8847a11b3bbf5406f37a360e5466f0e392c56383.
>
> That host name resolves to multiple IP addresses, is it possible that
> one of the servers was out of sync? I tried cloning directly from each
> address and couldn't reproduce the problem.
>
Anyhow, git-http-fetch shouldn't segfault.
It's not my server, I don't know the exact configuration.
Also the repository is not mine.
It is reproducible here 100% of the time.
Here, it resolves like that:
astralstorm@zen $ resolveip homepage.ntlworld.com
IP address of homepage.ntlworld.com is 62.253.162.12
IP address of homepage.ntlworld.com is 62.253.162.178
IP address of homepage.ntlworld.com is 62.253.162.10
IP address of homepage.ntlworld.com is 62.253.162.11
I have an strace for you, bzipped and attached.
It is an output of the command:
strace -e 'trace=!poll,gettimeofday,select' -o fetch-strace.log git-http-fetch
-v -a -w heads/master heads/master http://homepage.ntlworld.com/cmarinas/stgit.git/
I hope it is enough to hunt the bug. If you need more info, please just ask.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #1.2: fetch-strace.log.bz2 --]
[-- Type: application/octet-stream, Size: 15607 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Jakub Narebski @ 2006-04-04 20:18 UTC (permalink / raw)
To: git
In-Reply-To: <7vhd596ua0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I was re-reading the hydra stuff and realized I've seen the "a
> cap that bundles independent tracks together" pattern somewhere
> else in the history of git.
>
> It is very similar to how "bind commit" would have worked.
[...]
> A "bind commit" proposal was made to support subprojects living
> in their own subdirectories. The picture to describe the commit
> ancestry chain would be almost the same as the above picture,
> except that it did not uncap and recap, but would have built its
> own ancestry chain.
One of versions of "hydra commit" proposals, in the mail which is yet to
appear on Gmane git mailing list archive, and Gmane NNTP interface to git
mailing list, was to define commit dependency (to which chain commit would
get) in the terms of affecting files in the same directory. Simple
generalization to subtree (directory and its subdirectories) gives "bind
commit for subprojects".
> It had two different kinds of commit relationships: parenthood
> and directory structure binding.
Great minds think alike :-P -- we (Sam and I) were talking on #git about
adding "depends-on" field to commit.
In the email to write I would propose that instead of adding "depends-on"
field (or "bind") one can at least in prototype stage make parallel
development, commiting simultaneously to the tree where history is history,
and to the tree where history is dependence, or bind. I hope I will make
myself clearer in upcoming message; see Sam post beginning this thread - we
want to make both pictures (on the left and on the right) simultaneously.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [BUG] git-http-fetch segfault
From: Radoslaw Szkodzinski @ 2006-04-04 20:25 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Git Mailing List
In-Reply-To: <20060404184935.GG14967@reactrix.com>
[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]
Nick Hengeveld wrote:
> On Tue, Apr 04, 2006 at 07:11:40PM +0200, Radoslaw Szkodzinski wrote:
>
>> I have some problems cloning stgit repository (maybe something's broken there).
>>
>> astralstorm@zen /home/devel $ git clone
>> http://homepage.ntlworld.com/cmarinas/stgit.git stgit
>> error: Unable to find adad46f365219e9bcc1a212826ca65eaac09729c under
>> http://homepage.ntlworld.com/cmarinas/stgit.git/
>> Cannot obtain needed blob adad46f365219e9bcc1a212826ca65eaac09729c
>> while processing commit 8847a11b3bbf5406f37a360e5466f0e392c56383.
>
> That host name resolves to multiple IP addresses, is it possible that
> one of the servers was out of sync? I tried cloning directly from each
> address and couldn't reproduce the problem.
>
Okay, I've nailed it. It's caused by Privoxy.
It seems that Privoxy sends its 404 page with 200 OK reply.
Clearly a broken response.
Does anyone have any better proxy supporting real SOCKS 4a/5 upstream proxy?
(for Tor)
Delegate doesn't count - it has broken HTTP code, 1.0 only and slow too.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* [ANNOUNCE] GIT 1.2.5
From: Junio C Hamano @ 2006-04-04 22:38 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.2.5 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.2.5.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.2.5-1.$arch.rpm (RPM)
This is primarily made to help Solaris folks who were bitten by
pack-objects (hence cloning from a repository hosted on Solaris)
broken by the progress-bar eye-candy. People who follow the
"master" branch, and people who run 1.2.4 on platforms with BSD
signal semantics (which automatically restarts interrupted
read() upon signal) need not worry.
With the "master" branch work nearing 1.3.0, hopefully this will
be the last 1.2.X release.
----------------------------------------------------------------
Changes since v1.2.4 are as follows:
Jason Riedy:
Use sigaction and SA_RESTART in read-tree.c; add option in Makefile.
Junio C Hamano:
read-tree --aggressive: remove deleted entry from the working tree.
tar-tree: file/dirmode fix.
safe_fgets() - even more anal fgets()
Linus Torvalds:
Fix Solaris stdio signal handling stupidities
pack-objects: be incredibly anal about stdio semantics
^ permalink raw reply
* [PATCH] On some platforms, certain headers need to be included before regex.h
From: Johannes Schindelin @ 2006-04-04 23:01 UTC (permalink / raw)
To: git, junkio
Happily, these are already included in cache.h, which is included anyway...
so: change the order of includes.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
diffcore-pickaxe.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
0dcea02390ab0a15e2dbb62b4b876046fe0b4e79
diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
index d89f314..cfcce31 100644
--- a/diffcore-pickaxe.c
+++ b/diffcore-pickaxe.c
@@ -1,11 +1,11 @@
/*
* Copyright (C) 2005 Junio C Hamano
*/
-#include <regex.h>
-
#include "cache.h"
#include "diff.h"
#include "diffcore.h"
+
+#include <regex.h>
static unsigned int contains(struct diff_filespec *one,
const char *needle, unsigned long len,
--
1.3.0.rc2.g7eaca-dirty
^ permalink raw reply related
* What's in git.git
From: Junio C Hamano @ 2006-04-04 23:06 UTC (permalink / raw)
To: git
I've tagged the tip of "master" as 1.3.0-rc2. It has the
following changes since the last announcement.
- enhancement and a minor fix to built-in xdiff
(Davide Libenzi and Mark Wooding)
- contrib/git-svn updates (Eric Wong)
- documentation updates (J. Bruce Fields)
- build and other assorted fixes and cleanups (Jason Riedy,
Peter Eriksen, Rene Scharfe, Yasushi SHOJI, and Jim Radford)
- Solaris "clone" fix (Linus and Jason Riedy with initial
reproduction help from Peter Eriksen)
- revision traversal latency improvements with paths and
max-age limiting (Linus and me)
- http-fetch updates (Nick Hengeveld)
- updated gitk (Paul Mackerras)
* The 'next' branch, in addition, has these.
- fix cloning of upsteram whose HEAD does not point at master
(me); this is an attempt to fix a real bug, but I haven't had
a chance to test it sufficiently enough to convince myself it
is ready.
- pickaxe enhancements that looks for needles matching regexp
(Petr Baudis)
- combine-diff that uses built-in xdiff (me)
* The 'pu' branch, in addition, has these.
- assorted gitk updates from the list (Johannes Schindelin,
Keith Packard and Mark Wooding); I am waiting for some of
them to trickle back from Paul's canonical gitk tree.
- beginning of new pickaxe (me); I've got busy before getting this
one to do anything interesting. Currently it is just a bit
faster way to do 'rev-list | diff-tree --stdin path' for a
single path.
^ permalink raw reply
* [PATCH] parse_date(): fix parsing 03/10/2006
From: Junio C Hamano @ 2006-04-05 6:00 UTC (permalink / raw)
To: git; +Cc: Andrew Morton, Brown, Len
The comment associated with the date parsing code for three
numbers separated with slashes or dashes implied we wanted to
interpret using this order:
yyyy-mm-dd
yyyy-dd-mm
mm-dd-yy
dd-mm-yy
However, the actual code had the last two wrong, and making it
prefer dd-mm-yy format over mm-dd-yy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Spotted, thanks to Len Brown and Andrew Morton.
date.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
f5cd7df6e8322a0b783668b31881ab95a5ce33bd
diff --git a/date.c b/date.c
index 416ea57..18a0710 100644
--- a/date.c
+++ b/date.c
@@ -257,10 +257,10 @@ static int match_multi_number(unsigned l
break;
}
/* mm/dd/yy ? */
- if (is_date(num3, num2, num, tm))
+ if (is_date(num3, num, num2, tm))
break;
/* dd/mm/yy ? */
- if (is_date(num3, num, num2, tm))
+ if (is_date(num3, num2, num, tm))
break;
return 0;
}
--
1.3.0.rc2.g110c
^ permalink raw reply related
* Re: [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-05 6:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmj2b3w3.fsf@assigned-by-dhcp.cox.net>
On Mon, 2006-04-03 at 17:06 -0700, Junio C Hamano wrote:
> > diff --git a/git-clean.sh b/git-clean.sh
> >...
> > +for arg in "$@"; do
>
> for arg
> do
> ...
I checked other git shell scripts and copied the "while" construct from
one of them - if it's good for other commands, it's good for git-clean.
> > + if [ "$arg" = "-d" ]; then
>
> case "$arg" in -d)...
>
> > +excl1=
> > +excl2=
> > +if [ -z "$noexclude" ]; then
> > + excl1="--exclude-per-directory=.gitignore"
> > + if [ -f "$GIT_DIR/info/exclude" ]; then
> > + excl2="--exclude-from=$GIT_DIR/info/exclude"
> > + fi
> > +fi
> > +
> > +git-ls-files --others --directory "$excl1" "$excl2" |
> > +while read -r file; do
> > ...
>
> The $noexclude case passes two empty strings to git-ls-files,
> which may happen to be harmless with the current implementation,
> but does not feel quite right.
Good catch. This is needed since $GIT_DIR can contain spaces. I
believe ${excl2:+"$excl2"} would do the trick.
> Maybe better to read ls-files -z to be really pathname safe, I
> dunno.
I think "xargs -0" has its own problems (argument length limitations),
and the other solution is to use perl. While at that, I'd rather
rewrite the whole script in Perl, or maybe in even C.
I think this should eventually happen to all git scripts, but I have no
intention to do it right now unless you really want me to.
> > + $echo1 "Removing $file"
> > + [ "$cleandirhard" ] && chmod -R 700 "$file"
>
> I am not quite sure this chmod -R is a good idea. If we are
> trying really hard would we need to also make sure we can rmdir
> the "$file" by chmod'ing its parent directory? But once we
> start doing that where would we stop?
OK, I was undecided on that. I'm dropping this option.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-05 6:00 UTC (permalink / raw)
To: git
This command removes untracked files from the working tree. This
implementation is based on cg-clean with some simplifications. The
documentation is included.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
.gitignore | 1 +
Documentation/git-clean.txt | 50 +++++++++++++++++++++++++++
Makefile | 2 +
git-clean.sh | 80 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 132 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index 75891c3..b5959d6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,6 +15,7 @@ git-checkout
git-checkout-index
git-cherry
git-cherry-pick
+git-clean
git-clone
git-clone-pack
git-commit
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
new file mode 100644
index 0000000..e91b2ed
--- /dev/null
+++ b/Documentation/git-clean.txt
@@ -0,0 +1,50 @@
+git-clean(1)
+============
+
+NAME
+----
+git-clean - Remove untracked files from the working tree
+
+SYNOPSIS
+--------
+[verse]
+'git-clean' [-d | -D] [-n] [-q] [-x]
+
+DESCRIPTION
+-----------
+Removes files unknown to git. This allows to clean the working tree
+from files that are not under version control. If the '-x' option is
+specified, ignored files are also removed, allowing to remove all
+build products.
+
+OPTIONS
+-------
+-d::
+ Remove untracked directories in addition to untracked files.
+
+-n::
+ Don't actually remove anything, just show what would be done.
+
+-q::
+ Be quiet, only report errors, but not the files that are
+ successfully removed.
+
+-x::
+ Don't use the ignore rules. This allows removing all untracked
+ files, including build products. This can be used (possibly in
+ conjunction with gitlink:git-reset[1]) to create a pristine
+ working directory to test a clean build.
+
+-X::
+ Remove only files ignored by git. This may be useful to rebuild
+ everything from scratch, but keep manually created files.
+
+
+Author
+------
+Written by Pavel Roskin <proski@gnu.org>
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Makefile b/Makefile
index 145099a..3367b8c 100644
--- a/Makefile
+++ b/Makefile
@@ -114,7 +114,7 @@ ### --- END CONFIGURATION SECTION ---
SCRIPT_SH = \
git-add.sh git-bisect.sh git-branch.sh git-checkout.sh \
- git-cherry.sh git-clone.sh git-commit.sh \
+ git-cherry.sh git-clean.sh git-clone.sh git-commit.sh \
git-count-objects.sh git-diff.sh git-fetch.sh \
git-format-patch.sh git-log.sh git-ls-remote.sh \
git-merge-one-file.sh git-parse-remote.sh \
diff --git a/git-clean.sh b/git-clean.sh
new file mode 100755
index 0000000..b200868
--- /dev/null
+++ b/git-clean.sh
@@ -0,0 +1,80 @@
+#!/bin/sh
+#
+# Copyright (c) 2005-2006 Pavel Roskin
+#
+
+USAGE="[-d] [-n] [-q] [-x | -X]"
+LONG_USAGE='Clean untracked files from the working directory
+ -d remove directories as well
+ -n don'\''t remove anything, just show what would be done
+ -q be quiet, only report errors
+ -x remove ignored files as well
+ -X remove only ignored files as well'
+SUBDIRECTORY_OK=Yes
+. git-sh-setup
+
+ignored=
+ignoredonly=
+cleandir=
+quiet=
+rmf="rm -f"
+rmrf="rm -rf"
+rm_refuse="echo Not removing"
+echo1="echo"
+
+while case "$#" in 0) break ;; esac
+do
+ case "$1" in
+ -d)
+ cleandir=1
+ ;;
+ -n)
+ quiet=1
+ rmf="echo Would remove"
+ rmrf="echo Would remove"
+ rm_refuse="echo Would not remove"
+ echo1=":"
+ ;;
+ -q)
+ quiet=1
+ ;;
+ -x)
+ ignored=1
+ ;;
+ -X)
+ ignoredonly=1
+ ;;
+ *)
+ usage
+ esac
+ shift
+done
+
+case "$ignored,$ignoredonly" in
+ 1,1) usage;;
+esac
+
+if [ -z "$ignored" ]; then
+ excl="--exclude-per-directory=.gitignore"
+ if [ -f "$GIT_DIR/info/exclude" ]; then
+ excl_info="--exclude-from=$GIT_DIR/info/exclude"
+ fi
+ if [ "$ignoredonly" ]; then
+ excl="$excl --ignored"
+ fi
+fi
+
+git-ls-files --others --directory $excl ${excl_info:+"$excl_info"} |
+while read -r file; do
+ if [ -d "$file" -a ! -L "$file" ]; then
+ if [ -z "$cleandir" ]; then
+ $rm_refuse "$file"
+ continue
+ fi
+ $echo1 "Removing $file"
+ $rmrf "$file"
+ else
+ $echo1 "Removing $file"
+ $rmf "$file"
+ fi
+done
^ permalink raw reply related
* Re: [PATCH] parse_date(): fix parsing 03/10/2006
From: Andrew Morton @ 2006-04-05 6:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, len.brown
In-Reply-To: <7vodzg4l5n.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>
> The comment associated with the date parsing code for three
> numbers separated with slashes or dashes implied we wanted to
> interpret using this order:
>
> yyyy-mm-dd
> yyyy-dd-mm
> mm-dd-yy
> dd-mm-yy
>
> However, the actual code had the last two wrong, and making it
> prefer dd-mm-yy format over mm-dd-yy.
But there was a second problem. Once the parsing had misbehaved, Len
managed to create a commit which was six months in the future:
commit 8313524a0d466f451a62709aaedf988d8257b21c
Author: Bob Moore <robert.moore@intel.com>
Date: Tue Oct 3 00:00:00 2006 -0400
ACPI: ACPICA 20060310
Will your fix prevent that from happening? If not, perhaps some basic
sanity checking might be appropriate.
^ permalink raw reply
* Re: [PATCH] Add git-clean command
From: Jakub Narebski @ 2006-04-05 6:25 UTC (permalink / raw)
To: git
In-Reply-To: <20060405060048.6694.65940.stgit@dv.roinet.com>
Pavel Roskin wrote:
> +SYNOPSIS
> +--------
> +[verse]
> +'git-clean' [-d | -D] [-n] [-q] [-x]
Shouldn't it be
> +'git-clean' [-d] [-n] [-q] [-x | -X]
like in below?
> +USAGE="[-d] [-n] [-q] [-x | -X]"
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] parse_date(): fix parsing 03/10/2006
From: Junio C Hamano @ 2006-04-05 6:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20060404231606.219a4cc5.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> writes:
> But there was a second problem. Once the parsing had misbehaved, Len
> managed to create a commit which was six months in the future:
>
> commit 8313524a0d466f451a62709aaedf988d8257b21c
> Author: Bob Moore <robert.moore@intel.com>
> Date: Tue Oct 3 00:00:00 2006 -0400
>
> ACPI: ACPICA 20060310
>
> Will your fix prevent that from happening? If not, perhaps some basic
> sanity checking might be appropriate.
You _might_ get an e-mail to fix kernel problems from yourself
in the future, in which case you would want to commit with
future author date, like this ;-).
People would often deal with dates in the past (way in the past
when talking about importing foreign SCM history), but probably
it would never make sense to do dates way into the future. I'll
think about it.
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Sam Vilain @ 2006-04-05 6:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd596ua0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>A "bind commit" proposal was made to support subprojects living
>in their own subdirectories. The picture to describe the commit
>ancestry chain would be almost the same as the above picture,
>except that it did not uncap and recap, but would have built its
>own ancestry chain.
>
>
I had considered that this would make directory subprojects possible,
but didn't want to draw attention to it.
Actually I'm now of the thinking that the problem is that we are using
'parent' for two things;
1. the merge bases for this merge, if a merge
(or the base for this change for a patch)
2. the historical precedent(s) for this commit.
In the single line of history case these are always the same. For an
actual merge they are also the same. However, when you are superceding a
merge with a newer merge, or mucking with history they are different.
So, I think all we need to make this all work smashingly well is to have
a new field called "prior" or perhaps "previous".
As well as being mostly backwards compatible and supporting grouping
your commits into topics in a single checkout, this would also have the
side effect of:
- directly supporting stgit / pg style patchset evolution, without
needing to use seperate branches for each release of your patchset. This
would not replace the need for stgit etc to wind the head - while
revising a patchset you really don't want the system to record
intermediate changes, just the ones you want to publish
- supporting tree subprojects (as it is a more specific use case)
- rewriting history! Without losing the old commits. Unless you wanted
to - say, for archiving old commits by rebasing the whole project off a
new revision.
It also does not suffer from the 'problem' in Andreas' "dual head
commit" approach that one commit will thenceforth be known by two commit
IDs.
>It had two different kinds of commit relationships: parenthood
>and directory structure binding. The component subprojects
>lived in their own subdirectories (so if you are maintaining an
>embedded Linux along with matching toolchain, you would have linux/
>subdirectory that has the kernel hierarchy, gcc/, libc/, ...),
>and commit objects had "bind commit-sha1 subdirectory-name"
>lines to express how the components are bundled together. A
>commit object would have looked like this:
>
> tree fc9957b0052df6a8248420395bc9febd66194252
> parent 052df6a8248420395bc9febd66194252fc9957b0
> bind f6a8248420395bc9febd66194252fc9957b0052d linux/
> bind 20395bc9febd66194252fc9957b0052df6a82484 gcc/
> author A U Thor <author@example.com> 1144111304 -0700
>
>The "parent" line is the commit ancestry as usual, and each
>"bind" line names a commit object of component project and where
>in the directory hierarchy the tree for that commit object would
>be checked out. The "tree" line records the result of grafting
>the subprojects together. So, for example, ls-tree -d fc9957
>linux in the above example would have shown the tree object
>f6a824^{tree}.
>
>
While the approach I outlined supports this in a way, it is subtly
different.
Firstly, the above approach makes it a hard requirement that the
independent series of commits are in seperate paths, you mention a fix
for this -
>The structure forbid you from binding two separate projects at
>the same directory in order to enforce clean separation of
>subprojects, but if you allow multiple commits to be bound at
>the root level, that could be used as a hydra cap.
>
>
- but this means you are not storing the 'merged' tree in the commit,
which I think is a mistake. While we've been talking mostly about
dealing with managing changes simple enough to merge plainly for
simplicity of operations, this would *force* it to be so because you
need to allow anyone to check it out.
On the other hand - these bind commits enables tracking a sub-project in
a sub-directory whilst retaining the same commit IDs, to make tracking
easier.
Even this works using "prior", too - though you'd have to use surrogate
commits that link to the sub-project commit and wrapper tree object.
How does that sound?
Sam.
^ permalink raw reply
* Re: [PATCH] parse_date(): fix parsing 03/10/2006
From: Andrew Morton @ 2006-04-05 6:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virpo4jxf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
>
> > But there was a second problem. Once the parsing had misbehaved, Len
> > managed to create a commit which was six months in the future:
> >
> > commit 8313524a0d466f451a62709aaedf988d8257b21c
> > Author: Bob Moore <robert.moore@intel.com>
> > Date: Tue Oct 3 00:00:00 2006 -0400
> >
> > ACPI: ACPICA 20060310
> >
> > Will your fix prevent that from happening? If not, perhaps some basic
> > sanity checking might be appropriate.
>
> You _might_ get an e-mail to fix kernel problems from yourself
> in the future, in which case you would want to commit with
> future author date, like this ;-).
>
> People would often deal with dates in the past (way in the past
> when talking about importing foreign SCM history), but probably
> it would never make sense to do dates way into the future. I'll
> think about it.
>
Well it doesn't have to be fatal, of course. Some "do you really want to
do this [y/n]?" prompt, with a command option to override it. Or simply
print a big warning.
Whatever.
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Jakub Narebski @ 2006-04-05 7:11 UTC (permalink / raw)
To: git
In-Reply-To: <443364F5.2040504@vilain.net>
First, hydras or n-head was invented to avoid capping and recapping, and
just advance it as a normal head (and to remember what are
subprojects/patch dependency chains/whatever to choose).
Second, we could generalize those extra commit references in commit
structure (be they "bind", "prior" or "previous", or "depends-on") and have
commit/merge pluggable helper manage them. And merge strategy may make use
of them.
Third, would using *directory* with for a N-HEAD (containing all the
subheads, subprojects, chains, branches, fibers, whatever) instead of an
ordinary file for HEAD be a good idea? For hydra if we want it to be easily
interweaved with ordinary commit I think we would also need the link for
bottom, hydra shoulder, hydra tail i.e. common commit being starting point
for all the chains, or subprojects (for subprojects it can be empty tree
commit).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* How should I handle binary file with GIT
From: moreau francis @ 2006-04-05 7:30 UTC (permalink / raw)
To: git
Hi,
I'd like to use git to keep track of a documentation repository. This repo is
mainly composed by text file and the documenation is generated by asciidoc.
People who are using my repo and updating some docs which may include new
images can't send their whole work through patches.
For now they only send me the text updates through patch and attach new images
with the patch email. Then I do:
$ git am < text_only_patch
$ git reset --soft HEAD^
$ git add <new images>
$ git commit -a -C ORIG_HEAD
Now my question: is it the best way to achieve this process ?
thanks for you answers
Francis
___________________________________________________________________________
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Sam Vilain @ 2006-04-05 7:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e0vqjk$5dr$1@sea.gmane.org>
Jakub Narebski wrote:
>First, hydras or n-head was invented to avoid capping and recapping, and
>just advance it as a normal head (and to remember what are
>subprojects/patch dependency chains/whatever to choose).
>
>Second, we could generalize those extra commit references in commit
>structure (be they "bind", "prior" or "previous", or "depends-on") and have
>
>
Note that these are all quite different types of references. "Bind"
implies an unmerged tree to be woven in on checkout, "prior and
"previous" a historical relationship, and "depends-on" the previous
commit that the change that this commit supplies was based on.
So, I think "parent" already means "depends-on" closely enough.
>commit/merge pluggable helper manage them. And merge strategy may make use
>of them.
>
>Third, would using *directory* with for a N-HEAD (containing all the
>subheads, subprojects, chains, branches, fibers, whatever) instead of an
>ordinary file for HEAD be a good idea? For hydra if we want it to be easily
>interweaved with ordinary commit I think we would also need the link for
>bottom, hydra shoulder, hydra tail i.e. common commit being starting point
>for all the chains, or subprojects (for subprojects it can be empty tree
>commit).
>
>
This was similar to the original suggestion, of heads that have multiple
heads, or hydra. I think the basic rejection for this is that nothing is
then tracking the progression of the merged tree - unless you keep a
"cherry picked" tree for the combined work. And of course it is a
backwards incompatible change.
Sam.
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Jakub Narebski @ 2006-04-05 7:59 UTC (permalink / raw)
To: git
In-Reply-To: <4433723E.1080705@vilain.net>
Sam Vilain wrote:
> Jakub Narebski wrote:
>>Third, would using *directory* with for a N-HEAD (containing all the
>>subheads, subprojects, chains, branches, fibers, whatever) instead of an
>>ordinary file for HEAD be a good idea? For hydra if we want it to be
>>easily interweaved with ordinary commit I think we would also need the
>>link for bottom, hydra shoulder, hydra tail i.e. common commit being
>>starting point for all the chains, or subprojects (for subprojects it can
>>be empty tree commit).
>
> This was similar to the original suggestion, of heads that have multiple
> heads, or hydra. I think the basic rejection for this is that nothing is
> then tracking the progression of the merged tree - unless you keep a
> "cherry picked" tree for the combined work. And of course it is a
> backwards incompatible change.
I thought about keeping N-HEAD and HEAD and updating them simultaneously.
With extra fields in commit (however they would be named) use them, without
extra fields use ordinary branches, creating histories like in your example
in first post in the thread.
I.e. when doing [hydra] commit, add commit to ordinary history (recording
the time sequence of changes inside branch) advancing HEAD, and add commit
to appropriate chain/subhead/fiber in the N-HEAD and "advance N-HEAD". This
would make change backwards compatibile.
The problem would be to keep N-HEAD and HEAD to get out of sync, e.g. when
somebody updates only HEAD with an older git... well, we can always advance
N-HEAD to HEAD using commits from the time they were in sync to the current
head state.
--
Jakub Narebski
ShadeHawk on #git
Warsaw, Poland
^ 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