* [PATCH] Allow abbreviations in the first refspec to be merged
From: Daniel Barkalow @ 2007-09-28 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The config item for a refspec side and the ref name that it matches
aren't necessarily character-for-character identical. We actually want
to merge a ref by default if: there is no per-branch config, it is the
found result of looking for the match for the first refspec, and the
first refspec is not a pattern. Beyond that, anything that
get_fetch_map() thinks matches is fine.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
This fixes the configuration you gave for me, and passes all the
usual tests.
builtin-fetch.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 2f639cc..ac68ff5 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -102,7 +102,7 @@ static struct ref *get_ref_map(struct transport *transport,
remote->fetch[i].dst[0])
*autotags = 1;
if (!i && !has_merge && ref_map &&
- !strcmp(remote->fetch[0].src, ref_map->name))
+ !remote->fetch[0].pattern)
ref_map->merge = 1;
}
if (has_merge)
--
1.5.3.2.1107.ge9eab8-dirty
^ permalink raw reply related
* A tour of git: the basics (and notes on some unfriendly messages)
From: Carl Worth @ 2007-09-28 23:07 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 3109 bytes --]
I recently "ported" the introductory chapter of Bryan O’Sullivan's
Distributed revision control with Mercurial[1] from mercurial to
git. The result is here:
A tour of git: the basics
http://cworth.org/hgbook-git/tour/
I did this as an attempt to demonstrate that git and mercurial are
fundamentally equally "easy to learn", and definitely not as an effort
to try to leech Bryan's hard work, (nor would I even want to encourage
that kind of thing). More of my rationale is available here:
Git is easy to learn
http://cworth.org/hgbook-git/
I have two reasons for sharing this with the list. First, I'd
appreciate any feedback that the knowledgable readers on this list
might have. If anything could be made more clear, or if I have factual
mistakes in the text, I'd definitely like to fix those. Please let me
know.
Second, the process of porting the document highlighted a few issues
in git that I think would be nice to fix. I only noticed fairly
cosmetic issues, but I included them as XXX comments in the text. I'll
share them here as well: (all of these are with git 1.5.3.2).
* Is "git help" actually a builtin thing or just a way to call out to
"man"? Does it work at all in Windows ports of git, for example?
(OK, so that one's just a question, not an issue it git)
* Would it make sense to put much smaller amounts of text into "git
help" than the entire man page? For example, maybe just the
description and the most common options or maybe an example? Maybe
do something like "git -v help" for more details? See my text for
more on this, or compare "git help init" to "hg help init" and "hg
-v help init".
* The output from a git-clone operating locally is really confusing:
$ git clone hello hello-clone
Initialized empty Git repository in /tmp/hello-clone/.git/
0 blocks
Empty? Didn't I just clone it? What does "0 blocks" mean?
* git-log by default displays "Date" that is the author date, but
also only uses committer date for options such as --since. This is
confusing.
* It would be nice if all short-format options, (like "git log -p"), were
also available in a long-format option, (like "git log --patch").
* There's a ton of extraneous output from git-fetch. I would love to
see it reduced to a single-line progress bar, (even if a
multiple-staged progress bar). I'm imagining a final line
something like:
Computing (100%) Transferring (100%)
But you can imagine more accurate words than those, (I'm not even
sure what all of the things mean that git-fetch is currently
reporting progress on).
Obviously some of these would be pretty easy, and I should jump into
the git implementation to try them out, but I've just been typing this
stuff as fast as I could, and I'm about to go campout in the rain and
hail now, (fun, fun!), so I wanted to get this out before I forgot
anything.
Thanks in advance for any of your time, attention, or feedback, (and
especially any patches!).
-Carl
[1] http://hgbook.red-bean.com/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] fetch/push: readd rsync support
From: Johannes Schindelin @ 2007-09-28 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vtzpeo5ar.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 28 Sep 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > diff --git a/transport.c b/transport.c
> > index 4f9cddc..c8eed95 100644
> > --- a/transport.c
> > +++ b/transport.c
> > @@ -6,6 +6,330 @@
> > ...
> > +static int direntry_cmp(const void *a, const void *b)
> > +{
> > + const struct dirent *d1 = a;
> > + const struct dirent *d2 = b;
> > +
> > + return strcmp(d1->d_name, d2->d_name);
> > +}
> > ...
> > +/*
> > + * path is assumed to point to a buffer of PATH_MAX bytes, and
> > + * path + name_offset is expected to point to "refs/".
> > + */
> > +
> > +static int read_loose_refs(struct strbuf *path, int name_offset,
> > + struct ref **tail)
> > +{
> > + DIR *dir = opendir(path->buf);
> > + struct dirent *de;
> > + struct {
> > + char **entries;
> > + int nr, alloc;
> > + } list;
> > ...
> > + while ((de = readdir(dir))) {
> > + if (de->d_name[0] == '.' && (de->d_name[1] == '\0' ||
> > + (de->d_name[1] == '.' &&
> > + de->d_name[2] == '\0')))
> > + continue;
> > + ALLOC_GROW(list.entries, list.nr + 1, list.alloc);
> > + list.entries[list.nr++] = xstrdup(de->d_name);
> > + }
> > + closedir(dir);
> > +
> > + /* sort the list */
> > +
> > + qsort(list.entries, list.nr, sizeof(*de), direntry_cmp);
>
> Hmmmph...?
Ouch. Sorry.
Will resend in a few minutes. (After reading the patch -- again)
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn eliminating master
From: Russ Brown @ 2007-09-28 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkaqo49n.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Russ Brown <pickscrape@gmail.com> writes:
>
>> So I've been using git-svn for a while, and just decided to try
>> publishing my repo via gitweb so I can experiment with showing others my
>> local branches before I dcommit them to the subversion repository (i.e.
>> allowing code review prior to commit).
>>
>> It's working pretty nicely: the only problem I have is the master
>> branch. I don't use master at all, and I'm willing to be that a lot of
>> other git-svn users don't either. I take all of my branches from either
>> trunk or one of the other upstream svn server branches.
>>
>> The problem is gitweb appears to show the master branch by default,
>> while I'd rather show trunk by default.
>
> I think gitweb shows wherever HEAD points at. Update the file
> on the server and see if it helps.
Nice tip. I've updated that now. I'll know if it's worked once trunk
gets committed to again: I've rebased master against it so both
currently point at the same commit.
--
Russ
^ permalink raw reply
* Re: git-cat-file "Not a valid object name"
From: Sean @ 2007-09-28 22:15 UTC (permalink / raw)
To: Reza Roboubi; +Cc: git
In-Reply-To: <46FD7AA5.2080007@earthdetails.com>
On Fri, 28 Sep 2007 15:05:25 -0700
Reza Roboubi <reza@earthdetails.com> wrote:
> git-cat-file -t 9b22b50f814b22224d6f838433f1e9cd36bfc2
>
>
> says: "Not a valid object name".
>
> So what is this thing in my .git:
> ../.git/objects/92/9b22b50f814b22224d6f838433f1e9cd36bfc2
Reza,
The first two digits of the sha1 appear before the final slash (/)..
Therefore the actual object name in the case you give is
929b22b50f814b22224d6f838433f1e9cd36bfc2. So the following command
should work:
$ git cat-file -t 929b22b5
Sean
^ permalink raw reply
* Re: [PATCH 1/2] Introduce remove_dir_recursively()
From: David Kastrup @ 2007-09-28 22:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0709281323300.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 28 Sep 2007, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > +int remove_dir_recursively(char *path, int len, int only_empty)
>> > +{
>> > ...
>> > + namlen = strlen(e->d_name);
>> > + if (len + namlen > PATH_MAX ||
>> > + !memcpy(path + len, e->d_name, namlen) ||
>> > + (path[len + namlen] = '\0') ||
>> > + lstat(path, &st))
>> > + ; /* fall thru */
>> > + else if (S_ISDIR(st.st_mode)) {
>> > + if (!remove_dir_recursively(path, len + namlen,
>> > + only_empty))
>> > + continue; /* happy */
>> > + } else if (!only_empty &&
>> > + len + namlen + 1 < PATH_MAX &&
>> > + !unlink(path))
>> > + continue; /* happy, too */
>> > +
>> > + /* path too long, stat fails, or non-directory still exists */
>> > + ret = -1;
>> > + break;
>>
>> Is it only me who finds the first if () condition way too
>> convoluted and needs to read three times to convince oneself
>> that it is doing a sane thing?
>>
>> Please, especially...
>>
>> * For $DEITY's sake, memcpy() returns pointer to dst which you
>> know is not NULL. so !memcpy() is always false here, which
>> might be _convenient_ for you and the compiler but not for
>> a human reader of the code who needs to blink twice wondering
>> if you meant !memcmp().
>>
>> * Same for (path[] = '\0'), wondering if it is misspelled
>> (path[] == '\0').
>
> Okay, will fix (with an evil goto).
Uh, C has a comma operator. And inverting the first condition makes
for a nicer flow, no goto.
namlen = strlen(e->d_name);
if (len + namlen <= PATH_MAX
&& (memcpy(path + len, e->d_name, namlen),
path[len + namlen] = '\0',
lstat(path, &st) == 0)
if (S_ISDIR(st.st_mode)) {
if (!remove_dir_recursively(path, len + namlen,
only_empty))
continue; /* happy */
} else if (!only_empty &&
len + namlen + 1 < PATH_MAX &&
!unlink(path))
continue; /* happy, too */
/* path too long, stat fails, or non-directory still exists */
ret = -1;
break;
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git-cat-file "Not a valid object name"
From: Linus Torvalds @ 2007-09-28 22:12 UTC (permalink / raw)
To: Reza Roboubi; +Cc: git
In-Reply-To: <46FD7AA5.2080007@earthdetails.com>
On Fri, 28 Sep 2007, Reza Roboubi wrote:
>
> git-cat-file -t 9b22b50f814b22224d6f838433f1e9cd36bfc2
>
> says: "Not a valid object name".
>
> So what is this thing in my .git:
> ../.git/objects/92/9b22b50f814b22224d6f838433f1e9cd36bfc2
The object name for that thing is 929b22b5... You need the two first hex
digits too (which are used as the fan-out in the object directory).
Linus
^ permalink raw reply
* git-cat-file "Not a valid object name"
From: Reza Roboubi @ 2007-09-28 22:05 UTC (permalink / raw)
To: git
git-cat-file -t 9b22b50f814b22224d6f838433f1e9cd36bfc2
says: "Not a valid object name".
So what is this thing in my .git:
../.git/objects/92/9b22b50f814b22224d6f838433f1e9cd36bfc2
Thanks in advance.
Reza.
^ permalink raw reply
* Re: git-svn eliminating master
From: Junio C Hamano @ 2007-09-28 21:43 UTC (permalink / raw)
To: Russ Brown; +Cc: git
In-Reply-To: <46FD5DAF.7030204@gmail.com>
Russ Brown <pickscrape@gmail.com> writes:
> So I've been using git-svn for a while, and just decided to try
> publishing my repo via gitweb so I can experiment with showing others my
> local branches before I dcommit them to the subversion repository (i.e.
> allowing code review prior to commit).
>
> It's working pretty nicely: the only problem I have is the master
> branch. I don't use master at all, and I'm willing to be that a lot of
> other git-svn users don't either. I take all of my branches from either
> trunk or one of the other upstream svn server branches.
>
> The problem is gitweb appears to show the master branch by default,
> while I'd rather show trunk by default.
I think gitweb shows wherever HEAD points at. Update the file
on the server and see if it helps.
^ permalink raw reply
* Re: [PATCH] Merge non-first refs that match first refspec
From: Daniel Barkalow @ 2007-09-28 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vps02o55q.fsf@gitster.siamese.dyndns.org>
On Fri, 28 Sep 2007, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Daniel Barkalow <barkalow@iabervon.org> writes:
> >
> >> Beats me; Junio, what's your test case?
> >
> > I can paste tomorrow (it is a clone of git.git at work). I do
> > not use .git/config but .git/remotes/origin and explicit four
> > separate Pull: lines and going over http.
>
> Here are the files. Note that I use traditional layout and
> always have 'master' checked out when I initiate 'git pull'.
>
> : xyzzy git.git/master; cat .git/config
> [core]
> logallrefupdates = true
>
> [diff]
> color = auto
>
> [showbranch]
> default = --topo-order
> default = master
> default = next
> default = pu
>
> [alias]
> co = checkout
> : xyzzy git.git/master; cat .git/remotes origin
> URL: http://repo.or.cz/r/alt-git.git/
> Pull: master:origin
> Pull: next:next
> Pull: +pu:pu
> Pull: maint:maint
> Pull: todo:todo
The strcmp fails because the config uses an abbreviation and the server
doesn't. Forget my first attempt, and try replacing the strcmp on line 105
with "!remote->fetch[0].pattern", which is what we're really checking,
anyway.
(If this is the first refspec we're on, and we don't have a per-branch
config, and we got a match, and the refspec isn't a pattern, merge it;
anything that matches according to get_fetch_map is a satisfactory match,
even if it doesn't look quite the same.)
I'll do up an actual patch after dinner if nobody beats me to it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Merge non-first refs that match first refspec
From: Junio C Hamano @ 2007-09-28 21:23 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vve9vp1zw.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>> Beats me; Junio, what's your test case?
>
> I can paste tomorrow (it is a clone of git.git at work). I do
> not use .git/config but .git/remotes/origin and explicit four
> separate Pull: lines and going over http.
Here are the files. Note that I use traditional layout and
always have 'master' checked out when I initiate 'git pull'.
: xyzzy git.git/master; cat .git/config
[core]
logallrefupdates = true
[diff]
color = auto
[showbranch]
default = --topo-order
default = master
default = next
default = pu
[alias]
co = checkout
: xyzzy git.git/master; cat .git/remotes origin
URL: http://repo.or.cz/r/alt-git.git/
Pull: master:origin
Pull: next:next
Pull: +pu:pu
Pull: maint:maint
Pull: todo:todo
: xyzzy git.git/master; git pull
Warning: No merge candidate found because value of config option
"branch.master.merge" does not match any remote branch
fetched.
No changes.
: xyzzy git.git/master; git version
git version 1.5.3.2.1060.gaf79f
: xyzzy git.git/master; exit
^ permalink raw reply
* Re: [PATCH 2/2] fetch/push: readd rsync support
From: Junio C Hamano @ 2007-09-28 21:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0709281629270.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/transport.c b/transport.c
> index 4f9cddc..c8eed95 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -6,6 +6,330 @@
> ...
> +static int direntry_cmp(const void *a, const void *b)
> +{
> + const struct dirent *d1 = a;
> + const struct dirent *d2 = b;
> +
> + return strcmp(d1->d_name, d2->d_name);
> +}
> ...
> +/*
> + * path is assumed to point to a buffer of PATH_MAX bytes, and
> + * path + name_offset is expected to point to "refs/".
> + */
> +
> +static int read_loose_refs(struct strbuf *path, int name_offset,
> + struct ref **tail)
> +{
> + DIR *dir = opendir(path->buf);
> + struct dirent *de;
> + struct {
> + char **entries;
> + int nr, alloc;
> + } list;
> ...
> + while ((de = readdir(dir))) {
> + if (de->d_name[0] == '.' && (de->d_name[1] == '\0' ||
> + (de->d_name[1] == '.' &&
> + de->d_name[2] == '\0')))
> + continue;
> + ALLOC_GROW(list.entries, list.nr + 1, list.alloc);
> + list.entries[list.nr++] = xstrdup(de->d_name);
> + }
> + closedir(dir);
> +
> + /* sort the list */
> +
> + qsort(list.entries, list.nr, sizeof(*de), direntry_cmp);
Hmmmph...?
^ permalink raw reply
* [PATCH] gitk: add check for required tcl version >= 8.4
From: Steffen Prohaska @ 2007-09-28 20:57 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
In-Reply-To: <915048.40970.qm@web38908.mail.mud.yahoo.com>
gitk requires tcl version >= 8.4 to work flawlessly. So let's
check the tcl version and quit if it's too low.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
gitk | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 300fdce..6ea6489 100755
--- a/gitk
+++ b/gitk
@@ -7,6 +7,11 @@ exec wish "$0" -- "$@"
# and distributed under the terms of the GNU General Public Licence,
# either version 2, or (at your option) any later version.
+if {[info tclversion] < 8.4} {
+ puts stderr "Sorry, gitk requires tcl version >= 8.4."
+ exit 1
+}
+
proc gitdir {} {
global env
if {[info exists env(GIT_DIR)]} {
--
1.5.3.2.111.g5166
^ permalink raw reply related
* git-svn eliminating master
From: Russ Brown @ 2007-09-28 20:01 UTC (permalink / raw)
To: git
So I've been using git-svn for a while, and just decided to try
publishing my repo via gitweb so I can experiment with showing others my
local branches before I dcommit them to the subversion repository (i.e.
allowing code review prior to commit).
It's working pretty nicely: the only problem I have is the master
branch. I don't use master at all, and I'm willing to be that a lot of
other git-svn users don't either. I take all of my branches from either
trunk or one of the other upstream svn server branches.
The problem is gitweb appears to show the master branch by default,
while I'd rather show trunk by default. Is it legal to just delete the
master branch, or failing that have it automatically follow trunk so I
don't have to rebase it every time I want to push? Personally I'd rather
delete it because it's not used at all in my case and will only lead to
confuse the other developers who decide to look at my repo.
I've tried deleting master in a test repo, and it seems to be fine. But
I don't know if there are any hidden surprised that might come back to
bite me later.
Thanks.
--
Russ
^ permalink raw reply
* Re: [EGIT PATCH] Won't append '/' to an empty repo relative path.
From: Robin Rosenberg @ 2007-09-28 19:15 UTC (permalink / raw)
To: Jing Xue; +Cc: git
In-Reply-To: <20070928043957.GA18592@falcon.digizenstudio.com>
fredag 28 september 2007 skrev Jing Xue:
>
> When the repo relative path is empty, the extra "/" causes all subsequent
> "startsWith" tests to fail.
>
Thank you.
Please cc me in the future.
--- robin
^ permalink raw reply
* Re: [PATCH] Add a --dateformat= option to git-for-each-ref
From: Jeff King @ 2007-09-28 18:47 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200709281516.05438.andyparkins@gmail.com>
On Fri, Sep 28, 2007 at 03:15:58PM +0100, Andy Parkins wrote:
> > like a sane way to implement these sorts of things (e.g.,
> > "%(objectsize:human)", "%(parent:1)", etc).
>
> I'd thought about doing it like that, but imagined that there would
> objections that it was overcomplicating git-for-each-ref. As you
> think that's acceptable, I'll do it.
Well, I'm not sure my opinion counts for much, but at least there are
now two of us. :)
> A patch series that implements both your requested changes to follow.
Patches 1/2 look fine to me (but I agree with the squash suggestion).
3/4 are not exactly what I had in mind, but I think are reasonable in
this case. Rather than treating it was ":format", I had imagined more of
a ":attribute1:attribute2" style, where some attributes may be
understood by all substitutions (e.g., the moral equivalent of shell's
":-" and ":+"), and some only by some substitutions (such as date
formats). And on top of that, these sorts of substitutions should be
unified with the --pretty=format machinery.
Of course, that is a much larger task and you probably just want to do
your date formatting and get your other work done. So I think your
implementation is reasonable, in that it accomplishes what you want in a
reasonable amount of code, and its syntax doesn't prevent moving towards
what I described above (since %(foo:bar:baz) is currently nonsensical,
we would be free to adapt its meaning later).
So in a very verbose way,
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: [PATCH 2/4] Use parse_date_format() in revisions.c to parse the --date parameter
From: Junio C Hamano @ 2007-09-28 18:11 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Johannes Schindelin
In-Reply-To: <200709281900.25536.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Friday 2007, September 28, Johannes Schindelin wrote:
>
>> Since this is really more like a code move, 1/4 and 2/4 should be
>> squashed.
>
> I have no problem with that.
>
> Junio: would you like a resend?
Sounds like a good plan.
^ permalink raw reply
* Re: [PATCH] alloc_ref(): allow for trailing NUL
From: Junio C Hamano @ 2007-09-28 18:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0709281711010.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 28 Sep 2007, Daniel Barkalow wrote:
>
>> On Fri, 28 Sep 2007, Johannes Schindelin wrote:
>>
>> > Further, I am quite sure that the same mistake will happen again, until we
>> > change the function to get the name length, not the number of bytes to
>> > allocate.
>>
>> I agree. But leaving the majority of cases using the old convention is
>> just confusing.
>
> Yeah, sorry, that patch was only half-cooked.
>
> If people agree with me, I'll redo the patch (fixing all calling sites,
> too).
I think that is probably a better solution.
^ permalink raw reply
* Re: [PATCH 2/4] Use parse_date_format() in revisions.c to parse the --date parameter
From: Andy Parkins @ 2007-09-28 18:00 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0709281622240.28395@racer.site>
On Friday 2007, September 28, Johannes Schindelin wrote:
> Since this is really more like a code move, 1/4 and 2/4 should be
> squashed.
I have no problem with that.
Junio: would you like a resend?
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* [PATCH] Don't checkout the full tree if avoidable
From: Steven Walter @ 2007-09-28 17:24 UTC (permalink / raw)
To: git; +Cc: Steven Walter
In most cases of branching, the tree is copied unmodified from the trunk
to the branch. When that is done, we can simply start with the parent's
index and apply the changes on the branch as usual.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
---
git-svn.perl | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 484b057..2ca2042 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1847,6 +1847,13 @@ sub find_parent_branch {
$gs->ra->gs_do_switch($r0, $rev, $gs,
$self->full_url, $ed)
or die "SVN connection failed somewhere...\n";
+ } elsif ($self->trees_match($new_url, $r0,
+ $self->full_url, $rev)) {
+ $self->tmp_index_do(sub {
+ command_noisy('read-tree', $parent);
+ });
+ $self->{last_commit} = $parent;
+ # Assume copy with no changes
} else {
print STDERR "Following parent with do_update\n";
$ed = SVN::Git::Fetcher->new($self);
@@ -1859,6 +1866,17 @@ sub find_parent_branch {
return undef;
}
+sub trees_match {
+ my ($self, $url1, $rev1, $url2, $rev2) = @_;
+
+ my $ret=1;
+ open(my $fh, "svn diff $url1\@$rev1 $url2\@$rev2 |");
+ $ret=0 if (<$fh>);
+ close($fh);
+
+ return $ret;
+}
+
sub do_fetch {
my ($self, $paths, $rev) = @_;
my $ed;
--
1.5.3.1
^ permalink raw reply related
* Re: git-svn and branches
From: Steven Walter @ 2007-09-28 17:19 UTC (permalink / raw)
To: Eric Wong; +Cc: git, stevenrwalter
In-Reply-To: <20070927072404.GB1782@hand.yhbt.net>
On Thu, Sep 27, 2007 at 12:24:04AM -0700, Eric Wong wrote:
> I believe your case handles where a branch is created directly from a
> trunk copy with no file modifications in the branch, but not when a
> branch is created and files are modified in the trunk (or branch) within
> the same revision. Is this what's happening?
>
> Additionally, I think this breaks when an entire trunk or branch is
> moved around because the original directory has moved or gone away:
>
> /trunk => /project-a/trunk
>
> Anyways, as Sam said, newer SVN (1.4.4+) has a working do_switch()
> function and that code path will never be hit at all.
I think you're right that my code would only handle a verbatim copy. I
made a few changes and I think I have something that is more generally
useful. Using a newer version of subversion isn't practical for me, as
this is a work situation where I don't have control of the workstations.
One criticism of the patch: the trees_match function probably needs to
be re-written. My SVN::Perl-foo is weak.
Patch to follow
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Tom Clarke @ 2007-09-28 17:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0709281751390.28395@racer.site>
On 9/28/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > +# Copyright (c) 2005 Linus Torvalds
>
> Really?
Well 90% of the file was copy and pasted from one of the other merge
strategies which was indeed written by Linus. So it seemed
appropriate. If that's not appropriate attribution I can remove :-).
-Tom
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Johannes Schindelin @ 2007-09-28 17:03 UTC (permalink / raw)
To: Tom Clarke; +Cc: gitster, git
In-Reply-To: <11909961212172-git-send-email-tom@u2i.com>
Hi,
On Fri, 28 Sep 2007, Tom Clarke wrote:
> diff --git a/git-merge-rebase.sh b/git-merge-rebase.sh
> new file mode 100755
> index 0000000..fc07331
> --- /dev/null
> +++ b/git-merge-rebase.sh
> @@ -0,0 +1,34 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2005 Linus Torvalds
Really?
> +# Copyright (c) 2007 Tom Clarke
> +#
> +# Resolve two trees with rebase
> +
> +# The first parameters up to -- are merge bases; the rest are heads.
> +bases= head= remotes= sep_seen=
> +for arg
> +do
> + case ",$sep_seen,$head,$arg," in
> + *,--,)
> + sep_seen=yes
> + ;;
> + ,yes,,*)
> + head=$arg
> + ;;
> + ,yes,*)
> + remotes="$remotes$arg "
> + ;;
> + *)
> + bases="$bases$arg "
> + ;;
> + esac
> +done
> +
> +# Give up if we are given two or more remotes -- not handling octopus.
> +case "$remotes" in
> +?*' '?*)
> + exit 2 ;;
> +esac
You can check that much earlier, no? IOW something like
while test $# != 0
do
case "$1" in --) break ;; esac
shift
done
test $# = 3 || die "merge stragey rebase needs exactly one ref"
git rebase "$3"
(It's not like you need the variables...) Hmm?
> +git rebase $remotes || exit 2
> diff --git a/git-merge.sh b/git-merge.sh
> index 6c513dc..ea3cc16 100755
> --- a/git-merge.sh
> +++ b/git-merge.sh
> @@ -81,11 +82,18 @@ finish () {
> echo "No merge message -- not updating HEAD"
> ;;
> *)
> - git update-ref -m "$rlogm" HEAD "$1" "$head" || exit 1
> + case " $wt_strategy " in
> + *" $no_update_ref "*)
> + ;;
> + *)
> + git update-ref -m "$rlogm" HEAD "$1" "$head" || exit 1
> + ;;
> + esac
You may want to warn earlier, if a message was supplied with -s rebase, or
even error out.
> diff --git a/t/t3031-merge-rebase.sh b/t/t3031-merge-rebase.sh
> new file mode 100755
> index 0000000..8e3641d
> --- /dev/null
> +++ b/t/t3031-merge-rebase.sh
> @@ -0,0 +1,34 @@
> +#!/bin/sh
> +
> +test_description='merge-rebase backend test'
> +
> +. ./test-lib.sh
> +
> +test_expect_success 'merging using rebase does not create merge commit' '
> + echo hello >a &&
> + git add a &&
> + test_tick && git commit -m initial &&
> +
> + git checkout -b branch &&
> + echo hello >b &&
> + git add b &&
> + test_tick && git commit -m onbranch &&
> +
> + git checkout master &&
> + echo update >a &&
> + git add a &&
> + test_tick && git commit -m update &&
I like to have something like this in a "test_expect_success setup" part,
and then have the meat of the test in its own test case.
But hey, you're the author, it's for you to decide.
Thanks,
Dscho
^ permalink raw reply
* [PATCH] Adding rebase merge strategy
From: Tom Clarke @ 2007-09-28 16:15 UTC (permalink / raw)
To: gitster; +Cc: git, Tom Clarke
In addition to adding git-merge-rebase.sh, git-merge.sh is modified
to handle the rebase strategy specially and avoids running update-ref
as rebase won't generate a merge commit.
Signed-off-by: Tom Clarke <tom@u2i.com>
---
Re-submitting this patch as we were in a pre-release freeze last time I submitted
.gitignore | 1 +
Documentation/merge-strategies.txt | 6 ++++++
Makefile | 2 +-
git-merge-rebase.sh | 34 ++++++++++++++++++++++++++++++++++
git-merge.sh | 14 +++++++++++---
t/t3031-merge-rebase.sh | 34 ++++++++++++++++++++++++++++++++++
6 files changed, 87 insertions(+), 4 deletions(-)
create mode 100755 git-merge-rebase.sh
create mode 100755 t/t3031-merge-rebase.sh
diff --git a/.gitignore b/.gitignore
index e0b91be..fe5cdc4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -73,6 +73,7 @@ git-merge-tree
git-merge-octopus
git-merge-one-file
git-merge-ours
+git-merge-rebase
git-merge-recursive
git-merge-resolve
git-merge-stupid
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 7df0266..dff1909 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -33,3 +33,9 @@ ours::
merge is always the current branch head. It is meant to
be used to supersede old development history of side
branches.
+
+rebase::
+ This rebases the current branch based on a single head.
+ Commits are rewritten as with git-rebase. This doesn't
+ produce a merge. The procedure for dealing with conflicts
+ is the same as with git-rebase.
diff --git a/Makefile b/Makefile
index 8db4dbe..e6d3812 100644
--- a/Makefile
+++ b/Makefile
@@ -215,7 +215,7 @@ SCRIPT_SH = \
git-sh-setup.sh \
git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
- git-merge-resolve.sh git-merge-ours.sh \
+ git-merge-resolve.sh git-merge-ours.sh git-merge-rebase.sh \
git-lost-found.sh git-quiltimport.sh git-submodule.sh \
git-filter-branch.sh \
git-stash.sh
diff --git a/git-merge-rebase.sh b/git-merge-rebase.sh
new file mode 100755
index 0000000..fc07331
--- /dev/null
+++ b/git-merge-rebase.sh
@@ -0,0 +1,34 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Linus Torvalds
+# Copyright (c) 2007 Tom Clarke
+#
+# Resolve two trees with rebase
+
+# The first parameters up to -- are merge bases; the rest are heads.
+bases= head= remotes= sep_seen=
+for arg
+do
+ case ",$sep_seen,$head,$arg," in
+ *,--,)
+ sep_seen=yes
+ ;;
+ ,yes,,*)
+ head=$arg
+ ;;
+ ,yes,*)
+ remotes="$remotes$arg "
+ ;;
+ *)
+ bases="$bases$arg "
+ ;;
+ esac
+done
+
+# Give up if we are given two or more remotes -- not handling octopus.
+case "$remotes" in
+?*' '?*)
+ exit 2 ;;
+esac
+
+git rebase $remotes || exit 2
diff --git a/git-merge.sh b/git-merge.sh
index 6c513dc..ea3cc16 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -16,11 +16,12 @@ test -z "$(git ls-files -u)" ||
LF='
'
-all_strategies='recur recursive octopus resolve stupid ours subtree'
+all_strategies='recur recursive octopus resolve stupid ours subtree rebase'
default_twohead_strategies='recursive'
default_octopus_strategies='octopus'
no_fast_forward_strategies='subtree ours'
-no_trivial_strategies='recursive recur subtree ours'
+no_trivial_strategies='recursive recur subtree ours rebase'
+no_update_ref='rebase'
use_strategies=
allow_fast_forward=t
@@ -81,11 +82,18 @@ finish () {
echo "No merge message -- not updating HEAD"
;;
*)
- git update-ref -m "$rlogm" HEAD "$1" "$head" || exit 1
+ case " $wt_strategy " in
+ *" $no_update_ref "*)
+ ;;
+ *)
+ git update-ref -m "$rlogm" HEAD "$1" "$head" || exit 1
+ ;;
+ esac
;;
esac
;;
esac
+
case "$1" in
'')
;;
diff --git a/t/t3031-merge-rebase.sh b/t/t3031-merge-rebase.sh
new file mode 100755
index 0000000..8e3641d
--- /dev/null
+++ b/t/t3031-merge-rebase.sh
@@ -0,0 +1,34 @@
+#!/bin/sh
+
+test_description='merge-rebase backend test'
+
+. ./test-lib.sh
+
+test_expect_success 'merging using rebase does not create merge commit' '
+ echo hello >a &&
+ git add a &&
+ test_tick && git commit -m initial &&
+
+ git checkout -b branch &&
+ echo hello >b &&
+ git add b &&
+ test_tick && git commit -m onbranch &&
+
+ git checkout master &&
+ echo update >a &&
+ git add a &&
+ test_tick && git commit -m update &&
+
+ git checkout branch &&
+ git merge -s rebase master >expect &&
+
+ ( git log --pretty=oneline ) >actual &&
+ (
+ echo "4db7a5a013e67aa623d1fd294e8d46e89b3ace8f onbranch"
+ echo "893371811dbd13e85c098b72d1ab42bcfd24c2db update"
+ echo "0e960b10429bf3f1e168ee2cc7d531ac7c622580 initial"
+ ) >expected &&
+ git diff -w -u expected actual
+'
+
+test_done
--
1.5.3.rc7.3.g850f-dirty
^ permalink raw reply related
* Re: [PATCH] alloc_ref(): allow for trailing NUL
From: Johannes Schindelin @ 2007-09-28 16:11 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709281138270.5926@iabervon.org>
Hi,
On Fri, 28 Sep 2007, Daniel Barkalow wrote:
> On Fri, 28 Sep 2007, Johannes Schindelin wrote:
>
> > Hi,
> >
> > On Fri, 28 Sep 2007, Junio C Hamano wrote:
> >
> > > Daniel Barkalow <barkalow@iabervon.org> writes:
> > >
> > > > On Fri, 28 Sep 2007, Johannes Schindelin wrote:
> > > >
> > > >> The parameter name "namelen" suggests that you pass the equivalent of
> > > >> strlen() to the function alloc_ref(). However, this function did not
> > > >> allocate enough space to put a NUL after the name.
> > > >>
> > > >> Since struct ref does not have any member to describe the length of the
> > > >> string, this just does not make sense.
> > > >>
> > > >> So make space for the NUL.
> > > >
> > > > Good point, but shouldn't you then fix call sites that use strlen(name) +
> > > > 1?
> > >
> > > Good point.
> > >
> > > I audited "git grep -A2 -B4 -e alloc_ref next master" output,
> > > and it appears almost everybody knows alloc_ref() wants the
> > > caller to count the terminating NUL.
> > >
> > > There however are a few gotchas.
> > >
> > > * There is one overallocation in connect.c, which would not
> > > hurt but is wasteful;
> > >
> > > * next:transport.c has alloc_ref(strlen(e->name)) which is a
> > > no-no;
> > >
> > > Discarding Johannes's patch, the following would fix it.
> >
> > But should the signature of alloc_ref() not be changed, then, to read
> >
> > struct ref *alloc_ref(unsigned name_alloc);
> >
> > Hm?
> >
> > Further, I am quite sure that the same mistake will happen again, until we
> > change the function to get the name length, not the number of bytes to
> > allocate.
>
> I agree. But leaving the majority of cases using the old convention is
> just confusing.
Yeah, sorry, that patch was only half-cooked.
If people agree with me, I'll redo the patch (fixing all calling sites,
too).
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox