* Re: Rebase & Trailing Whitespace
From: Jeff King @ 2011-09-01 2:31 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi0rY4kRR4rvEdFhzzTgfhUczHMX=H5_9+o5aHnv4vTadw@mail.gmail.com>
On Wed, Aug 31, 2011 at 04:55:03PM -0700, Hilco Wijbenga wrote:
> hilco@centaur ~/workspaces/project-next project-next (next $)$ git rebase master
> [...]
> <stdin>:721810: trailing whitespace.
> [...]
> Note the trailing whitespace warnings. How do I find out which file(s)
> generated these warnings? Would it be possible to add the file name
> causing the warnings to be output? By default? (Using --verbose
> doesn't seem to make any difference where the whitespace warnings are
> concerned.)
You can see any whitespace warnings in your repository (and in which
commit they were introduced) by doing something like:
git log --oneline --check
The "--check" option is just another diff output format, so you use it
with "log" or "diff". For example, if you want to see just whitespace
problems that still exist in your current tree, you can diff against the
empty tree with --check, like:
git diff --check 4b825dc642cb6eb9a060e54bf8d69288fbee4904
where "4b825dc..." is the well-known sha1 of an empty tree[1].
> Furthermore, why didn't I get these or similar warnings when I
> committed/pushed that particular commit ("Use static WAR for SWF files
> and assets.")? I did just find "[core] whitespace = trailing-space"
> which I will add to my .gitconfig, I suppose. So I guess what I really
> mean to ask is, why do rebase (and merge?) behave differently from
> commit?
Because these warnings are only triggered by default when applying
patches. And the idea of rebase is to apply patches from one place to
another. I thought we squelched whitespace warnings for rebase these
days (since they are somewhat pointless; you are moving around your own
commits, not applying commits from some other contributor), but maybe I
am misremembering. Or maybe you have an older version of git. Which
version are you using?
If you want to enforce whitespace checks during commit or push, you can
do so with a hook. The sample "pre-commit" hook, for example, uses "diff
--check" for just this purpose. See "git help hooks" for more
information.
-Peff
[1] If you don't remember the empty tree sha1, you can always derive it
with:
git hash-object -t tree /dev/null
^ permalink raw reply
* [PATCH 2/2] remote: "rename o foo" should not rename ref "origin/bar"
From: Martin von Zweigbergk @ 2011-09-01 1:50 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Martin von Zweigbergk
In-Reply-To: <1314841843-19868-1-git-send-email-martin.von.zweigbergk@gmail.com>
When renaming a remote called 'o' using 'git remote rename o foo', git
should also rename any remote-tracking branches for the remote. This
does happen, but any remote-tracking branches starting with
'refs/remotes/o', such as 'refs/remotes/origin/bar', will also be
renamed (to 'refs/remotes/foorigin/bar' in this case).
Fix it by simply matching one more character, up to the slash
following the remote name.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
builtin/remote.c | 2 +-
t/t5505-remote.sh | 10 ++++++++++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index c1763ed..127cff4 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -570,7 +570,7 @@ static int read_remote_branches(const char *refname,
unsigned char orig_sha1[20];
const char *symref;
- strbuf_addf(&buf, "refs/remotes/%s", rename->old);
+ strbuf_addf(&buf, "refs/remotes/%s/", rename->old);
if (!prefixcmp(refname, buf.buf)) {
item = string_list_append(rename->remote_branches, xstrdup(refname));
symref = resolve_ref(refname, orig_sha1, 1, &flag);
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 7b6f443..57b584c 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -651,6 +651,16 @@ test_expect_success 'rename a remote with name part of fetch spec' '
'
+test_expect_success 'rename a remote with name prefix of other remote' '
+
+ git clone one four.three &&
+ (cd four.three &&
+ git remote add o git://example.com/repo.git &&
+ git remote rename o upstream &&
+ test "$(git rev-parse origin/master)" = "$(git rev-parse master)")
+
+'
+
cat > remotes_origin << EOF
URL: $(pwd)/one
Push: refs/heads/master:refs/heads/upstream
--
1.7.6.51.g07e0e
^ permalink raw reply related
* [PATCH 1/2] remote: write correct fetch spec when renaming remote 'remote'
From: Martin von Zweigbergk @ 2011-09-01 1:50 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Martin von Zweigbergk
When renaming a remote whose name is contained in a configured fetch
refspec for that remote, we currently replace the first occurrence of
the remote name in the refspec. This is correct in most cases, but
breaks if the remote name occurs in the fetch refspec before the
expected place. For example, we currently change
[remote "remote"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/remote/*
into
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/origins/remote/*
Reduce the risk of changing incorrect sections of the refspec by
requiring the string to be matched to have leading and trailing
slashes, i.e. match "/<name>/" instead of just "<name>".
We could have required even a leading ":refs/remotes/", but that would
mean that we would limit the types of refspecs we could help the user
update.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
builtin/remote.c | 12 ++++++++----
t/t5505-remote.sh | 20 ++++++++++++++++++++
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index f2a9c26..c1763ed 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -621,7 +621,8 @@ static int mv(int argc, const char **argv)
OPT_END()
};
struct remote *oldremote, *newremote;
- struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT, buf3 = STRBUF_INIT;
+ struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT, buf3 = STRBUF_INIT,
+ old_remote_context = STRBUF_INIT;
struct string_list remote_branches = STRING_LIST_INIT_NODUP;
struct rename_info rename;
int i;
@@ -659,15 +660,18 @@ static int mv(int argc, const char **argv)
strbuf_addf(&buf, "remote.%s.fetch", rename.new);
if (git_config_set_multivar(buf.buf, NULL, NULL, 1))
return error("Could not remove config section '%s'", buf.buf);
+ strbuf_addf(&old_remote_context, "/%s/", rename.old);
for (i = 0; i < oldremote->fetch_refspec_nr; i++) {
char *ptr;
strbuf_reset(&buf2);
strbuf_addstr(&buf2, oldremote->fetch_refspec[i]);
- ptr = strstr(buf2.buf, rename.old);
+ ptr = strstr(buf2.buf, old_remote_context.buf);
if (ptr)
- strbuf_splice(&buf2, ptr-buf2.buf, strlen(rename.old),
- rename.new, strlen(rename.new));
+ strbuf_splice(&buf2,
+ ptr-buf2.buf + 1,
+ strlen(rename.old), rename.new,
+ strlen(rename.new));
if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
return error("Could not append '%s'", buf.buf);
}
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 0d0222e..7b6f443 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -631,6 +631,26 @@ test_expect_success 'rename a remote' '
'
+test_expect_success 'rename a remote with non-default fetch refspec' '
+
+ git clone one four.one &&
+ (cd four.one &&
+ git config remote.origin.fetch +refs/heads/*:refs/heads/origin/* &&
+ git remote rename origin upstream &&
+ test "$(git config remote.upstream.fetch)" = "+refs/heads/*:refs/heads/upstream/*")
+
+'
+
+test_expect_success 'rename a remote with name part of fetch spec' '
+
+ git clone one four.two &&
+ (cd four.two &&
+ git remote rename origin remote &&
+ git remote rename remote upstream &&
+ test "$(git config remote.upstream.fetch)" = "+refs/heads/*:refs/remotes/upstream/*")
+
+'
+
cat > remotes_origin << EOF
URL: $(pwd)/one
Push: refs/heads/master:refs/heads/upstream
--
1.7.6.51.g07e0e
^ permalink raw reply related
* Re: [PATCH] Teach dcommit --mergeinfo to handle multiple lines
From: Eric Wong @ 2011-09-01 1:37 UTC (permalink / raw)
To: Sam Vilain; +Cc: Bryan Jacobs, git
In-Reply-To: <4E5EB26D.8030004@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> Ok, well I guess this is a useful intermediate feature then. Feel
> free to copy in any further changes you may come up with in this
> area to me, if you decide to do that.
Shall I consider this an Acked-by?
--
Eric Wong
^ permalink raw reply
* Re: [PATCH v6] Add a remote helper to interact with mediawiki (fetch & push)
From: Junio C Hamano @ 2011-09-01 0:24 UTC (permalink / raw)
To: Matthieu Moy
Cc: Sverre Rabbelier, git, gitster, Jeremie Nikaes, Arnaud Lacurie,
Claire Fousse, David Amouyal
In-Reply-To: <vpq7h5tbia6.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Here:
>
> + for my $refspec (@refsspecs) {
> + unless ($refspec =~ m/^(\+?)([^:]*):([^:]*)$/) {
> + die("Invalid refspec for push. Expected <src>:<dst> or +<src>:<dst>");
> + }
> + my ($force, $local, $remote) = ($1 eq "+", $2, $3);
>
> At this point, $force is a boolean saying whether there were a +, and
> $local and $remote are as you can guess.
It may be slightly more Perl-ish to hoist the "0-or-1" outside the group
and rely on $1 becoming undef, like this:
my ($force, $local, $remote) = $refspec =~ /^(\+)?([^:]*):([^:]*)$/
or die(...);
Even though it largely is a matter of taste, I think.
^ permalink raw reply
* Rebase & Trailing Whitespace
From: Hilco Wijbenga @ 2011-08-31 23:55 UTC (permalink / raw)
To: Git Users
Hi all,
Please have a look at the output below.
hilco@centaur ~/workspaces/project-next project-next (next $)$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: ...
Applying: ...
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: ...
:
Applying: Use static WAR for SWF files and assets.
Using index info to reconstruct a base tree...
<stdin>:721810: trailing whitespace.
Canadian word list.
<stdin>:721859: trailing whitespace.
SFX N y ication y
<stdin>:721860: trailing whitespace.
SFX N 0 en [^ey]
<stdin>:721869: trailing whitespace.
SFX H 0 th [^y]
<stdin>:721876: trailing whitespace.
SFX G 0 ing [^e]
warning: squelched 1067 whitespace errors
warning: 1072 lines add whitespace errors.
Falling back to patching base and 3-way merge...
:
Failed to merge in the changes.
Patch failed at 0008 Use static WAR for SWF files and assets.
Note the trailing whitespace warnings. How do I find out which file(s)
generated these warnings? Would it be possible to add the file name
causing the warnings to be output? By default? (Using --verbose
doesn't seem to make any difference where the whitespace warnings are
concerned.)
Furthermore, why didn't I get these or similar warnings when I
committed/pushed that particular commit ("Use static WAR for SWF files
and assets.")? I did just find "[core] whitespace = trailing-space"
which I will add to my .gitconfig, I suppose. So I guess what I really
mean to ask is, why do rebase (and merge?) behave differently from
commit?
Cheers,
Hilco
^ permalink raw reply
* Re: [PATCH] for-each-ref: add split message parts to %(contents:*).
From: Jeff King @ 2011-08-31 23:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michał Górny, git, Michael J Gruber
In-Reply-To: <7vy5y9xkd0.fsf@alter.siamese.dyndns.org>
On Wed, Aug 31, 2011 at 03:54:35PM -0700, Junio C Hamano wrote:
> > +The complete message in a commit and tag object is `contents`.
> > +Its first line is `contents:subject`, the remaining lines
> > +are `contents:body` and the optional GPG signature
> > +is `contents:signature`.
>
> To match the parsing of commit objects, I would prefer to see "subject" to
> mean "the first paragraph" (usually the first line alone but that is
> purely from convention), but that probably is a separate topic.
Good idea. I suspect pretty.c:format_subject can be reused here.
> To paraphrase the last part of your sentence, if a tag is merely annotated
> and not signed, contents:signature would be empty (I am just making sure
> that I am reading the description correctly).
That is what I checked for in the tests I added.
> > while (*buf == '\n')
> > buf++; /* skip blank between subject and body */
> > *body = buf;
> > + *signature = buf + parse_signature(buf, strlen(buf));
>
> If there is no signature, parse_signature() would return (size_t) 0, no?
No, it returns strlen(buf) in that case, making signature the empty
string. It would perhaps better be called find_signature_in_body(),
since it is actually about parsing the rest of the body until we get to
the signature.
-Peff
^ permalink raw reply
* Re: [PATCH] for-each-ref: add split message parts to %(contents:*).
From: Junio C Hamano @ 2011-08-31 22:54 UTC (permalink / raw)
To: Michał Górny; +Cc: git, Jeff King, Michael J Gruber
In-Reply-To: <1314781909-19252-1-git-send-email-mgorny@gentoo.org>
Michał Górny <mgorny@gentoo.org> writes:
> Now %(contents:subject) contains the message subject, %(contents:body)
> main body part and %(contents:signature) GPG signature.
> ---
Please sign-off when submitting the final round of this patch.
> +The complete message in a commit and tag object is `contents`.
> +Its first line is `contents:subject`, the remaining lines
> +are `contents:body` and the optional GPG signature
> +is `contents:signature`.
To match the parsing of commit objects, I would prefer to see "subject" to
mean "the first paragraph" (usually the first line alone but that is
purely from convention), but that probably is a separate topic.
To paraphrase the last part of your sentence, if a tag is merely annotated
and not signed, contents:signature would be empty (I am just making sure
that I am reading the description correctly).
Is it possible to get %(contents) with a combination of these three new
variants, or does the calling script need to see if each part is empty and
decide where to place newlines? IOW, a naïve attempt:
--format='%(contents:subject)\n%(contents:body)\n%(contents:signature)'
is not equivalent to
--format='%(contents)'
right?
> @@ -478,18 +481,20 @@ static void find_subpos(const char *buf, unsigned long sz, const char **sub, con
> buf = strchr(buf, '\n');
> if (!buf) {
> *body = "";
> + *signature = *body;
> return; /* no body */
> }
> while (*buf == '\n')
> buf++; /* skip blank between subject and body */
> *body = buf;
> + *signature = buf + parse_signature(buf, strlen(buf));
If there is no signature, parse_signature() would return (size_t) 0, no?
I suspect it may be easier for the caller if *signature pointed at the
terminating NUL at the end of the whole thing in such a case. Otherwise,
the caller that finds the buf and the signature points at the same address
cannot tell if the object was a signed tag with no message
$ git tag -s -m "" empty-tag
or if it was an annotated but not signed tag.
Or better yet, you may even want to stuff NULL there if there is no signature
so that it is absolutely clear for the caller which case it is.
> static void grab_sub_body_contents(struct atom_value *val, int deref, struct object *obj, void *buf, unsigned long sz)
> {
> int i;
> - const char *subpos = NULL, *bodypos = NULL;
> + const char *subpos = NULL, *bodypos = NULL, *sigpos = NULL;
>
> for (i = 0; i < used_atom_cnt; i++) {
> const char *name = used_atom[i];
> @@ -500,19 +505,26 @@ static void grab_sub_body_contents(struct atom_value *val, int deref, struct obj
> name++;
> if (strcmp(name, "subject") &&
> strcmp(name, "body") &&
> - strcmp(name, "contents"))
> + strcmp(name, "contents") &&
> + strcmp(name, "contents:subject") &&
> + strcmp(name, "contents:body") &&
> + strcmp(name, "contents:signature"))
> continue;
> if (!subpos)
> - find_subpos(buf, sz, &subpos, &bodypos);
> + find_subpos(buf, sz, &subpos, &bodypos, &sigpos);
> if (!subpos)
> return;
>
> - if (!strcmp(name, "subject"))
> + if (!strcmp(name, "subject") || !strcmp(name, "contents:subject"))
> v->s = copy_line(subpos);
> else if (!strcmp(name, "body"))
> v->s = xstrdup(bodypos);
> else if (!strcmp(name, "contents"))
> v->s = xstrdup(subpos);
> + else if (!strcmp(name, "contents:body"))
> + v->s = xstrndup(bodypos, sigpos - bodypos);
> + else if (!strcmp(name, "contents:signature"))
> + v->s = xstrdup(sigpos);
Again, how does this work for an annotated but not signed tag?
^ permalink raw reply
* Re: [spf:guess,iffy] Re: [spf:guess] Re: [PATCH] Teach dcommit --mergeinfo to handle multiple lines
From: Sam Vilain @ 2011-08-31 22:15 UTC (permalink / raw)
To: Bryan Jacobs; +Cc: Eric Wong, git
In-Reply-To: <20110831165109.0ca6373f@robyn.woti.com>
On 8/31/11 1:51 PM, Bryan Jacobs wrote:
> ...I didn't create the original --mergeinfo interface. I was very
> surprised when I first discovered it clobbered instead of integrating
> - it's easy to nuke your SVN repo's ability to merge with one careless
> use of this option. See below.
>> But so long as it makes something previously impossible possible, it
>> is a good change - my feeling is that it should be called something
>> like --mergeinfo-raw or --mergeinfo-set to leave room for a possible
>> --mergeinfo-add which knows how the lists work and adds them (which
>> is what I'd expect a plain --mergeinfo switch to do).
> I completely agree. I think there should at least be a
> --mergeinfo-update which fetches the current revision, merges that with
> the provided set using the branch paths as keys (and compacts using
> svn:mergeinfo rules), and sets the property to the final result.
>
> I actually do this currently with external scripts, which is why I
> wanted to make --mergeinfo capable of delivering my final payload. It
> would make my life easier if all the logic were part of git-svn instead.
>
> That said, this change is really small. That change would be larger.
> So I submitted this first.
>
Ok, well I guess this is a useful intermediate feature then. Feel free
to copy in any further changes you may come up with in this area to me,
if you decide to do that.
Cheers,
Sam
^ permalink raw reply
* [ANNOUNCE] unofficial git-announce mailing list
From: Julian Phillips @ 2011-08-31 21:20 UTC (permalink / raw)
To: Git Mailing List
Good evening all,
As some people may be aware, some time ago now I created some RSS feeds
by filtering the Git mailing lists (http://gitrss.q42.co.uk/) to make
the task of following only certain types of information from this list
easier.
I have now extended this tool to include a git-announce mailing list.
This is an announce-only style list that receives all the same mails
that are pulled into the announce RSS feed.
The website for the list can be found here:
http://lists.q42.co.uk/listinfo/git-announce
It's a mailman hosted list, so the normal email based interaction works
too. So you can also subscribe by mailing:
git-announce-subscribe@q42.co.uk
I primarily created this for my own use - but since it is something
that has been asked about in the past, I though I would share it.
Comments/suggestions welcome (though I don't promise to change anything
;).
Please also let me know if you have any objections to the existence of
this list (I do promise to respond to these).
--
Julian
^ permalink raw reply
* Re: [PATCH] grep: Fix race condition in delta_base_cache
From: Nicolas Morey-Chaisemartin @ 2011-08-31 19:13 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110831015936.GB2519@sigill.intra.peff.net>
On 08/31/2011 03:59 AM, Jeff King wrote:
> I notice there are some other code paths that end up in xmalloc without
> locking, too (e.g., load_file, and some strbuf_* calls). Don't those
> need locking, too, as malloc may try to release packfile memory?
>
> builtin/pack-objects.c dealt with this already by setting a new
> "try_to_free" routine that locks[1], which we should also do. It
> probably comes up less frequently, because it only happens when we're
> under memory pressure.
>
> -Peff
>
> [1] Actually, it looks like the "try_to_free" routine starts as nothing,
> and then add_packed_git sets it lazily to try_to_free_pack_memory.
> But what builtin/pack-objects tries to do is overwrite that with a
> version of try_to_free_pack_memory that does locking. So it's
> possible that we would not have read any packed objects while
> setting up the threads, and add_packed_git will overwrite our
> careful, locking version of try_to_free_pack_memory.
>
> I _think_ pack-objects is probably OK, because it will have already
> done the complete "counting objects" phase, which would look in any
> packs. But it may be harder for grep.
>
After some more looking around, I'd say the best way to fix this is provide a lock to the try_to_free function from sha1_file
and provide access to this lock for pack-objects and grep to replace respectively the read_mutex and read_sha1_mutex.
So we can simplify the problem by having a single lock to avoid all the cache/free issues (and reusable elsewhere if needed in the future), whether it's shared through direct access or API (I'm not sure what's git policy about that).
And this way, there is no need to duplicate what pack-objects is achieving and it gives some peace of mind about the fact that the try_to _free function won't be overwritten in our backs.
Nicolas Morey-Chaisemartin
^ permalink raw reply
* [GSoC 2011] libgit2: final report
From: Carlos Martín Nieto @ 2011-08-31 21:00 UTC (permalink / raw)
To: libgit2, git
[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]
Hello all,
GSoC is finished and I'll send the proof of work to Google shortly. Many
thanks to everyone who helped me along the way.
So? How did it go? Unfortunately I wasn't able to do everything that was
in the (quite optimistic) original plan as there were some changes and
additions that had to be done to the library in order to support the new
features (the code movement in preparation for the indexer
(git-index-pack) being the clearest example of this. The code has been
merged upstream and you want to look at examples of use, you can take a
look at my libgit2-utils repo[0] where you can find a functional
implementation of git-fetch (git-clone would be about 20 lines more, I
just never got around to writing it).
[0] https://github.com/carlosmn/libgit2-utils
Let me give you a few highlights of what new features were added to the
library:
_Remotes_
A remote (struct git_remote) is the (library) user's interface to the
communications with external repositories. When read from the
configuration file, it will parse the refspecs and take them into
consideration when fetching. With the most recent changes, you can also
create one on the fly with an URL. The remote will create an instance of
a transport and will take care of the lower-levels.
_Transports_
The logic exists inside the transports. Currently only the fetch part
of the plain git protocol is supported, but the architecture is
extensible. The code would have to live in the library, but adding
support for plug-ins, as it were, would be an easy task.
_pkt-line_
The code for parsing and creating these lines is its own namespace, so
that it can be used for other transports. It supports a kind of
streaming parsing, as it will return the appropriate error code if the
buffer isn't large enough for the line.
_Indexer_
This is what libgit2 has instead of git-index-pack. It's much slower
than the git implementation because it hasn't been optimised yet as it
uses the normal pack access methods. Currently the only user would be a
git-fetch implementation and that is still fast enough so it's not that
high a priority.
As a result of this work, the memory window and pack access code has
been made much more generic.
I plan to continue working on this project. The next steps are push
(which has quite a few prerequisites, not least pack generation) and
smart HTTP support. The addition of the new backend should help make
code more generic. After that, SSH support should be a matter of
wrapping the existing code up.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [spf:guess] Re: [PATCH] Teach dcommit --mergeinfo to handle multiple lines
From: Sam Vilain @ 2011-08-31 20:43 UTC (permalink / raw)
To: Eric Wong; +Cc: Bryan Jacobs, git
In-Reply-To: <20110831202131.GA27307@dcvr.yhbt.net>
On 8/31/11 1:21 PM, Eric Wong wrote:
>> --- a/Documentation/git-svn.txt
>> +++ b/Documentation/git-svn.txt
>> @@ -211,8 +211,9 @@ discouraged.
>> Add the given merge information during the dcommit
>> (e.g. `--mergeinfo="/branches/foo:1-10"`). All svn server versions can
>> store this information (as a property), and svn clients starting from
>> - version 1.5 can make use of it. 'git svn' currently does not use it
>> - and does not set it automatically.
>> + version 1.5 can make use of it. To specify merge information from multiple
>> + branches, use a single space character between the branches
>> + (`--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"`)
This interface seems regrettably stupid. Like, do I need to consider
the existing revisions that are already listed in the property? Is it
really impossible to derive the changes that were merged and generate
the list automatically?
But so long as it makes something previously impossible possible, it is
a good change - my feeling is that it should be called something like
--mergeinfo-raw or --mergeinfo-set to leave room for a possible
--mergeinfo-add which knows how the lists work and adds them (which is
what I'd expect a plain --mergeinfo switch to do).
Sam
^ permalink raw reply
* Re: [spf:guess] Re: [PATCH] Teach dcommit --mergeinfo to handle multiple lines
From: Bryan Jacobs @ 2011-08-31 20:51 UTC (permalink / raw)
To: Sam Vilain; +Cc: Eric Wong, git
In-Reply-To: <4E5E9CFB.4060600@vilain.net>
On Wed, 31 Aug 2011 13:43:39 -0700
Sam Vilain <sam@vilain.net> wrote:
> On 8/31/11 1:21 PM, Eric Wong wrote:
> >> --- a/Documentation/git-svn.txt
> >> +++ b/Documentation/git-svn.txt
> >> @@ -211,8 +211,9 @@ discouraged.
> >> Add the given merge information during the dcommit
> >> (e.g. `--mergeinfo="/branches/foo:1-10"`). All svn
> >> server versions can store this information (as a property), and
> >> svn clients starting from
> >> - version 1.5 can make use of it. 'git svn' currently does
> >> not use it
> >> - and does not set it automatically.
> >> + version 1.5 can make use of it. To specify merge
> >> information from multiple
> >> + branches, use a single space character between the
> >> branches
> >> + (`--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"`)
>
> This interface seems regrettably stupid. Like, do I need to consider
> the existing revisions that are already listed in the property? Is
> it really impossible to derive the changes that were merged and
> generate the list automatically?
Nope, it's possible. I didn't create the original --mergeinfo
interface. I was very surprised when I first discovered it clobbered
instead of integrating - it's easy to nuke your SVN repo's ability to
merge with one careless use of this option. See below.
> But so long as it makes something previously impossible possible, it
> is a good change - my feeling is that it should be called something
> like --mergeinfo-raw or --mergeinfo-set to leave room for a possible
> --mergeinfo-add which knows how the lists work and adds them (which
> is what I'd expect a plain --mergeinfo switch to do).
I completely agree. I think there should at least be a
--mergeinfo-update which fetches the current revision, merges that with
the provided set using the branch paths as keys (and compacts using
svn:mergeinfo rules), and sets the property to the final result.
I actually do this currently with external scripts, which is why I
wanted to make --mergeinfo capable of delivering my final payload. It
would make my life easier if all the logic were part of git-svn instead.
That said, this change is really small. That change would be larger.
So I submitted this first.
> Sam
^ permalink raw reply
* Re: [PATCH] Teach dcommit --mergeinfo to handle multiple lines
From: Eric Wong @ 2011-08-31 20:21 UTC (permalink / raw)
To: Bryan Jacobs; +Cc: git, Sam Vilain
In-Reply-To: <20110831124839.69c70486@robyn.woti.com>
Subsystem commit subjects should be prefixed with the approriate
subsystem (e.g. "git-svn: Teach dcommit --mergeinfo ..."
Bryan Jacobs <bjacobs@woti.com> wrote:
> "svn dcommit --mergeinfo" replaces the svn:mergeinfo property in an
> upstream SVN repository with the given text. The svn:mergeinfo
> property may contain commits originating on multiple branches,
> separated by newlines.
>
> Cause space characters in the mergeinfo to be replaced by newlines,
> allowing a user to create history representing multiple branches being
> merged into one.
>
> Update the corresponding documentation and add a test for the new
> functionality.
>
> Signed-off-by: Bryan Jacobs <bjacobs@woti.com>
This looks reasonable, Cc:-ing Sam since he handled the mergeinfo stuff.
After all this time, I still have no experience using SVN mergeinfo
anywhere :x
> ---
> Documentation/git-svn.txt | 5 +++--
> git-svn.perl | 3 +++
> t/t9158-git-svn-mergeinfo.sh | 13 +++++++++++++
> 3 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index ed5eca1..3ed28df 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -211,8 +211,9 @@ discouraged.
> Add the given merge information during the dcommit
> (e.g. `--mergeinfo="/branches/foo:1-10"`). All svn server versions can
> store this information (as a property), and svn clients starting from
> - version 1.5 can make use of it. 'git svn' currently does not use it
> - and does not set it automatically.
> + version 1.5 can make use of it. To specify merge information from multiple
> + branches, use a single space character between the branches
> + (`--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"`)
>
> 'branch'::
> Create a branch in the SVN repository.
> diff --git a/git-svn.perl b/git-svn.perl
> index 89f83fd..3ee26a2 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -548,6 +548,9 @@ sub cmd_dcommit {
> }
> my $expect_url = $url;
> Git::SVN::remove_username($expect_url);
> + if (defined($_merge_info)) {
> + $_merge_info =~ tr{ }{\n};
> + }
> while (1) {
> my $d = shift @$linear_refs or last;
> unless (defined $last_rev) {
> diff --git a/t/t9158-git-svn-mergeinfo.sh b/t/t9158-git-svn-mergeinfo.sh
> index 3ab4390..8c9539e 100755
> --- a/t/t9158-git-svn-mergeinfo.sh
> +++ b/t/t9158-git-svn-mergeinfo.sh
> @@ -38,4 +38,17 @@ test_expect_success 'verify svn:mergeinfo' '
> test "$mergeinfo" = "/branches/foo:1-10"
> '
>
> +test_expect_success 'change svn:mergeinfo multiline' '
> + touch baz &&
> + git add baz &&
> + git commit -m "baz" &&
> + git svn dcommit --mergeinfo="/branches/bar:1-10 /branches/other:3-5,8,10-11"
> +'
> +
> +test_expect_success 'verify svn:mergeinfo multiline' '
> + mergeinfo=$(svn_cmd propget svn:mergeinfo "$svnrepo"/trunk)
> + test "$mergeinfo" = "/branches/bar:1-10
> +/branches/other:3-5,8,10-11"
> +'
> +
> test_done
> --
> 1.7.6
^ permalink raw reply
* Re: [PATCH] stash: Don't paginate by default with list command
From: Ingo Brückl @ 2011-08-31 18:18 UTC (permalink / raw)
To: git
In-Reply-To: <4e5d2ac6.64676448.bm000@wupperonline.de>
I wrote on Tue, 30 Aug 2011 20:24:04 +0200:
> Ben Walton wrote on Tue, 30 Aug 2011 13:43:46 -0400:
>> Excerpts from Ingo Brückl's message of Tue Aug 30 13:21:18 -0400 2011:
>>> The output of "stash list" is such that piping into a pager
>>> normally isn't necessary but annoying, so disable it by default.
>> If you $PAGER is less and you use the default LESS environment value
>> FRXS, this shouldn't be annoying at all. Are you using either a
>> different pager or a different value for LESS?
> For some reason I have '-c' in LESS which must be convenient for a case
> I currently don't remember.
Now I know again. '-c' is within my LESS because I like small "git diff"
output printed on an erased terminal. I think it is easier to overview that
way.
With "git stash list" I'd like it the other way, because that output is
just a simple list (and usually very small in my case).
Ingo
^ permalink raw reply
* [PATCH] (short) documentation for the testgit remote helper
From: Matthieu Moy @ 2011-08-31 18:14 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1314809222-30528-1-git-send-email-Matthieu.Moy@imag.fr>
While it's not a command meant to be used by actual users (hence, not
mentionned in git(1)), this command is a very precious help for
remote-helpers authors.
The best place for such technical doc is the source code, but users may
not find it without a link in a manpage.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
While we're improving the docs, this is one more thing that would have
saved me some time ...
Documentation/git-remote-helpers.txt | 2 ++
Documentation/git-remote-testgit.txt | 30 ++++++++++++++++++++++++++++++
git-remote-testgit.py | 14 ++++++++++++++
3 files changed, 46 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-remote-testgit.txt
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 526fc6a..674797c 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -362,6 +362,8 @@ SEE ALSO
--------
linkgit:git-remote[1]
+linkgit:git-remote-testgit[1]
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/Documentation/git-remote-testgit.txt b/Documentation/git-remote-testgit.txt
new file mode 100644
index 0000000..2a67d45
--- /dev/null
+++ b/Documentation/git-remote-testgit.txt
@@ -0,0 +1,30 @@
+git-remote-testgit(1)
+=====================
+
+NAME
+----
+git-remote-testgit - Example remote-helper
+
+
+SYNOPSIS
+--------
+[verse]
+git clone testgit::<source-repo> [<destination>]
+
+DESCRIPTION
+-----------
+
+This command is a simple remote-helper, that is used both as a
+testcase for the remote-helper functionality, and as an example to
+show remote-helper authors one possible implementation.
+
+The best way to learn more is to read the comments and source code in
+'git-remote-testgit.py'.
+
+SEE ALSO
+--------
+linkgit:git-remote-helpers[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-remote-testgit.py b/git-remote-testgit.py
index e9c832b..91d4409 100644
--- a/git-remote-testgit.py
+++ b/git-remote-testgit.py
@@ -1,5 +1,19 @@
#!/usr/bin/env python
+# This command is a simple remote-helper, that is used both as a
+# testcase for the remote-helper functionality, and as an example to
+# show remote-helper authors one possible implementation.
+#
+# This is a Git <-> Git importer/exporter, that simply uses git
+# fast-import and git fast-export to consume and produce fast-import
+# streams.
+#
+# To understand better the way things work, one can set the variable
+# "static int debug" in transport-helper.c to 1, and/or the "DEBUG"
+# variable in git_remote_helpers/util.py to True, and try various
+# commands.
+
+
# hashlib is only available in python >= 2.5
try:
import hashlib
--
1.7.7.rc0.75.g56f27
^ permalink raw reply related
* Re: need to create new repository initially seeded with several branches
From: Johannes Sixt @ 2011-08-31 17:48 UTC (permalink / raw)
To: in-git-vger; +Cc: ryan@iridiumsuite.com, git
In-Reply-To: <201108311540.p7VFen5S015756@no.baka.org>
Am 31.08.2011 17:40, schrieb in-git-vger@baka.org:
> # Cause git to delete all files in the internal index
> git read-tree --reset -i 4b825dc642cb6eb9a060e54bf8d69288fbee4904
> # Cause git to delete all files in the working directory
> git clean -dfx
> ...
> The only "magic" is the read-tree/git-clean stuff. The 4b82… value is
> the SHA of an empty tree. It could be replaced by...
... a simple
git rm -rf .
-- Hannes
^ permalink raw reply
* Re: [PATCH v6] Add a remote helper to interact with mediawiki (fetch & push)
From: Matthieu Moy @ 2011-08-31 17:30 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: git, gitster, Jeremie Nikaes, Arnaud Lacurie, Claire Fousse,
David Amouyal
In-Reply-To: <CAGdFq_gu=SyjUnUS1bcjPrcPPtKVt+UjDBvBmZqosk+OuDFDHw@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> 2011/8/31 Matthieu Moy <Matthieu.Moy@imag.fr>:
>> So, after understanding better how import works, here's an updated
>> patch that gets rid of the hacky workaround to terminate and send the
>> "done" command at the right time.
>
> So what do you think of the way the protocol works now? Do you agree
> that (modulo lacking docs) it is better than previously?
I'm not sure I understood exactly how it was before, but the current
protocol seems indeed at least reasonable:
* It's possible to specify a batch of imports, so the remote-helper has
freedom to optimize the import of multiple refs.
* A batch of import is clearly delimited, both on stdin and stdout, so
it is possible to alternate import batches and other commands.
I still have a few complaints, because even with a better doc, I still
found the debugging a bit hard. To make it easy for remote-helpers
authors, I think the transport-helper could have an explicit "done"
command, so that the command stream look like
import foo
import bar
\n
done
instead of
import foo
import bar
\n
\n
and to let the remote-helper's code be like
while($cmd = <read command>) {
if ($cmd eq "command1") {
do something;
} elsif ($cmd eq "command2") {
something else;
} elsif ($cmd eq "done") {
exit properly;
}
}
I'm not sure whether changing this now is worth the trouble though.
I'd have appreciated if the transport-helper had given me an explicit
error message when writting to a broken pipe too. I finally got it with
gdb, but lost some time trying to understand (especially painfull since
there was a race condition between the remote-helper termination and git
writting to it, so the bug wasn't reproducible).
>> Actually, push had the same problem but it just went unnoticed (the
>> remote has just one branch, so it's silly to try to push multiple
>> branches at the same time ...). This version handles push more
>> cleanly, giving accurate error message in cases like
>>
>> git push origin :master
>> git push origin foo bar master
>>
>> or perhaps more commonly
>>
>> git push --all
>>
>> in a repository with branches other than master.
>
> My perl skills are minimal, but I'm curious how/where you implemented
> this?
Here:
+ for my $refspec (@refsspecs) {
+ unless ($refspec =~ m/^(\+?)([^:]*):([^:]*)$/) {
+ die("Invalid refspec for push. Expected <src>:<dst> or +<src>:<dst>");
+ }
+ my ($force, $local, $remote) = ($1 eq "+", $2, $3);
At this point, $force is a boolean saying whether there were a +, and
$local and $remote are as you can guess.
+ if ($force) {
+ print STDERR "Warning: forced push not allowed on a MediaWiki.\n";
+ }
+ if ($local eq "") {
+ print STDERR "Cannot delete remote branch on a MediaWiki\n";
+ print STDOUT "error $remote cannot delete\n";
print STDERR goes to the console (i.e. to the user), and print STDOUT
goes to the Git's transport-helper.
+ next;
+ }
+ if ($remote ne "refs/heads/master") {
+ print STDERR "Only push to the branch 'master' is supported on a MediaWiki\n";
+ print STDOUT "error $remote only master allowed\n";
+ next;
+ }
> Is this something that we can port to remote-testgit to document the
> CPB on handling such things?
CPB = ?
Actually, my case is very particular, since the only thing to do with
branches is to make sure the user doesn't use them. In remote-testgit,
there are actually branches.
And testgit use the undocumented "export" feature, which does not seem
to support branch deletion:
git push origin :branch2
fatal: remote-helpers do not support ref deletion
moy@bauges:/tmp/clone$ Traceback (most recent call last):
File "/home/moy/local/usr-squeeze/libexec/git-core/git-remote-testgit", line 252, in <module>
sys.exit(main(sys.argv))
File "/home/moy/local/usr-squeeze/libexec/git-core/git-remote-testgit", line 249, in main
more = read_one_line(repo)
File "/home/moy/local/usr-squeeze/libexec/git-core/git-remote-testgit", line 215, in read_one_line
sys.stdout.flush()
IOError: [Errno 32] Broken pipe
(This comes from
transport-helper.c:750: die("remote-helpers do not support ref deletion");
called before starting the exporter)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: need to create new repository initially seeded with several branches
From: Ryan Wexler @ 2011-08-31 17:09 UTC (permalink / raw)
To: Brandon Casey; +Cc: Jeff King, git
In-Reply-To: <XWAITZ7y0RejBGQezy-miO4ykUsgbNWA0mNtHRto22msjs3PP6WSZlN-pPueaz0duxAP6dCio3ZH2lna0K_g79NKdL0q7sJbzjj8sEKicYM@cipher.nrlssc.navy.mil>
Ok thanks for all the replies guys. I thought I was SOL. I will
start playing with it here and let you know how it goes.
On Wed, Aug 31, 2011 at 10:01 AM, Brandon Casey
<brandon.casey.ctr@nrlssc.navy.mil> wrote:
> On 08/31/2011 11:54 AM, Jeff King wrote:
>> On Wed, Aug 31, 2011 at 11:14:48AM -0500, Brandon Casey wrote:
>>
>>> git checkout -b devel && # make a new branch named "devel"
>>> # which has the same state as the
>>> # currently checked out branch: "master"
>>> # i.e. devel and master point to the
>>> # same tip commit.
>>> rm -rf * && # remove the files in the working dir
>>> cp -a $devel_dir/* . && # cp devel source code to working dir
>>> git add -A . && # add new/removed files to the index
>>> # to be committed on next 'git commit'
>>> git commit
>>> # use editor to give descriptive commit message
>>>
>>> Repeat for your topic branch based off of devel.
>>
>> I am probably just going to confuse the original poster more, but here
>> is how I would do it. It's slightly more efficient, as it doesn't
>> involve removing and copying files for the intermediate states:
>>
>> # make a repo and switch to it
>> git init repo && cd repo
>>
>> # and now add everything from the "master" version, and
>> # make a commit out of it
>> GIT_WORK_TREE=/path/to/master git add -A
>> git commit
>>
>> # now make the devel branch and do the same
>> git checkout -b devel
>> GIT_WORK_TREE=/path/to/devel git add -A
>> git commit
>>
>> # and then check out the result in the working tree of
>> # your newly created repo
>> git checkout -f
>
> Better.
>
> -Brandon
>
^ permalink raw reply
* Re: [PATCH v6] Add a remote helper to interact with mediawiki (fetch & push)
From: Sverre Rabbelier @ 2011-08-31 17:03 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, gitster, Jeremie Nikaes, Arnaud Lacurie, Claire Fousse,
David Amouyal, Matthieu Moy, Sylvain Boulmé
In-Reply-To: <1314809708-8177-1-git-send-email-Matthieu.Moy@imag.fr>
Heya,
2011/8/31 Matthieu Moy <Matthieu.Moy@imag.fr>:
> So, after understanding better how import works, here's an updated
> patch that gets rid of the hacky workaround to terminate and send the
> "done" command at the right time.
So what do you think of the way the protocol works now? Do you agree
that (modulo lacking docs) it is better than previously?
> Actually, push had the same problem but it just went unnoticed (the
> remote has just one branch, so it's silly to try to push multiple
> branches at the same time ...). This version handles push more
> cleanly, giving accurate error message in cases like
>
> git push origin :master
> git push origin foo bar master
>
> or perhaps more commonly
>
> git push --all
>
> in a repository with branches other than master.
My perl skills are minimal, but I'm curious how/where you implemented
this? Is this something that we can port to remote-testgit to document
the CPB on handling such things?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] xdiff/xprepare: initialise xdlclassifier_t cf in xdl_prepare_env()
From: Junio C Hamano @ 2011-08-31 17:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tay Ray Chuan, Git Mailing List
In-Reply-To: <7vei01zf89.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Tay Ray Chuan <rctay89@gmail.com> writes:
>
>> Ensure that the xdl_free_classifier() call on xdlclassifier_t cf is safe
>> even if xdl_init_classifier() isn't called. This may occur in the case
>> where diff is run with --histogram and a call to, say, xdl_prepare_ctx()
>> fails.
>>
>> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
>
> Thanks. Did you find this by code inspection?
>
>> xdiff/xprepare.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/xdiff/xprepare.c b/xdiff/xprepare.c
>> index 620fc9a..4323596 100644
>> --- a/xdiff/xprepare.c
>> +++ b/xdiff/xprepare.c
>> @@ -239,6 +239,9 @@ int xdl_prepare_env(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
>> long enl1, enl2, sample;
>> xdlclassifier_t cf;
>>
>> + cf.rchash = NULL;
>> + cf.ncha.head = NULL;
>
> Would it be more appropriate to use memcpy(&cf, 0, sizeof(cf)) instead, so
Oops, I meant memset(), obviously.
> that we wouldn't have to worry about a similar breakage when a new field
> is added to "struct xdlclassifier" later?
^ permalink raw reply
* Re: [PATCH] xdiff/xprepare: initialise xdlclassifier_t cf in xdl_prepare_env()
From: Junio C Hamano @ 2011-08-31 17:02 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git Mailing List
In-Reply-To: <1314766126-5060-1-git-send-email-rctay89@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> Ensure that the xdl_free_classifier() call on xdlclassifier_t cf is safe
> even if xdl_init_classifier() isn't called. This may occur in the case
> where diff is run with --histogram and a call to, say, xdl_prepare_ctx()
> fails.
>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Thanks. Did you find this by code inspection?
> xdiff/xprepare.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/xdiff/xprepare.c b/xdiff/xprepare.c
> index 620fc9a..4323596 100644
> --- a/xdiff/xprepare.c
> +++ b/xdiff/xprepare.c
> @@ -239,6 +239,9 @@ int xdl_prepare_env(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
> long enl1, enl2, sample;
> xdlclassifier_t cf;
>
> + cf.rchash = NULL;
> + cf.ncha.head = NULL;
Would it be more appropriate to use memcpy(&cf, 0, sizeof(cf)) instead, so
that we wouldn't have to worry about a similar breakage when a new field
is added to "struct xdlclassifier" later?
^ permalink raw reply
* Re: git-svn and mergeinfo
From: Sverre Rabbelier @ 2011-08-31 17:01 UTC (permalink / raw)
To: Bryan Jacobs; +Cc: Eric Wong, git
In-Reply-To: <20110831125557.56ccffe2@robyn.woti.com>
Heya,
On Wed, Aug 31, 2011 at 18:55, Bryan Jacobs <bjacobs@woti.com> wrote:
> Finally, I am uncertain why the git-svn-info lines are
> stored in commit bodies instead of as notes
Hysterical raisins mostly. I think git-notes predates git-svn by
several years :). I suspect that if someone would wade through the
mess that is git-svn.perl and tought it to (optionally) use git-notes
instead of commit messages that would be highly welcome.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: need to create new repository initially seeded with several branches
From: Brandon Casey @ 2011-08-31 17:01 UTC (permalink / raw)
To: Jeff King; +Cc: ryan@iridiumsuite.com, git
In-Reply-To: <20110831165405.GB4356@sigill.intra.peff.net>
On 08/31/2011 11:54 AM, Jeff King wrote:
> On Wed, Aug 31, 2011 at 11:14:48AM -0500, Brandon Casey wrote:
>
>> git checkout -b devel && # make a new branch named "devel"
>> # which has the same state as the
>> # currently checked out branch: "master"
>> # i.e. devel and master point to the
>> # same tip commit.
>> rm -rf * && # remove the files in the working dir
>> cp -a $devel_dir/* . && # cp devel source code to working dir
>> git add -A . && # add new/removed files to the index
>> # to be committed on next 'git commit'
>> git commit
>> # use editor to give descriptive commit message
>>
>> Repeat for your topic branch based off of devel.
>
> I am probably just going to confuse the original poster more, but here
> is how I would do it. It's slightly more efficient, as it doesn't
> involve removing and copying files for the intermediate states:
>
> # make a repo and switch to it
> git init repo && cd repo
>
> # and now add everything from the "master" version, and
> # make a commit out of it
> GIT_WORK_TREE=/path/to/master git add -A
> git commit
>
> # now make the devel branch and do the same
> git checkout -b devel
> GIT_WORK_TREE=/path/to/devel git add -A
> git commit
>
> # and then check out the result in the working tree of
> # your newly created repo
> git checkout -f
Better.
-Brandon
^ 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