* Re: [PATCH] .gitignore git-rerere and config.mak
From: Junio C Hamano @ 2006-02-08 5:34 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <1303.1139370931@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
> And Junio C Hamano writes:
> - I am not sure about this part. It is plausible that somebody
> - who privately uses config.mak has it in _his_ repository under
> - version control.
>
> Like me. That way I don't have to worry about conflicts in the
> Makefile. But I can change .gitignore in those branches...
Or you can leave that as is. .gitignore is used to sift
untracked files into two categories - ignored and unknown. So
my initial worry was unfounded.
Sorry for the noise.
^ permalink raw reply
* Re: [PATCH] .gitignore git-rerere and config.mak
From: Jason Riedy @ 2006-02-08 3:55 UTC (permalink / raw)
To: git
In-Reply-To: <7vk6c7uj21.fsf@assigned-by-dhcp.cox.net>
And Junio C Hamano writes:
- I am not sure about this part. It is plausible that somebody
- who privately uses config.mak has it in _his_ repository under
- version control.
Like me. That way I don't have to worry about conflicts in the
Makefile. But I can change .gitignore in those branches...
Jason
^ permalink raw reply
* Re: gitk changing line color for no reason after merge
From: Paul Mackerras @ 2006-02-08 2:30 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Junio C Hamano, git
In-Reply-To: <1139360047.13646.22.camel@dv>
Pavel Roskin writes:
> I'm trying to make it easier to follow a line. It's easier if its color
> is not changing, especially on trivial nodes (one parent, one child).
OK, you're using "line" to mean something a bit different from the
connection between a commit and its children, which is how I use it.
You seem to be using it more as a "line of development", or as a
series of related patches. Which is fine, if you can find a way to
identify lines of development automatically. (I know it looks obvious
when you look at the gitk display, but that's a lot different from
writing down an algorithm to do it.)
> http://red-bean.com/proski/gitk/gitk-ideal.png - made in GIMP. Trivial
> nodes never change line color, because it changes as soon as the line
> forks.
My problem with that is that it isn't clear that e.g. the green and
brown lines near the bottom actually represent the same parent - and
that will get worse with more complex graphs.
Paul.
^ permalink raw reply
* Re: gitk changing line color for no reason after merge
From: Pavel Roskin @ 2006-02-08 1:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17384.24784.898327.669875@cargo.ozlabs.ibm.com>
On Tue, 2006-02-07 at 19:56 +1100, Paul Mackerras wrote:
> Pavel Roskin writes:
> > Hello!
>
> > I didn't realize that the colors correspond to nodes, not branches.
> > Every node has one color that is used for lines to all of its children.
> > It would be much better to assign colors to "branches" consisting of
> > individual lines connecting nodes, but changing that would require many
>
> Why would that be better?
Because you would get consistent colors between line forks. The color
would help to tack the line. Anyway, I don't think I'll ever implement
it myself.
> > > - if {$nparents($id) <= 1 && $nchildren($id) == 1} {
> > > + if {$nchildren($id) == 1} {
> > > set child [lindex $children($id) 0]
> > > if {[info exists colormap($child)]
> > > && $nparents($child) == 1} {
> > >
> > >
> >
> > I still stand behind this patch because it eliminates color changes on
> > the nodes that have exactly one child and parent. $nparents($id) is
>
> Ummm... I don't see that you have changed anything for nodes that have
> exactly one parent?
Nodes with one parent are fine. It's nodes with multiple parents that
are the problem - they fail to inherit the color assigned to their
child.
Let's see what assigncolor does:
| ----------- color assigned to the child, possibly to be inherited
|
child
|
| ----------- we are assigning color to this line
|
id ----------- we are processing this node
|\
| \--------\
| |
parent1 parent2
Why should color at the child change because its single parent has
several parents?
> > However, further changes to reduce color changes didn't produce nice
> > results for me. If I try to keep one color running as long as possible,
> > I get branches of the same color because, as I said, gitk uses the same
> > color for connections to all children. So, every node on the branch
> > spurs branching lines of the same color, which can intersect or run
> > side-by-side.
>
> The colors are really just to make the lines visually distinct. They
> (the colors) have no semantic meaning. (I did try coloring the lines
> according to the committer, but I just ended up with an awful lot of
> lines being the same color - corresponding to one Linus Torvalds. :)
I guess I wasn't clear about my intentions. My only intention is
exactly that - "to make the lines visually distinct". There is one
corner case where the color changes for no reason. There are cases that
are harder to fix, but this one is easy, and I have found a working
solution.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] .gitignore git-rerere and config.mak
From: Junio C Hamano @ 2006-02-08 1:01 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: git
In-Reply-To: <43E92BFD.7060909@gorzow.mm.pl>
Radoslaw Szkodzinski <astralstorm@gorzow.mm.pl> writes:
> Somehow git-rerere didn't end up getting included in .gitignore...
Sorry for a bit confusing style of quoting. I edited that part out,
which I did not disagree with, when I commented on the patch.
^ permalink raw reply
* Re: gitk changing line color for no reason after merge
From: Pavel Roskin @ 2006-02-08 0:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7vlkwnxz5t.fsf@assigned-by-dhcp.cox.net>
On Tue, 2006-02-07 at 02:04 -0800, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> > I still stand behind this patch because it eliminates color changes on
> > the nodes that have exactly one child and parent. $nparents($id) is
> > irrelevant here, because it characterizes the current node, but the code
> > decides whether the line should change color at the child node.
>
> It all depends on what you are trying to achieve with colours.
I'm trying to make it easier to follow a line. It's easier if its color
is not changing, especially on trivial nodes (one parent, one child).
> Being a bit colour-challenged, I am not in a good position to
> comment on how much gitk's use of different colours is helping
> the readability, but I suspect not very much. Use of too many
> colours just makes things distracting. Especially weaker
> colours like light yellow are very hard to see on a white
> background, at least to me.
My point is not to use to many colors. There is one case when gitk
changes line color for no reason, and that case should be fixed. Since
the colors rotate as gitk picks them, extra color switch means that the
colors repeat more often.
By the way, there are some nice colors to add (lightblue darkcyan pink),
but let's use effectively what we've got.
> Trying to differenciate "trunk" with "side branches" may be
> sometimes useful in a small one-man project, but it quickly
> breaks down once you start merging from all over the place,
> since merges in distributed development do not have inherent
> distinction between "trunk" and "side branches".
It's not my point. My point is to make it easier to follow the lines,
without making any assumptions about "real" branches.
> One thing it _could_ do is to assign different colours to edges
> coming into a merge node, and match the colour of the edge that
> leads to a parent to the colour in which the diff text from
> that parent is shown. Then the colouring becomes somewhat
> meaningful.
Yes, that would be great.
> Maybe gitk is already doing it, but it makes me suspect it
> doesn't, to read the way the code initialises "$ctext tag conf
> m$N" and uses the m$N tag for each diff output line, which is
> done pretty much independently from the procedure that paint
> edges (the one you touch in your patch).
Correct.
To illustrate my point, I put some examples online:
http://red-bean.com/proski/gitk/gitk-before.png - what gitk is showing
now. There are color changes on trivial nodes both below and above
merges.
http://red-bean.com/proski/gitk/gitk-after.png - with my patch. Color
changes on trivial nodes only happen below merges.
http://red-bean.com/proski/gitk/gitk-ideal.png - made in GIMP. Trivial
nodes never change line color, because it changes as soon as the line
forks.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] .gitignore git-rerere and config.mak
From: Radoslaw Szkodzinski @ 2006-02-07 23:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.63.0602071951370.26070@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 815 bytes --]
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 7 Feb 2006, Junio C Hamano wrote:
>
>> Andreas Ericsson <ae@op5.se> writes:
>>
>>> --- a/.gitignore
>>> +++ b/.gitignore
>>> @@ -123,3 +124,4 @@ git-core.spec
>>> libgit.a
>>> *.o
>>> *.py[co]
>>> +config.mak
>> I am not sure about this part. It is plausible that somebody
>> who privately uses config.mak has it in _his_ repository under
>> version control. Should we list it in .gitignore?
>
> I have it in .gitignore. If there were changes to config.mak which I had
> in all my copies of git, I'd have them directly in the Makefile.
>
> Hth,
> Dscho
Somehow git-rerere didn't end up getting included in .gitignore...
--
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: 252 bytes --]
^ permalink raw reply
* Re: git-http-push and hooks
From: Nick Hengeveld @ 2006-02-07 23:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpslysqcb.fsf@assigned-by-dhcp.cox.net>
On Tue, Feb 07, 2006 at 03:26:28PM -0800, Junio C Hamano wrote:
> If I and you clone from a shared repository at the same time, I
> did my development while you did your own on top of that same
> commit without pulling from the repository further, and I
> uploaded my changes to update the ref, what should happen to you
> once you are ready to push?
>
> Is that what being asked?
>
> If so, I think the sensible thing to do is to reject your push
> and suggest you to pull first, just like the git native protocol
> push does. That pull would end up first merging my changes to
> your work in your repository, and then you can push the result
> back to the shared repository. Otherwise you would lose my
> changes.
Makes sense, and it's the way http-push already works for heads. I
guess where I'm not clear is tags - since info/refs is generated by
recursing through everything in the refs/ subdirectory. I think I just
answered my own question though; http-push needs to recurse through
everything under refs/ on the remote end to generate the new info/refs
file. That just leaves the problem that http-push doesn't push tags
yet.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: git-http-push and hooks
From: Junio C Hamano @ 2006-02-07 23:41 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: git
In-Reply-To: <4fb292fa0602071302p551aca02j53d40e3f8e25ff8a@mail.gmail.com>
Bertrand Jacquin <beber.mailing@gmail.com> writes:
> On 2/7/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
>> You can't push to a git daemon, can you?
>>
>> Furthermore, if the user has a working http/DAV server installed it
>> might be the case that she prefers to use that one instead of
>> installing a new daemon.
>
> Personaly is use http because at work i've a $$@#! proxy and allow dav
> and nothing else.
> Could you push over http/proxy with gitdaemon ? Isn't it just a read
> only method ?
I think you are agreeing with what Fredrik said. git-daemon is
a read-only thing. You would want to SSH into the repository
machine.
If you are using git at work for work, and the benefit git gives
you outweigh the cost and trouble to modify the proxy and/or
firewalling settings, maybe you can convince your management to
allow you to SSH out to make you more productive? That way you
can use git-push over native git protocol.
If you are using git while at work but not for work, then maybe
I should not be giving an advice ;-).
^ permalink raw reply
* Re: git-http-push and hooks
From: Junio C Hamano @ 2006-02-07 23:26 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20060207224551.GB3833@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> What happens if someone else updates a ref and it no longer
> matches your local ref? Should the push scan the remote
> versions of all local refs and update whatever doesn't match?
If I and you clone from a shared repository at the same time, I
did my development while you did your own on top of that same
commit without pulling from the repository further, and I
uploaded my changes to update the ref, what should happen to you
once you are ready to push?
Is that what being asked?
If so, I think the sensible thing to do is to reject your push
and suggest you to pull first, just like the git native protocol
push does. That pull would end up first merging my changes to
your work in your repository, and then you can push the result
back to the shared repository. Otherwise you would lose my
changes.
The criteria to allow a push is obviously not "no longer
matches" because in the above scenario what both you and I
fetched from the shared repository is something that is an
ancestor of what each of us is trying to push. The first one
should succeed -- it is pushing a new commit that is a
descendant of what is currently the head of the shared
repository. The latter one fails because at that time the head
of the shared repository is not an ancestor of what you are
trying to push.
If you are asking about a race, yes there is a race condition
and you have to be careful. The native protocol does it like
so (receive-pack.c):
1. At the shared repository grab the current head;
2. Examine what is being pushed. Is it a descendant of the one
we grabbed in the previous step? If not, reject.
3. Lock the ref, grab the current head again, make sure it is
still the same as what we got in the first step, update it
with what was pushed, and then unlock.
I think you may be able to do a similar check on the client
side, if DAV allows locking resources at least for a brief
period.
If you are asking about updating local tracking branch for the
remote ref after a successful push, I think that is an optional
feature and is entirely up to you. For example, if your
workflow is to fetch from the shared repository into origin,
merge that into master, work on master, and then push the result
to the master branch of the shared repository, you could update
your origin with the commit you just pushed. This lets you
pretend as if you fetched from there immediately after your
successful push.
I think Cogito does it that way, but I personally found leaving
the tracing ref as-is after a push more useful, so I left
git-push not to do so. For example, leaving when to update
"origin" up to me allows me do run "git log origin..master" to
write the "what's new in git.git" message after I push. Of
course the same thing can be done by running the git log before
I push, so there is not much practical difference either way.
^ permalink raw reply
* Re: git-http-push and hooks
From: Nick Hengeveld @ 2006-02-07 22:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtg6uaw6.fsf@assigned-by-dhcp.cox.net>
On Tue, Feb 07, 2006 at 01:17:13PM -0800, Junio C Hamano wrote:
> If the server info updates is the _only_ problem, then perhaps
> that would be the easiest and cleanest. Whenever you update or
> add a ref you would need to update info/refs (otherwise
> ls-remote would not give you the latest info), and whenever you
> repack you would need to update objects/info/packs.
What happens if someone else updates a ref and it no longer matches your
local ref? Should the push scan the remote versions of all local refs
and update whatever doesn't match?
> You may probably want to have a CGI to allow you manage the
> repository remotely anyway, to trigger a repack or remove a
> stale branch head, for example. Once you go that route maybe
> having the CGI to do something like the pack protocol for more
> efficient transfer might become more attractive.
That's an option if the user has the ability to install CGI scripts on the
DAV server, which doesn't seem like it will always be true. Perhaps it
would make sense to do both:
- add a git-http-repack command that works in a DAV-only environment
- add a CGI script to provide remote management, and a config
setting to git-http-push for the remote management URL
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* [PATCH 3/3] cg-patch: Add -d option to apply patch directory
From: Jonas Fonseca @ 2006-02-07 22:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
It tries to do some minimal sanity checking on the individual patch
files, to ensure that they are created with cg-mkpatch. This includes
checking that the filename starts with [0-9]*-, the patch is non-empty,
and it contains author information from git-cat-file output.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 35f920438f1c9f7413d708eeb57da7ea3dd8909a
tree 602514ba6eed872f936fdd133f17a12933fce38b
parent 77defc166986330f4285db8faf206c1176a6c4ae
author Jonas Fonseca <fonseca@diku.dk> Tue, 07 Feb 2006 23:30:42 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Tue, 07 Feb 2006 23:30:42 +0100
cg-patch | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/cg-patch b/cg-patch
index 90dfd30..e783985 100755
--- a/cg-patch
+++ b/cg-patch
@@ -12,6 +12,11 @@
#
# OPTIONS
# -------
+# -d DIRNAME:: Apply all patches in directory
+# Instead of applying the patch from stdin, apply all patches in the
+# specified directory. This can be used to import a range of patches
+# made with cg-mkpatch -d.
+#
# -R:: Apply in reverse
# Applies the patch in reverse (therefore effectively unapplies it)
#
@@ -68,11 +73,32 @@ redzone_border()
redzone_reset
}
+apply_directory() {
+ directory="$1"
+ patch="$(mktemp -t gitpatch.XXXXXX)"
+
+ find "$directory" -name '[0-9]*-*' | while read file; do
+ sed -n '/^---$/,$p' < "$file" > "$patch"
+ [ -s "$patch" ] || die "No patch found in '$file'"
+
+ author="$(sed -n '/^author /p' < "$patch")"
+ [ "$author" ] || die "No author info found in '$file'"
+
+ eval "$(echo "$author" | pick_author)"
+ echo "Applying ${file#$directory/}"
+ cg-patch < "$patch"
+ sed '/^---$/,$d' < "$file" | cg-commit
+ done
+}
reverse=
while optparse; do
if optparse -R; then
reverse=1
+ elif optparse -d=; then
+ [ -d "$OPTARG" ] || die "Not a directory '$OPTARG'."
+ apply_directory "$(echo "$OPTARG" | sed 's,/*$,,')"
+ exit
else
optfail
fi
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH 2/3] cg-patch: Use optparse
From: Jonas Fonseca @ 2006-02-07 22:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 77defc166986330f4285db8faf206c1176a6c4ae
tree 293120fe428f40eab2422ed59d84e77aa1fa53a1
parent 5095aca7013d87ccdb08dad20a9fb93d7465d33d
author Jonas Fonseca <fonseca@diku.dk> Tue, 07 Feb 2006 23:07:32 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Tue, 07 Feb 2006 23:07:32 +0100
cg-patch | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/cg-patch b/cg-patch
index 8be13be..90dfd30 100755
--- a/cg-patch
+++ b/cg-patch
@@ -70,10 +70,13 @@ redzone_border()
reverse=
-if [ "${ARGS[0]}" = "-R" ]; then
- reverse=1
- shift
-fi
+while optparse; do
+ if optparse -R; then
+ reverse=1
+ else
+ optfail
+ fi
+done
gonefile="$(mktemp -t gitapply.XXXXXX)"
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH 1/3] cg-commit: Move author picking to cg-Xlib
From: Jonas Fonseca @ 2006-02-07 22:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Adds pick_author utility function to cg-Xlib that uses the author line from
git-cat-file output to print a string that sets the GIT_AUTHOR_* env
variables. This string should then be eval'd by the caller.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 5095aca7013d87ccdb08dad20a9fb93d7465d33d
tree 9ec064a96718b937d373769c52d830b8c3a6daca
parent d3cabc9974357947eac035d613557d4318b85f9f
author Jonas Fonseca <fonseca@diku.dk> Tue, 07 Feb 2006 23:05:19 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Tue, 07 Feb 2006 23:05:19 +0100
cg-Xlib | 26 ++++++++++++++++++++++++++
cg-commit | 28 +---------------------------
2 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
index 308d798..e17c82f 100644
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -236,6 +236,32 @@ list_untracked_files()
git-ls-files -z --others $listdirs "${EXCLUDE[@]}"
}
+pick_author()
+{
+ local pick_author_script='
+ /^author /{
+ s/'\''/'\''\\'\'\''/g
+ h
+ s/^author \([^<]*\) <[^>]*> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/export GIT_AUTHOR_NAME='\''&'\''/p
+
+ g
+ s/^author [^<]* <\([^>]*\)> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/export GIT_AUTHOR_EMAIL='\''&'\''/p
+
+ g
+ s/^author [^<]* <[^>]*> \(.*\)$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/export GIT_AUTHOR_DATE='\''&'\''/p
+
+ q
+ }
+ '
+ LANG=C LC_ALL=C sed -ne "$pick_author_script"
+}
+
# Usage: showdate SECONDS TIMEZONE [FORMAT]
# Display date nicely based on how GIT stores it.
# Save the date to $_showdate
diff --git a/cg-commit b/cg-commit
index e5e98b4..06ab0c0 100755
--- a/cg-commit
+++ b/cg-commit
@@ -276,33 +276,7 @@ for msg in "${msgs[@]}"; do
done
if [ "$copy_commit" ]; then
- pick_author_script='
- /^author /{
- s/'\''/'\''\\'\'\''/g
- h
- s/^author \([^<]*\) <[^>]*> .*$/\1/
- s/'\''/'\''\'\'\''/g
- s/.*/GIT_AUTHOR_NAME='\''&'\''/p
-
- g
- s/^author [^<]* <\([^>]*\)> .*$/\1/
- s/'\''/'\''\'\'\''/g
- s/.*/GIT_AUTHOR_EMAIL='\''&'\''/p
-
- g
- s/^author [^<]* <[^>]*> \(.*\)$/\1/
- s/'\''/'\''\'\'\''/g
- s/.*/GIT_AUTHOR_DATE='\''&'\''/p
-
- q
- }
- '
- set_author_env="$(git-cat-file commit "$copy_commit" |
- LANG=C LC_ALL=C sed -ne "$pick_author_script")"
- eval "$set_author_env"
- export GIT_AUTHOR_NAME
- export GIT_AUTHOR_EMAIL
- export GIT_AUTHOR_DATE
+ eval "$(git-cat-file commit "$copy_commit" | pick_author)"
git-cat-file commit "$copy_commit" | sed -e '1,/^$/d'
written=1
fi >>"$LOGMSG"
--
Jonas Fonseca
^ permalink raw reply related
* Re: git-http-push and hooks
From: Bertrand Jacquin @ 2006-02-07 21:02 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Nick Hengeveld, Bertrand Jacquin (Beber), git
In-Reply-To: <20060207205709.GB7217@c165.ib.student.liu.se>
On 2/7/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> On Tue, Feb 07, 2006 at 12:23:51PM -0800, Nick Hengeveld wrote:
> > On Tue, Feb 07, 2006 at 08:54:58PM +0100, Fredrik Kuivinen wrote:
> >
> > > I know basically nothing about DAV, but wouldn't it be possible to
> > > have a CGI-script which executes the hooks upon the client's request?
> >
> > It would, although if custom software can be run on the server you might
> > as well run the git daemon.
>
> You can't push to a git daemon, can you?
>
> Furthermore, if the user has a working http/DAV server installed it
> might be the case that she prefers to use that one instead of
> installing a new daemon.
Personaly is use http because at work i've a $$@#! proxy and allow dav
and nothing else.
Could you push over http/proxy with gitdaemon ? Isn't it just a read
only method ?
>
> - Fredrik
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: git-http-push and hooks
From: Junio C Hamano @ 2006-02-07 21:17 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20060207202351.GA3833@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> There are options for a DAV-only environment though. While the hooks
> themselves can't be run, git-http-push can be modified to update the
> remote pack and ref info (although it's not clear to me under what
> conditions it should do so...) DAV-specific versions of pack
> management utilities are feasible as well.
If the server info updates is the _only_ problem, then perhaps
that would be the easiest and cleanest. Whenever you update or
add a ref you would need to update info/refs (otherwise
ls-remote would not give you the latest info), and whenever you
repack you would need to update objects/info/packs.
You may probably want to have a CGI to allow you manage the
repository remotely anyway, to trigger a repack or remove a
stale branch head, for example. Once you go that route maybe
having the CGI to do something like the pack protocol for more
efficient transfer might become more attractive.
^ permalink raw reply
* Re: git-http-push and hooks
From: Fredrik Kuivinen @ 2006-02-07 20:57 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Fredrik Kuivinen, Bertrand Jacquin (Beber), git
In-Reply-To: <20060207202351.GA3833@reactrix.com>
On Tue, Feb 07, 2006 at 12:23:51PM -0800, Nick Hengeveld wrote:
> On Tue, Feb 07, 2006 at 08:54:58PM +0100, Fredrik Kuivinen wrote:
>
> > I know basically nothing about DAV, but wouldn't it be possible to
> > have a CGI-script which executes the hooks upon the client's request?
>
> It would, although if custom software can be run on the server you might
> as well run the git daemon.
You can't push to a git daemon, can you?
Furthermore, if the user has a working http/DAV server installed it
might be the case that she prefers to use that one instead of
installing a new daemon.
- Fredrik
^ permalink raw reply
* Re: git-http-push and hooks
From: Bertrand Jacquin @ 2006-02-07 20:51 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Nick Hengeveld, git
In-Reply-To: <20060207195458.GA7217@c165.ib.student.liu.se>
On 2/7/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> On Mon, Feb 06, 2006 at 03:22:31PM -0800, Nick Hengeveld wrote:
> > On Mon, Feb 06, 2006 at 09:52:03PM +0100, Bertrand Jacquin (Beber) wrote:
> >
> > > Why aren't excute hooks/* (with +x perms) when I do a git-http-push ?
> > > Also if i push with cg-push on the same repo but with git+ssh
> > > protocol, hooks are execute.
> >
> > Hooks must run on the destination server when you're doing a push. If
> > you use the git+ssh protocol, that server is running a git daemon that
> > knows how to execute hooks; if you use the http/DAV protocol, that
> > server does not.
> >
>
> I know basically nothing about DAV, but wouldn't it be possible to
> have a CGI-script which executes the hooks upon the client's request?
Svn can execute hooks :/ But maybe this is implemented in -D SVN
module for Apache. Donno
>
> - Fredrik
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: [Cogito] Various bugs
From: Junio C Hamano @ 2006-02-07 20:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.64.0602070751410.3854@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> An empty GIT_AUTHOR_NAME should _not_ mean that we use the default name
> (which is usually the committer), because rather than meaning "default",
> it most likely means "buggy import script".
>
> I'd rather have an email import of mine say that it cannot commit, than
> have it put "Linus Torvalds" in the author line (and some random email).
I am inclined to agree. Something like this?
This would also make 'git-var GIT_COMMITTER_IDENT' to barf,
which I think is a good thing.
---
diff --git a/ident.c b/ident.c
index 0461b8b..23b8cfc 100644
--- a/ident.c
+++ b/ident.c
@@ -167,6 +167,11 @@ static const char *get_ident(const char
name = git_default_name;
if (!email)
email = git_default_email;
+
+ if (!*name || !*email)
+ die("empty ident %s <%s> not allowed",
+ name, email);
+
strcpy(date, git_default_date);
if (date_str)
parse_date(date_str, date, sizeof(date));
^ permalink raw reply related
* Re: "git diff a..b" broken
From: Junio C Hamano @ 2006-02-07 20:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602071024270.3854@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Ahh. Very simple.
>
> The "--cc" implies "-p", but without the recursive part.
Thanks.
^ permalink raw reply
* Re: git-http-push and hooks
From: Nick Hengeveld @ 2006-02-07 20:23 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Bertrand Jacquin (Beber), git
In-Reply-To: <20060207195458.GA7217@c165.ib.student.liu.se>
On Tue, Feb 07, 2006 at 08:54:58PM +0100, Fredrik Kuivinen wrote:
> I know basically nothing about DAV, but wouldn't it be possible to
> have a CGI-script which executes the hooks upon the client's request?
It would, although if custom software can be run on the server you might
as well run the git daemon.
There are options for a DAV-only environment though. While the hooks
themselves can't be run, git-http-push can be modified to update the
remote pack and ref info (although it's not clear to me under what
conditions it should do so...) DAV-specific versions of pack
management utilities are feasible as well.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: git-http-push and hooks
From: Fredrik Kuivinen @ 2006-02-07 19:54 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Bertrand Jacquin (Beber), git
In-Reply-To: <20060206232231.GK3873@reactrix.com>
On Mon, Feb 06, 2006 at 03:22:31PM -0800, Nick Hengeveld wrote:
> On Mon, Feb 06, 2006 at 09:52:03PM +0100, Bertrand Jacquin (Beber) wrote:
>
> > Why aren't excute hooks/* (with +x perms) when I do a git-http-push ?
> > Also if i push with cg-push on the same repo but with git+ssh
> > protocol, hooks are execute.
>
> Hooks must run on the destination server when you're doing a push. If
> you use the git+ssh protocol, that server is running a git daemon that
> knows how to execute hooks; if you use the http/DAV protocol, that
> server does not.
>
I know basically nothing about DAV, but wouldn't it be possible to
have a CGI-script which executes the hooks upon the client's request?
- Fredrik
^ permalink raw reply
* Re: [PATCH] git-commit: revamp the git-commit semantics.
From: Jon Loeliger @ 2006-02-07 19:25 UTC (permalink / raw)
To: Git List
In-Reply-To: <7vpslzuj6e.fsf@assigned-by-dhcp.cox.net>
On Tue, 2006-02-07 at 12:18, Junio C Hamano wrote:
> That means 1.2.0 (and its maintenance series 1.2.X) will ship
> with --include semantics for "git commit paths...", and will
> allow explicit --only/--include. After 1.2.0, at some point,
> the "master" branch will start shipping with --only semantics as
> default. No script should break when 1.3.0 happens.
>
> People who want to use --include semantics will acquire a habit
> of explicitly askign for --include during 1.3.0 development
> period. They do not need to unlearn anything when 1.3.0 happens.
>
> People who learned to type --only can unlearn it to reduce
> typing when 1.3.0 happens, but unlearning is not a requirement.
> Being explicit should always work.
>
> New people that come after 1.3.0 will get the --only semantics
> by default, the intuitiveness of which has been argued to death,
> without using any flags.
Hmmm... So maybe just to add fire to the discussion,
maybe the problem lies in the "tool name". What if there
were two tools named "git-commit-index" and "git-commit-path"?
I understand that this is, in some way, identical to the
"--include" and "--only" sorts of notions. But I think it
might make the intent clearer, and easier to describe/document.
I think part of my concern with the options is trying to
recall/describe just exactly _what_ is "included" with
the "--include", or what is excluded with the "--only".
It is the index's data/state, of course. So perhaps
a "git commit-index" might be consistent tool naming?
And for contrast "git commit-file" or "git commit-path"?
Just a thought.
jdl
^ permalink raw reply
* Re: [PATCH] git-commit: revamp the git-commit semantics.
From: Nicolas Pitre @ 2006-02-07 19:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602071304160.5397@localhost.localdomain>
On Tue, 7 Feb 2006, Nicolas Pitre wrote:
> The 1.3.x branch being the so called "unstable" branch makes it the
> appropriate place to do it at the earliest...
As someone refreshed my memory in private, there is no "unstable" branch
like Linux used to have. But hopefully you all understood what I meant
i.e. in the main branch after the stable 1.2.0 branch is forked.
Nicolas
^ permalink raw reply
* Re: [PATCH] .gitignore git-rerere and config.mak
From: Johannes Schindelin @ 2006-02-07 18:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vk6c7uj21.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 7 Feb 2006, Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -123,3 +124,4 @@ git-core.spec
> > libgit.a
> > *.o
> > *.py[co]
> > +config.mak
>
> I am not sure about this part. It is plausible that somebody
> who privately uses config.mak has it in _his_ repository under
> version control. Should we list it in .gitignore?
I have it in .gitignore. If there were changes to config.mak which I had
in all my copies of git, I'd have them directly in the Makefile.
Hth,
Dscho
^ 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