* Re: [PATCH] Clean up compatibility definitions.
From: Junio C Hamano @ 2005-12-06 3:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Alex Riesen
In-Reply-To: <20051205231203.GG22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Mon, Dec 05, 2005 at 09:22:42PM CET, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> diff --git a/git-compat-util.h b/git-compat-util.h
>> new file mode 100644
>
> What about compat/util.h or something? Nicer, shorter, and takes
> advantage of this fancy hierarchical namespace "directories" invention.
> ;-)
While I would appreciate a better name, I am afraid that is not a
particularly good one. It is not "compatibility utilities", but
compat things and util things mixed together, so it does not
belong to compat/ directory to begin with. die() and friends
are not about compatibility at all.
^ permalink raw reply
* Re: Wine + GIT
From: Junio C Hamano @ 2005-12-06 2:26 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git, Mike McCormack
In-Reply-To: <4394F173.6000505@pobox.com>
Jeff Garzik <jgarzik@pobox.com> writes:
> 5) never ever do
> git-checkout -f HEAD
>
> HEAD should always be a symlink. 'git checkout -f master' is probably
> what you want.
Correct. "git checkout -f HEAD" is a redundant way to say
"I screwed up and would want to revert the mess in my working
tree to my branch head". You do not need to say HEAD; "git
checkout -f" (or "git reset --hard" if you really want to clean
things up) would do.
> 6) For merges with hand-merged conflicts, I could have sworn that either
> a "git commit -a" or 'git-update-index' + 'git commit' was required.
> Maybe I'm wrong, or that has changed?
That has not changed. With the recent 0.99.9l change, I suspect
that the example on the wiki page (without update-index) would
fail to commit -- the index is now left unmerged after a failed
automerge.
The paragraph "Once you have finished editting [sic]..." needs
to be followed by:
git-update-index those paths you hand corrected
git-commit
^ permalink raw reply
* Re: Wine + GIT
From: Jeff Garzik @ 2005-12-06 2:18 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
In-Reply-To: <4394CD68.8020500@codeweavers.com>
Mike McCormack wrote:
> Hi All,
>
> The Wine project has started maintaining a wine.git in parallel to the
> Wine CVS. To introduce Wine developers to GIT, we've put together a
> short introduction on the Wine Wiki on using GIT to maintain patches.
> You can find it at:
>
> http://wiki.winehq.org/GitWine
One other comment: http:// is the slowest of all three transports.
git:// (git daemon) is preferred, followed by rsync.
http:// takes forever, comparatively.
Jeff
^ permalink raw reply
* Re: Wine + GIT
From: Jeff Garzik @ 2005-12-06 2:03 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
In-Reply-To: <4394CD68.8020500@codeweavers.com>
Mike McCormack wrote:
> Hi All,
>
> The Wine project has started maintaining a wine.git in parallel to the
> Wine CVS. To introduce Wine developers to GIT, we've put together a
> short introduction on the Wine Wiki on using GIT to maintain patches.
> You can find it at:
> http://wiki.winehq.org/GitWine
Very cool! :)
Comments:
1) I wrote a git howto for kernel hackers, 95% of which applies to other
projects as well: http://linux.yyz.us/git-howto.html
2) The "git-foo" commands are apparently uncool. "git foo ..." is
preferred.
3) replace
git-diff-index -p HEAD
with
git diff HEAD
4) "git commit -a" can often replace git-update-index+git-commit
5) never ever do
git-checkout -f HEAD
HEAD should always be a symlink. 'git checkout -f master' is probably
what you want.
6) For merges with hand-merged conflicts, I could have sworn that either
a "git commit -a" or 'git-update-index' + 'git commit' was required.
Maybe I'm wrong, or that has changed?
^ permalink raw reply
* Re: Weirdness with port-update hook and local push
From: Daniel Barkalow @ 2005-12-06 1:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0512052318290.3406@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 5 Dec 2005, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 5 Dec 2005, Daniel Barkalow wrote:
>
> > I think it's an environment thing of some sort, most likely, but it can't
> > be the user; nothing's setuid and I'm only one user.
>
> Can you insert "env > /tmp/env.$$.out", execute both without and with ssh,
> and compare?
Actually, "ls -l /proc/$$/fd" shows that stdin and stdout are sockets with
ssh, pipes with local, and ttys when just running the script.
The hooks probably ought to be run with something different for
stdin/stdout than the connection to the source of the data. /dev/null,
maybe? Or a log file? Maybe dup stderr, which still seems to be going to
the pusher's terminal?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Wine + GIT
From: Mike McCormack @ 2005-12-05 23:29 UTC (permalink / raw)
To: git
Hi All,
The Wine project has started maintaining a wine.git in parallel to the
Wine CVS. To introduce Wine developers to GIT, we've put together a
short introduction on the Wine Wiki on using GIT to maintain patches.
You can find it at:
http://wiki.winehq.org/GitWine
Comments, flames, corrections and additions welcome :)
Mike
^ permalink raw reply
* Re: announce: git browser
From: Petr Baudis @ 2005-12-05 23:26 UTC (permalink / raw)
To: Artem Khodush; +Cc: Git Mailing List
In-Reply-To: <40b2b7d90512041720i65f63ee1pcfe32d2c0c3c357b@mail.gmail.com>
Dear diary, on Mon, Dec 05, 2005 at 02:20:39AM CET, I got a letter
where Artem Khodush <greenkaa@gmail.com> said that...
> On 12/5/05, Petr Baudis <pasky@suse.cz> wrote:
> > * I would find it much nicer if you wouldn't "squeeze" all the day's
> > (except merge) commits together, but left them separate. Possibly a
> > switch to squeeze them, but I'm really not sure if it's even useful to
> > have.
>
> Well it's easy to do, but then, in Linus tree, a single day would not fit
> on my screen :-) So 'squeezed' mode is helpful for me, at least,
> to get big picture at a glance - in git tree, for example, I can see
> the 0.99.5 release branch to begin and end on a single screen.
I see. Well, how useful the big picture is? (Or rather the part of it
you don't get by just looking at the current state.)
> > * The line graphics etc. might be more colourful and prettier. ;-)
>
> And the question is: the colours are assigned to what:
> branches ? authors ? committers ? repositories ?
Branches for easy visual distinguishing of what line is what, I guess.
Coloring based on repositories in particular would be very hard.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Clean up compatibility definitions.
From: Petr Baudis @ 2005-12-05 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alex Riesen
In-Reply-To: <7voe3vb8fh.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Dec 05, 2005 at 09:22:42PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> diff --git a/git-compat-util.h b/git-compat-util.h
> new file mode 100644
What about compat/util.h or something? Nicer, shorter, and takes
advantage of this fancy hierarchical namespace "directories" invention.
;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] config.c: remove unnecessary header in minimum configuration file.
From: Johannes Schindelin @ 2005-12-05 22:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmnf9px8.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 5 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > However, reading the code I am not satisfied. If there is no template for
> > the config file, it does not test the filemode at all.
>
> I have a feeling that you have not tried the code you are
> arguing against.
Got me right there.
Sorry.
Ciao,
Dscho
^ permalink raw reply
* Re: Weirdness with port-update hook and local push
From: Junio C Hamano @ 2005-12-05 22:11 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0512051651050.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> The thing that confuses me is that it works when run from ssh or directly,
> but not when run from a local push. I'd expect the two that work to be
> most different.
One suspicion and one suggestion (without knowing exactly where
that suggestion might lead us to).
- your stdout/stderr might be connected to somewhere that your
output gets stuck ("broken pipe"), when your script is run
from the hook.
- your environment might be different from what you are
assuming.
How about doing something like this?
#!/bin/sh
+ exec >/var/tmp/hook-out.$$ 2>/var/tmp/hook-err.$$
+ echo "** env **"
+ env
+ echo "** vars **"
+ i=0
+ for v
+ do
+ echo "$i: $v"
+ i=$(($i+1))
+ done
+ echo "** pwd etc **"
+ pwd
+ id -a
unset GIT_DIR
cd /home/barkalow/auto-working/web
if ! git pull /home/barkalow/git/web.git/
and then next replace the whole thing with:
exec >/dev/null 2>&1
^ permalink raw reply
* Re: Weirdness with port-update hook and local push
From: Daniel Barkalow @ 2005-12-05 22:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0512052138560.6554@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 5 Dec 2005, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 5 Dec 2005, Daniel Barkalow wrote:
>
> > I have the following post-update hook:
> >
> > -----
> > #!/bin/sh
> >
> > unset GIT_DIR
> > cd /home/barkalow/auto-working/web
> > if ! git pull /home/barkalow/git/web.git/
> > then
> > exit 1
> > fi
> > make
> > -----
> >
> > >From that "git pull", I'm getting:
> >
> > /home/barkalow/bin/git-pull: line 108: 30608 Broken pipe git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
> >
> > It works fine when pushing over ssh,
>
> Maybe it runs as a different user? (Sorry if this sounds dumb, but that's
> exactly the kind of solution I usually find after *days*.)
I think it's an environment thing of some sort, most likely, but it can't
be the user; nothing's setuid and I'm only one user.
The thing that confuses me is that it works when run from ssh or directly,
but not when run from a local push. I'd expect the two that work to be
most different.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Clean up compatibility definitions.
From: Junio C Hamano @ 2005-12-05 21:58 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051205215059.GC4443@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Mon, Dec 05, 2005 21:22:42 +0100:
>> This attempts to clean up the way various compatibility
>> functions are defined and used.
> ...
>> --- a/compat/mmap.c
>> +++ b/compat/mmap.c
>> @@ -2,7 +2,7 @@
>> #include <stdlib.h>
>> #include <unistd.h>
>> #include <errno.h>
>> -#include "../cache.h"
>> +#include "../git-compat-util.h"
>
> I still think that compat functions should stand alone.
> Especially if it does not costs us much (or even less than that).
Sorry, you lost me. What do you mean by "standing alone"?
^ permalink raw reply
* Re: [PATCH] Clean up compatibility definitions.
From: Alex Riesen @ 2005-12-05 21:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe3vb8fh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Mon, Dec 05, 2005 21:22:42 +0100:
> This attempts to clean up the way various compatibility
> functions are defined and used.
...
> --- a/compat/mmap.c
> +++ b/compat/mmap.c
> @@ -2,7 +2,7 @@
> #include <stdlib.h>
> #include <unistd.h>
> #include <errno.h>
> -#include "../cache.h"
> +#include "../git-compat-util.h"
I still think that compat functions should stand alone.
Especially if it does not costs us much (or even less than that).
^ permalink raw reply
* Re: make gitfakemmap standalone to fix linking error in git.c
From: Junio C Hamano @ 2005-12-05 21:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051205213612.GA4443@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Mon, Dec 05, 2005 18:40:21 +0100:
>> > Why does it always happen...
>> Because you touched you did not absolutely have to ;-).
>
> well, git$(X) didn't link...
I meant your change to the "if ()" expression in gitfakemmap().
Does the change have anything to do with git$X linkage? I think
not.
^ permalink raw reply
* Re: [PATCH] config.c: remove unnecessary header in minimum configuration file.
From: Junio C Hamano @ 2005-12-05 21:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512052202300.12016@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> However, reading the code I am not satisfied. If there is no template for
> the config file, it does not test the filemode at all.
I have a feeling that you have not tried the code you are
arguing against.
It always creates the config file because it needs to record the
repository format version (among other things), so the config
file exists even if you do not have templates. Even if you do
not have a valid template directory that is supposed to work,
but obviously you have not tried it ;-).
Now, it is arguable that the current format version being 0, and
not having the format version is equivalent to having 0 as the
format version, it is not necessary to create an empty
configuration file at this moment, but by making sure we record
the format version the tool that created the repository supports
now in the version 0, we do not have to risk forgetting to add
that logic later when we _do_ need to write something non-zero.
^ permalink raw reply
* Re: [PATCH] Clean up compatibility definitions.
From: Alex Riesen @ 2005-12-05 21:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vk6ejb72r.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Mon, Dec 05, 2005 21:51:56 +0100:
> >> This attempts to clean up the way various compatibility
> >> functions are defined and used.
> >
> > You sure you want that before 1.0?
>
> I think this is mostly an obvious clean-up, but I do not have
> enough test environments, so ...
I will do cygwin. Tomorrow, that is.
^ permalink raw reply
* Re: make gitfakemmap standalone to fix linking error in git.c
From: Alex Riesen @ 2005-12-05 21:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyp7cuii.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Mon, Dec 05, 2005 18:40:21 +0100:
> > Why does it always happen...
> Because you touched you did not absolutely have to ;-).
well, git$(X) didn't link...
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9l aka 1.0rc4
From: Jon Loeliger @ 2005-12-05 21:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, Git List
In-Reply-To: <7vu0dnb8pm.fsf@assigned-by-dhcp.cox.net>
On Mon, 2005-12-05 at 14:16, Junio C Hamano wrote:
> This question is probably relevant only to you and people who
> want to build deb themselves until you package the updated
> upstream, but what is your (and others') preference on debian/
> directory in what _I_ ship?
I would like to see it remain and be current, please.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] config.c: remove unnecessary header in minimum configuration file.
From: Johannes Schindelin @ 2005-12-05 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek4rb6vc.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 5 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > However, you should also remove the header which is generated in init-db.c
> > when it is determined that the file system does not respect the executable
> > flag.
>
> I suspect that code is not there anymore.
Oops. I missed that one (probably because it did not say anything about
the filemode test in the shortlog).
However, reading the code I am not satisfied. If there is no template for
the config file, it does not test the filemode at all.
In fact, it reverses my design: I did *not* touch an existing config file,
but only created one if none existed. And if the filemode was not set, I
threw the config file away.
Ciao,
Dscho
^ permalink raw reply
* Re: cvsexportcommit/cvsimport workflow
From: Martin Langhoff @ 2005-12-05 20:57 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Git Mailing List
In-Reply-To: <200511212043.57434.lan@ac-sw.com>
On 11/21/05, Alexander Litvinov <lan@ac-sw.com> wrote:
> Can ypu please explain how to use cvsimport with cvsexportcommit scripts ?
Your approach is good -- that's exactly how I use them too. I normally
use git-format-patch to review what patches I have 'pending' to be
pushed upstream. It's great because it knows your last common commit,
and it uses git-cherry to spot commits that are identical on both
sides.
We should perhaps create git-cvsexport, followning git-format-patch's
usage of git-cherry, and calling git-cvsexportcommit with them.
There's been talk about doing it -- I'll probably do it as soon as I
need it for a project. Feel free to have a go at it ;-)
> 7. Export git commits to cvs: What should be exported question become harder
> and harder. Possible I should use some tag and run:
> git-rev-list MY-TAG..master | xargs -n 1 git-cvsexportcommit -vX -cX (by the
> way, why just -v -c does not work ? I must add something to make options
> work)
Strange. The getopts line should look like:
getopts('hpvc');
(al least it does on my repo) which means that it doesn't expect
parameter _values_. Have you got the same line in the script? Perhaps
your getopts is broken or strange?
> This cycle is a bit of mess. I can write some scripts but I have no idea how
> this is supposed to work !
Well... you have the right idea... and yes it's a bit of a mess.
> The biggest problem - conflict. I should resove them twice, during merging
> origin branch to master and when exporting these changes to cvs. By the way,
> I still can't export merge commit :-)
That's exactly the issue. It's somewhat manual -- because you can't
really automate it 100%. CVS won't know what to do with a merge, so
every time you develop in paralell under git and then merge, you'll
have to fudge things somehow to trick cvs. There's an impedance
mismatch there.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] config.c: remove unnecessary header in minimum configuration file.
From: Junio C Hamano @ 2005-12-05 20:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512052124400.4026@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> However, you should also remove the header which is generated in init-db.c
> when it is determined that the file system does not respect the executable
> flag.
I suspect that code is not there anymore.
^ permalink raw reply
* Re: [PATCH] Clean up compatibility definitions.
From: Junio C Hamano @ 2005-12-05 20:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512052135260.5944@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> This attempts to clean up the way various compatibility
>> functions are defined and used.
>
> You sure you want that before 1.0?
I think this is mostly an obvious clean-up, but I do not have
enough test environments, so ...
^ permalink raw reply
* Re: Weirdness with port-update hook and local push
From: Johannes Schindelin @ 2005-12-05 20:40 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0512051530560.25300@iabervon.org>
Hi,
On Mon, 5 Dec 2005, Daniel Barkalow wrote:
> I have the following post-update hook:
>
> -----
> #!/bin/sh
>
> unset GIT_DIR
> cd /home/barkalow/auto-working/web
> if ! git pull /home/barkalow/git/web.git/
> then
> exit 1
> fi
> make
> -----
>
> >From that "git pull", I'm getting:
>
> /home/barkalow/bin/git-pull: line 108: 30608 Broken pipe git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
>
> It works fine when pushing over ssh,
Maybe it runs as a different user? (Sorry if this sounds dumb, but that's
exactly the kind of solution I usually find after *days*.)
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Clean up compatibility definitions.
From: Johannes Schindelin @ 2005-12-05 20:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alex Riesen
In-Reply-To: <7voe3vb8fh.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 5 Dec 2005, Junio C Hamano wrote:
> This attempts to clean up the way various compatibility
> functions are defined and used.
You sure you want that before 1.0?
Ciao,
Dscho
^ permalink raw reply
* Weirdness with port-update hook and local push
From: Daniel Barkalow @ 2005-12-05 20:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
I have the following post-update hook:
-----
#!/bin/sh
unset GIT_DIR
cd /home/barkalow/auto-working/web
if ! git pull /home/barkalow/git/web.git/
then
exit 1
fi
make
-----
>From that "git pull", I'm getting:
/home/barkalow/bin/git-pull: line 108: 30608 Broken pipe git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
It works fine when pushing over ssh, and when I just run the hook
directly. (It does a fast forward merge without any trouble.) Any ideas on
what's confusing it?
-Daniel
*This .sig left intentionally blank*
^ 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