* [PATCH 1/2] gitweb: Always set 'from_file' and 'to_file' in parse_difftree_raw_line
From: Jakub Narebski @ 2007-11-01 11:38 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1193917089-15920-1-git-send-email-jnareb@gmail.com>
Always set 'from_file' and 'to_file' keys when parsing raw diff output
format line, even if filename didn't change (file was not renamed).
This allows for simpler code (and no problems with file named '0').
Use
$diffinfo->{'from_file'}
instead of
$diffinfo->{'from_file'} || $diffinfo->{'file'}
from now on.
While at it, replace (for merge commits)
$diffinfo->{'from_file'}[$i] || $diffinfo->{'to_file'}
by
defined $diffinfo->{'from_file'}[$i] ?
$diffinfo->{'from_file'}[$i] :
$diffinfo->{'to_file'};
to have no problems woth file named '0'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2e00756..79ea7ec 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1995,7 +1995,7 @@ sub parse_difftree_raw_line {
if ($res{'status'} eq 'R' || $res{'status'} eq 'C') { # renamed or copied
($res{'from_file'}, $res{'to_file'}) = map { unquote($_) } split("\t", $7);
} else {
- $res{'file'} = unquote($7);
+ $res{'from_file'} = $res{'to_file'} = $res{'file'} = unquote($7);
}
}
# '::100755 100755 100755 60e79ca1b01bc8b057abe17ddab484699a7f5fdb 94067cc5f73388f33722d52ae02f44692bc07490 94067cc5f73388f33722d52ae02f44692bc07490 MR git-gui/git-gui.sh'
@@ -2062,7 +2062,10 @@ sub parse_from_to_diffinfo {
fill_from_file_info($diffinfo, @parents)
unless exists $diffinfo->{'from_file'};
for (my $i = 0; $i < $diffinfo->{'nparents'}; $i++) {
- $from->{'file'}[$i] = $diffinfo->{'from_file'}[$i] || $diffinfo->{'to_file'};
+ $from->{'file'}[$i] =
+ defined $diffinfo->{'from_file'}[$i] ?
+ $diffinfo->{'from_file'}[$i] :
+ $diffinfo->{'to_file'};
if ($diffinfo->{'status'}[$i] ne "A") { # not new (added) file
$from->{'href'}[$i] = href(action=>"blob",
hash_base=>$parents[$i],
@@ -2074,7 +2077,7 @@ sub parse_from_to_diffinfo {
}
} else {
# ordinary (not combined) diff
- $from->{'file'} = $diffinfo->{'from_file'} || $diffinfo->{'file'};
+ $from->{'file'} = $diffinfo->{'from_file'};
if ($diffinfo->{'status'} ne "A") { # not new (added) file
$from->{'href'} = href(action=>"blob", hash_base=>$hash_parent,
hash=>$diffinfo->{'from_id'},
@@ -2084,7 +2087,7 @@ sub parse_from_to_diffinfo {
}
}
- $to->{'file'} = $diffinfo->{'to_file'} || $diffinfo->{'file'};
+ $to->{'file'} = $diffinfo->{'to_file'};
if (!is_deleted($diffinfo)) { # file exists in result
$to->{'href'} = href(action=>"blob", hash_base=>$hash,
hash=>$diffinfo->{'to_id'},
@@ -2829,7 +2832,7 @@ sub is_patch_split {
my ($diffinfo, $patchinfo) = @_;
return defined $diffinfo && defined $patchinfo
- && ($diffinfo->{'to_file'} || $diffinfo->{'file'}) eq $patchinfo->{'to_file'};
+ && $diffinfo->{'to_file'} eq $patchinfo->{'to_file'};
}
@@ -4667,8 +4670,8 @@ sub git_blobdiff {
}
%diffinfo = parse_difftree_raw_line($difftree[0]);
- $file_parent ||= $diffinfo{'from_file'} || $file_name || $diffinfo{'file'};
- $file_name ||= $diffinfo{'to_file'} || $diffinfo{'file'};
+ $file_parent ||= $diffinfo{'from_file'} || $file_name;
+ $file_name ||= $diffinfo{'to_file'};
$hash_parent ||= $diffinfo{'from_id'};
$hash ||= $diffinfo{'to_id'};
--
1.5.3.4
^ permalink raw reply related
* [PATCH 0/2] gitweb: Simplify dealing with raw diff output
From: Jakub Narebski @ 2007-11-01 11:38 UTC (permalink / raw)
To: git
This series of patches simplifies (and improves) gitweb code dealing
with (parsed) raw diff output format.
See individual patches for more detail.
Table of contents:
[PATCH 1/2] gitweb: Always set 'from_file' and 'to_file'
in parse_difftree_raw_line
[PATCH 2/2] gitweb: Add 'status_str' to parse_difftree_raw_line output
Diffstat:
gitweb/gitweb.perl | 22 +++++++++++++---------
1 files changed, 13 insertions(+), 9 deletions(-)
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 2/2] gitweb: Add 'status_str' to parse_difftree_raw_line output
From: Jakub Narebski @ 2007-11-01 11:38 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1193917089-15920-1-git-send-email-jnareb@gmail.com>
Add 'status_str' to diffinfo output, which stores status (also for
merge commit) as a string. This allows for easy checking if there is
given status among all for merge commit, e.g.
$diffinfo->{'status_str'} =~ /D/;
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 79ea7ec..e36dec1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1990,7 +1990,7 @@ sub parse_difftree_raw_line {
$res{'to_mode'} = $2;
$res{'from_id'} = $3;
$res{'to_id'} = $4;
- $res{'status'} = $5;
+ $res{'status'} = $res{'status_str'} = $5;
$res{'similarity'} = $6;
if ($res{'status'} eq 'R' || $res{'status'} eq 'C') { # renamed or copied
($res{'from_file'}, $res{'to_file'}) = map { unquote($_) } split("\t", $7);
@@ -2006,6 +2006,7 @@ sub parse_difftree_raw_line {
$res{'to_mode'} = pop @{$res{'from_mode'}};
$res{'from_id'} = [ split(' ', $3) ];
$res{'to_id'} = pop @{$res{'from_id'}};
+ $res{'status_str'} = $4;
$res{'status'} = [ split('', $4) ];
$res{'to_file'} = unquote($5);
}
@@ -2821,7 +2822,7 @@ sub fill_from_file_info {
sub is_deleted {
my $diffinfo = shift;
- return $diffinfo->{'to_id'} eq ('0' x 40);
+ return $diffinfo->{'status_str'} =~ /D/;
}
# does patch correspond to [previous] difftree raw line
--
1.5.3.4
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2007-11-01 11:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vmytycykt.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
> + rebase: allow starting from a dirty tree.
> + stash: implement "stash create"
>
> Will revert at least the latter one, but perhaps both, from
> 'next'. The traditional behaviour of refusing to work in a
> dirty tree is much safer, as the tool cannot decide where to
> unstash for you.
One of frequently requested features is ability to rebase and merge
in a dirty tree (CVS-like). Perhaps we should advocate git-stash better,
e.g. in error message for git-rebase / git-merge / git-pull when in dirty
state.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Mike Hommey @ 2007-11-01 10:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vejfag40g.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 31, 2007 at 06:15:27PM -0700, Junio C Hamano wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > BTW, you have workaround for git-merge also? It uses cpio to save/restore state.
>
> Why do people want "workaround"? Is installing cpio such a
> hassle?
Note that to do what git-merge does with cpio, i wonder if it wouldn't
be sensible to use git stash, now.
Mike
^ permalink raw reply
* Re: New features in gitk
From: Paul Mackerras @ 2007-11-01 10:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710280943090.30120@woody.linux-foundation.org>
Linus Torvalds writes:
> (And as mentioned many times earlier - if you can avoid topo-order and
> date-order entirely, you are going to perform a million times better at
> startup for the cold-cache case. Since you seem to be doing the graph
> layout lazily now, maybe you could aim for that some day? It does mean
> that you might - occasionally - end up having to add a commit to
> *before* one you already laid out).
The other thing --topo-order does is reorder the commits so that
related commits come together. So far, doing that in Tcl has turned
out to be much slower than having it done in C (within git log) for
the hot-cache case (which I expect is the common case).
I'm now thinking that the best approach would be to have gitk cache
the topology, and on startup only read in the part of the graph that
isn't in the cache. Mostly that will be small and so git log should
be fast even in the cold-cache case with --topo-order.
Paul.
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Andreas Ericsson @ 2007-11-01 9:29 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
In-Reply-To: <0A8A6A99-4C8B-4056-9068-DA54B69B08B5@zib.de>
Steffen Prohaska wrote:
>
> On Nov 1, 2007, at 9:18 AM, Andreas Ericsson wrote:
>
>> Junio C Hamano wrote:
>>
>>> (actually, shared repository people seem to
>>> prefer "fetch + rebase" over "pull" which is "fetch + merge").
>>
>> That's definitely true. The number of useless merge-commits we
>> have in our repos is annoying, and has twice made bisect a bit
>> troublesome for no good reason.
>
> Can you describe a bit more what's "annoying" about them?
> Is it the visualization? Or are there more problems; like
> the trouble with bisect?
>
Visualization is a small nuissance. git-bisect troubles are more
worrisome. I've been in the seat where useless merges means git
bisect needs constant babysitting and constant manual handling.
It's no fun at all, so we're sticking with the fetch+rebase flow.
> I'm trying to estimate if it's worth teaching _all_
> developers rebase or if we should just live with the "useless"
> merge-commits.
>
I'd say that depends on how valuable you find gitk, qgit and
git-bisect are. To me, I'd happily use any scm in the world,
so long as it has git-bisect. Otoh, I'm a lazy bastard and
love bisect so much that all our automated tests are focused
around "git bisect run". This means bugs in software released
to customers are few and far apart. When we get one reported,
we just create a new test that exposes it, fire up git-bisect
and then go to lunch. Quality costs, however. We pay that bill
by using a workflow that's perhaps more convoluted than
necessary.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Andreas Ericsson @ 2007-11-01 9:11 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
In-Reply-To: <6B0CD829-A964-410B-8C23-74D26BD2C0FA@zib.de>
Steffen Prohaska wrote:
>
> On Oct 31, 2007, at 10:31 PM, Junio C Hamano wrote:
>
>> Steffen Prohaska <prohaska@zib.de> writes:
>>
>>>> You forgot a lot more important part. Pushing into publishing
>>>> repositories. And the discussion is about git-push command.
>>>
>>> Exactly, here are two examples:
>>>
>>> If you push only to publishing repositories that are read
>>> only by others, you'll never encounter the problem that
>>> 10/10 tried to solve. The publishing repository is never
>>> changed by others. You are the only one who pushes to this
>>> repository. Therefore the remote never advances unexpectedly.
>>
>> Wrong.
>>
>> People can and do work from more than one private repositories
>> (I do). In a sense, that is sharing the repository with
>> oneself.
>
> I do, too. But as long as I do not forget what I've done, the
> branches do not advance _unexpectedly_. I am in full control.
>
>
>> I may do an emergency patch to fix breakage on 'maint' (and
>> 'maint' only) from a location that is not my primary development
>> box and push the fix out. I fully expect that the push will
>> push out 'maint' and expect the other branches such as 'master'
>> on the remote side to stay the same, as I haven't touched
>> 'master' on that box for quite a while and it is now stale. In
>> that situation, I _want_ the "git push" itself to report failure
>> to notify me that it did not push what _I_ asked it to push out,
>> so that I can be reminded that I'd better do "git push $remote
>> maint" the next time. In the meantime, even though it reports
>> a failure, 'master' on the remote side is _not_ updated, so the
>> behaviour is still _safe_.
>
> You're right it is safe, but it may be confusing.
>
>
>>> Another difference is the way changes are integrated. In
>>> a workflow without shared repositories, only pull is used
>>> for integration, while push in only used for publishing the
>>> changes.
>>
>> Wrong. push is a mirror of fetch and does not do _any_
>> integration. It is just a safe (because it insists on
>> fast-forward) propagation mechanism. Your integration still
>> happens with pull (actually, shared repository people seem to
>> prefer "fetch + rebase" over "pull" which is "fetch + merge").
>
> Right; but you can't push without doing the integration. If you
> have new changes on the remote side you _must_ pull before
> you can push.
Yes, because otherwise you'd rewrite published history. That's not
a good thing.
> You're forced to do the integration immediately.
Yes, but you get to choose how. Perhaps git-push should list more
options than just git-pull, such as the three commands required to
rebase the currently checked out branch onto its remote counterpart.
That would support more workflows.
> Your main objective was to push, but the shared workflow forces
> you to do the integration _now_ (by using pull). In a pull-only
> workflow, you can just push and defere the integration for later.
>
No, you can also fetch + rebase.
> Some people claim fetch + rebase is superior to fetch + merge.
> The only point I can see is that fetch + rebase gives a linear
> history without loops, which is nicer to visualize. I recently
> asked on the list if there are any benefits of fetch + rebase
> over fetch + merge, besides a nicer visualization.
It's easier to bisect. If git bisect lands you on a merge-commit,
you need to start a new bisect for each of the parents included
in the merge. Hopefully the nature of the merge gives a clue so
the user can make an educated guess as to which parent introduced
the bogus commit, but for an "evil octopus" (unusual) or if the
merge had conflicts which were resolved in a buggy way (not
exactly uncommon), it can be quite a hassle to get things right.
With a mostly linear history, this problem goes away.
> I didn't
> receive many interesting comments. One comment explained
> that rebase can shift the merge conflict resolution from
> the maintainer (merge) to the original author (rebase). But
> this is not very interesting in a shared workflow, because
> the author must resolve conflicts in any case before he can
> push. It doesn't matter much if he uses merge or rebase to
> do so.
>
It depends. When commit ordering doesn't matter the original
author can use "git rebase --skip" and then continue with the
rebase to get as much as possible out as quickly as possible.
I'm in the unfortunate position of having a boss that likes
to fiddle with help-texts in code when it's in alpha-testing.
Sometimes that causes conflicts but it's often not important
enough to spend 30 minutes figuring out how to resolve it
properly. I tend to just skip those patches and send them as
emails to our tech-writer instead, asking him to rephrase the
text to incorporate both changes, and then manually applying
the text to the end result.
>
> I am searching for a solution that just works for them. They
> currently use CVS. I'll give them a detailed getting started
> document for git. The workflow described should be as simple as
> possible, but safe and reliable.
If they're used to CVS and want to use more than one branch without
having to learn additional syntax, nothing can help, methinks.
>
> Another question is what to do with a local branch after
> you finished work. We recently had the
> "Re: best git practices, was Re: Git User's Survey 2007
> unfinished summary continued" aka the 200-local-branches
> discussion.
>
We're at 224 branches now, having added 7 new repos.
> There were different suggestions what to do. A reasonable
> suggestion was to delete the local branch after you're done.
Except that it doesn't work unless you either detach the HEAD
(which prints a big fat ugly message) or give it -D to force
it, which I really, really don't recommend. We use git because
I'm pretty confident in its capabilities of never ever losing
anything. Using the seemingly harmless -D switch to git-branch
puts us at risk of wiping history quite without noticing.
> This clearly distinguishes between remote branches (which are
> mirrored as a remote tracking branch) and local branches. Local
> branches are _your_ branches while the remote branches contain
> the shared work. If you're done with your local work, delete
> your local branch. So maybe you should do
>
> git checkout origin/devel
Except that this gives a warning-esque message:
Note: moving to "origin/devel" 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 deadbeef... Ma! Pa butchered all the cows!
To me, this indicates I've done something git thinks I shouldn't have.
>
> Independently of what the best practice is, leaving the local
> work branch there shouldn't do any harm because I'm sure that
> some devs will forget to clean up, independently of what I tell
> them.
>
I wholeheartedly agree with this one.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] git-clone.txt: Improve --depth description.
From: Ralf Wildenhues @ 2007-11-01 8:46 UTC (permalink / raw)
To: git, Junio C Hamano
Avoid abbreviation 'revs', improve the language a bit.
---
Documentation/git-clone.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 253f4f0..cca14d6 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -111,11 +111,11 @@ OPTIONS
--depth <depth>::
Create a 'shallow' clone with a history truncated to the
- specified number of revs. A shallow repository has
+ specified number of revisions. A shallow repository has a
number of limitations (you cannot clone or fetch from
it, nor push from nor into it), but is adequate if you
- want to only look at near the tip of a large project
- with a long history, and would want to send in a fixes
+ are only interested in the recent history of a large project
+ with a long history, and would want to send in fixes
as patches.
<repository>::
--
1.5.3.1.522.g85b0
^ permalink raw reply related
* [PATCH] git-rev-list.txt: rev stands for revision, not reverse.
From: Ralf Wildenhues @ 2007-11-01 8:45 UTC (permalink / raw)
To: git, Junio C Hamano
Mention revs, revisions as aliases for commit objects,
to clarify that rev-list is not an abbreviation for
listing in reverse order, but for listing revisions.
---
Yes, believe it or not, but I stumbled over the synopsis
| git-rev-list - Lists commit objects in reverse chronological order
asking myself whether rev could possibly mean "reverse".
I hope this helps avoid this pitfall for others.
Cheers,
Ralf
Documentation/git-rev-list.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 4852804..8afe34b 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -44,9 +44,9 @@ SYNOPSIS
DESCRIPTION
-----------
-Lists commit objects in reverse chronological order starting at the
-given commit(s), taking ancestry relationship into account. This is
-useful to produce human-readable log output.
+Lists commit objects (revs, revisions) in reverse chronological order
+starting at the given commit(s), taking ancestry relationship into
+account. This is useful to produce human-readable log output.
Commits which are stated with a preceding '{caret}' cause listing to
stop at that point. Their parents are implied. Thus the following
--
1.5.3.3.g34c6d
^ permalink raw reply related
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-11-01 8:36 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <47298BD7.2000902@op5.se>
On Nov 1, 2007, at 9:18 AM, Andreas Ericsson wrote:
> Junio C Hamano wrote:
>
>> (actually, shared repository people seem to
>> prefer "fetch + rebase" over "pull" which is "fetch + merge").
>
> That's definitely true. The number of useless merge-commits we
> have in our repos is annoying, and has twice made bisect a bit
> troublesome for no good reason.
Can you describe a bit more what's "annoying" about them?
Is it the visualization? Or are there more problems; like
the trouble with bisect?
I'm trying to estimate if it's worth teaching _all_
developers rebase or if we should just live with the "useless"
merge-commits.
Steffen
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Andreas Ericsson @ 2007-11-01 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git
In-Reply-To: <7vlk9jgeee.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>>> You forgot a lot more important part. Pushing into publishing
>>> repositories. And the discussion is about git-push command.
>> Exactly, here are two examples:
>>
>> If you push only to publishing repositories that are read
>> only by others, you'll never encounter the problem that
>> 10/10 tried to solve. The publishing repository is never
>> changed by others. You are the only one who pushes to this
>> repository. Therefore the remote never advances unexpectedly.
>
> Wrong.
>
> People can and do work from more than one private repositories
> (I do). In a sense, that is sharing the repository with
> oneself.
>
I believe your troubles are alleviated a great deal by the fact
that you actually know when upstream has changes, and what those
changes are supposed to be. A communications breakdown with only
one person involved is sort of hard to imagine.
> (actually, shared repository people seem to
> prefer "fetch + rebase" over "pull" which is "fetch + merge").
>
That's definitely true. The number of useless merge-commits we
have in our repos is annoying, and has twice made bisect a bit
troublesome for no good reason.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: remote#branch
From: Andreas Ericsson @ 2007-11-01 7:29 UTC (permalink / raw)
To: Mike Hommey; +Cc: Jeff King, Jakub Narebski, git
In-Reply-To: <20071031091529.GA25025@glandium.org>
Mike Hommey wrote:
> On Wed, Oct 31, 2007 at 10:03:16AM +0100, Andreas Ericsson <ae@op5.se> wrote:
>>> Or copied from gitweb.
>>>
>> Perhaps, but I've never seen that done. Partly because you can't be sure
>> the HTTP url is the same as the git address (perhaps people are used to
>> this from CVS and the likes), and partly because you'd, for most cases,
>> want to use git:// or ssh transport instead of http.
>>
>> It might be nifty to have gitweb print some git-valid locator for a repo
>> though, or even a full copy-pastable "git clone git://host/path/to/repo.git"
>> command-line thingie. I'll look into it when I have leisure.
>
> Hum... it already does print http and git "Mirror URL"s which are ready to
> be copy/pasted to feed git clone arguments.
>
True that. I went looking for such an option a long time ago and didn't find
it. I should do my research better.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Bug in git-show-branch, or in core-tutorial?
From: Junio C Hamano @ 2007-11-01 7:24 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <878x5j3uos.fsf@osv.gnss.ru>
I think that is a simple typo of "these", not "three".
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-11-01 7:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk9jgeee.fsf@gitster.siamese.dyndns.org>
On Oct 31, 2007, at 10:31 PM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>>> You forgot a lot more important part. Pushing into publishing
>>> repositories. And the discussion is about git-push command.
>>
>> Exactly, here are two examples:
>>
>> If you push only to publishing repositories that are read
>> only by others, you'll never encounter the problem that
>> 10/10 tried to solve. The publishing repository is never
>> changed by others. You are the only one who pushes to this
>> repository. Therefore the remote never advances unexpectedly.
>
> Wrong.
>
> People can and do work from more than one private repositories
> (I do). In a sense, that is sharing the repository with
> oneself.
I do, too. But as long as I do not forget what I've done, the
branches do not advance _unexpectedly_. I am in full control.
> I may do an emergency patch to fix breakage on 'maint' (and
> 'maint' only) from a location that is not my primary development
> box and push the fix out. I fully expect that the push will
> push out 'maint' and expect the other branches such as 'master'
> on the remote side to stay the same, as I haven't touched
> 'master' on that box for quite a while and it is now stale. In
> that situation, I _want_ the "git push" itself to report failure
> to notify me that it did not push what _I_ asked it to push out,
> so that I can be reminded that I'd better do "git push $remote
> maint" the next time. In the meantime, even though it reports
> a failure, 'master' on the remote side is _not_ updated, so the
> behaviour is still _safe_.
You're right it is safe, but it may be confusing.
>> Another difference is the way changes are integrated. In
>> a workflow without shared repositories, only pull is used
>> for integration, while push in only used for publishing the
>> changes.
>
> Wrong. push is a mirror of fetch and does not do _any_
> integration. It is just a safe (because it insists on
> fast-forward) propagation mechanism. Your integration still
> happens with pull (actually, shared repository people seem to
> prefer "fetch + rebase" over "pull" which is "fetch + merge").
Right; but you can't push without doing the integration. If you
have new changes on the remote side you _must_ pull before
you can push. You're forced to do the integration immediately.
Your main objective was to push, but the shared workflow forces
you to do the integration _now_ (by using pull). In a pull-only
workflow, you can just push and defere the integration for later.
Some people claim fetch + rebase is superior to fetch + merge.
The only point I can see is that fetch + rebase gives a linear
history without loops, which is nicer to visualize. I recently
asked on the list if there are any benefits of fetch + rebase
over fetch + merge, besides a nicer visualization. I didn't
receive many interesting comments. One comment explained
that rebase can shift the merge conflict resolution from
the maintainer (merge) to the original author (rebase). But
this is not very interesting in a shared workflow, because
the author must resolve conflicts in any case before he can
push. It doesn't matter much if he uses merge or rebase to
do so.
I evaluated if teaching people fetch + rebase before teaching
fetch + merge is a good idea. Therefore I tested some scenarios
with people who are new to git. The result is that there are
too many situations where fetch + rebase might be confusing.
I abandoned my idea.
I decided that fetch + merge is _easier_. It works in all
situations, it's easier to explain, it's better supported
(automerge), it can be used to work on shared topic branches.
Definitely fetch + merge is the first workflow you should
learn. At the moment I'm not anymore interested in the fetch +
rebase approach.
>> This is different if you work with a shared repository. Bob
>> checks out the shared branch foo to his local branch bar and
>> later he needs to push bar back to the shared branch foo. Bob
>> needs to push changes from his local branch bar to the branch
>> foo in the remote repository, a branch with a different name.
>> This need does not emerge when working with two publishing
>> repositories, as described above.
>
> So you do "git push $remote bar:foo". If you do that regulary,
> there are configuration mechanisms to help you reduce your
> keyboard wear. What's the problem?
Too complex and not flexible enough.
The configuration is in the remote section. Therefore I can
tell git what to do only on a per-branch basis. What do you
think about my recent proposal to add branch.$name.push?
And I want to avoid that people need to learn about the details
of the configuration mechanism on the first time they use git.
I am searching for a solution that just works for them. They
currently use CVS. I'll give them a detailed getting started
document for git. The workflow described should be as simple as
possible, but safe and reliable. No confusing error messages
should appear. Only a few commands should be needed to
contribute to a shared branch. The workflow described should
use git in a sane way that provides opportunities to use more
of its power later.
So here is what I'd like to have.
git clone ssh://server/git/project.git project
[ On Windows the hassel already starts because it actually is
git clone -n ssh://sever/git/project.git project
git config core.autocrlf true
And here's the next point. git config doesn't validate the
variable. It accepts _any_ variable. If you have a typo
you go without autocrlf. ... but this is a different story. ]
cd project
git checkout -b devel origin/devel
# work, commit, work, commit
git push # maybe git pull first, but git would tell you
The last command, git push, can already cause trouble. git
automatically created a local master and the remote master
may have advanced, so git push would complain with an error.
Currently the correct command would be
"git push origin devel".
An alternative scenario is that you want to start work that
will not be ready right away. So you start a topic branch
git checkout -b topic origin/devel
# work, commit, some time passes, work, commit
git pull # integrate changes from devel
# work, commit
git pull
git push # this one should push to origin/devel
In scenario three you planned to finish your work right away
but the problem turned out to be harder. Here, the following
would be nice
git checkout -b devel origin/devel
# work, commit, hmm... much harder ...
git branch -m devel dolater
# do something else
git checkout dolater
# finish work
git pull # integrate with other work on devel
git push # push back to shared branch
Another question is what to do with a local branch after
you finished work. We recently had the
"Re: best git practices, was Re: Git User's Survey 2007
unfinished summary continued" aka the 200-local-branches
discussion.
There were different suggestions what to do. A reasonable
suggestion was to delete the local branch after you're done.
This clearly distinguishes between remote branches (which are
mirrored as a remote tracking branch) and local branches. Local
branches are _your_ branches while the remote branches contain
the shared work. If you're done with your local work, delete
your local branch. So maybe you should do
git checkout origin/devel
git branch -d devel
Now you're on a detached branch that points to origin/work.
But how to do you get new changes from others? git pull would
not work and git fetch neither.
Independently of what the best practice is, leaving the local
work branch there shouldn't do any harm because I'm sure that
some devs will forget to clean up, independently of what I tell
them.
Steffen
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Junio C Hamano @ 2007-11-01 6:45 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, Mike Hommey, git
In-Reply-To: <fcaeb9bf0710311825k715900a0sa32a95b87cb146c7@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> It is on Windows because busybox cpio is not really good and busybox
> tar is even worse (for cpio emulation). Maybe I should just improve
> busybox cpio :-)
Sounds sensible, as it (at least its -p mode of operation) is
one of the programs that is very useful yet not so well known to
people new to UNIX.
^ permalink raw reply
* Re: [PATCH] git-diff.txt: add section "output format" describing the diff formats
From: Junio C Hamano @ 2007-11-01 6:33 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20071031135916.5625.qmail@134c5e95d8ec4d.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
> index 0015032..a580f18 100644
> --- a/Documentation/diff-format.txt
> +++ b/Documentation/diff-format.txt
> @@ -1,5 +1,5 @@
> -The output format from "git-diff-index", "git-diff-tree" and
> -"git-diff-files" are very similar.
> +The output format from "git-diff-index", "git-diff-tree",
> +"git-diff-files" and "git diff --raw" are very similar.
I like this attention to the detail of mentioning "--raw".
> @@ -62,9 +62,9 @@ respectively.
> diff format for merges
> ----------------------
>
> -"git-diff-tree" and "git-diff-files" can take '-c' or '--cc' option
> -to generate diff output also for merge commits. The output differs
> -from the format described above in the following way:
> +"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
> +'--cc' option to generate diff output also for merge commits. The
> +output differs from the format described above in the following way:
... and this part should do so, too.
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Mike Hommey @ 2007-11-01 6:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LFD.0.999.0710311742170.3342@woody.linux-foundation.org>
On Wed, Oct 31, 2007 at 05:46:40PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 31 Oct 2007, Mike Hommey wrote:
> > + if type cpio > /dev/null 2>&1; then
> > + local=yes
> > + fi
>
> Isn't "type" a bashism?
I think it's POSIX, and since I found the same construct in
git-mergetool.sh, I thought it would be okay for git.
Mike
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-11-01 5:41 UTC (permalink / raw)
To: git
In-Reply-To: <7vzly84qwf.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
I think it is time to plan freezing for 1.5.4 and this list is a
good place to start.
* js/forkexec (Fri Oct 19 21:48:06 2007 +0200) 14 commits
+ Use the asyncronous function infrastructure to run the content
filter.
+ Avoid a dup2(2) in apply_filter() - start_command() can do it for
us.
+ t0021-conversion.sh: Test that the clean filter really cleans
content.
+ upload-pack: Run rev-list in an asynchronous function.
+ upload-pack: Move the revision walker into a separate function.
+ Use the asyncronous function infrastructure in builtin-fetch-
pack.c.
+ Add infrastructure to run a function asynchronously.
+ upload-pack: Use start_command() to run pack-objects in
create_pack_file().
+ Have start_command() create a pipe to read the stderr of the
child.
+ Use start_comand() in builtin-fetch-pack.c instead of explicit
fork/exec.
+ Use run_command() to spawn external diff programs instead of
fork/exec.
+ Use start_command() to run content filters instead of explicit
fork/exec.
+ Use start_command() in git_connect() instead of explicit
fork/exec.
+ Change git_connect() to return a struct child_process instead of a
pid_t.
I haven't seen anything wrong with this series and we haven't
heard breakages from people on 'next' who have been running with
this for the past ten days. Will merge to 'master'.
* db/remote-builtin (Mon Oct 29 22:03:42 2007 -0400) 4 commits
- Use built-in send-pack.
- Build-in send-pack, with an API for other programs to call.
- Build-in peek-remote, using transport infrastructure.
- Miscellaneous const changes and utilities
Will be in 'next' soon after reviewing it again; hopefully in
'master' before 1.5.4.
* ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits
+ Fixed a command line option type for builtin-fsck.c
+ Make builtin-pack-refs.c use parse_options.
+ Make builtin-name-rev.c use parse_options.
+ Make builtin-count-objects.c use parse_options.
+ Make builtin-fsck.c use parse_options.
+ Update manpages to reflect new short and long option aliases
+ Make builtin-for-each-ref.c use parse-opts.
+ Make builtin-symbolic-ref.c use parse_options.
+ Make builtin-update-ref.c use parse_options
+ Make builtin-revert.c use parse_options.
+ Make builtin-describe.c use parse_options
+ Make builtin-branch.c use parse_options.
+ Make builtin-mv.c use parse-options
+ Make builtin-rm.c use parse_options.
+ Port builtin-add.c to use the new option parser.
+ parse-options: allow callbacks to take no arguments at all.
+ parse-options: Allow abbreviated options when unambiguous
+ Add shortcuts for very often used options.
+ parse-options: make some arguments optional, add callbacks.
+ Rework make_usage to print the usage message immediately
+ Add tests for parse-options.c
+ parse-options: be able to generate usages automatically
+ Add a simple option parser.
It appears 1.5.4 will be, to a certain extent, a "Let's clean up
the internal implementation" release. This series should become
part of it. Hopefully will merge to 'master' soon, but I
haven't looked this series very closely yet.
* kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits
+ Export rerere() and launch_editor().
+ Introduce entry point add_interactive and add_files_to_cache
+ Enable wt-status to run against non-standard index file.
+ Enable wt-status output to a given FILE pointer.
These four alone do not change anything user visible, as the
final goal of this series which is "git-commit in C" is not here
yet. But with the other topics touching internal API left and
right that is understandable. Will merge to 'master'.
* sp/help (Sat Oct 27 01:36:55 2007 -0700) 7 commits
+ shell should call the new setup_path() to setup $PATH
+ include $PATH in generating list of commands for "help -a"
+ use only the $PATH for exec'ing git commands
+ list_commands(): simplify code by using chdir()
+ "current_exec_path" is a misleading name, use "argv_exec_path"
+ remove unused/unneeded "pattern" argument of list_commands
+ "git" returns 1; "git help" and "git help -a" return 0
Will merge to 'master'.
* sp/mergetool (Thu Oct 18 12:25:34 2007 +0200) 3 commits
+ mergetool: avoid misleading message "Resetting to default..."
+ mergetool: add support for ECMerge
+ mergetool: use path to mergetool in config var
mergetool.<tool>.path
Will merge to 'master'.
* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
+ rebase: allow starting from a dirty tree.
+ stash: implement "stash create"
Will revert at least the latter one, but perhaps both, from
'next'. The traditional behaviour of refusing to work in a
dirty tree is much safer, as the tool cannot decide where to
unstash for you.
* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
+ Teach "git reflog" a subcommand to delete single entries
This by itself is not useful; will stay in 'next' until it is
used by selective clearing of stash or something else.
* jc/revert-merge (Tue Oct 23 13:33:26 2007 -0700) 1 commit
+ revert/cherry-pick: work on merge commits as well
This allows cherry-pick and revert to act on a merge commit if
you specify which parent to pick the changes from. I think it
would probably be handy when the need arises, but I suspect such
a need is felt only occasionally. I haven't heard any comment
on the list since it was posted. I am somewhat tempted to merge
this, but I am not in a hurry.
* np/progress (Wed Oct 31 23:57:04 2007 -0400) 17 commits
. Show total transferred as part of throughput progress display
- add throughput display to git-push
- add some copyright notice to the progress display code
- add throughput display to index-pack
- add throughput to progress display
- relax usage of the progress API
- make struct progress an opaque type
- prune-packed: don't call display_progress() for every file
+ Stop displaying "Pack pack-$ID created." during git-gc
+ Teach prune-packed to use the standard progress meter
+ Change 'Deltifying objects' to 'Compressing objects'
+ fix for more minor memory leaks
+ fix const issues with some functions
+ pack-objects.c: fix some global variable abuse and memory leaks
+ pack-objects: no delta possible with only one object in the list
+ cope with multiple line breaks within sideband progress messages
+ more compact progress display
This would give us a good usability enhancement. Will merge the
first half to 'master', cook the rest in 'next' and aim to merge
the whole thing before 1.5.4.
* jc/format-patch-encoding (Wed Oct 31 14:55:17 2007 -0700) 1 commit
- format-patch -s: add MIME encoding header if signer's name
requires so
Topic appeared today. I think this is a safe and sane
fix to a real problem. Needs cherry-pick to 'maint'.
* jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit
- git-diff: complain about >=8 consecutive spaces in initial indent
This is a counterpart of an earlier patch from J. Bruce Fields
to change "git-apply --whitespace" to make SP{8,} at the
beginning of line a whitespace error.
Personally, I am in favor of the stricter check, but I had to
reject the "git-apply" patch because there was no way to disable
the additional check without disabling the existing check for
trailing whitespaces. We probably would want to revisit that
one (perhaps with a new option and/or config to selectively
enable different kinds of whitespace check).
* dz/color-addi (Tue Oct 16 21:42:23 2007 -0400) 1 commit
- Add color support to git-add--interactive
I am not a big fan of color, and Shawn's "What's cooking"
mentioned issues with the implementation. Will not merge to
'next'.
* sp/push-refspec (Sun Oct 28 18:46:20 2007 +0100) 6 commits
- push: teach push to pass --verbose option to transport layer
- push: teach push to accept --verbose option
- push: use same rules as git-rev-parse to resolve refspecs
- add ref_abbrev_matches_full_with_rev_parse_rules() comparing
abbrev with full ref name
- rename ref_matches_abbrev() to
ref_abbrev_matches_full_with_fetch_rules()
- push: support pushing HEAD to real branch name
I have been meaning to review these again and merge to 'next'
but it seems I've been spending more time discussing the ones I
did not even pick up for 'pu'. Will try to find time to do so.
* jk/terse-fetch (Fri Oct 19 03:40:57 2007 -0400) 2 commits
- park
- git-fetch: mega-terse fetch output
No change ;-)
* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
- merge-nu: a new merge backend without using unpack_trees()
- read_tree: take an explicit index structure
- gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix
I was hoping that I can work on this series while in Japan, but
attending funeral and helping others to deal with the fallout
sucked all my energy and time. This is still a wip and not
progressing.
* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
- pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
- ls-tree.c: refactor show_recursive() and rename it.
- tree-diff.c: split out a function to match a single pattern.
My pet project to unify the pathspec handling between tree-diff
family and ls-files family (one side only knows "in this
directory" match, and the other knows how to handle fnmatch
globs as well). Stalled.
* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
. handle renames using similarity engine
. introduce generic similarity library
. change hash table calling conventions
Aiming for a worthy goal, but not merged to 'pu' yet.
* tf/afs (Fri Oct 19 07:38:16 2007 -0500) 1 commit
. Better support AFS hardlinking across object directories
Will drop from topic queue. This is labelled as "AFS hack", but
it hacks around a problem AFS has by breaking the safety we had
from very early days of git for everybody else.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-11-01 5:39 UTC (permalink / raw)
To: git
In-Reply-To: <20071022061115.GR14735@spearce.org>
* The 'maint' branch has just produced the 1.5.3.5 release.
* The 'master' branch has these since the last announcement
in addition to what's in 1.5.3.5.
- git-bisect enhancements to support "git bisect skip".
- git-fetch rewritten in C for performance and portability.
- git-svnimport is no more --- use git-svn.
- git-send-pack does not update the tracking ref on the local
side for failed push (needs cherry-picking to 'maint').
- git-rebase does not choke when $GIT_DIR has whitespace in it
(needs cherry-picking to 'maint').
- optimize rename detection.
- comes with updated gitk.
The above list makes me realize that it probably is a good
time to start freezing things for 1.5.4. Tonight's "What's
cooking" will talk about what other topics should graduate to
'master' before that happens.
Alex Riesen (1):
Fix a crash in ls-remote when refspec expands into nothing
Alexandre Julliard (4):
git.el: Fix typo in "Reverted file" message.
git.el: Fix typo in git-update-saved-file error handling.
git.el: Refresh only the changed file marks when marking/unmarking
all.
git.el: Run git-gc --auto after commits.
Benoit Sigoure (1):
core-tutorial: Catch up with current Git
Christian Couder (12):
Test suite: reset TERM to its previous value after testing.
rev-list: implement --bisect-all
rev-list documentation: add "--bisect-all".
Bisect: fix some white spaces and empty lines breakages.
Bisect: implement "bisect skip" to mark untestable revisions.
Bisect: refactor "bisect_write_*" functions.
Bisect: refactor some logging into "bisect_write".
Bisect: refactor "bisect_{bad,good,skip}" into "bisect_state".
Bisect: add "bisect skip" to the documentation.
Bisect: add a "bisect replay" test case.
Bisect run: "skip" current commit if script exit code is 125.
Bisect: add "skip" to the short usage string.
Dan McGee (1):
Remove outdated references to cogito in documentation
Daniel Barkalow (15):
Refactor http.h USE_CURL_MULTI fill_active_slots().
Make function to refill http queue a callback
Remove obsolete commit-walkers
Modularize commit-walker
Add uploadpack configuration info to remote.
Report information on branches from remote.h
Make fetch-pack a builtin with an internal API
Push code for transport library
Add matching and parsing for fetch-side refspec rules
Add fetch methods to transport library.
Make fetch a builtin
Allow abbreviations in the first refspec to be merged
Restore default verbosity for http fetches.
Remove duplicate ref matches in fetch
Correct handling of upload-pack in builtin-fetch-pack
David Symonds (3):
gitweb: Provide title attributes for abbreviated author names.
gitweb: Refactor abbreviation-with-title-attribute code.
gitweb: Use chop_and_escape_str in more places.
Gerrit Pape (1):
No longer install git-svnimport, move to contrib/examples
Jakub Narebski (1):
gitweb: Fix and simplify "split patch" detection
Jari Aalto (1):
On error, do not list all commands, but point to --help option
Jeff King (2):
send-pack: don't update tracking refs on error
t5516: test update of local refs on push
Jim Meyering (1):
hooks-pre-commit: use \t, rather than a literal TAB in regexp
Johannes Schindelin (6):
Move bundle specific stuff into bundle.[ch]
Add bundle transport
Introduce remove_dir_recursively()
fetch/push: readd rsync support
Fix compilation when NO_CURL is defined
fetch: if not fetching from default remote, ignore default merge
Jonathan del Strother (1):
Fixing path quoting in git-rebase
Junio C Hamano (5):
bundle transport: fix an alloc_ref() call
k.org git toppage: Add link to 1.5.3 release notes.
help: remove extra blank line after "See 'git --help'" message
git-fetch: do not fail when remote branch disappears
RelNotes-1.5.4: describe recent updates
Lars Hjemli (1):
Teach git-pull about --[no-]ff, --no-squash and --commit
Lars Knoll (1):
Speedup scanning for excluded files.
Linus Torvalds (8):
Add 'diffcore.h' to LIB_H
Split out "exact content match" phase of rename detection
Ref-count the filespecs used by diffcore
copy vs rename detection: avoid unnecessary O(n*m) loops
Do linear-time/space rename logic for exact renames
Do exact rename detection regardless of rename limits
Fix ugly magic special case in exact rename detection
Do the fuzzy rename detection limits with the exact renames removed
Miklos Vajna (1):
git-send-email: add a new sendemail.to configuration variable
Nguyễn Thái Ngọc Duy (1):
git-sh-setup.sh: use "git rev-parse --show-cdup" to check for
SUBDIRECTORY_OK
Paul Mackerras (34):
gitk: Establish and use global left-to-right ordering for commits
gitk: Improve the drawing of links to parent lines
gitk: Eliminate diagonal arrows
gitk: Get rid of idrowranges and rowrangelist
gitk: Get rid of idinlist array
gitk: Fix some problems with the display of ids as links
gitk: Get rid of the rowchk array
gitk: Do only the parts of the layout that are needed
gitk: Fix bug causing incorrect ref list contents when switching
view
gitk: Fix bug causing undefined variable error when cherry-picking
gitk: Add a cache for the topology info
gitk: Make it possible to lay out all the rows we have received so
far
gitk: Fix bugs in setting rowfinal
gitk: Get rid of lookingforhead, use commitinterest instead
gitk: Fix bug in generating patches
gitk: Simplify highlighting interface and combine with Find
function
gitk: Fix a couple of bugs
gitk: Add progress bars for reading in stuff and for finding
gitk: Fix the tab setting in the diff display window
gitk: Fix bug causing Tcl error when changing find match type
gitk: Use named fonts instead of the font specification
gitk: Keep track of font attributes ourselves instead of using font
actual
gitk: Add a font chooser
gitk: Fix bug where the last few commits would sometimes not be
visible
gitk: Get rid of the diffopts variable
gitk: Fix Tcl error: can't unset findcurline
gitk: Limit diff display to listed paths by default
gitk: Ensure tabstop setting gets restored by Cancel button
gitk: Integrate the reset progress bar in the main frame
gitk: Use the status window for other functions
gitk: Fix some bugs with path limiting in the diff display
gitk: Fix a couple more bugs in the path limiting
gitk: Simplify the code for finding commits
gitk: Use the UI font for the diff/old version/new version radio
buttons
Pierre Habouzit (3):
Add some fancy colors in the test library when terminal supports
it.
Support a --quiet option in the test-suite.
fast-import.c: fix regression due to strbuf conversion
Shawn O. Pearce (37):
Correct builtin-fetch to handle + in refspecs
Fix off by one bug in reflog messages written by builtin-fetch
Remove unnecessary debugging from builtin-fetch
Remove unused unpacklimit variable from builtin-fetch
Replace custom memory growth allocator with ALLOC_GROW
Simplify fetch transport API to just one function
Refactor index-pack "keep $sha1" handling for reuse
Remove pack.keep after ref updates in git-fetch
Always ensure the pack.keep file is removed by git-fetch
Fix builtin-fetch memory corruption by not overstepping array
Backup the array passed to fetch_pack so we can free items
Properly cleanup in http_cleanup so builtin-fetch does not segfault
Don't bother passing ref log details to walker in builtin-fetch
Cleanup duplicate initialization code in transport_get
Add transport.h to LIB_H as transport.o is in LIB_OBJS
Remove unnecessary 'fetch' argument from transport_get API
Allow builtin-fetch to work on a detached HEAD
Don't configure remote "." to fetch everything to itself
Remove more debugging from builtin-fetch
builtin-fetch: Don't segfault on "fetch +foo"
Don't attempt to merge non-existant remotes in t5515
Correct handling of branch.$name.merge in builtin-fetch
Avoid printing unnecessary warnings during fetch and push
Use 'unsigned:1' when we mean boolean options
Rename remote.uri to remote.url within remote handling internals
Refactor struct transport_ops inlined into struct transport
Always obtain fetch-pack arguments from struct fetch_pack_args
Ensure builtin-fetch honors {fetch,transfer}.unpackLimit
Fix memory leaks when disconnecting transport instances
Cleanup style nit of 'x == NULL' in remote.c
Cleanup unnecessary break in remote.c
Prevent send-pack from segfaulting when a branch doesn't match
Fix 'push --all branch...' error handling
Support 'push --dry-run' for rsync transport
Support 'push --dry-run' for http transport
Avoid scary errors about tagged trees/blobs during git-fetch
Define compat version of mkdtemp for systems lacking it
Väinö Järvelä (1):
Added a test for fetching remote tags when there is not tags.
^ permalink raw reply
* Re: [PATCH] rebase: standardize on $() for command substitution
From: Dan McGee @ 2007-11-01 5:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6jaczps.fsf@gitster.siamese.dyndns.org>
On 11/1/07, Junio C Hamano <gitster@pobox.com> wrote:
> Dan McGee <dpmcgee@gmail.com> writes:
>
> > Commit 889a50e909dba5f4416049afc5eeae601fe133bc changed several `` to $()
> > format for command substitution, so we should standardize on one format
> > for clarity.
> > ...
> > @@ -203,7 +203,7 @@ do
> > -s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
> > case "$#,$1" in
> > *,*=*)
> > - strategy=`expr "z$1" : 'z-[^=]*=\(.*\)'` ;;
> > + strategy=$(expr "z$1" : 'z-[^=]*=\(.*\)'` ;)
> > 1,*)
> > usage ;;
> > *)
>
> The patch might have meant well, but it is a rather unnecessary
> code churn without fixing anything and introducing a bug X-<.
Wow, back to the drawing board here. I've been up too long today.
-Dan
^ permalink raw reply
* Re: [PATCH] rebase: standardize on $() for command substitution
From: Junio C Hamano @ 2007-11-01 5:16 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <1193892608-31322-1-git-send-email-dpmcgee@gmail.com>
Dan McGee <dpmcgee@gmail.com> writes:
> Commit 889a50e909dba5f4416049afc5eeae601fe133bc changed several `` to $()
> format for command substitution, so we should standardize on one format
> for clarity.
> ...
> @@ -203,7 +203,7 @@ do
> -s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
> case "$#,$1" in
> *,*=*)
> - strategy=`expr "z$1" : 'z-[^=]*=\(.*\)'` ;;
> + strategy=$(expr "z$1" : 'z-[^=]*=\(.*\)'` ;)
> 1,*)
> usage ;;
> *)
The patch might have meant well, but it is a rather unnecessary
code churn without fixing anything and introducing a bug X-<.
^ permalink raw reply
* Re: remote#branch
From: Theodore Tso @ 2007-11-01 5:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Mike Hommey, Andreas Ericsson, Jeff King, git
In-Reply-To: <200711010122.34190.jnareb@gmail.com>
On Thu, Nov 01, 2007 at 01:22:33AM +0100, Jakub Narebski wrote:
> The only thing to add (for absolutely no gain IMHO) would be code
> which would add quotes (single or double) around URL/path which
> contain spaces:
>
> Mirror URL 'git://repo.or.cz/repo with spaces.git'
> 'http://repo.or.cz/r/repo with spaces.git'
> Push URL 'repo.or.cz:/srv/git/repo with spaces.git'
The one thing that I think might be worth doing out of all of this is
to add code to git so that it can accept URL quoted arguments. Given
that it's highly unlikely anyone is using repository pathnames that
contain the '%' character, this would be highly unlikely to cause any
backwards compatibility problems.
- Ted
^ permalink raw reply
* [PATCH] rebase: standardize on $() for command substitution
From: Dan McGee @ 2007-11-01 4:50 UTC (permalink / raw)
To: git; +Cc: Dan McGee
Commit 889a50e909dba5f4416049afc5eeae601fe133bc changed several `` to $()
format for command substitution, so we should standardize on one format
for clarity.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
---
git-rebase.sh | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 224cca9..63dea56 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -59,7 +59,7 @@ continue_merge () {
die "$RESOLVEMSG"
fi
- cmt=`cat "$dotest/current"`
+ cmt=$(cat "$dotest/current")
if ! git diff-index --quiet HEAD
then
if ! git-commit -C "$cmt"
@@ -74,7 +74,7 @@ continue_merge () {
fi
git rev-list --pretty=oneline -1 "$cmt" | sed -e 's/^[^ ]* //'
- prev_head=`git rev-parse HEAD^0`
+ prev_head=$(git rev-parse HEAD^0)
# save the resulting commit so we can read-tree on it later
echo "$prev_head" > "$dotest/prev_head"
@@ -203,7 +203,7 @@ do
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
case "$#,$1" in
*,*=*)
- strategy=`expr "z$1" : 'z-[^=]*=\(.*\)'` ;;
+ strategy=$(expr "z$1" : 'z-[^=]*=\(.*\)'` ;)
1,*)
usage ;;
*)
@@ -265,7 +265,7 @@ esac
# The upstream head must be given. Make sure it is valid.
upstream_name="$1"
-upstream=`git rev-parse --verify "${upstream_name}^0"` ||
+upstream=$(git rev-parse --verify "${upstream_name}^0") ||
die "invalid upstream $upstream_name"
# Make sure the branch to rebase onto is valid.
@@ -288,9 +288,9 @@ case "$#" in
git-checkout "$2" || usage
;;
*)
- if branch_name=`git symbolic-ref -q HEAD`
+ if branch_name=$(git symbolic-ref -q HEAD)
then
- branch_name=`expr "z$branch_name" : 'zrefs/heads/\(.*\)'`
+ branch_name=$(expr "z$branch_name" : 'zrefs/heads/\(.*\)')
else
branch_name=HEAD ;# detached
fi
@@ -343,11 +343,11 @@ fi
mkdir -p "$dotest"
echo "$onto" > "$dotest/onto"
echo "$onto_name" > "$dotest/onto_name"
-prev_head=`git rev-parse HEAD^0`
+prev_head=$(git rev-parse HEAD^0)
echo "$prev_head" > "$dotest/prev_head"
msgnum=0
-for cmt in `git rev-list --reverse --no-merges "$upstream"..ORIG_HEAD`
+for cmt in $(git rev-list --reverse --no-merges "$upstream"..ORIG_HEAD)
do
msgnum=$(($msgnum + 1))
echo "$cmt" > "$dotest/cmt.$msgnum"
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] git-gui: Update Japanese strings
From: Shawn O. Pearce @ 2007-11-01 4:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ, git
In-Reply-To: <7v640mfvqu.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> しらいしななこ <nanako3@bluebottle.com> writes:
>
> > This updates the Japanese translation file.
>
> This seems to be missing an earlier suggestion from Christian.
Thanks for the follow-up. This plus all of the other git-gui
patches from the past couple of days are now on repo.or.cz.
--
Shawn.
^ 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