* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Junio C Hamano @ 2006-05-31 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605292112530.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> (a) git-rev-list --pretty=oneline "$upstream"..ORIG_HEAD > rev-list
>
> (b) edit the rev-list, moving the single lines around, deleting them, etc
>
> (c) cat rev-list |
> git-format-patch -k --stdout --stdin --full_index |
> git-am
>
> because the "--pretty=oneline" format is actually very nice as a way to
> re-order things and select single commits to be deleted or whatever..
I am thinking about doing "format-patch --stdin" while I am
futzing with it for other reasons, and one issue is where to
"tac" the revision list.
We could internally reverse topo-sort what we read from --stdin
inside format-patch, but that would defeat the reordering that
is done in the step (b) above, so that is not a useful thing to
do.
If we wanted to make rev-list piped straight to format-patch
equilvalent to giving the arguments you would have given rev-list
directly to format-patch, then format-patch should read --stdin
and reverse the list before emitting them out.
However, that would mean in the step (b) above the user needs to
be conscious that the list being edited is in the reverse order,
so if the list of commits needs to be reordered (and that is one
of the reasons the user is doing this step) what comes earlier
in the edited list will be output later in the result.
Tentatively my feeling is that we should make it known that the
list format-patch takes from --stdin is supposed to be _not_
reversed, and do nothing in format-patch. In other words, the
list fed is a moral equivalent to quilt "series" file.
What this means is:
git-format-patch $revargs
is not equivalent to
git-rev-list $revargs | git-format-patch --stdin
but is equivalent to
git-rev-list $revargs | tac | git-format-patch --stdin
Thoughts from the list?
^ permalink raw reply
* [PATCH] send-email: only 'require' instead of 'use' Net::SMTP
From: Johannes Schindelin @ 2006-05-31 22:55 UTC (permalink / raw)
To: git, junkio, Eric Wong
This was proposed by Eric Wong and fixes the test. (Of course, git-send-email
does not work, if there is no Net::SMTP here, but it will say what is wrong
when you actually try to use send-email.)
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 0e368ff..ed1d89b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -21,7 +21,6 @@ use warnings;
use Term::ReadLine;
use Getopt::Long;
use Data::Dumper;
-use Net::SMTP;
# most mail servers generate the Date: header, but not all...
$ENV{LC_ALL} = 'C';
@@ -394,6 +393,7 @@ X-Mailer: git-send-email $gitversion
print $sm "$header\n$message";
close $sm or die $?;
} else {
+ require Net::SMTP;
$smtp ||= Net::SMTP->new( $smtp_server );
$smtp->mail( $from ) or die $smtp->message;
$smtp->to( @recipients ) or die $smtp->message;
--
1.3.3.gc46d3-dirty
^ permalink raw reply related
* Re: [PATCH] format-patch --signoff
From: Junio C Hamano @ 2006-05-31 23:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Geoff Russell, Marco Costalba, git, Seth Falcon
In-Reply-To: <Pine.LNX.4.63.0606010032410.21774@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I don't know, but it may be a good idea to make this more general: Why not
> build the sign-off line here, so that you could also add more than one
> sign-off lines ('--signoff="The great committer <ter@mit.com>"'), and
> maybe even Acked-by's?
Perhaps.
> Okay, this would be a little harder with multiple sign-offs. But the check
> could be easier, i.e. if we say
>
> rev.add_signoff = xmalloc(enough_room);
> strcpy(rev.add_signoff, "\nSigned-off-by: ");
> strcat(rev.add_signoff, committer_ident);
> strcat(rev.add_signoff, "\n");
>
> then a simple
>
> p = strstr(commit_buffer, rev.add_signoff);
> if (p)
> return (int)(p - commit_buffer);
>
> would do the trick.
Do you mean, by "multiple sign-offs", something like this?
for (so_list = rev.add_signoff; so_list; so_list = so_list->next) {
if (strstr(commit_buffer, so_list->item))
continue;
append_to_commit_buffer(so_list->item);
}
return tail - commit_buffer;
> And shouldn't we error out if there is not enough room for a sign-off?
I do not think we error out if the commit message is too long
either, so...
^ permalink raw reply
* [PATCH] http: prevent segfault during curl handle reuse
From: Nick Hengeveld @ 2006-05-31 23:25 UTC (permalink / raw)
To: git
If a curl handle is configured with special options, they may reference
information that is freed after the request is complete which can cause
a segfault if the curl handle is reused for a different type of request.
This patch resets these options to a safe state when a transfer slot is
assigned to a new request.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/http.c b/http.c
index 0cb42a8..146cf7b 100644
--- a/http.c
+++ b/http.c
@@ -25,7 +25,6 @@ long curl_low_speed_limit = -1;
long curl_low_speed_time = -1;
struct curl_slist *pragma_header;
-struct curl_slist *no_range_header;
struct active_request_slot *active_queue_head = NULL;
@@ -208,7 +207,6 @@ void http_init(void)
curl_global_init(CURL_GLOBAL_ALL);
pragma_header = curl_slist_append(pragma_header, "Pragma: no-cache");
- no_range_header = curl_slist_append(no_range_header, "Range:");
#ifdef USE_CURL_MULTI
{
@@ -344,9 +342,14 @@ #endif
slot->finished = NULL;
slot->callback_data = NULL;
slot->callback_func = NULL;
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, NULL);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, pragma_header);
- curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, no_range_header);
curl_easy_setopt(slot->curl, CURLOPT_ERRORBUFFER, curl_errorstr);
+ curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, NULL);
+ curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, NULL);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, NULL);
+ curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 0);
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
return slot;
}
--
1.3.3.g2186-dirty
^ permalink raw reply related
* Re: [PATCH] format-patch --signoff
From: Johannes Schindelin @ 2006-05-31 23:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Geoff Russell, Marco Costalba, git, Seth Falcon
In-Reply-To: <7vlkshyedf.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 31 May 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I don't know, but it may be a good idea to make this more general: Why not
> > build the sign-off line here, so that you could also add more than one
> > sign-off lines ('--signoff="The great committer <ter@mit.com>"'), and
> > maybe even Acked-by's?
>
> Perhaps.
>
> > Okay, this would be a little harder with multiple sign-offs. But the check
> > could be easier, i.e. if we say
> >
> > rev.add_signoff = xmalloc(enough_room);
> > strcpy(rev.add_signoff, "\nSigned-off-by: ");
> > strcat(rev.add_signoff, committer_ident);
> > strcat(rev.add_signoff, "\n");
> >
> > then a simple
> >
> > p = strstr(commit_buffer, rev.add_signoff);
> > if (p)
> > return (int)(p - commit_buffer);
> >
> > would do the trick.
>
> Do you mean, by "multiple sign-offs", something like this?
>
> for (so_list = rev.add_signoff; so_list; so_list = so_list->next) {
> if (strstr(commit_buffer, so_list->item))
> continue;
> append_to_commit_buffer(so_list->item);
> }
> return tail - commit_buffer;
Actually, I did not think of a linked list, but one buffer, but I like
your solution better.
> > And shouldn't we error out if there is not enough room for a sign-off?
>
> I do not think we error out if the commit message is too long
> either, so...
... so you could say that should be an error, too.
Ciao,
Dscho
^ permalink raw reply
* Re: irc usage..
From: Alec Warner @ 2006-06-01 1:42 UTC (permalink / raw)
To: Martin Langhoff
Cc: Donnie Berkholz, Linus Torvalds, Yann Dirson, Git Mailing List,
Matthias Urlichs, Johannes Schindelin
In-Reply-To: <46a038f90605311503o1526c664qe61b0f3f40929b92@mail.gmail.com>
Martin Langhoff wrote:
> On 6/1/06, Alec Warner <antarus@gentoo.org> wrote:
>
>> I have a dual opteron with 4gb of ram "on loan" from work :)
>>
>> It still dies though, using git cvsimport or parsecvs.
>
>
> The machine I am running this is more constrained than that, and it
> doesn't die. It just takes maybe 30hs. Make sure it's not a bad cvs
> binary you got there (latest from gentoo seems to leak memory).
>
> And if it's still dying... give us some more details ;-)
>
> cheers,
>
>
> martin
After reading the whole thread on this, I've using a git checkout of
git, cvsps-2.1 and cvs-1.11.12, running overnight in verbose mode with
screen. Hopefully will have a repo in the morning ;)
^ permalink raw reply
* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Shawn Pearce @ 2006-06-01 3:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vpshtyffk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > (a) git-rev-list --pretty=oneline "$upstream"..ORIG_HEAD > rev-list
> >
> > (b) edit the rev-list, moving the single lines around, deleting them, etc
> >
> > (c) cat rev-list |
> > git-format-patch -k --stdout --stdin --full_index |
> > git-am
> >
[snip]
> What this means is:
>
> git-format-patch $revargs
>
> is not equivalent to
>
> git-rev-list $revargs | git-format-patch --stdin
>
> but is equivalent to
>
> git-rev-list $revargs | tac | git-format-patch --stdin
>
>
> Thoughts from the list?
Aside from not knowing what tac is I agree with the latter.
It is what the user would expect to happen. Except maybe add a
--ancestors-first option to git-rev-list to do what tac does before
outputting the revisions?
git-rev-list --ancestors-first $revargs | git-format-patch --stdin
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Automatically line wrap long commit messages.
From: Shawn Pearce @ 2006-06-01 3:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64jm2380.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Junio C Hamano <junkio@cox.net> wrote:
> >
> >> If we supported multiple -m (presumably each becomes a single line?)
> >> with internal fmt, I do not see how it would become less work.
> >>
> >> $ git commit -w60 -m "This is my message." \
> >> -m '' \
> >> -m 'This is the body. Etc....'
> >>
> >> looks more typing to me, even without the second line to force
> >> the empty line between the summary and the body.
> >
> > Actually I was thinking each -m would be its own paragraph so blank
> > lines would split each -m and maybe the -w60 should be a config
> > option in .git/config or .gitrc so it doesn't always need to be
> > supplied on the command line.
>
> Now that makes the distinction between the current:
>
> $ git commit -m 'This is my message.
>
> This is the body. Etc....'
>
> vs. the proposed multi-em:
>
> $ git commit -m 'This is my message.' \
> -m 'This is the body. Etc....'
>
> Presumably Etc.... will be an multiline argument to -m. The
> distinction is even more blurry to me than before.
>
> Emacs users would just do "ESC q" and vi users would know how to
> filter the file contents through fmt, so this seems to come from
> aversion against invoking your $EDITOR. I just do not see why.
Because git-commit currently performs a status update and throws
that data into the editor buffer. That takes longer than committing
from the command line. Especially if I've just done a git-diff or
git-status to see what is changed and about to be committed...
On a project the size of GIT on a Unix system this isn't a big deal;
on a 9000 file project on Cygwin this difference is significant
to me.
It is just the way I am used to working.
> Having said that, I do realize that the current behaviour of
> accepting multiple -m without complaining and discarding all but
> the last one silently is far worse than what is being proposed,
> and I do not see downside to the multiple -m patch, so let's
> apply that. You can have your "fmt -w60" provided if it is made
> into an option.
I'll rework the fmt -w60 patch to instead accept an optional filter
command from .git/config; if the filter command is set then the
command line commit message will get run through the filter before
being piped into git-commit-tree.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Automatically line wrap long commit messages.
From: Junio C Hamano @ 2006-06-01 6:37 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060601033430.GA13485@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Because git-commit currently performs a status update and throws
> that data into the editor buffer. That takes longer than committing
> from the command line. Especially if I've just done a git-diff or
> git-status to see what is changed and about to be committed...
Ah, why does it take this many exchanges to extract the true
motive behind what people do even in a technical forum like
this, I wonder...
So what you want is not multiple -m options nor piping to fmt.
What you really want is an option that is the opposite of -v to
git-commit that omits the status list ("_could_ commit if you
update-index" part -- since "will commit" is something we would
need to compute anyway).
> On a project the size of GIT on a Unix system this isn't a big deal;
> on a 9000 file project on Cygwin this difference is significant
> to me.
I suspect you are suffering from lstat() performance. I wonder
if "assume unchanged" git help your situation?
^ permalink raw reply
* Re: [PATCH] git-svnimport: Improved detection of merges.
From: Junio C Hamano @ 2006-06-01 7:12 UTC (permalink / raw)
To: git; +Cc: Florian Forster
In-Reply-To: <11490715283626-git-send-email-octo@verplant.org>
Florian Forster <octo@verplant.org> writes:
> The regexes detecting merges (while still relying on the commit messages,
> though) have been improved to catch saner (and hopefully more) messages. The
> old regex was so generic that it often matched something else and missed the
> actual merge-message.
> Also, the regex given with the `-M' commandline-option is checked first:
> Explicitely given regexes should be considered better than the builtin ones,
> and should therefore be given a chance to match a message first.
The latter part sounds immensely sane. The former I am not a
good judge, since I do not interact with subversion repositories
myself. Opinions from real svn users?
BTW, did anybody received the latest "What's in git.git" I sent
out about 20 minutes ago?
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-06-01 7:47 UTC (permalink / raw)
To: antarus
Cc: Donnie Berkholz, Linus Torvalds, Yann Dirson, Git Mailing List,
Matthias Urlichs, Johannes Schindelin
In-Reply-To: <447E4611.7000309@gentoo.org>
On 6/1/06, Alec Warner <antarus@gentoo.org> wrote:
> After reading the whole thread on this, I've using a git checkout of
> git, cvsps-2.1 and cvs-1.11.12, running overnight in verbose mode with
> screen. Hopefully will have a repo in the morning ;)
Good stuff. I am rerunning it to prove (and bench) a complete an
uninterrupted import. So far it's done 4hs 30m, footprint grown to
207MB, 49750 commits. So I think it will be done in approx 30hs on
this single-cpu opteron.
Most commits are small, but there is a handful that are downright
massive -- and we hold all the file list in memory, which I think
explains (most of) the memory growth. I've looked into avoiding
holding the whole filelist in memory, but it involves rewriting the
cvsps output parsing loop, which is better left for a rainy day, with
a test case that doesn't take 30hs to resolve.
cheers,
martin
^ permalink raw reply
* What's in git.git (part #2)
From: Junio C Hamano @ 2006-06-01 9:19 UTC (permalink / raw)
To: git
It's been a while since the last feature release, and I
think with the recent "many things built-in" (including the
busybox style integration) we are nearing a good time to do the
next feature release 1.4.0.
Before doing a 1.4.0-rc1, I would like to see the following
topics in the "next" branch graduate to "master":
- re-add missing flags to format-patch. I have resurrected
"--signoff"; if people care about something else we dropped
when we went built-in, please raise hand and submit patches.
- tree-parser updates from Linus seems to be fine in the sense
I haven't seen breakage from it; I'll push it out to "master"
before the end of the week. I'd like to do another round of
update to introduce a unified tree/index/directory walker, so
settling this down is sort of urgent.
- http-fetch fixes from Nick, which looked obviously correct.
I would appreciate test reports from people who saw breakages
on this one.
- reflog from Shawn. Do people find this useful? I've enabled
reflog on "next" branch in my development repository to see
how useful it would be for myself a few days ago, and also in
a linux-2.6 repository I use for testing (I do not hack on
kernel myself).
Other topics in "next" includes:
- read/write-tree --prefix. This is remnant of now-vetoed
subproject support using "bind commit". I kept both of them
because they could be useful independent of "bind commit",
but I do not know how much. I think read-tree --prefix might
probably be more useful than write-tree --prefix, since the
latter can be writing out the whole tree and run rev-parse
$tree:/path/name to extract that part, but the former does
not have an easy equivalent (you could pipe ls-tree output to
sed and pipe that to update-cache --index-info, but that is
crumsy).
I'd like to do "gitlink" based subproject support but most
likely that needs to come after tree/index/directory walker.
- fetch-pack client-side hack. When your repository has more
roots than the repository you are fetching from, the common
commit discovery exchange between fetch-pack and upload-pack
ends up traversing down the ancestry chain of the history the
other end do not have. The hack in the "next" branch is to
give up the common commit discovery early on the client side,
which Ralf Baechle who originally reported the problem says
to fix the problem (<20060526154239.GA20839@linux-mips.org>);
but the proper fix involves a bit smarter upload-pack.
I've posted a hacky upload-pack patch:
<7vfyiwi4xl.fsf@assigned-by-dhcp.cox.net>
but I think it should really needs to be cleaned up properly.
Things that we might want to have in 1.4.0 but not even in "next"
yet include:
- p4 importer (Sean Estabrooks) -- are people interested?
- letting fetch-pack to ask for an arbitrary commit object the
user obtained out of band (Eric W Biederman) -- waiting for
updated patch. We would need a corresponding one-liner patch
to upload-pack when we do this.
- using ~/.gitrc to give a fall-back default when
$GIT_DIR/config does not have values.
- command aliases and possibly default arguments via the
configuration file.
^ permalink raw reply
* Re: [PATCH] git-svnimport: Improved detection of merges.
From: Eric Wong @ 2006-06-01 9:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Florian Forster
In-Reply-To: <7vlkshs618.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Florian Forster <octo@verplant.org> writes:
>
> > The regexes detecting merges (while still relying on the commit messages,
> > though) have been improved to catch saner (and hopefully more) messages. The
> > old regex was so generic that it often matched something else and missed the
> > actual merge-message.
>
> > Also, the regex given with the `-M' commandline-option is checked first:
> > Explicitely given regexes should be considered better than the builtin ones,
> > and should therefore be given a chance to match a message first.
>
> The latter part sounds immensely sane. The former I am not a
> good judge, since I do not interact with subversion repositories
> myself. Opinions from real svn users?
Sounds sane to me, but I've not seen the patch from Florian.
I've been toying around a bit with enhanced branch/merge-tracking
support in git-svn, too.
>
> BTW, did anybody received the latest "What's in git.git" I sent
> out about 20 minutes ago?
Nope, I haven't seen that nor Florian's patch (assuming it was sent to
the ml). Ah, I just saw (part #2) pop up.
--
Eric Wong
^ permalink raw reply
* Re: What's in git.git (part #2)
From: Junio C Hamano @ 2006-06-01 9:23 UTC (permalink / raw)
To: git
In-Reply-To: <7v64jli66m.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> It's been a while since the last feature release,...
So apparently somehow part #1 (the regular "master has these",
"next in addition has these" message I occasionally do) is not
liked by the mailing list. I wonder what's in it that makes it
dropped on the floor...
^ permalink raw reply
* What's in git.git (part #1-2)
From: Junio C Hamano @ 2006-06-01 9:27 UTC (permalink / raw)
To: git
(this one is about "next" only -- I am bisecting)
* The 'next' branch, in addition, has these.
- git-svnimport
Florian Forster:
git-svnimport: Improved detection of merges.
- read-tree/write-tree --prefix
Junio C Hamano:
read-tree: --prefix=<path>/ option.
write-tree: --prefix=<path>
read-tree: reorganize bind_merge code.
- format-patch
Junio C Hamano:
format-patch --signoff
- tree parser updates
Linus Torvalds:
Add raw tree buffer info to "struct tree"
Make "tree_entry" have a SHA1 instead of a union of object pointers
Switch "read_tree_recursive()" over to tree-walk functionality
Remove "tree->entries" tree-entry list from tree parser
Make "struct tree" contain the pointer to the tree buffer
Make "tree_entry" have a SHA1 instead of a union of object pointers
Switch "read_tree_recursive()" over to tree-walk functionality
builtin-read-tree.c: avoid tree_entry_list in prime_cache_tree_rec()
Remove "tree->entries" tree-entry list from tree parser
fsck-objects: avoid unnecessary tree_entry_list usage
Remove unused "zeropad" entry from tree_list_entry
Convert "mark_tree_uninteresting()" to raw tree walker
Convert fetch.c: process_tree() to raw tree walker
Remove last vestiges of generic tree_entry_list
tree_entry(): new tree-walking helper function
- fetch-pack into a repository with more root than the server
Junio C Hamano:
fetch-pack: give up after getting too many "ack continue"
- http-fetch fixes
Nick Hengeveld:
http: prevent segfault during curl handle reuse
Sean Estabrooks:
Remove possible segfault in http-fetch.
- reflog
Junio C Hamano:
fetch.c: do not pass uninitialized lock to unlock_ref().
Shawn Pearce:
Improve abstraction of ref lock/write.
Convert update-ref to use ref_lock API.
Log ref updates to logs/refs/<ref>
Support 'master@2 hours ago' syntax
Fix ref log parsing so it works properly.
General ref log reading improvements.
Added logs/ directory to repository layout.
Force writing ref if it doesn't exist.
Log ref updates made by fetch.
Change 'master@noon' syntax to 'master@{noon}'.
Correct force_write bug in refs.c
Change order of -m option to update-ref.
Include ref log detail in commit, reset, etc.
Create/delete branch ref logs.
Enable ref log creation in git checkout -b.
Verify git-commit provides a reflog message.
Test that git-branch -l works.
^ permalink raw reply
* What's on git.git "master" (1/2)
From: Junio C Hamano @ 2006-06-01 9:29 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement.
(this is only the first half of "master" -- I am bisecting)
- Misc Fixes and Enhancements
Dennis Stosberg:
git-clean fails on files beginning with a dash
Dmitry V. Levin:
execv_git_cmd: Fix stack buffer overflow.
git_exec_path, execv_git_cmd: ignore empty environment variables
Paul Mackerras:
Make git-diff-tree indicate when it flushes
Salikh Zakirov:
Fixed Cygwin CR-munging problem in mailsplit
Shawn Pearce:
Allow multiple -m options to git-commit.
- Tests and Documentation
Eric Wong:
t3300-funny-names: shell portability fixes
tests: Remove heredoc usage inside quotes
t5500-fetch-pack: remove local (bashism) usage.
t6000lib: workaround a possible dash bug
Horst von Brand:
Fix some documentation typoes
J. Bruce Fields:
documentation: mention gitk font adjustment in tutorial
documentation: add brief mention of cat-file to tutorial part I
Documentation: retitle the git-core tutorial
Documentation: fix a tutorial-2 typo
Shawn Pearce:
Remove unnecessary output from t3600-rm.
Improved pack format documentation.
^ permalink raw reply
* Re: What's in git.git (part #2)
From: Jakub Narebski @ 2006-06-01 9:31 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wu9i608.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>> It's been a while since the last feature release,...
>
> So apparently somehow part #1 (the regular "master has these",
> "next in addition has these" message I occasionally do) is not
> liked by the mailing list. I wonder what's in it that makes it
> dropped on the floor...
I had same problem (message not appearing on list), and as far as
I was able to analyse it was because message accidentally (via unclean
copy'n'paste) had some unusual characters.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] git-svnimport: Improved detection of merges.
From: Florian Forster @ 2006-06-01 9:36 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20060601092238.GB9333@hand.yhbt.net>
[-- Attachment #1.1: Type: text/plain, Size: 1178 bytes --]
Hi,
On Thu, Jun 01, 2006 at 02:22:39AM -0700, Eric Wong wrote:
> Nope, I haven't seen that nor Florian's patch (assuming it was sent to
> the ml). Ah, I just saw (part #2) pop up.
sorry, I'm new to the git development and didn't know that patches
should be sent to the ML. I've attached that patch I sent to Junio to
this mail.
Florian Forster <octo@verplant.org> writes:
> The regexes detecting merges (while still relying on the commit
> messages, though) have been improved to catch saner (and hopefully
> more) messages. The old regex was so generic that it often matched
> something else and missed the actual merge-message.
The assumption here is that merges are between branches or between a
branch and the trunk. The regexes therefore match things like
(parenthesis showing what is being used as the branch name if it
matches).
- `branch/(name)'
- `(trunk)'
- `(name) branch'
Prior to the patch `git-svnimport' would match the message
``Merging from branch/foo to branch/bar''
and return `from' as the branch name.
Regards,
Florian Forster
--
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
[-- Attachment #1.2: 0001-git-svnimport-Improved-detection-of-merges.txt --]
[-- Type: text/plain, Size: 1607 bytes --]
From nobody Mon Sep 17 00:00:00 2001
From: Florian Forster <octo@verplant.org>
Date: Wed, 31 May 2006 12:28:41 +0200
Subject: [PATCH] git-svnimport: Improved detection of merges.
The regexes detecting merges (while still relying on the commit messages,
though) have been improved to catch saner (and hopefully more) messages. The
old regex was so generic that it often matched something else and missed the
actual merge-message.
Also, the regex given with the `-M' commandline-option is checked first:
Explicitely given regexes should be considered better than the builtin ones,
and should therefore be given a chance to match a message first.
---
git-svnimport.perl | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
1075d5b0cd92dbb8dc77838b2da2d8190904b351
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 61f559f..38ac732 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -63,10 +63,17 @@ my $svn_dir = $ARGV[1];
our @mergerx = ();
if ($opt_m) {
- @mergerx = ( qr/\W(?:from|of|merge|merging|merged) (\w+)/i );
+ my $branch_esc = quotemeta ($branch_name);
+ my $trunk_esc = quotemeta ($trunk_name);
+ @mergerx =
+ (
+ qr!\b(?:merg(?:ed?|ing))\b.*?\b((?:(?<=$branch_esc/)[\w\.\-]+)|(?:$trunk_esc))\b!i,
+ qr!\b(?:from|of)\W+((?:(?<=$branch_esc/)[\w\.\-]+)|(?:$trunk_esc))\b!i,
+ qr!\b(?:from|of)\W+(?:the )?([\w\.\-]+)[-\s]branch\b!i
+ );
}
if ($opt_M) {
- push (@mergerx, qr/$opt_M/);
+ unshift (@mergerx, qr/$opt_M/);
}
# Absolutize filename now, since we will have chdir'ed by the time we
--
1.3.3
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] git-svnimport: Improved detection of merges.
From: Junio C Hamano @ 2006-06-01 9:58 UTC (permalink / raw)
To: Florian Forster; +Cc: git
In-Reply-To: <20060601093603.GY2315@verplant.org>
Florian Forster <octo@verplant.org> writes:
> On Thu, Jun 01, 2006 at 02:22:39AM -0700, Eric Wong wrote:
>> Nope, I haven't seen that nor Florian's patch (assuming it was sent to
>> the ml). Ah, I just saw (part #2) pop up.
>
> sorry, I'm new to the git development and didn't know that patches
> should be sent to the ML. I've attached that patch I sent to Junio to
> this mail.
Thanks for a resend.
The patch is already queued in "next", so svn people might want
to take a peek there.
^ permalink raw reply
* Re: What's in git.git (part #2)
From: Sean @ 2006-06-01 11:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64jli66m.fsf@assigned-by-dhcp.cox.net>
On Thu, 01 Jun 2006 02:19:45 -0700
Junio C Hamano <junkio@cox.net> wrote:
> - p4 importer (Sean Estabrooks) -- are people interested?
Junio,
There just won't be anywhere near the call for this as there is
for the cvs and svn importers. Even so, a few people have expressed
interest and it has been used by the Sourcemage folks with some success.
Would you consider carrying this in contrib just so it has a home?
Sean
^ permalink raw reply
* [PATCH] cg-commit -p tries to remove a non-existent file
From: Dennis Stosberg @ 2006-06-01 15:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
This produces an error message when the user aborts the commit:
$ cg init -m "Initial commit"
$ echo "some text" >file
$ cg add file
$ EDITOR=/bin/false cg commit -p
Log message unchanged or not specified
Abort or commit? [ac] a
rm: cannot remove `/tmp/gitci.zdAHil/patch2.diff': No such file or \
directory
Commit message not modified, commit aborted
---
cg-commit | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-commit b/cg-commit
index 4ec2b33..c636b1a 100755
--- a/cg-commit
+++ b/cg-commit
@@ -442,7 +442,7 @@ cp "$LOGMSG" "$LOGMSG2"
if tty -s; then
if [ "$editor" ] && ! editor $commitalways commit c; then
rm "$LOGMSG" "$LOGMSG2"
- [ "$review" ] && rm "$PATCH" "$PATCH2"
+ [ "$review" ] && rm "$PATCH"
echo "Commit message not modified, commit aborted" >&2
if [ "$merging" ]; then
cat >&2 <<__END__
--
1.3.3+git20060531-dest1
^ permalink raw reply related
* git reset --hard not removing some files
From: Martin Waitz @ 2006-06-01 16:00 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 855 bytes --]
hoi :)
I have the following problem:
nbg1l001:~/src/git > git branch
* master
next
origin
nbg1l001:~/src/git > git checkout -b test
nbg1l001:~/src/git > git status
# On branch refs/heads/test
nothing to commit
zsh: exit 1 git status
nbg1l001:~/src/git > git reset --hard v1.3.3
nbg1l001:~/src/git > git status
# On branch refs/heads/test
#
# Untracked files:
# (use "git add" to add to commit)
#
# git-quiltimport
# git-upload-tar
nothing to commit
zsh: exit 1 git status
nbg1l001:~/src/git > git reset --hard master
nbg1l001:~/src/git > git status
# On branch refs/heads/test
nothing to commit
zsh: exit 1 git status
nbg1l001:~/src/git > git --version
git version 1.3.3.g0825d
However, the complete test suite and especially t7101-reset.sh succeed.
Any ideas?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Sean @ 2006-06-01 16:13 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060601160052.GK14325@admingilde.org>
On Thu, 1 Jun 2006 18:00:52 +0200
Martin Waitz <tali@admingilde.org> wrote:
Removed your prompt just to make it a bit more readable:
> $ git branch
> * master
> next
> origin
>
> $ git checkout -b test
>
> $ git status
> # On branch refs/heads/test
> nothing to commit
The generated files "git-quiltimport" and "git-upload-tar" exist at
this point. They are both untracked files and aren't listed because
they have entries in the .gitignore file.
> $ git reset --hard v1.3.3
>
> $ git status
> # On branch refs/heads/test
> #
> # Untracked files:
> # (use "git add" to add to commit)
> #
> # git-quiltimport
> # git-upload-tar
> nothing to commit
Resetting to version 1.3.3 gets you an old version of the .gitignore
file which doesn't ignore these two untracked files. Reset --hard
doesn't remove them because it only deals with tracked files. Thus,
they show up in your status report.
> $ git reset --hard master
> $ git status
> # On branch refs/heads/test
> nothing to commit
Returning to the current version gets you an updated .gitignore and the
two files are no longer listed even though they still exist.
> $ git --version
> git version 1.3.3.g0825d
This is the expected behavior regardless of version.
Sean
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Linus Torvalds @ 2006-06-01 16:21 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060601160052.GK14325@admingilde.org>
On Thu, 1 Jun 2006, Martin Waitz wrote:
>
> I have the following problem:
It's not a problem, it's a feature.
> nbg1l001:~/src/git > git branch
> * master
> next
> origin
> nbg1l001:~/src/git > git checkout -b test
> nbg1l001:~/src/git > git status
> # On branch refs/heads/test
> nothing to commit
> zsh: exit 1 git status
> nbg1l001:~/src/git > git reset --hard v1.3.3
> nbg1l001:~/src/git > git status
> # On branch refs/heads/test
> #
> # Untracked files:
> # (use "git add" to add to commit)
> #
> # git-quiltimport
> # git-upload-tar
Those files were _never_ tracked.
What happened is that when you switched to an earlier version, you _also_
switched the ".gitignore" file to the earlier version, and that older
.gitignore file doesn't have those two (newer) binaries listed as being
ignored.
And "git reset" won't be deleting files it doesn't track (it had _better_
not touch them), even more so when it has been told to ignore them, so it
makes total sense to _not_ delete them when doing that reset.
Linus
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Jakub Narebski @ 2006-06-01 17:21 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP04B113F61282BAE465D7F0AE900@CEZ.ICE>
Sean wrote:
> On Thu, 1 Jun 2006 18:00:52 +0200
> Martin Waitz <tali@admingilde.org> wrote:
>
>> $ git reset --hard v1.3.3
>>
>> $ git status
>> # On branch refs/heads/test
>> #
>> # Untracked files:
>> # (use "git add" to add to commit)
>> #
>> # git-quiltimport
>> # git-upload-tar
>> nothing to commit
>
> Resetting to version 1.3.3 gets you an old version of the .gitignore
> file which doesn't ignore these two untracked files. Reset --hard
> doesn't remove them because it only deals with tracked files. Thus,
> they show up in your status report.
Do you think it is _frequently_ asked question, worth adding
to http://git.or.cz/gitwiki/GitFaq ?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox