* Re: [PATCH] t6024: fix timing problem
From: Johannes Schindelin @ 2006-12-12 23:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvekgog0r.fsf@assigned-by-dhcp.cox.net>
hI,
On Tue, 12 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This script tests a complicated merge, where _all_ files conflict. In
> > these circumstances, the ordering of the commits -- which is affected
> > not by the timestamps in the commit message -- becomes a deciding factor
> > of the merge result.
>
> "not by the timestamps", or "by the timestamps"? I am confused...
I deleted the "only", but not the "not" in front of it. Should have read
my mail before sending... Sorry.
> Do you mean the commit timestamps affect which merge base commit becomes
> ours and theirs during the computation of the virtual merge base commit?
> That certainly explains the problem.
It affects in which order the merge bases are merged. I remember that I
made a case for the oldest merge base to go first. If two of them (or all
three!) have the same timestamp, I _think_ they are ordered by SHA1...
Now, the problem here is that two of the merge bases have a common merge
base, but the third has a completely different root. So, depending on
which merge base goes first, the add/add conflict can remove the file from
the index early, in which case the next merge does not find a stage 1.
> > How about this: if there is an add/add conflict, we treat it as
> > if there _was_ an empty file, and we let the shiny new xdl_merge()
> > find the _true_ conflicts, _instead of_ removing the file from
> > the index, adding both files with different "~blabla" markers
> > appended to their file names to the working directory.
>
> I was not thinking about this t6024 test failure problem but was
> wondering about doing exactly that in merge-recursive to match
> the "two file merge" magic we have in git-merge-one-file.sh ---
> I guess great minds do think alike ;-).
*beams* Gee, thanks!
Ciao,
Dscho
^ permalink raw reply
* Re: Using git as a general backup mechanism (was Re: Using GIT to store /etc)
From: Johannes Schindelin @ 2006-12-13 0:01 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <457F3606.7020805@midwinter.com>
Hi,
On Tue, 12 Dec 2006, Steven Grimm wrote:
> Johannes Schindelin wrote:
> > $ git pull --depth 1
> >
> > Though it needs a server _and_ a client supporting shallow clones,
> > which support is brewed in "next" right now.
>
> Will that actually discard old revisions that are already stored
> locally?
No. A pull should _never_ lose anything from the repository. However, if
some objects become no-longer reachable (and at the moment it looks like
we cut of history, even if we should not need to), they can be pruned from
the repo.
Hth,
Dscho
^ permalink raw reply
* Re: t9100-git-svn-basic.sh fails
From: Johannes Schindelin @ 2006-12-13 0:03 UTC (permalink / raw)
To: Sebastian Harl; +Cc: git
In-Reply-To: <20061212232321.GL2476@albany.tokkee.org>
Hi,
On Wed, 13 Dec 2006, Sebastian Harl wrote:
> When compiling git 1.4.4.2 on my Debian Sarge box t9100-git-svn-basic.sh
> fails with the following output:
>
> * FAIL 6: detect node change from directory to file #1
> git-svn commit --find-copies-harder --rmdir \
> remotes/git-svn..mybranch2
Could you please run the test like this:
git/t> sh t9100-* -i -v
The "-i" tells it to stop when a test fails, and "-v" makes it verbose.
Ciao,
^ permalink raw reply
* Re: [RFC/PATCH] runstatus: restructure visual appearance
From: Junio C Hamano @ 2006-12-13 0:46 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <8c5c35580612120330n36bcdd00p57b2a7cd1d6c801@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> On 12/2/06, Lars Hjemli <hjemli@gmail.com> wrote:
>> This is a rather subjective 'improvement', but I think it makes the commit
>> message easier to comprehend and I hope that goes for both new and
>> experienced users.
>
> Just wondering if this patch got dropped or simply overlooked...
I looked at the patch, and I was neutral to slightly negative
(but only slightly. I thought M vs M+ was too subtle and
cryptic until the user gets used to them).
I however did not see overwhelming support from the list, so I
did not further think about it.
One thing that was mentioned in the past on the list about the
output from git-status was that we do not make mode changes
stand out, and people can mistakenly do something silly to
change the -x bit and the current git-status would only say:
modified: git-foobar.sh
which would not help them notice the mistake, as a result,
accidental mode change can get committed.
If we are designing a new format to make git-status output more
compact and easier to understand, I think it should also attempt
to address this problem as well.
^ permalink raw reply
* Re: t9100-git-svn-basic.sh fails
From: Eric Wong @ 2006-12-13 1:01 UTC (permalink / raw)
To: Sebastian Harl; +Cc: git
In-Reply-To: <20061212232321.GL2476@albany.tokkee.org>
Sebastian Harl <sh@tokkee.org> wrote:
> Hi,
>
> When compiling git 1.4.4.2 on my Debian Sarge box t9100-git-svn-basic.sh fails
> with the following output:
>
> * FAIL 6: detect node change from directory to file #1
> git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch2
>
> I'm using subversion 1.3.2.
>
> Versions up to 1.4.3.2 built fine.
>
> Any clues what this might be caused by?
Are you using the svn command-line client or are the Perl SVN libraries
installed? I made a fix for people using version 1.4.x of the the
command-line client, but I recall backwards compatibility was preserved
as far as svn 1.1 goes.
--
^ permalink raw reply
* [PATCH 4/3] git-svn: correctly handle packed-refs in refs/remotes/
From: Eric Wong @ 2006-12-13 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11659636263755-git-send-email-normalperson@yhbt.net>
We now use git-rev-parse universally to read refs, instead
of our own file_to_s function (which I plan on removing).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 1f8a3b0..aac8f73 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2016,9 +2016,17 @@ sub git_commit {
# just in case we clobber the existing ref, we still want that ref
# as our parent:
- if (my $cur = eval { file_to_s("$GIT_DIR/refs/remotes/$GIT_SVN") }) {
+ open my $null, '>', '/dev/null' or croak $!;
+ open my $stderr, '>&', \*STDERR or croak $!;
+ open STDERR, '>&', $null or croak $!;
+ if (my $cur = eval { safe_qx('git-rev-parse',
+ "refs/remotes/$GIT_SVN^0") }) {
+ chomp $cur;
push @tmp_parents, $cur;
}
+ open STDERR, '>&', $stderr or croak $!;
+ close $stderr or croak $!;
+ close $null or croak $!;
if (exists $tree_map{$tree}) {
foreach my $p (@{$tree_map{$tree}}) {
--
1.4.4.2.g6f98
^ permalink raw reply related
* Re: [PATCH 4/3] git-svn: correctly handle packed-refs in refs/remotes/
From: Junio C Hamano @ 2006-12-13 1:27 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061213004500.GA17811@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
> We now use git-rev-parse universally to read refs, instead
> of our own file_to_s function (which I plan on removing).
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> ---
> git-svn.perl | 10 +++++++++-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 1f8a3b0..aac8f73 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -2016,9 +2016,17 @@ sub git_commit {
>
> # just in case we clobber the existing ref, we still want that ref
> # as our parent:
> - if (my $cur = eval { file_to_s("$GIT_DIR/refs/remotes/$GIT_SVN") }) {
> + open my $null, '>', '/dev/null' or croak $!;
> + open my $stderr, '>&', \*STDERR or croak $!;
> + open STDERR, '>&', $null or croak $!;
> + if (my $cur = eval { safe_qx('git-rev-parse',
> + "refs/remotes/$GIT_SVN^0") }) {
> + chomp $cur;
> push @tmp_parents, $cur;
> }
> + open STDERR, '>&', $stderr or croak $!;
> + close $stderr or croak $!;
> + close $null or croak $!;
>
> if (exists $tree_map{$tree}) {
> foreach my $p (@{$tree_map{$tree}}) {
It's a neat trick you do to stash away STDERR and redirect to
/dev/null ;-). It might be worth doing something like this:
sub without_stderr {
my ($cmd, @param) = @_;
# stash away magic
my @return = eval {
safe_qx($cmd, @param);
};
# restore magic
return @return;
}
in Git.pm?
Then the caller would do something like this instead:
sub git_commit {
...
if (my ($cur) = without_stderr(qw(git rev-parse --verify),
"refs/remotes/$GIT_SVN^0")) {
...
^ permalink raw reply
* Re: [PATCH] Move Fink and Ports check to after config file
From: Brian Gernhardt @ 2006-12-13 1:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce
In-Reply-To: <7vslfkpwcn.fsf@assigned-by-dhcp.cox.net>
On Dec 12, 2006, at 5:45 PM, Junio C Hamano wrote:
> First time I saw this today I said "I'd swear I've seen this".
>
> I guess after I asked for a confirmation from you I simply
> forgot to apply it. Thanks for a reminder.
'salright. I got so used to "git rebase origin/master" that I forgot
that I had brought it up. Oh, well. Discussing the perl/Makefile
issue reminded me that I had this sitting in my tree.
^ permalink raw reply
* Re: [PATCH 4/3] git-svn: correctly handle packed-refs in refs/remotes/
From: Eric Wong @ 2006-12-13 2:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlklcmvoo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > We now use git-rev-parse universally to read refs, instead
> > of our own file_to_s function (which I plan on removing).
> >
> > Signed-off-by: Eric Wong <normalperson@yhbt.net>
> > ---
> > git-svn.perl | 10 +++++++++-
> > 1 files changed, 9 insertions(+), 1 deletions(-)
> >
> > diff --git a/git-svn.perl b/git-svn.perl
> > index 1f8a3b0..aac8f73 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -2016,9 +2016,17 @@ sub git_commit {
> >
> > # just in case we clobber the existing ref, we still want that ref
> > # as our parent:
> > - if (my $cur = eval { file_to_s("$GIT_DIR/refs/remotes/$GIT_SVN") }) {
> > + open my $null, '>', '/dev/null' or croak $!;
> > + open my $stderr, '>&', \*STDERR or croak $!;
> > + open STDERR, '>&', $null or croak $!;
> > + if (my $cur = eval { safe_qx('git-rev-parse',
> > + "refs/remotes/$GIT_SVN^0") }) {
> > + chomp $cur;
> > push @tmp_parents, $cur;
> > }
> > + open STDERR, '>&', $stderr or croak $!;
> > + close $stderr or croak $!;
> > + close $null or croak $!;
> >
> > if (exists $tree_map{$tree}) {
> > foreach my $p (@{$tree_map{$tree}}) {
>
> It's a neat trick you do to stash away STDERR and redirect to
> /dev/null ;-). It might be worth doing something like this:
I also did it for libsvn_get_file() with STDOUT :)
> sub without_stderr {
> my ($cmd, @param) = @_;
> # stash away magic
> my @return = eval {
> safe_qx($cmd, @param);
> };
> # restore magic
> return @return;
> }
>
> in Git.pm?
Looking at Git.pm for the first time, it seems that _command_common_pipe
(and all it's users) already support closing/redirecting STDERR.
I'll look into revamping git-svn to use Git.pm sometime tonight or
tomorrow.
--
^ permalink raw reply
* Re: GIT - releases workflow
From: Linus Torvalds @ 2006-12-13 2:43 UTC (permalink / raw)
To: Sean Kelley; +Cc: git
In-Reply-To: <89b129c60612121444t18ba94ecv57eea4c72be1663a@mail.gmail.com>
On Tue, 12 Dec 2006, Sean Kelley wrote:
>
> I was wondering if anyone could share ideas on how best to use GIT to
> handle releases for those working with a remote GIT repository? Do
> you create a branch and push it to the remote? Thus you have a new
> branch referencing the particular release?
I don't think there is a "right" model, but at least _one_ model is what
the kernel uses:
- the actual "release" is just tagged
- any release development (ie "maintenance") is literally done in a
totally separate repository, both from a development standpoint _and_
an actual release management standpoint.
This may sound strange, but it actually has what I consider to be huge
advantages:
- it fits very well in the "distributed" mental model
- it makes the separation of "maintenance" and "development" very very
clear. It's clear at all levels that the two are not the same thing,
don't have the same goals, and often not done by even the same groups,
or even by same management.
I think the second point is actually important.
At the same time, the distributed model of git means that if you want to
mix the two trees, you easily can: you just fetch from the two independent
release trees into the same repository. So the fact that they are
maintained completely independently doesn't mean that they can't be
joined, it just means that there's a clear separation at all levels.
Also note how _different_ releases may well end up having _separate_
repositories. So it's not that there is "one repository for development,
and one repository for maintenance". It's literally "one repository for
_each_ release maintenance".
Now, I think this kind of "separate repository for release maintenance
trees" is actually a great model, and I think it can make perfect sense in
various commercial/proprietary settings too (ie I know from experience
that you tend to often have separate groups and very different rules for
maintenance, so having the separate repository really does make sense).
But at the same time, for a smaller project, it obviously does NOT make
sense. Git itself, for example, just has a "maint" branch, and does
everything with the same maintainer, and in the same repository. Within
something like git, that makes sense, because there just isn't a separate
"stable tree maintainer", and trying to enforce that kind of thing would
just be insane anyway within the setting of git.
So in some settings, you might just have a branch for each stable release,
or as in the case of git, just a single branch for "maintenance", just
because nobody is going to maintain older releases really at all (that
might change with time, of course, but I think it's a pretty common
pattern for smaller projects).
In short: I don't think there is "one correct way" to do these things.
^ permalink raw reply
* [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Johannes Schindelin @ 2006-12-13 3:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvekgog0r.fsf@assigned-by-dhcp.cox.net>
Unify the handling for cases C (add/add) and D (modify/modify).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 12 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > How about this: if there is an add/add conflict, we treat it
> > as if there _was_ an empty file, and we let the shiny new
> > xdl_merge() find the _true_ conflicts, _instead of_ removing
> > the file from the index, adding both files with different
> > "~blabla" markers appended to their file names to the working
> > directory.
>
> I was not thinking about this t6024 test failure problem but was
> wondering about doing exactly that in merge-recursive to match
> the "two file merge" magic we have in git-merge-one-file.sh
As can be seen with the test case, the result is more pleasing.
merge-recursive.c | 44 +++++++++++++++-----------------------------
t/t6024-recursive-merge.sh | 12 +++++++++++-
2 files changed, 26 insertions(+), 30 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 7d203a6..5bec599 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -610,6 +610,12 @@ static void fill_mm(const unsigned char *sha1, mmfile_t *mm)
unsigned long size;
char type[20];
+ if (!hashcmp(sha1, null_sha1)) {
+ mm->ptr = xstrdup("");
+ mm->size = 0;
+ return;
+ }
+
mm->ptr = read_sha1_file(sha1, type, &size);
if (!mm->ptr || strcmp(type, blob_type))
die("unable to read blob object %s", sha1_to_hex(sha1));
@@ -1045,38 +1051,17 @@ static int process_entry(const char *path, struct stage_data *entry,
output("Adding %s", path);
update_file(1, sha, mode, path);
}
- } else if (!o_sha && a_sha && b_sha) {
- /* Case C: Added in both (check for same permissions). */
- if (sha_eq(a_sha, b_sha)) {
- if (a_mode != b_mode) {
- clean_merge = 0;
- output("CONFLICT: File %s added identically in both branches, "
- "but permissions conflict %06o->%06o",
- path, a_mode, b_mode);
- output("CONFLICT: adding with permission: %06o", a_mode);
- update_file(0, a_sha, a_mode, path);
- } else {
- /* This case is handled by git-read-tree */
- assert(0 && "This case must be handled by git-read-tree");
- }
- } else {
- const char *new_path1, *new_path2;
- clean_merge = 0;
- new_path1 = unique_path(path, branch1);
- new_path2 = unique_path(path, branch2);
- output("CONFLICT (add/add): File %s added non-identically "
- "in both branches. Adding as %s and %s instead.",
- path, new_path1, new_path2);
- remove_file(0, path, 0);
- update_file(0, a_sha, a_mode, new_path1);
- update_file(0, b_sha, b_mode, new_path2);
- }
-
- } else if (o_sha && a_sha && b_sha) {
+ } else if (a_sha && b_sha) {
+ /* Case C: Added in both (check for same permissions) and */
/* case D: Modified in both, but differently. */
+ const char *reason = "content";
struct merge_file_info mfi;
struct diff_filespec o, a, b;
+ if (!o_sha) {
+ reason = "add/add";
+ o_sha = (unsigned char *)null_sha1;
+ }
output("Auto-merging %s", path);
o.path = a.path = b.path = (char *)path;
hashcpy(o.sha1, o_sha);
@@ -1093,7 +1078,8 @@ static int process_entry(const char *path, struct stage_data *entry,
update_file(1, mfi.sha, mfi.mode, path);
else {
clean_merge = 0;
- output("CONFLICT (content): Merge conflict in %s", path);
+ output("CONFLICT (%s): Merge conflict in %s",
+ reason, path);
if (index_only)
update_file(0, mfi.sha, mfi.mode, path);
diff --git a/t/t6024-recursive-merge.sh b/t/t6024-recursive-merge.sh
index 9416c27..964010e 100644
--- a/t/t6024-recursive-merge.sh
+++ b/t/t6024-recursive-merge.sh
@@ -58,9 +58,19 @@ GIT_AUTHOR_DATE="2006-12-12 23:00:08" git commit -m F
test_expect_failure "combined merge conflicts" "git merge -m final G"
+cat > expect << EOF
+<<<<<<< HEAD/a1
+F
+=======
+G
+>>>>>>> 26f86b677eb03d4d956dbe108b29cb77061c1e73/a1
+EOF
+
+test_expect_success "result contains a conflict" "diff -u expect a1"
+
git ls-files --stage > out
cat > expect << EOF
-100644 f70f10e4db19068f79bc43844b49f3eece45c4e8 1 a1
+100644 f16f906ab60483c100d1241dfc39868de9ec9fcb 1 a1
100644 cf84443e49e1b366fac938711ddf4be2d4d1d9e9 2 a1
100644 fd7923529855d0b274795ae3349c5e0438333979 3 a1
EOF
--
^ permalink raw reply related
* Re: [PATCH] git-add --interactive (wip)
From: Josef Weidendorfer @ 2006-12-13 3:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vwt4wpytm.fsf@assigned-by-dhcp.cox.net>
On Tuesday 12 December 2006 22:51, Junio C Hamano wrote:
> I've updated my "git add --interactive" in 'pu' and it now knows
> how to split a hunk into smaller pieces and recounting the diff
> offsets before applying
Nice.
Yes, this seems to be a missing piece in this hunk-wise staging.
> To make it easier, one possibility might be to add a subcommand
> to "git add --interactive" that lets you edit what is currently
> staged in the index by opening a temporary copy in your favorite
> editor, and stage the result of your edit in the index.
Yes. Sounds interesting.
Another would be to open the editor with the diff of this hunk.
> But I
> feel quite uneasy to introduce ways to update the index with
> something _wildly_ different from what you ever had in your
> working tree as a whole.
Hmm... yes.
Is this not a general problem with staging, of course to
a lesser degree if you work at file granularity, because
the probability of dependence of changes in multiple files,
which could lead to a wrong commit, is less.
> I think it is wrong to commit partially, purely from the index,
> when you are building a series that has complex changes that
> come during the series but go away at the end. The user should
> be able to verify all the steps in the middle in such a complex
> series, but it is not easy if you have it only in the index.
What you really want is to test the commit afterwards. If
you did it wrong, you always can do "git reset --mixed HEAD^"
or "git commit --amend".
However, testing a commit with a dirty working tree is not
possible. For this to work, you would want that
"git-checkout --store" can store away a dirty working state when
going to another revision, e.g. store it into a temporary ref
"<current branch>.dirtywork".
You would need a "git-checkout --restore" which would restore
the dirty state of the branch you are switching too.
Then, to check the commit of staged things, it should be enough
to do "git-checkout --store", check the commit, and do a
"git-checkout --restore" afterwards to get the dirty state back.
> You could do
>
> $ git checkout-index --prefix=testarea/ -f -q -u -a
>
> and run your tests there, but that takes a discipline, and is
> cumbersome to do.
IMHO that is too tricky for the average git user.
> So in short, I think per-hunk update-index is a cute hack and
> may be useful in a narrow simple cases, but it would not be so
> useful in the real life.
No. It currently is starting to get useful. With the ability
to temporarily store away a dirty state of the working directory,
it really could become very good.
> > Just as a sidenote: after deciding to not apply hunks, you
> > lose them in this WIP, as you will find nothing in "unstaged" mode
> > afterwards :-(
>
> I do not understand this part. You can 'revert' to match the
> index to HEAD and run 'patch' to pick what you want again.
Hmmm...
I lost my changes in the working directory; there was nothing to
pick again any more.
Perhaps I did something wrong.
^ permalink raw reply
* Re: [PATCH] git-add --interactive (wip)
From: Junio C Hamano @ 2006-12-13 5:34 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200612130415.59038.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> No. It currently is starting to get useful. With the ability
> to temporarily store away a dirty state of the working directory,
> it really could become very good.
Hmm, a way to easily stash away local changes and restoring
would lead to a system where you can easily stash and unstash
multiple snapshots and switch between them, and such a model
sounds vaguely familiar...
>> > Just as a sidenote: after deciding to not apply hunks, you
>> > lose them in this WIP, as you will find nothing in "unstaged" mode
>> > afterwards :-(
>>
>> I do not understand this part. You can 'revert' to match the
>> index to HEAD and run 'patch' to pick what you want again.
>
> I lost my changes in the working directory; there was nothing to
> pick again any more.
That's worrysome. By design, "git add" should not touch working
tree at all (only read from there), so if you find cases that
violates it that should be fixed; please let me know.
^ permalink raw reply
* Re: Topic descriptions
From: Sam Vilain @ 2006-12-09 1:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7v4ps8y7un.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I think the right place to store that <anything at all>
> information is per-branch configuration item. Perhaps:
>
> [branch "ap/clone-origin"]
> description = we talk about what this thing does and \
> what the current status of it is.
>
> I am unlikely to use such a thing for the "What's in" message,
> though. The part that talks about "what the current status is"
> is much easier to write when I need to talk about "the current";
> otherwise I'd be forced to remember to think if I need to update
> the information, every time I touch topic branches.
And this information could even be put into the commit message of the
merge commit.
gitweb/repo could give a "dashboard" of feature branches;
- creator
- aim/description of feature branch
- (computed) mergability with master/trunk/etc (perhaps
config "merge target(s)")
- whether tests are passing on this branch (obviously not a
git-core feature, but a useful thing to know)
- how many new tests are introduced by this branch.
Some ideas that occurred from watching Martin Pool's talk on managing
distributed VCS with bzr, and the Patch Queue Manager.
Some people might like to include all of the above information in the
merge commit to close the branch, others just the non-redundant information.
Sam.
^ permalink raw reply
* Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Junio C Hamano @ 2006-12-13 6:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Catalin Marinas
In-Reply-To: <Pine.LNX.4.63.0612130402300.2807@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Unify the handling for cases C (add/add) and D (modify/modify).
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> On Tue, 12 Dec 2006, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > How about this: if there is an add/add conflict, we treat it
> > > as if there _was_ an empty file, and we let the shiny new
> > > xdl_merge() find the _true_ conflicts, _instead of_ removing
> > > the file from the index, adding both files with different
> > > "~blabla" markers appended to their file names to the working
> > > directory.
> >
> > I was not thinking about this t6024 test failure problem but was
> > wondering about doing exactly that in merge-recursive to match
> > the "two file merge" magic we have in git-merge-one-file.sh
>
> As can be seen with the test case, the result is more pleasing.
This fixes the behaviour in "both branches add the path
differently" case. Previously merge-recursive did not create
the working tree file, but now it does just like merge-resolve.
Although I would feel very happy about this change, Catalin
might want to be informed about potential interaction this
change might have with his commit 8d41555 in StGIT.
^ permalink raw reply
* Re: t9100-git-svn-basic.sh fails
From: Sebastian Harl @ 2006-12-13 8:46 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612130102000.2807@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]
Hi,
On Wed, Dec 13, 2006 at 01:03:21AM +0100, Johannes Schindelin wrote:
> On Wed, 13 Dec 2006, Sebastian Harl wrote:
>
> > When compiling git 1.4.4.2 on my Debian Sarge box t9100-git-svn-basic.sh
> > fails with the following output:
> >
> > * FAIL 6: detect node change from directory to file #1
> > git-svn commit --find-copies-harder --rmdir \
> > remotes/git-svn..mybranch2
>
> Could you please run the test like this:
>
> git/t> sh t9100-* -i -v
* expecting failure: git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch2
diff-tree 5d3b7d019e8fa8d509091bd1d80113c8f20f9f4f 91d77f97b74783aa97ba2aed5a966e936eb9d30f
Transaction is out of date: Out of date: 'test-git-svn/bar' in transaction '2-2' at /home/tokkee/projects/debian/backports/backports.org/git-core/git-core-1.4.4.2/t/../git-svn line 1573
65280 at /home/tokkee/projects/debian/backports/backports.org/git-core/git-core-1.4.4.2/t/../git-svn line 575
main::commit_lib('91d77f97b74783aa97ba2aed5a966e936eb9d30f') called at /home/tokkee/projects/debian/backports/backports.org/git-core/git-core-1.4.4.2/t/../git-svn line 481
main::commit('remotes/git-svn..mybranch2') called at /home/tokkee/projects/debian/backports/backports.org/git-core/git-core-1.4.4.2/t/../git-svn line 173
* FAIL 6: detect node change from directory to file #1
git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch2
Cheers,
Sebastian
--
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: t9100-git-svn-basic.sh fails
From: Sebastian Harl @ 2006-12-13 8:47 UTC (permalink / raw)
To: git
In-Reply-To: <20061213010103.GA18036@localdomain>
[-- Attachment #1: Type: text/plain, Size: 740 bytes --]
Hi,
On Tue, Dec 12, 2006 at 05:01:03PM -0800, Eric Wong wrote:
> Sebastian Harl <sh@tokkee.org> wrote:
> > When compiling git 1.4.4.2 on my Debian Sarge box t9100-git-svn-basic.sh fails
> > with the following output:
> >
> > * FAIL 6: detect node change from directory to file #1
> > git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch2
> >
> > I'm using subversion 1.3.2.
> >
> > Versions up to 1.4.3.2 built fine.
> >
> > Any clues what this might be caused by?
>
> Are you using the svn command-line client or are the Perl SVN libraries
> installed?
The Perl SVN libs are installed.
Cheers,
Sebastian
--
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-pull: "Cannot obtain needed none"?
From: Martin Waitz @ 2006-12-13 8:22 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0612120943i48c8597u32d0300cbbd7b3e8@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
hoi :)
On Tue, Dec 12, 2006 at 06:43:48PM +0100, Alex Riesen wrote:
> error: Unable to find 9a6e87b60dbd2305c95cecce7d9d60f849a0658d under
> http://www.kernel.org/pub/scm/git/git.git/
> Cannot obtain needed none 9a6e87b60dbd2305c95cecce7d9d60f849a0658d
> while processing commit 0000000000000000000000000000000000000000.
Yesterday I noticed the exact same message, but with a different sha1, in
the logs of my script which updated the linux kernel repository at work.
I did not have the time to track it down and today everything worked as
normal again.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* spurious .sp in manpages
From: Junio C Hamano @ 2006-12-13 8:58 UTC (permalink / raw)
To: git
This is just a random hack to work around problems people seem
to be seeing in manpage backend of xmlto (it appears we are
getting ".sp" at the end of line without line break).
Could people test this out?
---
diff --git a/Documentation/callouts.xsl b/Documentation/callouts.xsl
index ad03755..6a361a2 100644
--- a/Documentation/callouts.xsl
+++ b/Documentation/callouts.xsl
@@ -13,4 +13,18 @@
<xsl:apply-templates/>
<xsl:text>.br </xsl:text>
</xsl:template>
+
+<!-- sorry, this is not about callouts, but attempts to work around
+ spurious .sp at the tail of the line docbook stylesheets seem to add -->
+<xsl:template match="simpara">
+ <xsl:variable name="content">
+ <xsl:apply-templates/>
+ </xsl:variable>
+ <xsl:value-of select="normalize-space($content)"/>
+ <xsl:if test="not(ancestor::authorblurb) and
+ not(ancestor::personblurb)">
+ <xsl:text> </xsl:text>
+ </xsl:if>
+</xsl:template>
+
</xsl:stylesheet>
^ permalink raw reply related
* Re: [RFC/PATCH] runstatus: restructure visual appearance
From: Lars Hjemli @ 2006-12-13 9:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3b7koc6b.fsf@assigned-by-dhcp.cox.net>
On 12/13/06, Junio C Hamano <junkio@cox.net> wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
> > Just wondering if this patch got dropped or simply overlooked...
>
> I looked at the patch, and I was neutral to slightly negative
> (but only slightly. I thought M vs M+ was too subtle and
> cryptic until the user gets used to them).
Hmm, yes, I agree it's a bit subtle. But whenever the '+' or '-' is
added to a state symbol, the big warning that is printed should make
it less so (the warning should also mention git-rm, btw).
And of course the man-page for git-status should be updated to
describe the different state symbols, the meaning of +/-, and how to
'resolve' them.
> I however did not see overwhelming support from the list, so I
> did not further think about it.
The silence was earth shattering
> One thing that was mentioned in the past on the list about the
> output from git-status was that we do not make mode changes
> stand out, and people can mistakenly do something silly to
> change the -x bit and the current git-status would only say:
>
> modified: git-foobar.sh
>
> which would not help them notice the mistake, as a result,
> accidental mode change can get committed.
>
>If we are designing a new format to make git-status output more
>compact and easier to understand, I think it should also attempt
>to address this problem as well.
Excellent point, I'll use it as an excuse to refine and resend the patch.
--
^ permalink raw reply
* [PATCH] Allow subcommand.color and color.subcommand color configuration
From: Andy Parkins @ 2006-12-13 9:13 UTC (permalink / raw)
To: git
While adding colour to the branch command it was pointed out that a
config option like "branch.color" conflicts with the pre-existing
"branch.something" namespace used for specifying default merge urls and
branches. The suggested solution was to flip the order of the
components to "color.branch", which I did for colourising branch.
This patch does the same thing for
- git-log (color.diff)
- git-status (color.status)
- git-diff (color.diff)
- pager (color.pager)
I haven't removed the old config options; but they should probably be
deprecated and eventually removed to prevent future namespace
collisions. I've done this deprecation by changing the documentation
for the config file to match the new names; and adding the "color.XXX"
options to contrib/completion/git-completion.bash.
Unfortunately git-svn reads "diff.color" and "pager.color"; which I
don't like to change unilaterally.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/config.txt | 12 ++++++------
builtin-log.c | 2 +-
config.c | 2 +-
contrib/completion/git-completion.bash | 3 +++
diff.c | 4 ++--
wt-status.c | 4 ++--
6 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9090762..9bdd824 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -130,16 +130,16 @@ branch.<name>.merge::
When in branch <name>, it tells `git fetch` the default remote branch
to be merged.
-pager.color::
+color.pager::
A boolean to enable/disable colored output when the pager is in
use (default is true).
-diff.color::
+color.diff::
When true (or `always`), always use colors in patch.
When false (or `never`), never. When set to `auto`, use
colors only when the output is to the terminal.
-diff.color.<slot>::
+color.diff.<slot>::
Use customized color for diff colorization. `<slot>`
specifies which part of the patch to use the specified
color, and is one of `plain` (context text), `meta`
@@ -264,19 +264,19 @@ showbranch.default::
The default set of branches for gitlink:git-show-branch[1].
See gitlink:git-show-branch[1].
-status.color::
+color.status::
A boolean to enable/disable color in the output of
gitlink:git-status[1]. May be set to `true` (or `always`),
`false` (or `never`) or `auto`, in which case colors are used
only when the output is to a terminal. Defaults to false.
-status.color.<slot>::
+color.status.<slot>::
Use customized color for status colorization. `<slot>` is
one of `header` (the header text of the status message),
`updated` (files which are updated but not committed),
`changed` (files which are changed but not updated in the index),
or `untracked` (files which are not tracked by git). The values of
- these variables may be specified as in diff.color.<slot>.
+ these variables may be specified as in color.diff.<slot>.
tar.umask::
By default, gitlink:git-tar-tree[1] sets file and directories modes
diff --git a/builtin-log.c b/builtin-log.c
index 7acf5d3..6821a08 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -118,7 +118,7 @@ static int git_format_config(const char *var, const char *value)
strcat(extra_headers, value);
return 0;
}
- if (!strcmp(var, "diff.color")) {
+ if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
return 0;
}
return git_log_config(var, value);
diff --git a/config.c b/config.c
index 3cae390..06e7fdb 100644
--- a/config.c
+++ b/config.c
@@ -314,7 +314,7 @@ int git_default_config(const char *var, const char *value)
return 0;
}
- if (!strcmp(var, "pager.color")) {
+ if (!strcmp(var, "pager.color") || !strcmp(car, "color.pager")) {
pager_use_color = git_config_bool(var,value);
return 0;
}
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 447ec20..9c4d23a 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -712,10 +712,13 @@ _git_repo_config ()
core.legacyHeaders
i18n.commitEncoding
diff.color
+ color.diff
diff.renameLimit
diff.renames
pager.color
+ color.pager
status.color
+ color.status
log.showroot
show.difftree
showbranch.default
diff --git a/diff.c b/diff.c
index 3315378..726b01e 100644
--- a/diff.c
+++ b/diff.c
@@ -60,7 +60,7 @@ int git_diff_ui_config(const char *var, const char *value)
diff_rename_limit_default = git_config_int(var, value);
return 0;
}
- if (!strcmp(var, "diff.color")) {
+ if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
diff_use_color_default = git_config_colorbool(var, value);
return 0;
}
@@ -74,7 +74,7 @@ int git_diff_ui_config(const char *var, const char *value)
diff_detect_rename_default = DIFF_DETECT_RENAME;
return 0;
}
- if (!strncmp(var, "diff.color.", 11)) {
+ if (!strncmp(var, "diff.color.", 11) || !strncmp(var, "color.diff.", 11)) {
int slot = parse_diff_color_slot(var, 11);
color_parse(value, var, diff_colors[slot]);
return 0;
diff --git a/wt-status.c b/wt-status.c
index de1be5b..df582a0 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -297,11 +297,11 @@ void wt_status_print(struct wt_status *s)
int git_status_config(const char *k, const char *v)
{
- if (!strcmp(k, "status.color")) {
+ if (!strcmp(k, "status.color") || !strcmp(k, "color.status")) {
wt_status_use_color = git_config_colorbool(k, v);
return 0;
}
- if (!strncmp(k, "status.color.", 13)) {
+ if (!strncmp(k, "status.color.", 13) || !strncmp(k, "color.status", 13)) {
int slot = parse_status_slot(k, 13);
color_parse(v, k, wt_status_colors[slot]);
}
--
1.4.4.1.g3ece-dirty
^ permalink raw reply related
* Re: [PATCH] Allow building GIT in a different directory from the source directory
From: Andreas Ericsson @ 2006-12-13 9:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612121951000.2807@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 12 Dec 2006, Han-Wen Nienhuys wrote:
>
>> I still don't understand the problem with autoconf; there are already
>> plenty of baroque shell scripts in GIT. I hate writing m4 macros as
>> well, but that's not a problem for GIT users (ie. people who compile
>> GIT).
>
> That, together with the complexity of GIT_EXEC_DIR and path mangling
> problems, makes me take every opportunity to suggest we should build in
> most if not all of Git into the "git wrapper".
>
> Granted, without completion scripts, the "git-" convention was nice.
>
> Granted, with bash, Perl and even Python, you can rapidly prototype your
> thoughts (even if I often miss the power of C there).
>
We could still allow that by simply not removing the "run this external
program" code from the git wrapper even if we make all default commands
built-ins. Pluggable git, just as it is today, and when something turns
out to be useful, feature-complete and stable enough "someone" will
hopefully hop in to make it a built-in.
> But in the end, I'd say it makes lots of sense to have everything in one
> executable.
>
Yup. Not least for portability issues. The lack of a native windows
client has already made us lose at least one major "customer", and afaiu
it was *only* the lack of a native windows client that caused this, so
obviously it's a big issue for big cross-platform projects.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: GIT - releases workflow
From: Matthias Kestenholz @ 2006-12-13 9:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sean Kelley, git
In-Reply-To: <Pine.LNX.4.63.0612122353320.2807@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Tue, 2006-12-12 at 23:54 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 12 Dec 2006, Sean Kelley wrote:
>
> > I was wondering if anyone could share ideas on how best to use GIT to
> > handle releases for those working with a remote GIT repository? Do you
> > create a branch and push it to the remote? Thus you have a new branch
> > referencing the particular release?
>
> Why not just tag the release, and push the tag?
I am doing both in my web SDK project.
I currently have two branches, master and maint/v1. Over time, if
necessary, I'll open new branches named maint/v2, maint/v3 etc.
New development happens on master, bugfixes go to maint/v1 and get
merged into master. If I do bugfix releases (2.0.x), I tag the tip of
the maint/v1 branch.
I need a full branch, because I need the ability to do bugfixes for the
already-released version.
Matthias
^ permalink raw reply
* Re: Adding a new file as if it had existed
From: Andreas Ericsson @ 2006-12-13 9:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bahadir Balban, git, Johannes Schindelin, Andy Parkins
In-Reply-To: <7vzm9tuft7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "Bahadir Balban" <bahadir.balban@gmail.com> writes:
>
> There is one thing we could further optimize, though.
>
> Switching branches with 100k blobs in a commit even when there
> are a handful paths different between the branches would still
> need to populate the index by reading two trees and collapsing
> them into a single stage. In theory, we should be able to do a
> lot better if two-tree case of read-tree took advanrage of
> cache-tree information. If ce_match_stat() says Ok for all
> paths in a subdirectory and the cached tree object name for that
> subdirectory in the index match what we are reading from the new
> tree, we should be able to skip reading that subdirectory (and
> its subdirectories) from the new tree object at all.
>
> Anybody interested to give it a try?
>
I'm not vell-versed enough in git internals to have my hopes high of
making something useful of it, but if you give me a pointer of where to
start I'd be happy to try, and perhaps learn something in the process.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: t9100-git-svn-basic.sh fails
From: Eric Wong @ 2006-12-13 9:43 UTC (permalink / raw)
To: Junio C Hamano, Sebastian Harl; +Cc: git
In-Reply-To: <20061213084620.GN2476@albany.tokkee.org>
Sebastian Harl <sh@tokkee.org> wrote:
> Hi,
>
> On Wed, Dec 13, 2006 at 01:03:21AM +0100, Johannes Schindelin wrote:
> > On Wed, 13 Dec 2006, Sebastian Harl wrote:
> >
> > > When compiling git 1.4.4.2 on my Debian Sarge box t9100-git-svn-basic.sh
> > > fails with the following output:
> > >
> > > * FAIL 6: detect node change from directory to file #1
> > > git-svn commit --find-copies-harder --rmdir \
> > > remotes/git-svn..mybranch2
> >
> > Could you please run the test like this:
> >
> > git/t> sh t9100-* -i -v
>
> * expecting failure: git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch2
> diff-tree 5d3b7d019e8fa8d509091bd1d80113c8f20f9f4f 91d77f97b74783aa97ba2aed5a966e936eb9d30f
> Transaction is out of date: Out of date: 'test-git-svn/bar' in transaction '2-2' at /home/tokkee/projects/debian/backports/backports.org/git-core/git-core-1.4.4.2/t/../git-svn line 1573
> 65280 at /home/tokkee/projects/debian/backports/backports.org/git-core/git-core-1.4.4.2/t/../git-svn line 575
> main::commit_lib('91d77f97b74783aa97ba2aed5a966e936eb9d30f') called at /home/tokkee/projects/debian/backports/backports.org/git-core/git-core-1.4.4.2/t/../git-svn line 481
> main::commit('remotes/git-svn..mybranch2') called at /home/tokkee/projects/debian/backports/backports.org/git-core/git-core-1.4.4.2/t/../git-svn line 173
> * FAIL 6: detect node change from directory to file #1
> git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch2
Oh, *smacks head* I'm only half-awake at the moment, but
it looks like 1.4.4.2 doesn't have commit
d25c26e771fdf771f264dc85be348719886d354f
(git-svn: exit with status 1 for test failures)
Junio:
can you please cherry-pick that commit (and also apply
"git-svn: correctly display fatal() error messages"
(Message-Id: <11659636263755-git-send-email-normalperson@yhbt.net>)
into maint?
Thanks.
--
^ 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