* Re: irc usage..
From: Donnie Berkholz @ 2006-05-29 22:32 UTC (permalink / raw)
To: Martin Langhoff
Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <46a038f90605291521q37f34209wd923608bdebb9084@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]
Martin Langhoff wrote:
> On 5/30/06, Donnie Berkholz <spyderous@gentoo.org> wrote:
>> Finally hit an OOM sometime in the past day (yep, a week later) =\. Not
>> sure whether it was cvsimport or cvs. Anyone else had more luck?
>
> It seemed like it had finished on the machine I was running it, and I
> assumed it was alright in yours too. Looking closer it only made it
> till April 2004 -- but it may have been killed by a sysadmin, the
> captured log talks about 'signal 9', I have no idea what the OOM
> sends.
Looking closer, I see that the memory suckers do appear to be git, from
dmesg:
Out of Memory: Kill process 17230 (git-repack) score 97207 and children.
Out of memory: Killed process 17231 (git-rev-list).
Just ends like this:
Tree ID 2cc632e5e1d3a430a2cc891bf33c4a12f19a4d0e
Parent ID ad92d7073a52458e0581633bbd8ccbbec838d9e6
Committed patch 249100 (origin 2005-08-20 05:05:58)
Commit ID 28941f00d714f57ab49f1fd725d1c3ce8a5d0b93
Fetching sys-kernel/ck-sources/ChangeLog v 1.113
Update sys-kernel/ck-sources/ChangeLog: 25425 bytes
Fetching sys-kernel/ck-sources/Manifest v 1.164
Update sys-kernel/ck-sources/Manifest: 252 bytes
Delete sys-kernel/ck-sources/ck-sources-2.6.12_p5-r1.ebuild
Fetching sys-kernel/ck-sources/ck-sources-2.6.12_p6.ebuild v 1.1
New sys-kernel/ck-sources/ck-sources-2.6.12_p6.ebuild: 1438 bytes
Delete sys-kernel/ck-sources/files/digest-ck-sources-2.6.12_p5-r1
Fetching sys-kernel/ck-sources/files/digest-ck-sources-2.6.12_p6 v 1.1
New sys-kernel/ck-sources/files/digest-ck-sources-2.6.12_p6: 279 bytes
Can't fork at /usr/bin/git-cvsimport line 592, <CVS> line 3810053.
cat: write error: Broken pipe
> It had done 285070 of 343822 patchsets.
>
> Have you dropped the -a from the git-repack invocation? That should
> help. Try also Linus' patch for git-rev-list. The other thing hurting
> us is that the commits are _huge_. I wonder how you guys were managing
> this with CVS. Now _this_ explains why cvsimport grows humongous.
I wasn't running with a version that did repacks; I just suspended the
cvsimport a couple of times and ran a repack manually.
> I'll try to rework the commit loop so that we don't need to hold all
> the filenames in memory. It seems to be choking with the commits after
> April 2004. But that will have to wait till tonight.
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Junio C Hamano @ 2006-05-29 22:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605291145360.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Ok, this is largely the same series as the previous 1..4 patches, but
> rebased on top of the current master tree because the cache-tree patches
> added some tree_entry_list walkers (which accounts for one extra patch in
> the series, and some trivial merge fixups).
>
> Two new patches then clean up fsck-objects, which really didn't want the
> old tree_entry_list at all (and had added some hacks to the list entry
> just because fsck actually needed to check the raw data).
>
> Another two new patches convert the last remnant of tree_entry_list in
> revision.c and fetch.c respectively to the new world order.
>
> And the final patch then moves the "tree_entry_list" crud into the only
> remaining user, namely builtin-read-tree.c. That file is pretty messy and
> hard to convert, and I don't want to touch it right now, so I left it with
> the nasty compatibility functions. But now that's at least well-contained.
>
> I think the series is all good, and should replace the old one in "next"
> (and cook there for a while just to make sure it's ok).
Sorry for having you have done this -- last night I've merged
the series without rebasing and have the result in "next". I'll
compare to see if you have spotted my mismerges there tonight.
This reminds me of one issue.
From: Junio C Hamano <junkio@cox.net>
Subject: Necessity of "evil" merge and topic branches
Cc: git@vger.kernel.org
Date: Wed, 17 May 2006 23:25:55 -0700
Message-ID: <7vy7wz6e8c.fsf@assigned-by-dhcp.cox.net>
I have such an evil-merge branch merged in "next" to deal with
necessarily adjustments; it is 0a2586c, which is the tip of its
own branch. I was hoping this way I can merge it in to "master"
when I want to pull your yesterday's series.
^ permalink raw reply
* Re: [PATCH] Make git-diff-tree indicate when it flushes
From: Paul Mackerras @ 2006-05-29 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmh07a9k.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> I am not quite sure exactly what you are trying to achieve, but
> one trivial way is not giving -s perhaps?
I'm asking git-diff-tree which of a given set of commits affect any of
a set of paths, so that gitk can highlight the ones that do.
Furthermore I want to be able to use the git-diff-tree process for
multiple sets of commit IDs.
If I don't use -s, then I will get lines starting with a ":" after the
commit IDs of the commits that do affect the set of paths I specified.
That means I get a definite indication for all except the last commit
I send. For the last commit I still don't know whether the absence of
any ":" lines means that the commit doesn't affect the set of paths,
or that git-diff-tree is being slow. So I still need something like
the patch I sent.
I could get the indication I want (with or without -s) if I close the
pipe going to the git-diff-tree process. But then the process will
exit, and I want it to stay around so that I don't have to pay the
fork/exec and startup time of git-diff-tree next time (which will be
when the user scrolls the commit list window or asks to move to the
next highlighted commit).
Thus, --always (with or without -s) doesn't quite do what I need.
Paul.
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-05-29 22:21 UTC (permalink / raw)
To: Donnie Berkholz
Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <447B6D85.4050601@gentoo.org>
On 5/30/06, Donnie Berkholz <spyderous@gentoo.org> wrote:
> Donnie Berkholz wrote:
> > Linus Torvalds wrote:
> >> The latest stable CVS release is 1.11.21, I think: you seem to be running
> >> the "development" version (1.12.x).
> >
> > Backed down to the 1.11 series, things seem to be going fine so far.
>
> Finally hit an OOM sometime in the past day (yep, a week later) =\. Not
> sure whether it was cvsimport or cvs. Anyone else had more luck?
It seemed like it had finished on the machine I was running it, and I
assumed it was alright in yours too. Looking closer it only made it
till April 2004 -- but it may have been killed by a sysadmin, the
captured log talks about 'signal 9', I have no idea what the OOM
sends.
It had done 285070 of 343822 patchsets.
Have you dropped the -a from the git-repack invocation? That should
help. Try also Linus' patch for git-rev-list. The other thing hurting
us is that the commits are _huge_. I wonder how you guys were managing
this with CVS. Now _this_ explains why cvsimport grows humongous.
I'll try to rework the commit loop so that we don't need to hold all
the filenames in memory. It seems to be choking with the commits after
April 2004. But that will have to wait till tonight.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Make git-diff-tree indicate when it flushes
From: Junio C Hamano @ 2006-05-29 22:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <7vzmh07a9k.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Paul Mackerras <paulus@samba.org> writes:
>
>> With --always, how do I tell that 65aadb affects apply.c and cc189c
>> doesn't?
>
> I am not quite sure exactly what you are trying to achieve, but
> one trivial way is not giving -s perhaps?
Having said that, I suspect this might be a better way.
Whatever you throw at it from stdin that are not a validly
looking object name, you will get them back, so you can use your
favorite markers.
diff --git a/builtin-diff-tree.c b/builtin-diff-tree.c
index cc53b81..7208c48 100644
--- a/builtin-diff-tree.c
+++ b/builtin-diff-tree.c
@@ -138,11 +138,15 @@ int cmd_diff_tree(int argc, const char *
if (opt->diffopt.detect_rename)
opt->diffopt.setup |= (DIFF_SETUP_USE_SIZE_CACHE |
DIFF_SETUP_USE_CACHE);
- while (fgets(line, sizeof(line), stdin))
- if (line[0] == '\n')
+ while (fgets(line, sizeof(line), stdin)) {
+ unsigned char sha1[20];
+
+ if (get_sha1_hex(line, sha1)) {
+ fputs(line);
fflush(stdout);
+ }
else
diff_tree_stdin(line);
-
+ }
return 0;
}
^ permalink raw reply related
* Re: [RFC] git commit --branch
From: Shawn Pearce @ 2006-05-29 22:16 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060529215537.GH14325@admingilde.org>
Martin Waitz <tali@admingilde.org> wrote:
> hoi :)
>
> On Mon, May 29, 2006 at 05:35:43PM -0400, Shawn Pearce wrote:
> > Now that diff+apply is probably faster than a 3 way merge in
> > read-tree precisely because it doesn't need to run merge-recursive
> > I'm starting to look at how we can use apply to do partial
> > application of a patch and use RCS' diff3 or just drop a reject
> > file out when a hunk doesn't apply cleanly.
>
> but when applying patches, we have to be careful not to overwrite
> any changes in the working tree which have not yet been committed.
> With read-tree it should operate entirely in its temporary index without
> touching the working tree.
Agreed. But that's not always what you want. There's two cases of
applying a patch:
1) Apply this patch but only affect my working tree if everything
is going to patch clean. If anything goes wrong fail without
touching anything. git-apply already does this.
2) I know that not all hunks in this patch will apply cleanly. So
do the best you can by applying what you can and leave me the
remainder for manual merging. git-merge-recursive does this
through RCS' diff3.
But I think I want #2 built into git-apply where it can handle
add/rename/delete cases without the expense of git-merge-recursive.
I also want it to apply what it can and leave me reject files _NOT_
a messy RCS style conflict in the file. Some people just prefer
reject files. I know someone has asked about this in the past as
Emacs has a good merge tool based on reject files.
But in the case of #2 we get a mess in our working directory and in
our index as the patch didn't go in cleanly. That's OK. I want
the unmerged stages in the index and I want the working directory
to contain the conflicts as I want to fix that all up before commit.
> > > But then an operation as important as commit has to be bullet-proof
> > > and I don't like to do anything complex in there.
> >
> > I agree. But I'd like to see some sort of functionality to
> > automatically handle some common topic branche cases in commit.
> > Of course I consider the current commit tool to already be too
> > complex (like being able to pull the commit message from any
> > random commit).
>
> And I really feel guilt for trying to add even more.
> Is there some other way to add such a feature?
Not really. Short of adding a new command which is a variant of
git-commit specialized for this type of work. Which may be what I
wind up doing to get what I want.
> I have been dreaming of such a system for years now, and with GIT
> it really feels feasible at last.
> Graphics programs could compose an image out of different layers for
> ages, now it is time for version control software to do the same :-)
Heh. Its not quite as simple as it is in an image editor. But yes,
I agree. Darcs can sort of do this I believe. StGIT and pg both
attempt to do some basic operations but don't really get everything
right.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-send-email.perl extract_valid_address issue
From: Eric Wong @ 2006-05-29 22:12 UTC (permalink / raw)
To: Horst von Brand; +Cc: Ryan Anderson, Nicolas Troncoso Carrere, git
In-Reply-To: <200605292109.k4TL9g7E014263@laptop11.inf.utfsm.cl>
Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> Fix regexps to better match email addresses if Email::Valid isn't present
> Make it return the address on match containing a @
>
> Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
> ---
> git-send-email.perl | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 312a4ea..6e39f2f 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -309,14 +309,14 @@ sub extract_valid_address {
> my $address = shift;
>
> # check for a local address:
> - return $address if ($address =~ /^([\w\-]+)$/);
> + return $address if ($address =~ /^([\w\-.]+)$/);
>
> if ($have_email_valid) {
> return Email::Valid->address($address);
> } else {
> # less robust/correct than the monster regexp in Email::Valid,
> # but still does a 99% job, and one less dependency
> - return ($address =~ /([^\"<>\s]+@[^<>\s]+)/);
> + return ($address =~ /([\w\-.]+@[\w\-.]+)/) ? $1 : undef;
> }
> }
Oops on the original bug, my fault :x
Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Make git-diff-tree indicate when it flushes
From: Junio C Hamano @ 2006-05-29 22:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17531.28529.215905.856397@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
>> Wouldn't this help?
>>
>> $ git-diff-tree --stdin --always
>
> On the git.git tree:
>
> $ cat revs
> 65aadb92a1ce9605fa2f412b51de91781a3ef3d6
> cc189c2ca2c725c430f100f61e7c4a6849f93163
> $ git diff-tree -r -s --stdin -- apply.c <revs
> 65aadb92a1ce9605fa2f412b51de91781a3ef3d6
> $ git diff-tree -r -s --stdin --always -- apply.c <revs
> 65aadb92a1ce9605fa2f412b51de91781a3ef3d6
> cc189c2ca2c725c430f100f61e7c4a6849f93163
> $
>
> With --always, how do I tell that 65aadb affects apply.c and cc189c
> doesn't?
I am not quite sure exactly what you are trying to achieve, but
one trivial way is not giving -s perhaps?
^ permalink raw reply
* Re: [PATCH] Make git-diff-tree indicate when it flushes
From: Paul Mackerras @ 2006-05-29 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejyc8ymw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> Paul Mackerras <paulus@samba.org> writes:
>
> > There are times when gitk needs to know that the commits it has sent
> > to git-diff-tree --stdin did not match, and it needs to know in a
> > timely fashion even if none of them match. At the moment,
> > git-diff-tree outputs nothing for non-matching commits, so it is
> > impossible for gitk to distinguish between git-diff-tree being slow
> > and git-diff-tree saying no.
>
> Wouldn't this help?
>
> $ git-diff-tree --stdin --always
On the git.git tree:
$ cat revs
65aadb92a1ce9605fa2f412b51de91781a3ef3d6
cc189c2ca2c725c430f100f61e7c4a6849f93163
$ git diff-tree -r -s --stdin -- apply.c <revs
65aadb92a1ce9605fa2f412b51de91781a3ef3d6
$ git diff-tree -r -s --stdin --always -- apply.c <revs
65aadb92a1ce9605fa2f412b51de91781a3ef3d6
cc189c2ca2c725c430f100f61e7c4a6849f93163
$
With --always, how do I tell that 65aadb affects apply.c and cc189c
doesn't?
Paul.
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Johannes Schindelin @ 2006-05-29 21:58 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060529213704.GG14325@admingilde.org>
Hi,
On Mon, 29 May 2006, Martin Waitz wrote:
> I'm doing two commits, one to HEAD and one to the other branch.
> It is more like:
>
> git commit
> git checkout otherbranch
> git rebase --onto otherbranch master^ master <-- first
> git checkout master
> git merge msg master otherbranch <-- second
Wouldn't this merit a different option name, such as "--also-onto" instead
of "--branch"?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Martin Waitz @ 2006-05-29 21:55 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060529213543.GA29054@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
hoi :)
On Mon, May 29, 2006 at 05:35:43PM -0400, Shawn Pearce wrote:
> Now that diff+apply is probably faster than a 3 way merge in
> read-tree precisely because it doesn't need to run merge-recursive
> I'm starting to look at how we can use apply to do partial
> application of a patch and use RCS' diff3 or just drop a reject
> file out when a hunk doesn't apply cleanly.
but when applying patches, we have to be careful not to overwrite
any changes in the working tree which have not yet been committed.
With read-tree it should operate entirely in its temporary index without
touching the working tree.
> > But then an operation as important as commit has to be bullet-proof
> > and I don't like to do anything complex in there.
>
> I agree. But I'd like to see some sort of functionality to
> automatically handle some common topic branche cases in commit.
> Of course I consider the current commit tool to already be too
> complex (like being able to pull the commit message from any
> random commit).
And I really feel guilt for trying to add even more.
Is there some other way to add such a feature?
I have been dreaming of such a system for years now, and with GIT
it really feels feasible at last.
Graphics programs could compose an image out of different layers for
ages, now it is time for version control software to do the same :-)
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: irc usage..
From: Donnie Berkholz @ 2006-05-29 21:54 UTC (permalink / raw)
To: Donnie Berkholz
Cc: Linus Torvalds, Martin Langhoff, Yann Dirson, Git Mailing List,
Matthias Urlichs, Johannes Schindelin
In-Reply-To: <447231C4.2030508@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 406 bytes --]
Donnie Berkholz wrote:
> Linus Torvalds wrote:
>> The latest stable CVS release is 1.11.21, I think: you seem to be running
>> the "development" version (1.12.x).
>
> Backed down to the 1.11 series, things seem to be going fine so far.
Finally hit an OOM sometime in the past day (yep, a week later) =\. Not
sure whether it was cvsimport or cvs. Anyone else had more luck?
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [PATCH] git-receive-pack needs to set umask(2)
From: Johannes Schindelin @ 2006-05-29 21:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060529212830.GA4074@limbo.home>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 984 bytes --]
Hi,
On Mon, 29 May 2006, Alex Riesen wrote:
> [...]
> Reading man sshd:
>
> $HOME/.ssh/rc
> If this file exists, it is run with /bin/sh after reading the
> environment files but before starting the user's shell or com
> mand. It must not produce any output on stdout; stderr must be
> used instead. If X11 forwarding is in use, it will receive the
> "proto cookie" pair in its standard input (and DISPLAY in its
> environment). The script must call xauth(1) because sshd will
> not run xauth automatically to add X11 cookies.
> and
>
> /etc/ssh/sshrc
> Like $HOME/.ssh/rc. This can be used to specify machine-specific
> login-time initializations globally. This file should be
> writable only by root, and should be world-readable.
>
>
> This guaranteed to work (at least for ssh).
But not for bash. Back to square 1.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Martin Waitz @ 2006-05-29 21:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605292310280.17412@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
hoi :)
On Mon, May 29, 2006 at 11:14:32PM +0200, Johannes Schindelin wrote:
> Doesn't
>
> $ git-update-index $(git-ls-files --modified)
> $ git-checkout -b tempBranch
> $ git-commit -m "to test"
>
> work? It also avoids totally bogus parents (if I read your patch
> correctly, you take the current HEAD as the true parent, but record the
> current HEAD of the other branch as parent nevertheless).
I'm doing two commits, one to HEAD and one to the other branch.
It is more like:
git commit
git checkout otherbranch
git rebase --onto otherbranch master^ master <-- first
git checkout master
git merge msg master otherbranch <-- second
Now your current HEAD is still a merge of your topic branches,
and you commited your changes to one clean topic branch.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Shawn Pearce @ 2006-05-29 21:35 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060529212249.GF14325@admingilde.org>
Martin Waitz <tali@admingilde.org> wrote:
> On Mon, May 29, 2006 at 04:41:58PM -0400, Shawn Pearce wrote:
> > Interesting. I have been kicking around doing the very same
> > thing myself but just have not gotten around to it. Its complex,
> > especially if the current HEAD isn't strictly the merge commit
> > between the topic branch and the previous value of HEAD; in that
> > case you may want to replay the commits which are on HEAD but are
> > post the merge commit using a form of git-rebase. Except you would
> > want to preserve any merges which happened by remerging them rather
> > than simply exporting a massive patch and reapplying it.
>
> Perhaps something like merge-recursive makes sense, except that
> I have no clue how it works ;-)
merge-recursive isn't the right tool here. Its job is to perform a
3 way merge "quickly" by dealing with file adds, deletes, renames
and patch application when a file was modified by both parents.
Now that diff+apply is probably faster than a 3 way merge in
read-tree precisely because it doesn't need to run merge-recursive
I'm starting to look at how we can use apply to do partial
application of a patch and use RCS' diff3 or just drop a reject
file out when a hunk doesn't apply cleanly.
> But then an operation as important as commit has to be bullet-proof
> and I don't like to do anything complex in there.
I agree. But I'd like to see some sort of functionality to
automatically handle some common topic branche cases in commit.
Of course I consider the current commit tool to already be too
complex (like being able to pull the commit message from any
random commit).
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-receive-pack needs to set umask(2)
From: Alex Riesen @ 2006-05-29 21:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Salikh Zakirov, git
In-Reply-To: <Pine.LNX.4.64.0605290956190.5623@g5.osdl.org>
Linus Torvalds, Mon, May 29, 2006 19:00:42 +0200:
>
> I realize that you already found the solution (Core.SharedRepository),
> but:
>
> On Mon, 29 May 2006, Salikh Zakirov wrote:
> >
> > 2) I have 'umask 002' in my ~/.profile. Somehow, it does not help,
> > because ~/.profile is not read on non-interactive SSH sessions
> > (to verify that, just try to do 'ssh somehost umask')
>
> The ".profile" thing is indeed read only for interactive tasks.
>
> So use ".bashrc" instead.
>
Will not work:
$ man bash
...
When an interactive shell that is not a login shell is
started, bash reads and executes commands from ~/.bashrc,
if that file exists. ...
Besides, not everyone has bash as their login shell.
Reading man sshd:
$HOME/.ssh/rc
If this file exists, it is run with /bin/sh after reading the
environment files but before starting the user's shell or com
mand. It must not produce any output on stdout; stderr must be
used instead. If X11 forwarding is in use, it will receive the
"proto cookie" pair in its standard input (and DISPLAY in its
environment). The script must call xauth(1) because sshd will
not run xauth automatically to add X11 cookies.
and
/etc/ssh/sshrc
Like $HOME/.ssh/rc. This can be used to specify machine-specific
login-time initializations globally. This file should be
writable only by root, and should be world-readable.
This guaranteed to work (at least for ssh).
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Jakub Narebski @ 2006-05-29 21:27 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0605292310280.17412@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Mon, 29 May 2006, Martin Waitz wrote:
>
>> Sometimes it is neccessary to have some local modifications in the tree
>> in order to test it and work with it.
>
> Doesn't
>
> $ git-update-index $(git-ls-files --modified)
> $ git-checkout -b tempBranch
> $ git-commit -m "to test"
>
> work?
Added to GitFaq page on GitWiki, under
"How do I save some local modifications?"
http://git.or.cz/gitwiki/GitFaq#saving-draft
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Martin Waitz @ 2006-05-29 21:22 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060529204158.GC28538@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]
hoi :)
On Mon, May 29, 2006 at 04:41:58PM -0400, Shawn Pearce wrote:
> Interesting. I have been kicking around doing the very same
> thing myself but just have not gotten around to it. Its complex,
> especially if the current HEAD isn't strictly the merge commit
> between the topic branch and the previous value of HEAD; in that
> case you may want to replay the commits which are on HEAD but are
> post the merge commit using a form of git-rebase. Except you would
> want to preserve any merges which happened by remerging them rather
> than simply exporting a massive patch and reapplying it.
Perhaps something like merge-recursive makes sense, except that
I have no clue how it works ;-)
But then an operation as important as commit has to be bullet-proof
and I don't like to do anything complex in there.
In any case, this functionality needs a lot of testing.
Any contributions to the test case are welcome :)
> > + git update-ref "$onto_branch" $commit2 &&
>
> If this is going into next perhaps you would like to considering adding
> the -m flag to your git-update-ref calls and include a log message
> in the reflog (if the user has it enabled for the current branch and
> the topic branch)?
Makes sense.
> Also shouldn't this be 'git-update-ref'?
Yes, all the rest uses git-*, too.
If the move to buildin commands continues at the same speed we
may soon be able to remove some "-"s, but it's not time for that yet.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Johannes Schindelin @ 2006-05-29 21:14 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060529202851.GE14325@admingilde.org>
Hi,
On Mon, 29 May 2006, Martin Waitz wrote:
> Sometimes it is neccessary to have some local modifications in the tree
> in order to test it and work with it.
Doesn't
$ git-update-index $(git-ls-files --modified)
$ git-checkout -b tempBranch
$ git-commit -m "to test"
work? It also avoids totally bogus parents (if I read your patch
correctly, you take the current HEAD as the true parent, but record the
current HEAD of the other branch as parent nevertheless).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix some documentation typoes
From: Horst von Brand @ 2006-05-29 21:11 UTC (permalink / raw)
To: git
Fix some typoes in Documentation/everyday.txt
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/everyday.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 3ab9b91..a3f3a65 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -65,7 +65,7 @@ Check health and remove cruft.::
<1> running without "--full" is usually cheap and assures the
repository health reasonably well.
<2> check how many loose objects there are and how much
-diskspace is wasted by not repacking.
+disk space is wasted by not repacking.
<3> without "-a" repacks incrementally. repacking every 4-5MB
of loose objects accumulation may be a good rule of thumb.
<4> after repack, prune removes the duplicate loose objects.
@@ -86,7 +86,7 @@ Individual Developer (Standalone)[[Indiv
----------------------------------------------------------------------
A standalone individual developer does not exchange patches with
-other poeple, and works alone in a single repository, using the
+other people, and works alone in a single repository, using the
following commands.
* gitlink:git-show-branch[1] to see where you are.
@@ -371,7 +371,7 @@ Examples
Run git-daemon to serve /pub/scm from inetd.::
+
------------
-$ grep git /etc/inet.conf
+$ grep git /etc/inetd.conf
git stream tcp nowait nobody \
/usr/bin/git-daemon git-daemon --inetd --syslog --export-all /pub/scm
------------
--
1.3.3.g0f0ac
^ permalink raw reply related
* Re: [PATCH] git-send-email.perl extract_valid_address issue
From: Horst von Brand @ 2006-05-29 21:09 UTC (permalink / raw)
To: Ryan Anderson, Nicolas Troncoso Carrere; +Cc: git
In-Reply-To: <20060529200026.GA32457@h4x0r5.com>
Fix regexps to better match email addresses if Email::Valid isn't present
Make it return the address on match containing a @
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
git-send-email.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 312a4ea..6e39f2f 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -309,14 +309,14 @@ sub extract_valid_address {
my $address = shift;
# check for a local address:
- return $address if ($address =~ /^([\w\-]+)$/);
+ return $address if ($address =~ /^([\w\-.]+)$/);
if ($have_email_valid) {
return Email::Valid->address($address);
} else {
# less robust/correct than the monster regexp in Email::Valid,
# but still does a 99% job, and one less dependency
- return ($address =~ /([^\"<>\s]+@[^<>\s]+)/);
+ return ($address =~ /([\w\-.]+@[\w\-.]+)/) ? $1 : undef;
}
}
--
1.3.3.g0f0ac
^ permalink raw reply related
* Re: [PATCH] git-send-email.perl extract_valid_address issue
From: Horst von Brand @ 2006-05-29 21:06 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Nicolas Troncoso Carrere, git
In-Reply-To: <20060529200026.GA32457@h4x0r5.com>
Ryan Anderson <ryan@michonline.com> wrote:
> On Mon, May 29, 2006 at 12:00:44AM -0400, Nicolas Troncoso Carrere wrote:
> >
> > The third fallback was returning if the match was done or not instead of
> > returning the actual email address that was matched. This prevented sending
> > the mail to the people included in the CC. This bug only affect those that
> > dont have Email::Valid.
> >
> > I initialized $valid_email as undef so it would mimic the behavior of
> > Email::Verify->address(), which returns undef if no valid address was found.
>
> Odd, I noticed the same thing this weekend.
>
> > Signed-off-by: Nicolas <ntroncos@inf.utfsm.cl>
> Acked-by: Ryan Anderson <ryan@michonline.com>
>
> (Or pick up my patch that fixes this in a slightly different way)
>
> >
> >
> > ---
> >
> > git-send-email.perl | 4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > 84853ca89c15de7a24e9eb9fd422654b86c63be9
> > diff --git a/git-send-email.perl b/git-send-email.perl
> > index 312a4ea..dfff3e6 100755
> > --- a/git-send-email.perl
> > +++ b/git-send-email.perl
> > @@ -316,7 +316,9 @@ sub extract_valid_address {
> > } else {
> > # less robust/correct than the monster regexp in Email::Valid,
> > # but still does a 99% job, and one less dependency
> > - return ($address =~ /([^\"<>\s]+@[^<>\s]+)/);
> > + my $valid_email=undef;
> > + ($valid_email ) = ($address =~ /([^\"<>\s]+@[^<>\s]+)/);
> > + return ($valid_email);
> > }
> > }
I just looked it over, and this is certainly broken in the original. The
first return gives the string back if it matches, the second one evaluates
the list returned by the match in scalar context, and so returns 1 for a
match or 0 for non-match. Besides, the regexps are fishy...
- The first one won't consider 'Joe.Hacker' as a valid local address
- The second one will consider 'Joe.Hacker@example.com"' valid (note ")
Need to make both branches (with and without @) agree here, at least. And
this is certainly severely underpowered... dunno if it merits a better job
(or just bail out if Email::Valid isn't found, instead of kludgeing
around...)
Will propose a fix ASAP.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Shawn Pearce @ 2006-05-29 20:41 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060529202851.GE14325@admingilde.org>
Martin Waitz <tali@admingilde.org> wrote:
> Allow to commit to another branch and creating a merge in the current branch.
Interesting. I have been kicking around doing the very same
thing myself but just have not gotten around to it. Its complex,
especially if the current HEAD isn't strictly the merge commit
between the topic branch and the previous value of HEAD; in that
case you may want to replay the commits which are on HEAD but are
post the merge commit using a form of git-rebase. Except you would
want to preserve any merges which happened by remerging them rather
than simply exporting a massive patch and reapplying it.
> + test $(git merge-base "$onto_branch" HEAD^) != $onto_branch_commit &&
> + test $(git merge-base "$onto_branch"^ HEAD^) = $(git rev-parse --verify "$onto_branch"^) ||
> + die "commits on $onto_branch and HEAD differ, cannot amend."
> + onto_branch_commit=$(git rev-parse --verify "$onto_branch"^)
Shouldn't these be 'git-merge-base' and 'git-rev-parse' ?
> + git update-ref "$onto_branch" $commit2 &&
If this is going into next perhaps you would like to considering adding
the -m flag to your git-update-ref calls and include a log message
in the reflog (if the user has it enabled for the current branch and
the topic branch)?
Also shouldn't this be 'git-update-ref'?
--
Shawn.
^ permalink raw reply
* [RFC] git commit --branch
From: Martin Waitz @ 2006-05-29 20:28 UTC (permalink / raw)
To: git
Allow to commit to another branch and creating a merge in the current branch.
Sometimes it is neccessary to have some local modifications in the tree
in order to test it and work with it. With this patch you can have
one working tree which combines several topic branches in order to
develop and test your changes. When your changes are ready, you can
commit them to the appropriate topic branch.
With the --branch option, the commit will automatically be rebased to
that branch. The original tree will then be commited to your working
branch as a merge.
---
Perhaps something like this can even be integrated into the extended
branch configuration which is currently under discussion.
It may make sense to have one branch which always contains a merge
of a selected set of other branches and having a default branch
for new commits.
Documentation/git-commit.txt | 6 +++
git-commit.sh | 62 ++++++++++++++++++++++++++++++++++-
t/t3800-commit-onto-other-branch.sh | 32 ++++++++++++++++++
3 files changed, 99 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 38df59c..8111ba4 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -49,6 +49,12 @@ OPTIONS
Override the author name used in the commit. Use
`A U Thor <author@example.com>` format.
+--branch <branch>::
+ Actually commit the changes to another branch.
+ Afterwards it will be merged into the current branch.
+ This is useful if you work on a branch with local modifications
+ but want to keep one clean branch without those.
+
-m <msg>::
Use the given <msg> as the commit message.
diff --git a/git-commit.sh b/git-commit.sh
index 1983d45..9ed0050 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -3,7 +3,7 @@ #
# Copyright (c) 2005 Linus Torvalds
# Copyright (c) 2006 Junio C Hamano
-USAGE='[-a] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit>] [-u] [--amend] [-e] [--author <author>] [[-i | -o] <path>...]'
+USAGE='[-a] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit>] [-u] [--amend] [-e] [--author <author>] [--branch <branch>] [[-i | -o] <path>...]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -245,6 +245,12 @@ do
force_author="$1"
shift
;;
+ -b|--b|--br|--bra|--bran|--branc|--branch)
+ case "$#" in 1) usage ;; esac
+ shift
+ onto_branch="$1"
+ shift
+ ;;
-e|--e|--ed|--edi|--edit)
no_edit=
shift
@@ -405,6 +411,7 @@ t,,[1-9]*)
die "No paths with -i does not make sense." ;;
esac
+
################################################################
# Prepare index to have a tree to be committed
@@ -623,6 +630,32 @@ else
current=
fi
+if test -n "$onto_branch"
+then
+ onto_branch_commit=$(git-rev-parse --verify "$onto_branch") ||
+ die "Branch $onto_branch does not exist."
+ test $(git merge-base "$onto_branch" HEAD) = $onto_branch_commit ||
+ die "Branch "$onto_branch" already contains unmerged commits."
+ case "$PARENTS" in
+ -p*-p*) die "Cannot commit a merge to another branch." ;;
+ esac
+ if test $(git-rev-parse --verify HEAD) = $onto_branch_commit
+ then
+ # no merge neccessary, branches identically
+ forward_onto_branch="$onto_branch"
+ onto_branch=""
+ fi
+ if test "$amend" = t
+ then
+ # test that the tip of HEAD really came from the tip of
+ # $onto_branch and that we can amend both of them
+ test $(git merge-base "$onto_branch" HEAD^) != $onto_branch_commit &&
+ test $(git merge-base "$onto_branch"^ HEAD^) = $(git rev-parse --verify "$onto_branch"^) ||
+ die "commits on $onto_branch and HEAD differ, cannot amend."
+ onto_branch_commit=$(git rev-parse --verify "$onto_branch"^)
+ fi
+fi
+
if test -z "$no_edit"
then
{
@@ -689,8 +722,35 @@ then
tree=$(GIT_INDEX_FILE="$TMP_INDEX" git-write-tree) &&
rm -f "$TMP_INDEX"
fi &&
+ if test -n "$onto_branch"
+ then
+ # create temporary index
+ ONTO_INDEX="$GIT_DIR/onto-index"
+ cp "$USE_INDEX" "$ONTO_INDEX" &&
+ GIT_INDEX_FILE="$ONTO_INDEX" \
+ git-read-tree -i -m "$onto_branch_commit"
+ # merge new changes into the branch
+ GIT_INDEX_FILE="$ONTO_INDEX" \
+ git-read-tree -i --aggressive -m \
+ HEAD "$onto_branch_commit" "$tree" &&
+ GIT_INDEX_FILE="$ONTO_INDEX" \
+ git-merge-index git-merge-one-file -a || {
+ echo >&2 "Cannot rebase your commit to $onto_branch."
+ echo >&2 "Please merge and commit manually."
+ false
+ } &&
+ tree2=$(GIT_INDEX_FILE="$ONTO_INDEX" git-write-tree) &&
+ commit2=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree2 -p $onto_branch_commit) &&
+ git update-ref "$onto_branch" $commit2 &&
+ rm -f "$ONTO_INDEX" &&
+ PARENTS="$PARENTS -p $commit2"
+ fi &&
commit=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&
git-update-ref HEAD $commit $current &&
+ if test -n "$forward_onto_branch"
+ then
+ git-update-ref "$forward_onto_branch" $commit $current
+ fi &&
rm -f -- "$GIT_DIR/MERGE_HEAD" &&
if test -f "$NEXT_INDEX"
then
diff --git a/t/t3800-commit-onto-other-branch.sh b/t/t3800-commit-onto-other-branch.sh
new file mode 100755
index 0000000..f4f6410
--- /dev/null
+++ b/t/t3800-commit-onto-other-branch.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Martin Waitz
+#
+
+test_description='Test a commit to another branch'
+
+. ./test-lib.sh
+
+echo AAA > A
+echo BBB > B
+
+test_expect_success 'Initial commit' \
+'git add A B &&
+ git commit -m "Initial commit" &&
+ git branch topic'
+
+test_expect_success 'Modify HEAD' \
+'echo A2 > A &&
+ git commit -m "modify A" A'
+
+test_expect_success 'Commit to branch' \
+'echo B2 > B &&
+ git commit -m "modify B" --branch topic B'
+
+# now test that HEAD and topic only differs in A
+test_expect_success 'Verify trees' \
+'echo ":100644 100644 43d5a8e... 3ce238a... M A" > expected &&
+ git diff-tree --abbrev topic HEAD > current &&
+ diff expected current'
+
+test_done
--
1.3.3.ged90
--
Martin Waitz
^ permalink raw reply related
* Re: [PATCH] git-send-email.perl extract_valid_address issue
From: Ryan Anderson @ 2006-05-29 20:00 UTC (permalink / raw)
To: Nicolas Troncoso Carrere; +Cc: git
In-Reply-To: <200605290000.44463.ntroncos@alumnos.inf.utfsm.cl>
On Mon, May 29, 2006 at 12:00:44AM -0400, Nicolas Troncoso Carrere wrote:
>
> The third fallback was returning if the match was done or not instead of
> returning the actual email address that was matched. This prevented sending
> the mail to the people included in the CC. This bug only affect those that
> dont have Email::Valid.
>
> I initialized $valid_email as undef so it would mimic the behavior of
> Email::Verify->address(), which returns undef if no valid address was found.
Odd, I noticed the same thing this weekend.
> Signed-off-by: Nicolas <ntroncos@inf.utfsm.cl>
Acked-by: Ryan Anderson <ryan@michonline.com>
(Or pick up my patch that fixes this in a slightly different way)
>
>
> ---
>
> git-send-email.perl | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> 84853ca89c15de7a24e9eb9fd422654b86c63be9
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 312a4ea..dfff3e6 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -316,7 +316,9 @@ sub extract_valid_address {
> } else {
> # less robust/correct than the monster regexp in Email::Valid,
> # but still does a 99% job, and one less dependency
> - return ($address =~ /([^\"<>\s]+@[^<>\s]+)/);
> + my $valid_email=undef;
> + ($valid_email ) = ($address =~ /([^\"<>\s]+@[^<>\s]+)/);
> + return ($valid_email);
> }
> }
> --
> Nicol?s Troncoso Carr?re User #272312 counter.li.org
> Estudiante Mag?ster en Ciencias de la Inform?tica
> Universidad T?cnica Federico Santa Mar?a
> http://www.alumnos.inf.utfsm.cl/~ntroncos
> -
> 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
>
^ 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