* 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 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: 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: [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: [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: [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: 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: 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: 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: HTTP repo referencing stale heads (can't clone)
From: Nick Hengeveld @ 2006-04-04 17:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060404152737.GN27689@pasky.or.cz>
On Tue, Apr 04, 2006 at 05:27:37PM +0200, Petr Baudis wrote:
> Because people do not know they have to set up their post-update hook.
> When they are already going at lengths to find out how to set up DAV for
> git fetch, they would discover the post-update hook way as well.
There are other reasons that a client can end up with a stale copy of
the server info files - in this case the problem was an intermediate
proxy out of the control of the repo admin.
While we should be able to fix that particular problem, it seems safer
to go straight to the source if possible.
> So, it really seems rather redundant to me.
If I've already enabled DAV for pushing to a repo, I'd find it nice to
be able to use it for fetches as well.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* [BUG] git-http-fetch segfault
From: Radoslaw Szkodzinski @ 2006-04-04 17:11 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 3379 bytes --]
I have some problems cloning stgit repository (maybe something's broken there).
The repository seems to be using symlink HEAD.
Possibly the problem is because of a non-existent tag commit.
Yes, it has that broken HTTP error message bug.
Git version:
astralstorm@zen /home/devel/git $ git log -n 1 | head -n 1
commit fc9957b0052df6a8248420395bc9febd66194252
Session log (slightly linewrapped):
astralstorm@zen /home/devel $ git clone
http://homepage.ntlworld.com/cmarinas/stgit.git stgit
got 52f3900c0c7dec8581fa907495a09c900a3d39d7
walk 52f3900c0c7dec8581fa907495a09c900a3d39d7
got c82395b46d238948882045e76e7770319a4f40e8
got aa78d4ed34d262b6f811e7e47415c8c4ac6d80a2
walk c82395b46d238948882045e76e7770319a4f40e8
got 098c1d3e9fe5c39b859ccff6c7d36d2c193d1b62
got 4ebca0e1cabe90ecdcd29aab6fa16521d4999fb5
got 8d2bebd9d1824f1b7af5cfe6fbd11f9cbfde6d74
got 184ded8e08cb92a14b79c79f9919469ba352ab70
got d60c31a97a544b53039088d14fe9114583c0efc3
got e5affe07bf8b39e2aa0309299dbc9532e05940b5
got c2514fd418472dc173a5fef09c82ccf666c9555f
got 3c900ce9dae0959a9e4479b55b8a71d1b92d170d
got 7888f29f97452f8db39f4a9e857b7f1d2c913765
got 4359033a665b7943f2a7579e8329a715fd2fdc57
got def843c5d5fd4dee9a54504512b4308cb3a84018
got 0c3ad3951bb8cf368c70b13240665495e19a98a9
got 32977d8fae38a542b15dd9c5e39d64076a35227b
got 8847a11b3bbf5406f37a360e5466f0e392c56383
got 07704b8331d6d78a132c731874f66749dfa0f85c
got 5b8d95f20b8989fde6b0731c55b3f985ed01630a
got 6a8557477abde3f1368304e6fb8d890e2982267e
got de7bd13bae9eec619ae4baf46e65475602d52979
got 5899c38225df2244c7b09015f5b754d9735415d5
got ebd09f908d165c7aa3a135ddc8bbd5a05787df93
walk 8847a11b3bbf5406f37a360e5466f0e392c56383
got 6480a2a7f279002c3daf5a56ece16636cd5df26f
got 568bc169d53ee40ef5dc7481e7cab8078141fa9e
Getting alternates list for http://homepage.ntlworld.com/cmarinas/stgit.git/
got 4b03e3a6440883cf8ef6092426b3d932b8b0c73a
got ee90cfb41de9e3a589fc688ba1350e9c8b846c20
got c394572a81d9b3322a7a7cdccec0c1846d445dcc
got 66e9f41044631264c2740f61ddafbc4bd01ec71a
got c603ff88fcd21f1e4b806413d195c90f29ea547f
got a0569457816c345e8c7fa92135fd664dd67ea97c
got 5749b3bd8476df9e2808a3723e23d7acd4e4c71d
got f4d749004ac695720ab883c338fdc3df5da394bb
got e7f3481a23600c969a3cdf9bf793e8239546c1d1
got 1317788c088c3f621f83ceae657e0d1f6f34af54
got 7881993b68ead8678545516fa8e04f8919569b8e
got 44cd19e162f9ff976df475bccecd63a42e04a244
Getting pack list for http://homepage.ntlworld.com/cmarinas/stgit.git/
got 694ea0c23cc88422d923104b04832df48865dae6
got 938ce9bb5812cac4d0902ae6f87a276d51a58cd9
got 9534f1c94a19e5521bbb7a5664d587400eb55905
got fc9c5a73a29673f06b683a85134531ad6d9520ea
got f80bef4918840e4290f03f291d8b4dbb98b12d80
error: Unable to find adad46f365219e9bcc1a212826ca65eaac09729c under
http://homepage.ntlworld.com/cmarinas/stgit.git/
Cannot obtain needed blob adad46f365219e9bcc1a212826ca65eaac09729c
while processing commit 8847a11b3bbf5406f37a360e5466f0e392c56383.
Waiting for
http://homepage.ntlworld.com/cmarinas/stgit.git/objects/d5/68cd60c5759cfd84d4148f3c3d5bf9f5b85d41
/usr/bin/git-clone: line 29: 13000 Naruszenie ochrony pamięci git-http-fetch
-v -a -w "$tname" "$name" "$1/"
(Naruszenie ochrony pamięci = Segmentation fault)
--
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
* [PATCH] Set HTTP user agent to git/GIT_VERSION
From: Nick Hengeveld @ 2006-04-04 17:11 UTC (permalink / raw)
To: git
Useful for diagnostics/troubleshooting to know which client versions are
hitting your server.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
Makefile | 3 +++
http.c | 2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
468d4d4ac3cbdb0757a7cc1c207ca379ce3a5d56
diff --git a/Makefile b/Makefile
index 19ce42c..c7d5ecf 100644
--- a/Makefile
+++ b/Makefile
@@ -510,6 +510,9 @@ git$X git.spec \
exec_cmd.o: exec_cmd.c
$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' $<
+http.o: http.c
+ $(CC) -o $*.o -c $(ALL_CFLAGS) -DGIT_USER_AGENT='"git/$(GIT_VERSION)"' $<
+
ifdef NO_EXPAT
http-fetch.o: http-fetch.c
$(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<
diff --git a/http.c b/http.c
index 9604e33..0cb42a8 100644
--- a/http.c
+++ b/http.c
@@ -195,6 +195,8 @@ #endif
if (getenv("GIT_CURL_VERBOSE"))
curl_easy_setopt(result, CURLOPT_VERBOSE, 1);
+ curl_easy_setopt(result, CURLOPT_USERAGENT, GIT_USER_AGENT);
+
return result;
}
--
1.3.0.rc1.g9aef-dirty
^ permalink raw reply related
* Re: [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-04 15:52 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Junio C Hamano, git
In-Reply-To: <20060404105818.GA17326@mars.ravnborg.org>
On Tue, 2006-04-04 at 12:58 +0200, Sam Ravnborg wrote:
> On Mon, Apr 03, 2006 at 05:06:36PM -0700, Junio C Hamano wrote:
> >
> > I am not opposed to the command in the sense that I do not want
> > to forbid people from doing what they want to do, but on the
> > other hand I do not see why people (apparently many people) want
> > to have something like this. Are their "make clean" broken?
Normally it is not, but if it is, they want to know it. If git-clean
remove something after "make clean" then maybe the later is incomplete.
To put it another way, if I make changes and share them with others, I
want to make sure that my changes will work for them. If the mechanism
for sharing my changes is make-based, I rely on make to check them. In
projects using Automake it's called "make distcheck". If I'm sharing my
changes as a git patch, I want a git-based verification that the project
still builds from scratch.
Also, the files cleaned by "make clean" are normally build products.
Things that you _really_ don't want to be in the source tree at the
release time are other files, such as backup files with changes that you
decided to back out, sources that you may not share, firmware that cost
your company $50000 and so on. "make clean" won't remove them.
> No reason to waste time on make clean.
> git ls-files -o | xargs rm
> Does the same job nicely.
This would remove ignored files. It's not always what I want.
> Other typical usecases for me:
> Remove temporaries that I created while trying out stuff.
> Often I have a bunch of files named 'x', 'xx', 'fisk' etc.
> around for no use. An easy way to remove these without breaking
> my 'allmodconfig' build is nice. It anyway > 1 hour to build and
> I like to get rid of the untracked stuff in an easy way.
>
> So use cases goes like this:
> - Remove everything not tracked by git (including .gitignore files)
> - Remove everything except tracked by git or ignored
> - Remove ignored files (replacement of make clean) (seldom)
I'll think about the later.
> Above should work both from top-level dir and in subdirectories.
>
> That is my minimal expectations to git clean.
> What Pavel came up with cover everything except the make clean
> replacement part.
Exactly. The "make clean" replacement is actually the one I didn't
implement.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] read-cache.c: Slight parameter name improvement.
From: Peter Eriksen @ 2006-04-04 15:42 UTC (permalink / raw)
To: git
From: Peter Eriksen <s022018@student.dtu.dk>
Date: Tue Apr 4 17:40:02 2006 +0200
Subject: [PATCH] read-cache.c: Slight parameter name improvement.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
read-cache.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
dde622db1412a556b216eceff4a9a677b41568c3
diff --git a/read-cache.c b/read-cache.c
index f97f92d..2e8fdc5 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -257,7 +257,7 @@ int cache_name_compare(const char *name1
return 0;
}
-int cache_name_pos(const char *name, int namelen)
+int cache_name_pos(const char *name, int flags)
{
int first, last;
@@ -266,7 +266,7 @@ int cache_name_pos(const char *name, int
while (last > first) {
int next = (last + first) >> 1;
struct cache_entry *ce = active_cache[next];
- int cmp = cache_name_compare(name, namelen, ce->name, ntohs(ce->ce_flags));
+ int cmp = cache_name_compare(name, flags, ce->name, ntohs(ce->ce_flags));
if (!cmp)
return next;
if (cmp < 0) {
--
1.3.0.rc1.gfc99-dirty
^ permalink raw reply related
* Re: [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-04 15:32 UTC (permalink / raw)
To: Alex Riesen; +Cc: Martin Waitz, git
In-Reply-To: <81b0412b0604040217s3b8863d3w1b79400c42ca2b90@mail.gmail.com>
On Tue, 2006-04-04 at 11:17 +0200, Alex Riesen wrote:
> On 4/4/06, Martin Waitz <tali@admingilde.org> wrote:
> > What is the use case of cleaning up all untracked files without also
> > cleaning ignored files?
>
> Thinks of git's .gitignore: it has config.mak in it. Are you sure you want
> "clean" your build customizations?
In may case, I normally want to remove copies of the sources. For
example, I take foo.c, make a clean copy of it, then I change and test
it. If if doesn't work and I want to try another approach, I copy it to
foo.c-bad or foo.c-approach1. I also make diffs between files to see
what exactly I changed. I may also create files for output, valgrind
logs and so on.
At some point, I'm satisfied with foo.c, so I commit it. Then I want to
remove copies, diffs and other stuff. Yet I don't want to rebuild
everything.
It's very rare that I add a new file, and I always remember to add it to
the version control. But I'll consider adding an option to only remove
ignored files.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Petr Baudis @ 2006-04-04 15:27 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20060404121056.GB14967@reactrix.com>
Dear diary, on Tue, Apr 04, 2006 at 02:10:57PM CEST, I got a letter
where Nick Hengeveld <nickh@reactrix.com> said that...
> On Tue, Apr 04, 2006 at 12:00:35PM +0200, Petr Baudis wrote:
>
> > Well, what is the actual advantage of DAV compared to
> > git-update-server-info? Why would I prefer enabling DAV?
>
> In theory, things should work the same either way. It seems that in
> practice though, the server info files continue to surface as a source
> of fetch problems.
Because people do not know they have to set up their post-update hook.
When they are already going at lengths to find out how to set up DAV for
git fetch, they would discover the post-update hook way as well.
So, it really seems rather redundant to me.
--
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
* [PATCH] Solaris needs strings.h when using index().
From: Peter Eriksen @ 2006-04-04 12:36 UTC (permalink / raw)
To: git
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>
---
blame.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
832067e6e16ae6c1ac3bd043ddeb56daa993e682
diff --git a/blame.c b/blame.c
index 396defc..1a08434 100644
--- a/blame.c
+++ b/blame.c
@@ -6,6 +6,7 @@ #include <assert.h>
#include <time.h>
#include <sys/time.h>
#include <math.h>
+#include <strings.h>
#include "cache.h"
#include "refs.h"
--
1.3.0.rc1.gfc99-dirty
^ permalink raw reply related
* [PATCH] http-fetch: add optional DAV-based pack list
From: Nick Hengeveld @ 2006-04-04 12:33 UTC (permalink / raw)
To: git
If git is not built with NO_EXPAT, this patch changes git-http-fetch to
attempt using DAV to get a list of remote packs and fall back to using
objects/info/packs if the DAV request fails.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
Makefile | 7 +
http-fetch.c | 278 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 284 insertions(+), 1 deletions(-)
9aef9577cabbd96de20562902d2958108616a7e4
diff --git a/Makefile b/Makefile
index c79d646..19ce42c 100644
--- a/Makefile
+++ b/Makefile
@@ -510,6 +510,11 @@ git$X git.spec \
exec_cmd.o: exec_cmd.c
$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' $<
+ifdef NO_EXPAT
+http-fetch.o: http-fetch.c
+ $(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<
+endif
+
git-%$X: %.o $(GITLIBS)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
@@ -532,7 +537,7 @@ git-imap-send$X: imap-send.o $(LIB_FILE)
git-http-fetch$X: fetch.o http.o http-fetch.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
- $(LIBS) $(CURL_LIBCURL)
+ $(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
git-http-push$X: revision.o http.o http-push.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
diff --git a/http-fetch.c b/http-fetch.c
index dc67218..71a7daf 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -4,6 +4,35 @@ #include "pack.h"
#include "fetch.h"
#include "http.h"
+#ifndef NO_EXPAT
+#include <expat.h>
+
+/* Definitions for DAV requests */
+#define DAV_PROPFIND "PROPFIND"
+#define DAV_PROPFIND_RESP ".multistatus.response"
+#define DAV_PROPFIND_NAME ".multistatus.response.href"
+#define DAV_PROPFIND_COLLECTION ".multistatus.response.propstat.prop.resourcetype.collection"
+#define PROPFIND_ALL_REQUEST "<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n<D:propfind xmlns:D=\"DAV:\">\n<D:allprop/>\n</D:propfind>"
+
+/* Definitions for processing XML DAV responses */
+#ifndef XML_STATUS_OK
+enum XML_Status {
+ XML_STATUS_OK = 1,
+ XML_STATUS_ERROR = 0
+};
+#define XML_STATUS_OK 1
+#define XML_STATUS_ERROR 0
+#endif
+
+/* Flags that control remote_ls processing */
+#define PROCESS_FILES (1u << 0)
+#define PROCESS_DIRS (1u << 1)
+#define RECURSIVE (1u << 2)
+
+/* Flags that remote_ls passes to callback functions */
+#define IS_DIR (1u << 0)
+#endif
+
#define PREV_BUF_SIZE 4096
#define RANGE_HEADER_SIZE 30
@@ -15,6 +44,7 @@ static struct curl_slist *no_pragma_head
struct alt_base
{
char *base;
+ int path_len;
int got_indices;
struct packed_git *packs;
struct alt_base *next;
@@ -56,8 +86,32 @@ struct alternates_request {
struct buffer *buffer;
struct active_request_slot *slot;
int http_specific;
+};
+
+#ifndef NO_EXPAT
+struct xml_ctx
+{
+ char *name;
+ int len;
+ char *cdata;
+ void (*userFunc)(struct xml_ctx *ctx, int tag_closed);
+ void *userData;
};
+struct remote_ls_ctx
+{
+ struct alt_base *repo;
+ char *path;
+ void (*userFunc)(struct remote_ls_ctx *ls);
+ void *userData;
+ int flags;
+ char *dentry_name;
+ int dentry_flags;
+ int rc;
+ struct remote_ls_ctx *parent;
+};
+#endif
+
static struct object_request *object_queue_head = NULL;
static size_t fwrite_sha1_file(void *ptr, size_t eltsize, size_t nmemb,
@@ -500,6 +554,7 @@ static void process_alternates_response(
int serverlen = 0;
struct alt_base *newalt;
char *target = NULL;
+ char *path;
if (data[i] == '/') {
serverlen = strchr(base + 8, '/') - base;
okay = 1;
@@ -540,6 +595,13 @@ static void process_alternates_response(
newalt->base = target;
newalt->got_indices = 0;
newalt->packs = NULL;
+ path = strstr(target, "//");
+ if (path) {
+ path = index(path+2, '/');
+ if (path)
+ newalt->path_len = strlen(path);
+ }
+
while (tail->next != NULL)
tail = tail->next;
tail->next = newalt;
@@ -608,9 +670,212 @@ #endif
got_alternates = -1;
free(data);
+ free(url);
+}
+
+#ifndef NO_EXPAT
+static void
+xml_start_tag(void *userData, const char *name, const char **atts)
+{
+ struct xml_ctx *ctx = (struct xml_ctx *)userData;
+ const char *c = index(name, ':');
+ int new_len;
+
+ if (c == NULL)
+ c = name;
+ else
+ c++;
+
+ new_len = strlen(ctx->name) + strlen(c) + 2;
+
+ if (new_len > ctx->len) {
+ ctx->name = xrealloc(ctx->name, new_len);
+ ctx->len = new_len;
+ }
+ strcat(ctx->name, ".");
+ strcat(ctx->name, c);
+
+ if (ctx->cdata) {
+ free(ctx->cdata);
+ ctx->cdata = NULL;
+ }
+
+ ctx->userFunc(ctx, 0);
+}
+
+static void
+xml_end_tag(void *userData, const char *name)
+{
+ struct xml_ctx *ctx = (struct xml_ctx *)userData;
+ const char *c = index(name, ':');
+ char *ep;
+
+ ctx->userFunc(ctx, 1);
+
+ if (c == NULL)
+ c = name;
+ else
+ c++;
+
+ ep = ctx->name + strlen(ctx->name) - strlen(c) - 1;
+ *ep = 0;
+}
+
+static void
+xml_cdata(void *userData, const XML_Char *s, int len)
+{
+ struct xml_ctx *ctx = (struct xml_ctx *)userData;
+ if (ctx->cdata)
+ free(ctx->cdata);
+ ctx->cdata = xcalloc(len+1, 1);
+ strncpy(ctx->cdata, s, len);
+}
+
+static int remote_ls(struct alt_base *repo, const char *path, int flags,
+ void (*userFunc)(struct remote_ls_ctx *ls),
+ void *userData);
+
+static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
+{
+ struct remote_ls_ctx *ls = (struct remote_ls_ctx *)ctx->userData;
+
+ if (tag_closed) {
+ if (!strcmp(ctx->name, DAV_PROPFIND_RESP) && ls->dentry_name) {
+ if (ls->dentry_flags & IS_DIR) {
+ if (ls->flags & PROCESS_DIRS) {
+ ls->userFunc(ls);
+ }
+ if (strcmp(ls->dentry_name, ls->path) &&
+ ls->flags & RECURSIVE) {
+ ls->rc = remote_ls(ls->repo,
+ ls->dentry_name,
+ ls->flags,
+ ls->userFunc,
+ ls->userData);
+ }
+ } else if (ls->flags & PROCESS_FILES) {
+ ls->userFunc(ls);
+ }
+ } else if (!strcmp(ctx->name, DAV_PROPFIND_NAME) && ctx->cdata) {
+ ls->dentry_name = xmalloc(strlen(ctx->cdata) -
+ ls->repo->path_len + 1);
+ strcpy(ls->dentry_name, ctx->cdata + ls->repo->path_len);
+ } else if (!strcmp(ctx->name, DAV_PROPFIND_COLLECTION)) {
+ ls->dentry_flags |= IS_DIR;
+ }
+ } else if (!strcmp(ctx->name, DAV_PROPFIND_RESP)) {
+ if (ls->dentry_name) {
+ free(ls->dentry_name);
+ }
+ ls->dentry_name = NULL;
+ ls->dentry_flags = 0;
+ }
+}
+
+static int remote_ls(struct alt_base *repo, const char *path, int flags,
+ void (*userFunc)(struct remote_ls_ctx *ls),
+ void *userData)
+{
+ char *url = xmalloc(strlen(repo->base) + strlen(path) + 1);
+ struct active_request_slot *slot;
+ struct slot_results results;
+ struct buffer in_buffer;
+ struct buffer out_buffer;
+ char *in_data;
+ char *out_data;
+ XML_Parser parser = XML_ParserCreate(NULL);
+ enum XML_Status result;
+ struct curl_slist *dav_headers = NULL;
+ struct xml_ctx ctx;
+ struct remote_ls_ctx ls;
+
+ ls.flags = flags;
+ ls.repo = repo;
+ ls.path = strdup(path);
+ ls.dentry_name = NULL;
+ ls.dentry_flags = 0;
+ ls.userData = userData;
+ ls.userFunc = userFunc;
+ ls.rc = 0;
+
+ sprintf(url, "%s%s", repo->base, path);
+
+ out_buffer.size = strlen(PROPFIND_ALL_REQUEST);
+ out_data = xmalloc(out_buffer.size + 1);
+ snprintf(out_data, out_buffer.size + 1, PROPFIND_ALL_REQUEST);
+ out_buffer.posn = 0;
+ out_buffer.buffer = out_data;
+
+ in_buffer.size = 4096;
+ in_data = xmalloc(in_buffer.size);
+ in_buffer.posn = 0;
+ in_buffer.buffer = in_data;
+
+ dav_headers = curl_slist_append(dav_headers, "Depth: 1");
+ dav_headers = curl_slist_append(dav_headers, "Content-Type: text/xml");
+
+ slot = get_active_slot();
+ slot->results = &results;
+ curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.size);
+ curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+ curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
+ curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PROPFIND);
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
+
+ if (start_active_slot(slot)) {
+ run_active_slot(slot);
+ if (results.curl_result == CURLE_OK) {
+ ctx.name = xcalloc(10, 1);
+ ctx.len = 0;
+ ctx.cdata = NULL;
+ ctx.userFunc = handle_remote_ls_ctx;
+ ctx.userData = &ls;
+ XML_SetUserData(parser, &ctx);
+ XML_SetElementHandler(parser, xml_start_tag,
+ xml_end_tag);
+ XML_SetCharacterDataHandler(parser, xml_cdata);
+ result = XML_Parse(parser, in_buffer.buffer,
+ in_buffer.posn, 1);
+ free(ctx.name);
+
+ if (result != XML_STATUS_OK) {
+ ls.rc = error("XML error: %s",
+ XML_ErrorString(
+ XML_GetErrorCode(parser)));
+ }
+ } else {
+ ls.rc = -1;
+ }
+ } else {
+ ls.rc = error("Unable to start PROPFIND request");
+ }
+
+ free(ls.path);
free(url);
+ free(out_data);
+ free(in_buffer.buffer);
+ curl_slist_free_all(dav_headers);
+
+ return ls.rc;
}
+static void process_ls_pack(struct remote_ls_ctx *ls)
+{
+ unsigned char sha1[20];
+
+ if (strlen(ls->dentry_name) == 63 &&
+ !strncmp(ls->dentry_name, "objects/pack/pack-", 18) &&
+ !strncmp(ls->dentry_name+58, ".pack", 5)) {
+ get_sha1_hex(ls->dentry_name + 18, sha1);
+ setup_index(ls->repo, sha1);
+ }
+}
+#endif
+
static int fetch_indices(struct alt_base *repo)
{
unsigned char sha1[20];
@@ -632,6 +897,12 @@ static int fetch_indices(struct alt_base
if (get_verbosely)
fprintf(stderr, "Getting pack list for %s\n", repo->base);
+
+#ifndef NO_EXPAT
+ if (remote_ls(repo, "objects/pack/", PROCESS_FILES,
+ process_ls_pack, NULL) == 0)
+ return 0;
+#endif
url = xmalloc(strlen(repo->base) + 21);
sprintf(url, "%s/objects/info/packs", repo->base);
@@ -947,6 +1218,7 @@ int main(int argc, char **argv)
{
char *commit_id;
char *url;
+ char *path;
int arg = 1;
int rc = 0;
@@ -987,6 +1259,12 @@ int main(int argc, char **argv)
alt->got_indices = 0;
alt->packs = NULL;
alt->next = NULL;
+ path = strstr(url, "//");
+ if (path) {
+ path = index(path+2, '/');
+ if (path)
+ alt->path_len = strlen(path);
+ }
if (pull(commit_id))
rc = 1;
--
1.3.0.rc1.gd4df-dirty
^ permalink raw reply related
* Re: HTTP repo referencing stale heads (can't clone)
From: Nick Hengeveld @ 2006-04-04 12:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060404100035.GM27689@pasky.or.cz>
On Tue, Apr 04, 2006 at 12:00:35PM +0200, Petr Baudis wrote:
> Well, what is the actual advantage of DAV compared to
> git-update-server-info? Why would I prefer enabling DAV?
In theory, things should work the same either way. It seems that in
practice though, the server info files continue to surface as a source
of fetch problems.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Andreas Ericsson @ 2006-04-04 11:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e0tjpk$ktu$1@sea.gmane.org>
Jakub Narebski wrote:
> Andreas Ericsson wrote:
>
>
>>Wouldn't "git commit -M -b topic", for committing to a different branch
>>than what is checked out (-b) and also to the checked out branch (-M)
>>have the same beneficial effects, but without the complexity of hydras
>>and patch dependency theory? It would only remove the cherry-pick stage
>>though, but perhaps it's good enough. Although when I think about it, -b
>><branch> for committing to another branch and -B <branch> for doing the
>>above probably makes more sense.
>
>
> Do you mean that you commit current state to the checked out (working)
> branch, and commit *changes* (i.e. apply patch) to a different branch?
>
No, I mean that this would commit both to the testing branch (being the
result of several merged topic-branches) and to the topic-branch merged
in. Commit as in regular commit, with a commit-message and a patch. The
resulting repository would be the exact same as if the change was
committed only to the topic-branch and then cherry-picked on to the
testing-branch.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Catalin Marinas @ 2006-04-04 11:05 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List
In-Reply-To: <4430D352.4010707@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> "Patch dependency chains", the best plain-English term we could find for
> the scary sounding darcs term "patch calculus", are said by some to be a
> very good reason to use a system like darcs, even to some its
> fundamental advantage over systems such as git.
As Linus pointed out, while darcs theory is interesting, it doesn't
work properly in practice. Dependency tracking can create problems
with merging. Darcs' patch commuting theory has (a big, IMHO) problem
since every time you pull a patch (or more) it needs to commute all
the patches back to the common ancestor. Over time, the merging
becomes slower and slower (i.e. even much slower than what darcs shows
in simple tests with the Linux kernel).
Inexact patch commuting can be achieved using diff3 (or merge) with 3
snapshots of the tree (the bottom of the patch, the top of the patch
and the current head on top of which the patch is being applied) which
GIT handles very well and fast since there is no need to commute
thousands of patches back to the common ancestor. The slight
disadvantage is that diff3 merging is not as exact as Darcs' patch
commuting but OK for 99% of the real cases.
StGIT is based on this inexact patch commuting "theory" and, with the
addition of upstream merging detection (based on reverse-applying), it
is seems to behave properly in almost all the cases (though you can
deliberately create some patches to break the algorithm).
I've been thinking about adding patch dependency tracking to StGIT but
only as a recommendation and not enforcement. The algorithm would be
similar to the upstream merging detection.
--
Catalin
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Jakub Narebski @ 2006-04-04 11:03 UTC (permalink / raw)
To: git
In-Reply-To: <44323C52.2030803@op5.se>
Andreas Ericsson wrote:
> Wouldn't "git commit -M -b topic", for committing to a different branch
> than what is checked out (-b) and also to the checked out branch (-M)
> have the same beneficial effects, but without the complexity of hydras
> and patch dependency theory? It would only remove the cherry-pick stage
> though, but perhaps it's good enough. Although when I think about it, -b
> <branch> for committing to another branch and -B <branch> for doing the
> above probably makes more sense.
Do you mean that you commit current state to the checked out (working)
branch, and commit *changes* (i.e. apply patch) to a different branch?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] Add git-clean command
From: Sam Ravnborg @ 2006-04-04 10:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vzmj2b3w3.fsf@assigned-by-dhcp.cox.net>
On Mon, Apr 03, 2006 at 05:06:36PM -0700, Junio C Hamano wrote:
>
> I am not opposed to the command in the sense that I do not want
> to forbid people from doing what they want to do, but on the
> other hand I do not see why people (apparently many people) want
> to have something like this. Are their "make clean" broken?
No reason to waste time on make clean.
git ls-files -o | xargs rm
Does the same job nicely.
Other typical usecases for me:
Remove temporaries that I created while trying out stuff.
Often I have a bunch of files named 'x', 'xx', 'fisk' etc.
around for no use. An easy way to remove these without breaking
my 'allmodconfig' build is nice. It anyway > 1 hour to build and
I like to get rid of the untracked stuff in an easy way.
So use cases goes like this:
- Remove everything not tracked by git (including .gitignore files)
- Remove everything except tracked by git or ignored
- Remove ignored files (replacement of make clean) (seldom)
Above should work both from top-level dir and in subdirectories.
That is my minimal expectations to git clean.
What Pavel came up with cover everything except the make clean
replacement part.
Sam
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Andreas Ericsson @ 2006-04-04 10:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wwd8y9j.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>Sam Vilain wrote:
>>
>>>Junio C Hamano wrote:
>>>
>>>>[ made change on a test branch that bundles topic branches
>>>> -- now want to commit back to the component topic branch ]
>>>>Would patch commutation calculus help with his problem?
>>>>
>>>
>>>I'd provisionally say "yes, that's the fit". It's just like having
>>>multiple topic branches all checked out at once, with commits going to
>>>the appropriate branch as necessary.
>>
>>Wouldn't "git commit -M -b topic", for committing to a different
>>branch than what is checked out (-b) and also to the checked out
>>branch (-M) have the same beneficial effects, but without the
>>complexity of hydras and patch dependency theory? It would only remove
>>the cherry-pick stage though, but perhaps it's good enough. Although
>>when I think about it, -b
>><branch> for committing to another branch and -B <branch> for doing
>>the above probably makes more sense.
>
>
> It feels to me that the above set of flags encourage a workflow
> that:
>
> (1) modify the source and run tests in "test" branch;
> (2) have tool automatically adjust the change to match the other
> branch (i.e. the topic to be checked in) automatically;
> (3) make a commit, without a chance to do the final sanity
> check in the context of the branch being committed.
>
I don't fully understand 3 here. The workflow makes it easier to test
how different topics work together, and make fixes to those that don't
play well with others. Granted, it's not possible to test each topic by
itself without checking it out, making the changes and re-compiling and
so on, but since commits are so easy to undo I think it'd be nice to
have the changes tracked. Another good thing is that fixes that apply on
top of the "work-together" fixes, but that only make the topic branch
build/work properly are completely rebase'able, and should result in a
fast-forward merge since they share the same commit.
> An individual topic branch itself might not be even testable
> standalone, but at least I'd prefer to have a chance to double
> check if the "patch commuting" (or "cherry-pick stage") did a
> sensible thing [*1*].
>
Understandable, and this workflow would still be available, but see below.
> As I said on the list in the past, I am from a school that
> believes in not committing anything that has not been
> tested/reviewed as a whole, especially when it comes to
> individual developers, so I am not sure it is a good idea
> in general to make it easy to do so to begin with.
>
In short, you're from the school of centralized repositories. I used to
be very careful about committing things too, but since I switched to git
I happily commit smaller and more often, and regularly toss up a
throw-away branch to make small commits that may or may not work and
later apply the (tested) combined diff as a single commit or series of
commits at points where I've tested one feature/fix to actually work as
intended. This is nifty because people that help with testing can pull
from my throw-away branch and get to work without me having to send them
a tar-tree and a patch.
I believe in not *pushing* anything that hasn't been thoroughly tested,
but the ability to track and commit possibly broken changes without it
affecting the project as a whole is what makes git so great for me. In
the CVS days distributed testing was a nuissance. With git it's smooth
sailing.
>
>>Those flags don't exist currently btw, in case someone's reading this
>>on the archives.
>
>
> I take it that you are volunteering to come up with an initial
> round of implementation of these flags?
>
Unless someone can convince me I'm on the wrong track before I get off
work, yes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Petr Baudis @ 2006-04-04 10:00 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Junio C Hamano, Daniel Drake, git
In-Reply-To: <20060403180929.GA14967@reactrix.com>
Dear diary, on Mon, Apr 03, 2006 at 08:09:30PM CEST, I got a letter
where Nick Hengeveld <nickh@reactrix.com> said that...
> Long term, this could give a repo admin the choice of either making sure
> git-update-server-info has been run after every ref/pack change or
> enabling DAV once. Assuming they need to use HTTP.
Well, what is the actual advantage of DAV compared to
git-update-server-info? Why would I prefer enabling DAV?
--
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
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