* [PATCH] [RFC] send-email: honor --suppress-from --signed-off-cc
From: Uwe Kleine-König @ 2007-07-10 17:02 UTC (permalink / raw)
To: git; +Cc: Uwe Kleine-König
In-Reply-To: <11840869641759-git-send-email-ukleinek@informatik.uni-freiburg.de>
From: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
---
Not sure, if this is how it should be. Maybe we need another flag?
Best regards
Uwe
git-send-email.perl | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 8b3d450..a03153b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -641,9 +641,11 @@ foreach my $t (@files) {
if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {
my $c = $2;
chomp $c;
- push @cc, $c;
- printf("(sob) Adding cc: %s from line '%s'\n",
- $c, $_) unless $quiet;
+ if (!$suppress_from or $c eq $from) {
+ push @cc, $c;
+ printf("(sob) Adding cc: %s from line '%s'\n",
+ $c, $_) unless $quiet;
+ }
}
}
}
--
1.5.3.rc0.823.gdedbf
^ permalink raw reply related
* Re: how to combine two clones in a collection
From: Linus Torvalds @ 2007-07-10 17:05 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20070710062104.GA22603@piper.oerlikon.madduck.net>
On Tue, 10 Jul 2007, martin f krafft wrote:
>
> also sprach Linus Torvalds <torvalds@linux-foundation.org> [2007.07.10.0435 +0200]:
> > I really _think_ that what you want is to just use separate
> > branches, if I understand correctly. That makes it really easy to
> > just have both lines of development (both the "trunk" and your
> > "debian" one) in one git repository.
>
> It does mean, however, that I duplicate the upstream into my repo,
> and thus into the published repo at git.debian.org, because I cannot
> just publish a single branch ('debian') in such a way that people
> could clone it and still be able to build the package against
> upstream (which they'd have to obtain for themselves), right?
Well, I think you have two cases:
- the git users
These would get both branches (including all of the upstream, of
course), but that's ok, since git will share all the common objects
*anyway*, so there is no "duplication". You can have a hundred
branches, and they won't use one whit more memory of bandwidth (apart
from the branch refs themselves being sent over, of course), and only
the actual *differences* between branches will take up space.
- the non-git users
Here, I don't really know how the debian package management is supposed
to work, but since they obviously aren't using git, they must be using
something else. A tar-ball or just a series of patches? Both would be
trivial to implement as just an "export" from your git tree. Or you'd
export the "debian" branch as a separate SVN repo (I've not used the
"export back into a SVN" thing, so I don't know how well that works).
In particular, if all your "debian-specific" stuff is almost all in the
"debian" subdirectory, then you can trivially make a tar-file by just
using
git archive --prefix=upstream- HEAD debian > upstream-debian.tar
and git will literally generate the tar-file of that directory for you.
> The way I tend to think about a pair of branches is that one depends
> on the other, or rather, one stems from the other.
.. and no, that's not really how git works from a technical angle: in the
the git model, all branches are technically 100% equal, and no branch
"depends" on anything else, they are all equally first-class citizens.
But while *technically* all branches are equal in git, at the same time
there's no reason not to _think_ of branches as having a hierarchy if you
want to. In particular:
- it's how people tend to use git anyway (ie the "origin" branch is
what you're tracking, and you have your own changes in your local
branches)
- and git will never duplicate information for branches that have a
common history or contents anyway. So while git branches are totally
"independent" in the technical sense, the data structures are all
designed so that they will share everything that they can possibly
share (in fact, thanks to the "delta-against-anything" model, different
branches will share much more than in something like CVS/SVN)
> So if I made changes to the debian branch, I'd check it out first,
> then return to the upstream branch when done.
It sounds like you would actually be fairly comfy with the git "switch
branches within one repository" model, and you might not even need to make
it look like two different trees.
> Okay, this is beginning to make sense. However, the debian branch
> tracks changes mostly to ./debian/*. To check it out separately,
> I need a directory. If usptream is checked out to ., then if I'd
> check out the debian branch do ./debian, I'd end up with
> ./debian/debian. Do you suggest the use of a symlink then?
No, I'm suggesting that you have the upstream thing checked out in ".",
and you have the "debian" branch IN THE SAME PLACE. So when you do
git checkout debian
it will just check out all the debian stuff in the same directory, so now
you'll get a ./debian/ directory with all your debian stuff.
When you do
git checkout upstream
the files in that directory just go away, because it doesn't exist in
the "upstream" branch
But I don't want to fool you - I do think you'll have to change *some* of
how you work. But it sounds like your workflow is *fairly* close to a very
natural git flow.
Linus
^ permalink raw reply
* Re: [PATCH] Teach the --cover-letter option to format-patch
From: Daniel Barkalow @ 2007-07-10 17:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707101424140.4047@racer.site>
I think this is missing the ultra-important "extra_headers" stuff, which
is what makes my messages actually reach the right people. That's why I'd
like the code shared for generating headers (except for Subject) for a
rev_info between the code that does it for patch messages and the code for
the cover letter. I think it's also missing making [PATCH 1/N] a reply to
it if the series is set up as replies.
I like the design, in any case. I want the blurb actually stored in the
objects directory somehow, so that I don't have to trawl through my sent
email for it when I send the series again for some reason, but that's a
relatively straightforward extension to your code. (Read an object with a
hash and stick the text in instead of the ***...*** parts.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Teach the --cover-letter option to format-patch
From: Johannes Schindelin @ 2007-07-10 17:20 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707101300450.6977@iabervon.org>
Hi,
On Tue, 10 Jul 2007, Daniel Barkalow wrote:
> I think this is missing the ultra-important "extra_headers" stuff, which
> is what makes my messages actually reach the right people. That's why
> I'd like the code shared for generating headers (except for Subject) for
> a rev_info between the code that does it for patch messages and the code
> for the cover letter. I think it's also missing making [PATCH 1/N] a
> reply to it if the series is set up as replies.
Ah yes. Both issues should be relatively easy to integrate into my patch.
> I like the design, in any case. I want the blurb actually stored in the
> objects directory somehow, so that I don't have to trawl through my sent
> email for it when I send the series again for some reason, but that's a
> relatively straightforward extension to your code. (Read an object with
> a hash and stick the text in instead of the ***...*** parts.)
I do not understand. But then, my patch should be a good starting point.
Go wild.
Ciao,
Dscho
^ permalink raw reply
* Re: pushing changes to a remote branch
From: Jeff King @ 2007-07-10 17:34 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <20070710143614.GA29681@piper.oerlikon.madduck.net>
On Tue, Jul 10, 2007 at 04:36:14PM +0200, martin f krafft wrote:
> git checkout origin/vim
> Note: moving to "origin/vim" which isn't a local branch
> echo change > newfile; git add newfile
> git commit -m'make change'
> Created commit 64b8b2e: make change
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 newfile
>
> If I now checkout master and then return to origin/vim, the commit
> is gone.
That's because 'origin/vim' is a tracking branch for the remote; it's
where you store the information "here's what the remote 'origin' thinks
is in the branch 'vim'." That's why you get the "note" warning above.
If you want to make changes, you should make a local branch starting
from that point:
git-checkout -b vim origin/vim
# hack hack hack
git-commit -m changes
> Much more, however, I am interested how I am supposed to push
> commits back to select remote branches.
Now when you issue a git-push, you will push _your_ 'vim' branch to the
remote's 'vim' branch. Before, you didn't _have_ a vim branch, so
nothing was pushed.
So the key thing you are missing in all of this is that you shouldn't be
doing _anything_ with branches in origin/* (which are, of course,
actually refs/remotes/origin/*) except for read-only operations (like
diffing against them, merging with them, etc). They are purely for
tracking the remote's branches.
-Peff
^ permalink raw reply
* Re: how to combine two clones in a collection
From: martin f krafft @ 2007-07-10 17:45 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <alpine.LFD.0.999.0707100950520.3412@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 4097 bytes --]
also sprach Linus Torvalds <torvalds@linux-foundation.org> [2007.07.10.1905 +0200]:
> These would get both branches (including all of the upstream,
> of course), but that's ok, since git will share all the common
> objects *anyway*, so there is no "duplication". You can have
> a hundred branches, and they won't use one whit more memory of
> bandwidth (apart from the branch refs themselves being sent
> over, of course), and only the actual *differences* between
> branches will take up space.
The duplication I meant was when upstream uses SVN or a tarball,
which I then have to track/import into my git repo. But it's just
space and that's cheap these days.
> Here, I don't really know how the debian package management is
> supposed to work, but since they obviously aren't using git,
> they must be using something else. A tar-ball or just a series
> of patches? Both would be trivial to implement as just an
> "export" from your git tree. Or you'd export the "debian"
> branch as a separate SVN repo (I've not used the "export back
> into a SVN" thing, so I don't know how well that works).
Just in case you're interested, otherwise the following two
paragraphs can be safely skipped:
There is no standard for Debian packaging. In general, it's the
upstream tarball and a diff to be applied for debianisation. Some
people just use one giant diff, others use the diff to add patches
as separate files to the unpacked contents of the tarball, which
are then applied.
I guess my final goal is to use git and branches, one to track
upstream, one for every feature/patch I add, and then to create
a source package from that by packaging the upstream branch into
a tarball (or reusing an existing one), turning each branch into
a single-file patch and then create the overall diff to add these
single-files, including some glue to apply them automatically on
unpacking/building.
> > The way I tend to think about a pair of branches is that one
> > depends on the other, or rather, one stems from the other.
>
> .. and no, that's not really how git works from a technical angle:
> in the the git model, all branches are technically 100% equal, and
> no branch "depends" on anything else, they are all equally
> first-class citizens.
Right, I knew that. What I meant is more that a branch derives off
another, meaning that before and including the branching commit,
they have shared ancestry.
I wonder how to create a project with two completely independent
branches which have no common ancestry. I don't think it's possible.
One needs a throwaway branch to create the first commit, then branch
each of the two branches off that, then delete the throwaya branch
(or keep it around).
But this is getting academic now...
> > So if I made changes to the debian branch, I'd check it out
> > first, then return to the upstream branch when done.
>
> It sounds like you would actually be fairly comfy with the git
> "switch branches within one repository" model, and you might not
> even need to make it look like two different trees.
Definitely.
As a Debian maintainer who really wants to use git for Debian
packaging though, I also need to worry about all the other people
who obtain my source package and need to be comfortable with it.
I may well understand what my 123 branches are for and how they are
interlinked, but that doesn't help Jane Schmoo fixing
a release-critical bug while I'm backpacking in Southeast Asia.
> But I don't want to fool you - I do think you'll have to change
> *some* of how you work. But it sounds like your workflow is
> *fairly* close to a very natural git flow.
Thanks for the encouragement!
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
it is better to have loft and lost
than to never have loft at all.
-- groucho marx
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH v2 1/2] Add for_each_remote() function, and extend remote_find_tracking()
From: Johannes Schindelin @ 2007-07-10 17:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paolo Bonzini, git, Daniel Barkalow
In-Reply-To: <7vy7hosv7v.fsf@assigned-by-dhcp.cox.net>
The function for_each_remote() does exactly what the name suggests.
The function remote_find_tracking() was extended to be able to search
remote refs for a given local ref. You have to set the parameter
"reverse" to true for that behavior.
Both changes are required for the next step: simplification of
git-branch's --track functionality.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Thanks, Daniel and Junio, for your suggestions.
remote.c | 60 ++++++++++++++++++++++++++++++++++++++++++++--------------
remote.h | 5 +++-
send-pack.c | 4 +-
3 files changed, 51 insertions(+), 18 deletions(-)
diff --git a/remote.c b/remote.c
index 09c4279..bb774d0 100644
--- a/remote.c
+++ b/remote.c
@@ -279,6 +279,25 @@ struct remote *remote_get(const char *name)
return ret;
}
+int for_each_remote(each_remote_fn fn, void *priv)
+{
+ int i, result = 0;
+ read_config();
+ for (i = 0; i < allocated_remotes && !result; i++) {
+ struct remote *r = remotes[i];
+ if (!r)
+ continue;
+ if (!r->fetch)
+ r->fetch = parse_ref_spec(r->fetch_refspec_nr,
+ r->fetch_refspec);
+ if (!r->push)
+ r->push = parse_ref_spec(r->push_refspec_nr,
+ r->push_refspec);
+ result = fn(r, priv);
+ }
+ return result;
+}
+
int remote_has_uri(struct remote *remote, const char *uri)
{
int i;
@@ -291,32 +310,43 @@ int remote_has_uri(struct remote *remote, const char *uri)
int remote_find_tracking(struct remote *remote, struct refspec *refspec)
{
+ int find_src = refspec->src == NULL;
+ char *needle, **result;
int i;
+
+ if (find_src) {
+ if (refspec->dst == NULL)
+ return error("find_tracking: need either src or dst");
+ needle = refspec->dst;
+ result = &refspec->src;
+ } else {
+ needle = refspec->src;
+ result = &refspec->dst;
+ }
+
for (i = 0; i < remote->fetch_refspec_nr; i++) {
struct refspec *fetch = &remote->fetch[i];
+ const char *key = find_src ? fetch->dst : fetch->src;
+ const char *value = find_src ? fetch->src : fetch->dst;
if (!fetch->dst)
continue;
if (fetch->pattern) {
- if (!prefixcmp(refspec->src, fetch->src)) {
- refspec->dst =
- xmalloc(strlen(fetch->dst) +
- strlen(refspec->src) -
- strlen(fetch->src) + 1);
- strcpy(refspec->dst, fetch->dst);
- strcpy(refspec->dst + strlen(fetch->dst),
- refspec->src + strlen(fetch->src));
- refspec->force = fetch->force;
- return 0;
- }
- } else {
- if (!strcmp(refspec->src, fetch->src)) {
- refspec->dst = xstrdup(fetch->dst);
+ if (!prefixcmp(needle, key)) {
+ *result = xmalloc(strlen(value) +
+ strlen(needle) -
+ strlen(key) + 1);
+ strcpy(*result, value);
+ strcpy(*result + strlen(value),
+ needle + strlen(key));
refspec->force = fetch->force;
return 0;
}
+ } else if (!strcmp(needle, key)) {
+ *result = xstrdup(value);
+ refspec->force = fetch->force;
+ return 0;
}
}
- refspec->dst = NULL;
return -1;
}
diff --git a/remote.h b/remote.h
index 080b7da..17b8b5b 100644
--- a/remote.h
+++ b/remote.h
@@ -20,13 +20,16 @@ struct remote {
struct remote *remote_get(const char *name);
+typedef int each_remote_fn(struct remote *remote, void *priv);
+int for_each_remote(each_remote_fn fn, void *priv);
+
int remote_has_uri(struct remote *remote, const char *uri);
struct refspec {
unsigned force : 1;
unsigned pattern : 1;
- const char *src;
+ char *src;
char *dst;
};
diff --git a/send-pack.c b/send-pack.c
index fecbda9..9fc8a81 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -305,8 +305,8 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
if (remote) {
struct refspec rs;
rs.src = ref->name;
- remote_find_tracking(remote, &rs);
- if (rs.dst) {
+ rs.dst = NULL;
+ if (!remote_find_tracking(remote, &rs)) {
struct ref_lock *lock;
fprintf(stderr, " Also local %s\n", rs.dst);
if (will_delete_ref) {
--
1.5.3.rc0.2783.gf3f7
^ permalink raw reply related
* [PATCH v2 2/2] branch --track: code cleanup and saner handling of local branches
From: Johannes Schindelin @ 2007-07-10 17:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paolo Bonzini, git, Daniel Barkalow
In-Reply-To: <7vy7hosv7v.fsf@assigned-by-dhcp.cox.net>
This patch cleans up some complicated code, and replaces it with a
cleaner version, using code from remote.[ch], which got extended a
little in the process. This also enables us to fix two cases:
The earlier "fix" to setup tracking only when the original ref started
with "refs/remotes" is wrong. You are absolutely allowed to use a
separate layout for your tracking branches. The correct fix, of course,
is to set up tracking information only when there is a matching
remote.<nick>.fetch line containing a colon.
Another corner case was not handled properly. If two remotes write to
the original ref, just warn the user and do not set up tracking.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Sorry, but I really do not feel like manually making the patch
nicer to read today. It is really annoying to me to see the
empty and the not-really-interesting lines match up. Oh, well.
builtin-branch.c | 170 +++++++++++++++++------------------------------------
t/t3200-branch.sh | 21 ++++---
2 files changed, 66 insertions(+), 125 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 49195a1..d16d3f2 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -10,6 +10,7 @@
#include "refs.h"
#include "commit.h"
#include "builtin.h"
+#include "remote.h"
static const char builtin_branch_usage[] =
"git-branch [-r] (-d | -D) <branchname> | [--track | --no-track] [-l] [-f] <branchname> [<start-point>] | (-m | -M) [<oldbranch>] <newbranch> | [--color | --no-color] [-r | -a] [-v [--abbrev=<length> | --no-abbrev]] [--sort-by-date]";
@@ -22,7 +23,7 @@ static const char builtin_branch_usage[] =
static const char *head;
static unsigned char head_sha1[20];
-static int branch_track = 1; /* 0 = none, 1 = remotes, 2 = all */
+static int branch_track = 1;
static int branch_use_color;
static char branch_colors[][COLOR_MAXLEN] = {
@@ -66,12 +67,8 @@ static int git_branch_config(const char *var, const char *value)
color_parse(value, var, branch_colors[slot]);
return 0;
}
- if (!strcmp(var, "branch.autosetupmerge")) {
- if (!strcmp(value, "all"))
- branch_track = 2;
- else
+ if (!strcmp(var, "branch.autosetupmerge"))
branch_track = git_config_bool(var, value);
- }
return git_default_config(var, value);
}
@@ -349,125 +346,70 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev,
free_ref_list(&ref_list);
}
-static char *config_repo;
-static char *config_remote;
-static const char *start_ref;
+struct tracking {
+ struct refspec spec;
+ char *src;
+ const char *remote;
+ int matches;
+};
-static int get_remote_branch_name(const char *value)
+static int find_tracked_branch(struct remote *remote, void *priv)
{
- const char *colon;
- const char *end;
+ struct tracking *tracking = priv;
- if (*value == '+')
- value++;
-
- colon = strchr(value, ':');
- if (!colon)
- return 0;
-
- end = value + strlen(value);
-
- /*
- * Try an exact match first. I.e. handle the case where the
- * value is "$anything:refs/foo/bar/baz" and start_ref is exactly
- * "refs/foo/bar/baz". Then the name at the remote is $anything.
- */
- if (!strcmp(colon + 1, start_ref)) {
- /* Truncate the value before the colon. */
- nfasprintf(&config_repo, "%.*s", colon - value, value);
- return 1;
+ if (!remote_find_tracking(remote, &tracking->spec)) {
+ if (++tracking->matches == 1) {
+ tracking->src = tracking->spec.src;
+ tracking->remote = remote->name;
+ } else {
+ free(tracking->spec.src);
+ if (tracking->src) {
+ free(tracking->src);
+ tracking->src = NULL;
+ }
+ }
+ tracking->spec.src = NULL;
}
- /*
- * Is this a wildcard match?
- */
- if ((end - 2 <= value) || end[-2] != '/' || end[-1] != '*' ||
- (colon - 2 <= value) || colon[-2] != '/' || colon[-1] != '*')
- return 0;
-
- /*
- * Value is "refs/foo/bar/<asterisk>:refs/baz/boa/<asterisk>"
- * and start_ref begins with "refs/baz/boa/"; the name at the
- * remote is refs/foo/bar/ with the remaining part of the
- * start_ref. The length of the prefix on the RHS is (end -
- * colon - 2), including the slash immediately before the
- * asterisk.
- */
- if ((strlen(start_ref) < end - colon - 2) ||
- memcmp(start_ref, colon + 1, end - colon - 2))
- return 0; /* does not match prefix */
-
- /* Replace the asterisk with the remote branch name. */
- nfasprintf(&config_repo, "%.*s%s",
- (colon - 1) - value, value,
- start_ref + (end - colon - 2));
- return 1;
-}
-
-static int get_remote_config(const char *key, const char *value)
-{
- const char *var;
- if (prefixcmp(key, "remote."))
- return 0;
-
- var = strrchr(key, '.');
- if (var == key + 6 || strcmp(var, ".fetch"))
- return 0;
- /*
- * Ok, we are looking at key == "remote.$foo.fetch";
- */
- if (get_remote_branch_name(value))
- nfasprintf(&config_remote, "%.*s", var - (key + 7), key + 7);
-
return 0;
}
-static void set_branch_merge(const char *name, const char *config_remote,
- const char *config_repo)
+
+/*
+ * This is called when new_ref is branched off of orig_ref, and tries
+ * to infer the settings for branch.<new_ref>.{remote,merge} from the
+ * config.
+ */
+static int setup_tracking(const char *new_ref, const char *orig_ref)
{
char key[1024];
- if (sizeof(key) <=
- snprintf(key, sizeof(key), "branch.%s.remote", name))
- die("what a long branch name you have!");
- git_config_set(key, config_remote);
-
- /*
- * We do not have to check if we have enough space for
- * the 'merge' key, since it's shorter than the
- * previous 'remote' key, which we already checked.
- */
- snprintf(key, sizeof(key), "branch.%s.merge", name);
- git_config_set(key, config_repo);
-}
+ struct tracking tracking;
-static void set_branch_defaults(const char *name, const char *real_ref)
-{
- /*
- * name is the name of new branch under refs/heads;
- * real_ref is typically refs/remotes/$foo/$bar, where
- * $foo is the remote name (there typically are no slashes)
- * and $bar is the branch name we map from the remote
- * (it could have slashes).
- */
- start_ref = real_ref;
- git_config(get_remote_config);
- if (!config_repo && !config_remote &&
- !prefixcmp(real_ref, "refs/heads/")) {
- set_branch_merge(name, ".", real_ref);
- printf("Branch %s set up to track local branch %s.\n",
- name, real_ref);
- }
+ if (strlen(new_ref) > 1024 - 7 - 7 - 1)
+ return error("Tracking not set up: name too long: %s",
+ new_ref);
- if (config_repo && config_remote) {
- set_branch_merge(name, config_remote, config_repo);
+ memset(&tracking, 0, sizeof(tracking));
+ tracking.spec.dst = (char *)orig_ref;
+ if (for_each_remote(find_tracked_branch, &tracking) ||
+ !tracking.matches)
+ return 1;
+
+ if (tracking.matches > 1)
+ return error("Not tracking: ambiguous information for ref %s",
+ orig_ref);
+
+ if (tracking.matches == 1) {
+ sprintf(key, "branch.%s.remote", new_ref);
+ git_config_set(key, tracking.remote ? tracking.remote : ".");
+ sprintf(key, "branch.%s.merge", new_ref);
+ git_config_set(key, tracking.src);
+ free(tracking.src);
printf("Branch %s set up to track remote branch %s.\n",
- name, real_ref);
+ new_ref, orig_ref);
}
- if (config_repo)
- free(config_repo);
- if (config_remote)
- free(config_remote);
+ return 0;
}
static void create_branch(const char *name, const char *start_name,
@@ -529,10 +471,8 @@ static void create_branch(const char *name, const char *start_name,
/* When branching off a remote branch, set up so that git-pull
automatically merges from there. So far, this is only done for
remotes registered via .git/config. */
- if (real_ref && (track == 2 ||
- (track == 1 &&
- !prefixcmp(real_ref, "refs/remotes/"))))
- set_branch_defaults(name, real_ref);
+ if (real_ref && track)
+ setup_tracking(name, real_ref);
if (write_ref_sha1(lock, sha1, msg) < 0)
die("Failed to write ref: %s.", strerror(errno));
@@ -604,7 +544,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
break;
}
if (!strcmp(arg, "--track")) {
- track = 2;
+ track = 1;
continue;
}
if (!strcmp(arg, "--no-track")) {
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index a19e961..ef1eeb7 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -148,13 +148,14 @@ test_expect_success 'test tracking setup via config' \
test $(git config branch.my3.remote) = local &&
test $(git config branch.my3.merge) = refs/heads/master'
-test_expect_success 'autosetupmerge = all' '
+test_expect_success 'avoid ambiguous track' '
git config branch.autosetupmerge true &&
+ git config remote.ambi1.url = lalala &&
+ git config remote.ambi1.fetch = refs/heads/lalala:refs/heads/master &&
+ git config remote.ambi2.url = lilili &&
+ git config remote.ambi2.fetch = refs/heads/lilili:refs/heads/master &&
git branch all1 master &&
- test -z "$(git config branch.all1.merge)" &&
- git config branch.autosetupmerge all &&
- git branch all2 master &&
- test $(git config branch.all2.merge) = refs/heads/master
+ test -z "$(git config branch.all1.merge)"
'
test_expect_success 'test overriding tracking setup via --no-track' \
@@ -167,10 +168,10 @@ test_expect_success 'test overriding tracking setup via --no-track' \
! test "$(git config branch.my2.remote)" = local &&
! test "$(git config branch.my2.merge)" = refs/heads/master'
-test_expect_success 'test local tracking setup' \
+test_expect_success 'no tracking without .fetch entries' \
'git branch --track my6 s &&
- test $(git config branch.my6.remote) = . &&
- test $(git config branch.my6.merge) = refs/heads/s'
+ test -z "$(git config branch.my6.remote)" &&
+ test -z "$(git config branch.my6.merge)"'
test_expect_success 'test tracking setup via --track but deeper' \
'git config remote.local.url . &&
@@ -182,8 +183,8 @@ test_expect_success 'test tracking setup via --track but deeper' \
test_expect_success 'test deleting branch deletes branch config' \
'git branch -d my7 &&
- test "$(git config branch.my7.remote)" = "" &&
- test "$(git config branch.my7.merge)" = ""'
+ test -z "$(git config branch.my7.remote)" &&
+ test -z "$(git config branch.my7.merge)"'
test_expect_success 'test deleting branch without config' \
'git branch my7 s &&
--
1.5.3.rc0.2783.gf3f7
^ permalink raw reply related
* git-svn+cygwin failed fetch
From: Russ Dill @ 2007-07-10 18:06 UTC (permalink / raw)
To: git
[...]/src $ mkdir foo
[...]/src $ cd foo
[...]/src/foo $ git-svn init -t tags -b branches -T trunk
https://www.[...].com/svn/foo/bar/bla
Initialized empty Git repository in .git/
Using higher level of URL: https://www.[...].com/svn/foo/bar/bla =>
https://www.[...].com/svn/foo
[...]/src/foo $ git-svn fetch
config --get svn-remote.svn.url: command returned error: 1
[...]/src/foo $ git config --get svn-remote.svn.url
https://www.[...].com/svn/foo
[...]/src/foo $ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = https://www.[...].com/svn/foo
fetch = bar/bla/trunk:refs/remotes/trunk
branches = bar/bla/branches/*:refs/remotes/*
tags = bar/bla/tags/*:refs/remotes/tags/*
[...]/src/foo $ git --version
git version 1.5.2.2
[...]/src/foo $ git-svn --version
git-svn version 1.5.2.2 (svn 1.4.3)
My versions of git and svn are the one that comes with cygwin.
^ permalink raw reply
* Re: pushing changes to a remote branch
From: Brian Gernhardt @ 2007-07-10 18:10 UTC (permalink / raw)
To: Jeff King; +Cc: git discussion list
In-Reply-To: <20070710173401.GB5032@sigill.intra.peff.net>
On Jul 10, 2007, at 1:34 PM, Jeff King wrote:
> On Tue, Jul 10, 2007 at 04:36:14PM +0200, martin f krafft wrote:
>
>> git checkout origin/vim
>> Note: moving to "origin/vim" which isn't a local branch
>> echo change > newfile; git add newfile
>> git commit -m'make change'
>> Created commit 64b8b2e: make change
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>> create mode 100644 newfile
>>
>> If I now checkout master and then return to origin/vim, the commit
>> is gone.
>
> That's because 'origin/vim' is a tracking branch for the remote; it's
> where you store the information "here's what the remote 'origin'
> thinks
> is in the branch 'vim'." That's why you get the "note" warning above.
>
> If you want to make changes, you should make a local branch starting
> from that point:
>
> git-checkout -b vim origin/vim
> # hack hack hack
> git-commit -m changes
Indeed, in master, git outputs a hint to that when you checkout the
remote branch.
$ git checkout origin/master
Note: moving to "origin/master" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at f4855d4... 1
Perhaps git-commit should also also output a warning? "Commit made
on detached HEAD. Use "git branch <new_branch_name>" to save your
commit"? That's bad wording, but the idea is there.
~~ Brian
^ permalink raw reply
* Re: how to combine two clones in a collection
From: Brian Gernhardt @ 2007-07-10 18:27 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20070710174543.GA16054@piper.oerlikon.madduck.net>
On Jul 10, 2007, at 1:45 PM, martin f krafft wrote:
> I wonder how to create a project with two completely independent
> branches which have no common ancestry. I don't think it's possible.
> One needs a throwaway branch to create the first commit, then branch
> each of the two branches off that, then delete the throwaya branch
> (or keep it around).
>
> But this is getting academic now...
But interesting.
What you describe won't create two independent branches. They'll
share the root commit. I think what you have do is create the first
branch as normal, then clear out the working copy (be sure not to
delete .git) and do the commit manually. I believe it goes something
like this:
git init
# Create files for master
git add .
git commit
rm -rf * .git/index
# Create files for second branch
git add .
tree=$(git write-tree)
# Edit commit message into some file (commit-msg here)
commit=$(git commit-tree $tree < commit-msg)
git update-ref refs/branches/independent $commit
The important bits are to be sure to remove the index so you don't
commit the wrong files and the last four lines that do the heavy
lifting. You could also create the branch in a second repository and
pull it from there into the first (probably simpler), or perhaps
trick git-commit into thinking there isn't any commits yet (remove
the index and HEAD perhaps?).
~~ Brian
^ permalink raw reply
* Re: git-svn problems with branches containing spaces
From: Jan Hudec @ 2007-07-10 18:33 UTC (permalink / raw)
To: git
In-Reply-To: <20070710134236.2870.qmail@986bac8bfff25d.315fe32.mid.smarden.org>
[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]
On Tue, Jul 10, 2007 at 13:42:35 +0000, Gerrit Pape wrote:
> On Wed, Jun 27, 2007 at 08:53:06AM +0200, Ewald, Robert wrote:
> > As I have reported yesterday on IRC, git-svn has problems with branches
> > containing spaces.
> > I get the following message, when I want to clone from the repository
> > containing a branch with a space.
> > Cloning until the revision the branch is created everything works fine.
> >
> > fatal: refs/remotes/Modbus Error Limit Fix: cannot lock the ref
> > update-ref -m r1897 refs/remotes/Modbus Error Limit Fix
> > ff0819c8e9c97c24e9865bc868c503fd9b64f980: command returned error: 128
> >
> > Thanks for your help.
>
> Hi, the same problem has been reported some time ago through
> http://bugs.debian.org/430518
>
> There's a patch attached to the report, but from a first glance, I don't
> think it's the solution.
It depends on whether it's OK for git to have refs with funny characters in
them. If it is, than the patch would be a fix. If not, than the escaping the
patch removes needs to be added to all other places that have any business
with refs.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] Add for_each_remote() function, and extend remote_find_tracking()
From: Junio C Hamano @ 2007-07-10 18:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Paolo Bonzini, git, Daniel Barkalow
In-Reply-To: <Pine.LNX.4.64.0707101848050.4047@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The function for_each_remote() does exactly what the name suggests.
>
> The function remote_find_tracking() was extended to be able to search
> remote refs for a given local ref. You have to set the parameter
> "reverse" to true for that behavior.
The updated patch does not use "reverse" but the old description
is still there.
Daniel, one thing I fear about your "I want to store the message
in the object store so that I can reuse even after I re-polish
the series" desire on the cover letter topic is this kind of
gotcha, and that is why I suggested "*** BLURB GOES HERE ***".
Both the summary (diffstat and shortlog) part and the
description part should be kept fresh in the updated 0/N; while
we can automate the summary part whenever we re-generate 0/N,
you cannot automate the description part.
^ permalink raw reply
* Re: how to combine two clones in a collection
From: Kalle Pokki @ 2007-07-10 19:27 UTC (permalink / raw)
To: git
In-Reply-To: <72218C10-EE5E-4CD9-B5DE-DFEC40EBEF27@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> What you describe won't create two independent branches. They'll
> share the root commit. I think what you have do is create the first
> branch as normal, then clear out the working copy (be sure not to
> delete .git) and do the commit manually. I believe it goes something
> like this:
You can also just create two different git repositories and start making
the commits in the master (or any other) branch. Then combine the
repositories by fetching
cd repo1
git fetch ../repo2 master:repo2
This way the branches don't share anything, do they?
^ permalink raw reply
* Re: [PATCH v2 1/2] Add for_each_remote() function, and extend remote_find_tracking()
From: Johannes Schindelin @ 2007-07-10 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paolo Bonzini, git, Daniel Barkalow
In-Reply-To: <7vtzscqf2r.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 10 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > The function for_each_remote() does exactly what the name suggests.
> >
> > The function remote_find_tracking() was extended to be able to search
> > remote refs for a given local ref. You have to set the parameter
> > "reverse" to true for that behavior.
>
> The updated patch does not use "reverse" but the old description
> is still there.
Urgh. Right. May I ask you to paste this instead?
The function remote_find_tracking() was extended to be able to search
remote refs for a given local ref. You have to set either src or dst in
the refspec, and remote_find_tracking() will fill in the other and return
0.
> Daniel, one thing I fear about your "I want to store the message
> in the object store so that I can reuse even after I re-polish
> the series" desire on the cover letter topic is this kind of
> gotcha, and that is why I suggested "*** BLURB GOES HERE ***".
I am happy that my fsckup served a purpose, then. (And maybe this would
be a good hint in rebase -i's man page, too, since that is how the error
was introduced here.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Support wholesale directory renames in fast-import
From: David Frech @ 2007-07-10 19:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Uwe Kleine-König, git
In-Reply-To: <20070710141442.GM4436@spearce.org>
Hmm. I think Uwe is right. Copy is probably the "right" primitive, and
rename can always be synthesized from copy+delete.
Since Subversion is built around the idea of "cheap copies" there is
no incentive for them to represent renames other than as "copy, then
delete".
But isn't the same true in a way of git? If I copy a directory (a
tree), then the new tree is the same tree - it has the same SHA-1
hash, so I can simply refer to the existing object. Same for file
blobs.
Subversion dump files have *lots* of copies. Might be nice to be able
to feed these directly into fast-import and have it DTRT, esp if it
was smart about sharing identical data structures.
- David
On 7/10/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Uwe Kleine-K??nig <ukleinek@informatik.uni-freiburg.de> wrote:
> > David Frech wrote:
> > > Now my challenge is that the svn dump doesn't *actually* say "rename
> > > a/ to b/"; it says "copy a/ to b/; delete a/", so I have to infer the
> > > rename.
> >
> > I don't know fast-import very well, but why not doing exactly what the
> > dump file suggests: copy a b; delete a ?
>
> Because there is no copy operator in fast-import. So you cannot
> do "copy a b". Apparently that's what I should have implemented,
> as rename in Git really is as simple as the copy/delete pair. Ugh.
>
> Copy isn't really that hard, it just can't be nearly as efficient as
> rename, as copying a subtree will force me to either duplicate data
> in memory or reload trees from disk to duplicate data in memory.
> But its a copy, so data duplication is expected. ;-)
>
> I'll implement a copy opertor soon. Shouldn't be too difficult.
> Maybe someone else would like to take a shot at implementing it...
>
> --
> Shawn.
>
--
If I have not seen farther, it is because I have stood in the
footsteps of giants.
^ permalink raw reply
* Re: how to combine two clones in a collection
From: Brian Gernhardt @ 2007-07-10 20:00 UTC (permalink / raw)
To: Kalle Pokki; +Cc: git
In-Reply-To: <m3644suki6.fsf@host32.eke.fi>
On Jul 10, 2007, at 3:27 PM, Kalle Pokki wrote:
> You can also just create two different git repositories and start
> making
> the commits in the master (or any other) branch. Then combine the
> repositories by fetching
>
> cd repo1
> git fetch ../repo2 master:repo2
>
> This way the branches don't share anything, do they?
Yes, that's what I was referring to at the end when I wrote:
> You could also create the branch in a second repository and pull it
> from there into the first (probably simpler),
But it seemed too simple. ;-) And that is exactly how I'd do it...
Assuming I thought of it before using write-tree, commit-tree, and
update-ref. (Which is what happened. I thought of the complicated
method and wrote it up before thinking "duh, just use a second repo.")
~~ Brian
^ permalink raw reply
* git-filter-branch exits early
From: Alex Riesen @ 2007-07-10 20:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
I have a Debian system where git-filter-branch exits immediately after
"unset CDPATH" in git-sh-setup (the command exits with 1, as CDPATH is
not defined). The system still has bash-2.05a.
git-filter-branch has "set -e", which is why the script finishes
prematurely. If this is not really needed, maybe it can be removed?
I'll see if the system can be upgraded, but I suspect someone can get
a similar problem.
^ permalink raw reply
* Re: [PATCH v2 1/2] Add for_each_remote() function, and extend remote_find_tracking()
From: Daniel Barkalow @ 2007-07-10 21:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Paolo Bonzini, git
In-Reply-To: <7vtzscqf2r.fsf@assigned-by-dhcp.cox.net>
On Tue, 10 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > The function for_each_remote() does exactly what the name suggests.
> >
> > The function remote_find_tracking() was extended to be able to search
> > remote refs for a given local ref. You have to set the parameter
> > "reverse" to true for that behavior.
>
> The updated patch does not use "reverse" but the old description
> is still there.
>
> Daniel, one thing I fear about your "I want to store the message
> in the object store so that I can reuse even after I re-polish
> the series" desire on the cover letter topic is this kind of
> gotcha, and that is why I suggested "*** BLURB GOES HERE ***".
> Both the summary (diffstat and shortlog) part and the
> description part should be kept fresh in the updated 0/N; while
> we can automate the summary part whenever we re-generate 0/N,
> you cannot automate the description part.
It seems to me that commit messages are much more likely to mention the
sorts of details that are affected by review than cover letters are.
Furthermore, if the message is coming out of a tag on the head of the
series, whatever is used to put the tag onto the new head of the series
would present the buffer for editting again, just like commit --amend
does. So the user would be just as likely to think to update a series
header as a commit message, and less likely to need to.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH 1/2] t0030: Remove repeated instructions and add missing &&
From: Carlos Rica @ 2007-07-10 21:53 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin
Moved some tests to another test_expect_success block.
Many tests now reuse the same "expect" file. Also replacing
many printf "" >expect with one >expect instruction.
Added missing && which concatenated tests in some
test_expect_success blocks.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
t/t0030-stripspace.sh | 37 +++++++++++++------------------------
1 files changed, 13 insertions(+), 24 deletions(-)
diff --git a/t/t0030-stripspace.sh b/t/t0030-stripspace.sh
index fdc9fdc..4a2980c 100755
--- a/t/t0030-stripspace.sh
+++ b/t/t0030-stripspace.sh
@@ -85,39 +85,36 @@ test_expect_success \
'
test_expect_success \
- 'consecutive blank lines at the beginning should be removed' '
- printf "" > expect &&
+ 'only consecutive blank lines should be completely removed' '
+ > expect &&
+
printf "\n" | git stripspace >actual &&
git diff expect actual &&
- printf "" > expect &&
printf "\n\n\n" | git stripspace >actual &&
git diff expect actual &&
- printf "" > expect &&
printf "$sss\n$sss\n$sss\n" | git stripspace >actual &&
git diff expect actual &&
- printf "" > expect &&
printf "$sss$sss\n$sss\n\n" | git stripspace >actual &&
git diff expect actual &&
- printf "" > expect &&
printf "\n$sss\n$sss$sss\n" | git stripspace >actual &&
git diff expect actual &&
- printf "" > expect &&
printf "$sss$sss$sss$sss\n\n\n" | git stripspace >actual &&
git diff expect actual &&
- printf "" > expect &&
printf "\n$sss$sss$sss$sss\n\n" | git stripspace >actual &&
git diff expect actual &&
- printf "" > expect &&
printf "\n\n$sss$sss$sss$sss\n" | git stripspace >actual &&
- git diff expect actual &&
+ git diff expect actual
+'
+test_expect_success \
+ 'consecutive blank lines at the beginning should be removed' '
printf "$ttt\n" > expect &&
printf "\n$ttt\n" | git stripspace >actual &&
git diff expect actual &&
@@ -139,26 +136,22 @@ test_expect_success \
git diff expect actual &&
printf "$ttt\n" > expect &&
+
printf "$sss\n$sss\n$sss\n$ttt\n" | git stripspace >actual &&
git diff expect actual &&
- printf "$ttt\n" > expect &&
printf "\n$sss\n$sss$sss\n$ttt\n" | git stripspace >actual &&
git diff expect actual &&
- printf "$ttt\n" > expect &&
printf "$sss$sss\n$sss\n\n$ttt\n" | git stripspace >actual &&
git diff expect actual &&
- printf "$ttt\n" > expect &&
printf "$sss$sss$sss\n\n\n$ttt\n" | git stripspace >actual &&
git diff expect actual &&
- printf "$ttt\n" > expect &&
printf "\n$sss$sss$sss\n\n$ttt\n" | git stripspace >actual &&
git diff expect actual &&
- printf "$ttt\n" > expect &&
printf "\n\n$sss$sss$sss\n$ttt\n" | git stripspace >actual &&
git diff expect actual
'
@@ -186,26 +179,22 @@ test_expect_success \
git diff expect actual &&
printf "$ttt\n" > expect &&
+
printf "$ttt\n$sss\n$sss\n$sss\n" | git stripspace >actual &&
git diff expect actual &&
- printf "$ttt\n" > expect &&
printf "$ttt\n\n$sss\n$sss$sss\n" | git stripspace >actual &&
git diff expect actual &&
- printf "$ttt\n" > expect &&
printf "$ttt\n$sss$sss\n$sss\n\n" | git stripspace >actual &&
git diff expect actual &&
- printf "$ttt\n" > expect &&
printf "$ttt\n$sss$sss$sss\n\n\n" | git stripspace >actual &&
git diff expect actual &&
- printf "$ttt\n" > expect &&
printf "$ttt\n\n$sss$sss$sss\n\n" | git stripspace >actual &&
git diff expect actual &&
- printf "$ttt\n" > expect &&
printf "$ttt\n\n\n$sss$sss$sss\n" | git stripspace >actual &&
git diff expect actual
'
@@ -224,7 +213,7 @@ test_expect_success \
'text plus spaces without newline at end should end with newline' '
test `printf "$ttt$sss" | git stripspace | wc -l` -gt 0 &&
test `printf "$ttt$ttt$sss" | git stripspace | wc -l` -gt 0 &&
- test `printf "$ttt$ttt$ttt$sss" | git stripspace | wc -l` -gt 0
+ test `printf "$ttt$ttt$ttt$sss" | git stripspace | wc -l` -gt 0 &&
test `printf "$ttt$sss$sss" | git stripspace | wc -l` -gt 0 &&
test `printf "$ttt$ttt$sss$sss" | git stripspace | wc -l` -gt 0 &&
test `printf "$ttt$sss$sss$sss" | git stripspace | wc -l` -gt 0
@@ -340,13 +329,13 @@ test_expect_success \
printf "" >expect &&
printf "" | git stripspace >actual &&
- git diff expect actual
+ git diff expect actual &&
printf "$sss$sss" | git stripspace >actual &&
- git diff expect actual
+ git diff expect actual &&
printf "$sss$sss$sss" | git stripspace >actual &&
- git diff expect actual
+ git diff expect actual &&
printf "$sss$sss$sss$sss" | git stripspace >actual &&
git diff expect actual
--
1.5.0
^ permalink raw reply related
* [PATCH 2/2] t0030: Add tests with consecutive text lines and others with spaces added.
From: Carlos Rica @ 2007-07-10 21:59 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin
Previous tests only had paragraphs of one line. This commit adds some
tests to check when many consecutive text lines are given.
Also, it adds tests for checking that many lines between paragraphs are
correctly reduced to one when there are tabs and spaces in those lines.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
These were used in the development of the new in-place version
of the stripspace function, which acts on a buffer instead
on file descriptors. The first version I wrote passed the
previous tests but it was completely broken in these cases.
t/t0030-stripspace.sh | 51 +++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/t/t0030-stripspace.sh b/t/t0030-stripspace.sh
index 4a2980c..b1c9003 100755
--- a/t/t0030-stripspace.sh
+++ b/t/t0030-stripspace.sh
@@ -81,6 +81,30 @@ test_expect_success \
printf "$ttt\n\n$ttt$ttt$ttt\n" > expect &&
printf "$ttt\n\n\n\n\n$ttt$ttt$ttt\n" | git stripspace >actual &&
+ git diff expect actual &&
+
+ printf "$ttt\n\n$ttt\n" > expect &&
+ printf "$ttt\n\t\n \n\n \t\t\n$ttt\n" | git stripspace >actual &&
+ git diff expect actual &&
+
+ printf "$ttt$ttt\n\n$ttt\n" > expect &&
+ printf "$ttt$ttt\n\t\n \n\n \t\t\n$ttt\n" | git stripspace >actual &&
+ git diff expect actual &&
+
+ printf "$ttt$ttt$ttt\n\n$ttt\n" > expect &&
+ printf "$ttt$ttt$ttt\n\t\n \n\n \t\t\n$ttt\n" | git stripspace >actual &&
+ git diff expect actual &&
+
+ printf "$ttt\n\n$ttt\n" > expect &&
+ printf "$ttt\n\t\n \n\n \t\t\n$ttt\n" | git stripspace >actual &&
+ git diff expect actual &&
+
+ printf "$ttt\n\n$ttt$ttt\n" > expect &&
+ printf "$ttt\n\t\n \n\n \t\t\n$ttt$ttt\n" | git stripspace >actual &&
+ git diff expect actual &&
+
+ printf "$ttt\n\n$ttt$ttt$ttt\n" > expect &&
+ printf "$ttt\n\t\n \n\n \t\t\n$ttt$ttt$ttt\n" | git stripspace >actual &&
git diff expect actual
'
@@ -341,4 +365,31 @@ test_expect_success \
git diff expect actual
'
+test_expect_success \
+ 'consecutive text lines should be unchanged' '
+ printf "$ttt$ttt\n$ttt\n" >expect &&
+ printf "$ttt$ttt\n$ttt\n" | git stripspace >actual &&
+ git diff expect actual &&
+
+ printf "$ttt\n$ttt$ttt\n$ttt\n" >expect &&
+ printf "$ttt\n$ttt$ttt\n$ttt\n" | git stripspace >actual &&
+ git diff expect actual &&
+
+ printf "$ttt\n$ttt\n$ttt\n$ttt$ttt\n" >expect &&
+ printf "$ttt\n$ttt\n$ttt\n$ttt$ttt\n" | git stripspace >actual &&
+ git diff expect actual &&
+
+ printf "$ttt\n$ttt\n\n$ttt$ttt\n$ttt\n" >expect &&
+ printf "$ttt\n$ttt\n\n$ttt$ttt\n$ttt\n" | git stripspace >actual &&
+ git diff expect actual &&
+
+ printf "$ttt$ttt\n\n$ttt\n$ttt$ttt\n" >expect &&
+ printf "$ttt$ttt\n\n$ttt\n$ttt$ttt\n" | git stripspace >actual &&
+ git diff expect actual &&
+
+ printf "$ttt\n$ttt$ttt\n\n$ttt\n" >expect &&
+ printf "$ttt\n$ttt$ttt\n\n$ttt\n" | git stripspace >actual &&
+ git diff expect actual
+'
+
test_done
--
1.5.0
^ permalink raw reply related
* Re: pushing changes to a remote branch
From: Jeff King @ 2007-07-10 22:04 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git discussion list
In-Reply-To: <844FC382-DFB3-4762-93C2-6512612136AC@silverinsanity.com>
On Tue, Jul 10, 2007 at 02:10:01PM -0400, Brian Gernhardt wrote:
> Perhaps git-commit should also also output a warning? "Commit made on
> detached HEAD. Use "git branch <new_branch_name>" to save your commit"?
> That's bad wording, but the idea is there.
There was much discussion in this area, and the conclusion (and current
behavior) is:
1. Notify about the state change to detached HEAD, since some commands
will be subtly different.
2. Don't warn about commiting on detached HEAD, since there is nothing
technically wrong with it.
3. When moving away from detached HEAD, print the previous HEAD
position, so the user knows what might have been lost.
See this message (and a bunch of surrounding messages):
http://article.gmane.org/gmane.comp.version-control.git/38254
It would be nice if we could allow (3) only when commits weren't being
lost, but that would require doing a reachability analysis from all
refs, which is expensive. The reflog for HEAD makes those commits
recoverable, as well.
Personally, I think (2) (commits on detached HEAD) should simply be
disallowed, since it is simple enough to 'git checkout -b newbranch' as
an override (and I have not personally found a need for commits on
detached HEAD, anyway), and it saves the exact newbie error that Martin
ran into. But others obviously disagree.
-Peff
^ permalink raw reply
* Re: git-filter-branch exits early
From: Johannes Schindelin @ 2007-07-10 21:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Sven Verdoolaege
In-Reply-To: <20070710205202.GA3212@steel.home>
Hi,
On Tue, 10 Jul 2007, Alex Riesen wrote:
> I have a Debian system where git-filter-branch exits immediately after
> "unset CDPATH" in git-sh-setup (the command exits with 1, as CDPATH is
> not defined). The system still has bash-2.05a.
>
> git-filter-branch has "set -e", which is why the script finishes
> prematurely. If this is not really needed, maybe it can be removed?
>
> I'll see if the system can be upgraded, but I suspect someone can get
> a similar problem.
I do not really understand why "unset CDPATH" should trigger an error. I
guess that this is one of the nice braindamages in dash, right?
Anyway, "set -e" was one thing I wanted to fix. But I'm not sure I want
to work on filter-branch now, what with skimo (possibly? hopefully?)
working on my wishlist for rewrite-commits. If rewrite-commits gets the
features I wished for, IMHO filter-branch is obsolete.
Using rewrite-commits would have a couple of advantages:
- the name is much better,
- since we have reflogs enabled by default now, there is really no good
reason why you should have to copy the rewritten branches back to their
original name (we would need a way to redirect that, though, for
example for subdirectory filters),
- it is faster,
- since it is a C program, it should be more stable, eventually, than a
shell script, where you have to work around limitations all the time,
- with the trick I described in the mail to skimo, you can have
convenience functions (think "map") in the commit filter, too,
- and it would be less work for me.
Your case is a really good illustration for why C is a better language
than shell in the long run.
Oh, BTW, if the index filter gets the current (original) commit SHA1 as an
environment variable, like it does in filter-branch, it can act as a
the first half of a subdirectory filter:
--index-filter "git read-tree $COMMIT_SHA1:sub/directory/"
The second half of it is to add "-- sub/directory/" to the command line.
Ciao,
Dscho
^ permalink raw reply
* RE: git-svn set-tree
From: Joakim Tjernlund @ 2007-07-10 22:45 UTC (permalink / raw)
To: 'Eric Wong'; +Cc: git
In-Reply-To: <20070709054541.GA2301@mayonaise>
> -----Original Message-----
> From: Eric Wong [mailto:normalperson@yhbt.net]
> Sent: den 9 juli 2007 07:46
> To: Tjernlund
> Cc: git@vger.kernel.org
> Subject: Re: git-svn set-tree
>
> Tjernlund <tjernlund@tjernlund.se> wrote:
> > I have noticed that if I do a git-svn set-tree, remotes/git-svn
> > retains the parent from the branch where set-tree was performed.
> >
> > If a coworker wants recreate my tree by using git-svn init
> && git-svn
> > fetch he looses the parent I have in my tree.
> >
> > I wonder if not git-svn set-tree can record the parent
> information in
> > the svn repos log, so that git-svn init/fetch can recreate
> the parent
> > relationship?
>
> We could at yet another non-standardized property into SVN to handle
> merges. Currently there are at least two properties used in
> the SVN/SVK
> world to represent merges (Sam Vilain can give you the fun details of
> each one!).
I have read his page, quite informative.
>
> I'm afraid adding a third incompatible yet similair property
> for git-svn
> would just confuse people.
>
> I've become very much against crazy stuff like set-tree which ends up
> creating a M:N history mapping between git and svn. 1:1 is
> the simplest
> and easiest. I'm more than willing to sacrifice multi-parent
> histories
> in git for easier compatibility with other systems.
set-tree is needed for starting a SVN tree from a git tree, I don't
know of any other way to do that. I got both linux and u-boot
git trees in which I do custom mods. I then use git-svn
to maintain a svn tree which I start with set-tree to commit
the initial tree, then I dcommit my local mods.
Maybe maybe an option to git-svn init/clone where you can specify the git
parent for a certain svn revision?
>
> Heck, linear history is just easier to deal with and probably
> preferable
> in most/many cases. I'm sure that the rising popularity of
> git-rebase,
> quilt, stgit, guilt, mq and other like tools is a testament to that.
>
git rebase is a bit annoying as you loose the old tree if you don't take precations.
Also, I am not sure what will be committed to SVN if I rebase my local mods on top
of linus latest.
Jocke
> --
> Eric Wong
>
^ permalink raw reply
* [PATCH] t7004: Add tests for the git tag -n option.
From: Carlos Rica @ 2007-07-10 23:11 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin
These tests check the syntax for the git tag -n option
and its output when one, none or many lines of the
message are requested.
Also this commit adds a missing && in the test
that checks the sorted output of git tag -l.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
t/t7004-tag.sh | 202 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 201 insertions(+), 1 deletions(-)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index b785080..17de2a9 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -164,7 +164,7 @@ test_expect_success 'listing all tags should print them ordered' '
git tag a1 &&
git tag v1.0 &&
git tag t210 &&
- git tag -l > actual
+ git tag -l > actual &&
git diff expect actual
'
@@ -437,6 +437,106 @@ test_expect_success \
git diff expect actual
'
+# listing messages for annotated non-signed tags:
+
+test_expect_success \
+ 'listing the one-line message of a non-signed tag should succeed' '
+ git-tag -m "A msg" tag-one-line &&
+
+ echo "tag-one-line" >expect &&
+ git-tag -l | grep "^tag-one-line" >actual &&
+ git diff expect actual &&
+ git-tag -n 0 -l | grep "^tag-one-line" >actual &&
+ git diff expect actual &&
+ git-tag -n 0 -l tag-one-line >actual &&
+ git diff expect actual &&
+
+ echo "tag-one-line A msg" >expect &&
+ git-tag -n xxx -l | grep "^tag-one-line" >actual &&
+ git diff expect actual &&
+ git-tag -n "" -l | grep "^tag-one-line" >actual &&
+ git diff expect actual &&
+ git-tag -n 1 -l | grep "^tag-one-line" >actual &&
+ git diff expect actual &&
+ git-tag -n -l | grep "^tag-one-line" >actual &&
+ git diff expect actual &&
+ git-tag -n 1 -l tag-one-line >actual &&
+ git diff expect actual &&
+ git-tag -n 2 -l tag-one-line >actual &&
+ git diff expect actual &&
+ git-tag -n 999 -l tag-one-line >actual &&
+ git diff expect actual
+'
+
+test_expect_success \
+ 'listing the zero-lines message of a non-signed tag should succeed' '
+ git-tag -m "" tag-zero-lines &&
+
+ echo "tag-zero-lines" >expect &&
+ git-tag -l | grep "^tag-zero-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n 0 -l | grep "^tag-zero-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n 0 -l tag-zero-lines >actual &&
+ git diff expect actual &&
+
+ echo "tag-zero-lines " >expect &&
+ git-tag -n 1 -l | grep "^tag-zero-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n -l | grep "^tag-zero-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n 1 -l tag-zero-lines >actual &&
+ git diff expect actual &&
+ git-tag -n 2 -l tag-zero-lines >actual &&
+ git diff expect actual &&
+ git-tag -n 999 -l tag-zero-lines >actual &&
+ git diff expect actual
+'
+
+echo 'tag line one' >annotagmsg
+echo 'tag line two' >>annotagmsg
+echo 'tag line three' >>annotagmsg
+test_expect_success \
+ 'listing many message lines of a non-signed tag should succeed' '
+ git-tag -F annotagmsg tag-lines &&
+
+ echo "tag-lines" >expect &&
+ git-tag -l | grep "^tag-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n 0 -l | grep "^tag-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n 0 -l tag-lines >actual &&
+ git diff expect actual &&
+
+ echo "tag-lines tag line one" >expect &&
+ git-tag -n 1 -l | grep "^tag-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n -l | grep "^tag-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n 1 -l tag-lines >actual &&
+ git diff expect actual &&
+
+ echo " tag line two" >>expect &&
+ git-tag -n 2 -l | grep "^ *tag.line" >actual &&
+ git diff expect actual &&
+ git-tag -n 2 -l tag-lines >actual &&
+ git diff expect actual &&
+
+ echo " tag line three" >>expect &&
+ git-tag -n 3 -l | grep "^ *tag.line" >actual &&
+ git diff expect actual &&
+ git-tag -n 3 -l tag-lines >actual &&
+ git diff expect actual &&
+ git-tag -n 4 -l | grep "^ *tag.line" >actual &&
+ git diff expect actual &&
+ git-tag -n 4 -l tag-lines >actual &&
+ git diff expect actual &&
+ git-tag -n 99 -l | grep "^ *tag.line" >actual &&
+ git diff expect actual &&
+ git-tag -n 99 -l tag-lines >actual &&
+ git diff expect actual
+'
+
# trying to verify annotated non-signed tags:
test_expect_success \
@@ -651,6 +751,106 @@ test_expect_success \
git-tag -v commentnonlfile-signed-tag
'
+# listing messages for signed tags:
+
+test_expect_success \
+ 'listing the one-line message of a signed tag should succeed' '
+ git-tag -s -m "A message line signed" stag-one-line &&
+
+ echo "stag-one-line" >expect &&
+ git-tag -l | grep "^stag-one-line" >actual &&
+ git diff expect actual &&
+ git-tag -n 0 -l | grep "^stag-one-line" >actual &&
+ git diff expect actual &&
+ git-tag -n 0 -l stag-one-line >actual &&
+ git diff expect actual &&
+
+ echo "stag-one-line A message line signed" >expect &&
+ git-tag -n xxx -l | grep "^stag-one-line" >actual &&
+ git diff expect actual &&
+ git-tag -n "" -l | grep "^stag-one-line" >actual &&
+ git diff expect actual &&
+ git-tag -n 1 -l | grep "^stag-one-line" >actual &&
+ git diff expect actual &&
+ git-tag -n -l | grep "^stag-one-line" >actual &&
+ git diff expect actual &&
+ git-tag -n 1 -l stag-one-line >actual &&
+ git diff expect actual &&
+ git-tag -n 2 -l stag-one-line >actual &&
+ git diff expect actual &&
+ git-tag -n 999 -l stag-one-line >actual &&
+ git diff expect actual
+'
+
+test_expect_success \
+ 'listing the zero-lines message of a signed tag should succeed' '
+ git-tag -s -m "" stag-zero-lines &&
+
+ echo "stag-zero-lines" >expect &&
+ git-tag -l | grep "^stag-zero-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n 0 -l | grep "^stag-zero-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n 0 -l stag-zero-lines >actual &&
+ git diff expect actual &&
+
+ echo "stag-zero-lines " >expect &&
+ git-tag -n 1 -l | grep "^stag-zero-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n -l | grep "^stag-zero-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n 1 -l stag-zero-lines >actual &&
+ git diff expect actual &&
+ git-tag -n 2 -l stag-zero-lines >actual &&
+ git diff expect actual &&
+ git-tag -n 999 -l stag-zero-lines >actual &&
+ git diff expect actual
+'
+
+echo 'stag line one' >sigtagmsg
+echo 'stag line two' >>sigtagmsg
+echo 'stag line three' >>sigtagmsg
+test_expect_success \
+ 'listing many message lines of a signed tag should succeed' '
+ git-tag -s -F sigtagmsg stag-lines &&
+
+ echo "stag-lines" >expect &&
+ git-tag -l | grep "^stag-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n 0 -l | grep "^stag-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n 0 -l stag-lines >actual &&
+ git diff expect actual &&
+
+ echo "stag-lines stag line one" >expect &&
+ git-tag -n 1 -l | grep "^stag-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n -l | grep "^stag-lines" >actual &&
+ git diff expect actual &&
+ git-tag -n 1 -l stag-lines >actual &&
+ git diff expect actual &&
+
+ echo " stag line two" >>expect &&
+ git-tag -n 2 -l | grep "^ *stag.line" >actual &&
+ git diff expect actual &&
+ git-tag -n 2 -l stag-lines >actual &&
+ git diff expect actual &&
+
+ echo " stag line three" >>expect &&
+ git-tag -n 3 -l | grep "^ *stag.line" >actual &&
+ git diff expect actual &&
+ git-tag -n 3 -l stag-lines >actual &&
+ git diff expect actual &&
+ git-tag -n 4 -l | grep "^ *stag.line" >actual &&
+ git diff expect actual &&
+ git-tag -n 4 -l stag-lines >actual &&
+ git diff expect actual &&
+ git-tag -n 99 -l | grep "^ *stag.line" >actual &&
+ git diff expect actual &&
+ git-tag -n 99 -l stag-lines >actual &&
+ git diff expect actual
+'
+
# tags pointing to objects different from commits:
tree=$(git rev-parse HEAD^{tree})
--
1.5.0
^ permalink raw reply related
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