* Re: [PATCH 1/3] make index-pâck able to complete thin packs
From: Karl Hasselström @ 2006-10-26 9:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehppbg$phq$1@sea.gmane.org>
On 2006-10-26 09:50:48 +0200, Jakub Narebski wrote:
> That said, git-am should understand QP with coding in mail headers.
I really hope it does, since I just patched StGIT to generate such
headers. (Out of pure vanity -- I don't want my name mangled!)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* merge-recursive, was Re: What's in git.git
From: Johannes Schindelin @ 2006-10-26 9:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk62npipb.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 26 Oct 2006, Junio C Hamano wrote:
> We'd still need more work on merge-recursive to fix the
> overcautious "working file will be overwritten by merge" --
> this is really needed for usability.
I am sorry, but I do not have the time to wrap my head around this for at
least another week. It seems to be a complicated problem (not the fix,
mind you, but the side effects you have to think of!), and I stupidly
started to play with shallow clones when I knew I had no time already.
BTW what happened to the builtin shortlog? It is the last Perl script I
use regularly... (should make people happy who are stuck with Activision
Perl...)
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git
From: Jakub Narebski @ 2006-10-26 9:12 UTC (permalink / raw)
To: git
In-Reply-To: <7vk62npipb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> * The 'master' branch has these since the last announcement.
>
> I've flushed all the 'gitweb/' changes from "next" and core
> support that some of them needed; notably "for-each-ref" and
> "blame --porcelain" is now in "master". Oh, and "annotate"
> is now a mere synonym for "blame -c".
[...]
> Junio C Hamano (20):
[...]
> gitweb: prepare for repositories with packed refs.
[...]
> gitweb: use for-each-ref to show the latest activity across branches
This unfortunately means that I cannot test gitweb based on 'master'
branch using _released_ git core, git version 1.4.3.3, as it doesn't have
git-for-each-ref nor git-show-ref.
BTW. do people often use latest gitweb with older git binaries? Should
we try to wait for core feature to mature to released version before using
it in gitweb? Or perhaps we should add some kind of version checking, and
provide workrounds, e.g. using $ENV{GIT_DIR} if git core doesn't support
--git-dir option, pathlimit filtering using git-rev-list piped to
git-diff-tree --stdin in git_history if there is no --full-history
option, show always HEAD activity if there is no git-for-each-ref
etc.; well the latest we can do without checking for git core version, just
if -x qx($GIT --exec-path)/git-for-each-ref
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH (resend)] gitweb: Use --no-commit-id in git_commit and git_commitdiff
From: Junio C Hamano @ 2006-10-26 8:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610261050.21214.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Use --no-commit-id option to git-diff-tree command in git_commit and
> git_commitdiff to filter out commit ID output that git-diff-tree adds
> when called with only one <tree-ish> (not only for --stdin). Remove
> filtering commit IDs from git-diff-tree output.
>
> This option is in git since at least v1.0.0, so make use of it.
*BLUSH*
I think we would need something like this, if only for
completeness.
-- >8 --
[PATCH] combine-diff: honour --no-commit-id
Somehow we forgot to look at no_commit_id flag in these
codepaths.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
combine-diff.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 01a8437..8ff46e8 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -737,7 +737,7 @@ static void show_patch_diff(struct combi
int added = 0;
int deleted = 0;
- if (rev->loginfo)
+ if (rev->loginfo && !rev->no_commit_id)
show_log(rev, opt->msg_sep);
dump_quoted_path(dense ? "diff --cc " : "diff --combined ",
elem->path, c_meta, c_reset);
@@ -815,7 +815,7 @@ static void show_raw_diff(struct combine
if (!line_termination)
inter_name_termination = 0;
- if (rev->loginfo)
+ if (rev->loginfo && !rev->no_commit_id)
show_log(rev, opt->msg_sep);
if (opt->output_format & DIFF_FORMAT_RAW) {
@@ -887,7 +887,7 @@ void diff_tree_combined(const unsigned c
diffopts.output_format = DIFF_FORMAT_NO_OUTPUT;
diffopts.recursive = 1;
- show_log_first = !!rev->loginfo;
+ show_log_first = !!rev->loginfo && !rev->no_commit_id;
needsep = 0;
/* find set of paths that everybody touches */
for (i = 0; i < num_parent; i++) {
^ permalink raw reply related
* Re: VCS comparison table
From: James Henstridge @ 2006-10-26 8:52 UTC (permalink / raw)
To: Carl Worth
Cc: bazaar-ng, Matthew D. Fuller, Linus Torvalds, Andreas Ericsson,
git, Jakub Narebski
In-Reply-To: <87slhcz8zh.wl%cworth@cworth.org>
On 25/10/06, Carl Worth <cworth@cworth.org> wrote:
> On Wed, 25 Oct 2006 18:08:22 +0800, "James Henstridge" wrote:
> > If there aren't, or you made the merge by mistake, you can make a call
> > to "bzr revert" to clean things up without ever having created a new
> > revision.
>
> One result of this approach is that developers of different trees
> don't necessarily have common revision IDs to compare. Imagine a
> question like:
>
> When you ran that test did you have the same code I've got?
>
> In git, the answer would be determined by comparing revision IDs.
Can you really just rely on equal revision IDs meaning you have the
same code though?
Lets say that I clone your git repository, and then we both merge the
same diverged branch. Will our head revision IDs match? From a quick
look at the logs of cairo, it seems that the commits generated for
such a merge include the date and author, so the two commits would
have different SHA1 sums (and hence different revision IDs).
So I'd have a revision you don't have and vice versa, even though the
trees are identical.
> In bzr, the only answer I'm hearing is attempting a merge to see if it
> introduces any changes. (I'm deliberately avoiding "pull" since we're
> talking about distributed cases here).
Or run "bzr missing". If the sole missing revision is a merge (and
not the revisions introduced by the merge), you could assume that you
have the same tree state.
> And to comment on something mentioned earlier in the thread, there's
> no need for "wildly complex" distributed scenarios. All of these
> issues are present with developers working together as peers, (and
> each considering their own repository as canonical).
>
> A harder question (for bzr) is:
>
> Do you have all of the history I've got?
>
> (The problem being that when one developer is missing some history and
> merges it in, she necessarily creates new history, so there's never a
> stable point for both sides to agree on.)
Why does it matter if they create a new revision? They can still tell
if they've got all the history you had.
^ permalink raw reply
* [PATCH (resend)] gitweb: Use --no-commit-id in git_commit and git_commitdiff
From: Jakub Narebski @ 2006-10-26 8:50 UTC (permalink / raw)
To: git
Use --no-commit-id option to git-diff-tree command in git_commit and
git_commitdiff to filter out commit ID output that git-diff-tree adds
when called with only one <tree-ish> (not only for --stdin). Remove
filtering commit IDs from git-diff-tree output.
This option is in git since at least v1.0.0, so make use of it.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d7034b4..35a9afb 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3133,14 +3133,12 @@ sub git_commit {
if (!defined $parent) {
$parent = "--root";
}
- open my $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts, $parent, $hash
+ open my $fd, "-|", git_cmd(), "diff-tree", '-r', "--no-commit-id",
+ @diff_opts, $parent, $hash
or die_error(undef, "Open git-diff-tree failed");
my @difftree = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading git-diff-tree failed");
- # filter out commit ID output
- @difftree = grep(!/^[0-9a-fA-F]{40}$/, @difftree);
-
# non-textual hash id's can be cached
my $expires;
if ($hash =~ m/^[0-9a-fA-F]{40}$/) {
@@ -3453,15 +3451,14 @@ sub git_commitdiff {
my @difftree;
if ($format eq 'html') {
open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
+ "--no-commit-id",
"--patch-with-raw", "--full-index", $hash_parent, $hash
or die_error(undef, "Open git-diff-tree failed");
while (chomp(my $line = <$fd>)) {
# empty line ends raw part of diff-tree output
last unless $line;
- # filter out commit ID output
- push @difftree, $line
- unless $line =~ m/^[0-9a-fA-F]{40}$/;
+ push @difftree, $line;
}
} elsif ($format eq 'plain') {
--
1.4.3.3
^ permalink raw reply related
* Re: [PATCH] git-svnimport: support for partial imports
From: Karl Hasselström @ 2006-10-26 8:47 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Junio C Hamano, git, Matthias Urlichs
In-Reply-To: <20061025225026.GA13031@sashak.voltaire.com>
On 2006-10-26 00:50:26 +0200, Sasha Khapyorsky wrote:
> This adds support for partial svn imports. Let's assume that SVN
> repository layout looks like:
>
> $trunk/path/to/our/project
> $branches/path/to/our/project
> $tags/path/to/our/project
>
> , and we would like to import only tree under this specific
> 'path/to/our/project' and not whole tree under $trunk, $branches,
> etc.. Now we will be be able to do it by using '-P
> path/to/our/project' option with git-svnimport.
Isn't this already doable with "-T trunk/path/to/our/project -t
tags/path/to/our/project -b branches/path/to/our/project"?
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-10-26 8:47 UTC (permalink / raw)
To: git
* The 'maint' branch has produced 1.4.3.3 and has these fixes
since the last announcement (some of them are post 1.4.3.3).
Christian Couder (1):
Remove --syslog in git-daemon inetd documentation examples.
Eric Wong (1):
git-svn: fix symlink-to-file changes when using command-line svn 1.4.0
Gerrit Pape (1):
Set $HOME for selftests
J. Bruce Fields (1):
Documentation: updates to "Everyday GIT"
Jakub Narebski (1):
diff-format.txt: Combined diff format documentation supplement
Junio C Hamano (6):
Documentation: note about contrib/.
RPM package re-classification.
Refer to git-rev-parse:Specifying Revisions from git.txt
Update cherry documentation.
Documentation/SubmittingPatches: 3+1 != 6
Documentation: clarify refname disambiguation rules.
Petr Baudis (1):
xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines
Tuncer Ayaz (1):
git-fetch.sh printed protocol fix
* The 'master' branch has these since the last announcement.
I've flushed all the 'gitweb/' changes from "next" and core
support that some of them needed; notably "for-each-ref" and
"blame --porcelain" is now in "master". Oh, and "annotate"
is now a mere synonym for "blame -c".
Alan Chandler (1):
Gitweb - provide site headers and footers
Andy Whitcroft (2):
cvsimport: move over to using git-for-each-ref to read refs.
git-for-each-ref: improve the documentation on scripting modes
Christian Couder (1):
Remove --syslog in git-daemon inetd documentation examples.
Eric Wong (1):
git-svn: fix symlink-to-file changes when using command-line svn 1.4.0
Gerrit Pape (1):
Set $HOME for selftests
J. Bruce Fields (1):
Documentation: updates to "Everyday GIT"
Jakub Narebski (4):
gitweb: Get rid of git_print_simplified_log
gitweb: Filter out commit ID from @difftree in git_commit and git_commitdiff
gitweb: Print commit message without title in commitdiff only if there is any
diff-format.txt: Combined diff format documentation supplement
Junio C Hamano (20):
Add git-for-each-ref: helper for language bindings
gitweb: make leftmost column of blame less cluttered.
gitweb: prepare for repositories with packed refs.
Revert 954a6183756a073723a7c9fd8d2feb13132876b0
blame.c: whitespace and formatting clean-up.
git-blame: --show-name (and -f)
git-blame: --show-number (and -n)
blame.c: move code to output metainfo into a separate function.
git-blame --porcelain
gitweb: use blame --porcelain
blame: Document and add help text for -f, -n, and -p
gitweb: spell "blame --porcelain" with -p
gitweb: use for-each-ref to show the latest activity across branches
Documentation: note about contrib/.
RPM package re-classification.
Refer to git-rev-parse:Specifying Revisions from git.txt
Update cherry documentation.
Documentation/SubmittingPatches: 3+1 != 6
Documentation: clarify refname disambiguation rules.
combine-diff: a few more finishing touches.
Luben Tuikov (3):
gitweb: blame: print commit-8 on the leading row of a commit-block
gitweb: blame: Mouse-over commit-8 shows author and date
gitweb: blame porcelain: lineno and orig lineno swapped
Petr Baudis (5):
gitweb: Restore object-named links in item lists
gitweb: Make search type a popup menu
gitweb: Do not automatically append " git" to custom site name
gitweb: Show project's README.html if available
xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines
Ryan Anderson (1):
Remove git-annotate.perl and create a builtin-alias for git-blame
Tuncer Ayaz (1):
git-fetch.sh printed protocol fix
* The 'next' branch, in addition, has these.
The next series to graduate is Linus's "packed-ref" and
associated changes, including rewrite of "branch" in C,
perhaps early next week.
Christian Couder (12):
Add [-s|--hash] option to Linus' show-ref.
Use Linus' show ref in "git-branch.sh".
Document git-show-ref [-s|--hash] option.
Fix show-ref usage for --dereference.
Add pack-refs and show-ref test cases.
When creating branch c/d check that branch c does not already exists.
Uncomment test case: git branch c/d should barf if branch c exists.
Fix a remove_empty_dir_recursive problem.
Clean up "git-branch.sh" and add remove recursive dir test cases.
Use git-update-ref to delete a tag instead of rm()ing the ref file.
Check that a tag exists using show-ref instead of looking for the ref file.
Do not create tag leading directories since git update-ref does it.
Dennis Stosberg (2):
lock_ref_sha1_basic does not remove empty directories on BSD
Remove bashism from t3210-pack-refs.sh
Jeff King (3):
wt-status: use simplified resolve_ref to find current branch
gitignore: git-pack-refs is a generated file.
gitignore: git-show-ref is a generated file.
Johannes Schindelin (2):
Fix git-update-index --again
show-branch: mark active branch with a '*' again
Jonas Fonseca (1):
Add man page for git-show-ref
Junio C Hamano (47):
upload-pack: stop the other side when they have more roots than we do.
Fix t1400-update-ref test minimally
fsck-objects: adjust to resolve_ref() clean-up.
symbolit-ref: fix resolve_ref conversion.
Add callback data to for_each_ref() family.
Tell between packed, unpacked and symbolic refs.
pack-refs: do not pack symbolic refs.
git-pack-refs --prune
pack-refs: fix git_path() usage.
lock_ref_sha1_basic: remove unused parameter "plen".
Clean-up lock-ref implementation
update-ref: -d flag and ref creation safety.
update a few Porcelain-ish for ref lock safety.
Teach receive-pack about ref-log
receive-pack: call setup_ident before git_config
ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
refs: minor restructuring of cached refs data.
lock_ref_sha1(): do not sometimes error() and sometimes die().
lock_ref_sha1(): check D/F conflict with packed ref when creating.
delete_ref(): delete packed ref
git-branch: remove D/F check done by hand.
show-ref --hash=len, --abbrev=len, and --abbrev
git-fetch: adjust to packed-refs.
Fix refs.c;:repack_without_ref() clean-up path
git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
pack-refs: use lockfile as everybody else does.
pack-refs: call fflush before fsync.
ref-log: allow ref@{count} syntax.
core.logallrefupdates create new log file only for branch heads.
git-pack-refs --all
core.logallrefupdates thinko-fix
pack-objects: use of version 3 delta is now optional.
Revert "pack-objects: use of version 3 delta is now optional."
ref-log: fix D/F conflict coming from deleted refs.
git-pickaxe: blame rewritten.
git-pickaxe -M: blame line movements within a file.
git-pickaxe -C: blame cut-and-pasted lines.
git-pickaxe: pagenate output by default.
git-pickaxe: fix nth_line()
git-pickaxe: improve "best match" heuristics
git-pickaxe: introduce heuristics to avoid "trivial" chunks
git-pickaxe: do not keep commit buffer.
git-pickaxe: do not confuse two origins that are the same.
git-pickaxe: get rid of wasteful find_origin().
git-pickaxe: swap comparison loop used for -C
sha1_name.c: avoid compilation warnings.
t3200: git-branch testsuite update
Lars Hjemli (1):
Make git-branch a builtin
Linus Torvalds (6):
Add "git show-ref" builtin command
Teach "git checkout" to use git-show-ref
Start handling references internally as a sorted in-memory list
Add support for negative refs
Make ref resolution saner
Enable the packed refs file format
Luben Tuikov (1):
git-revert with conflicts to behave as git-merge with conflicts
Nicolas Pitre (1):
enable index-pack streaming capability
Petr Baudis (2):
Fix broken sha1 locking
Fix buggy ref recording
Rene Scharfe (1):
Built-in cherry
* The 'pu' branch, in addition, has these.
We'd still need more work on merge-recursive to fix the
overcautious "working file will be overwritten by merge" --
this is really needed for usability.
The diff/apply change I am holding back is the one that
appends an extra tab after "---/+++" filename to the diff
output, when the filename has an embedded SP in it, to make it
compatible with GNU diff. Updates to git-apply to understand
the new output is already in "master" but not in 1.4.3 series,
and until it propagates to majority of users, this change
cannot be unleashed, in order to keep people with older git
who use such a pathname happy.
I did not hear any comments on the left-right stuff; perhaps
it is not needed, or it is not useful as its current shape (it
could be enhanced to say which starting commits each of the
commit is reachable from, by borrowing much of show-branch
code).
I looked at Pasky's "project forks" gitweb code, and while I
liked it a lot (having a demonstration site repo.or.cz really
helps), I read on #git log that Pasky himself was having
doubt, so it is parked in "pu", not in "next".
Nico's 3-patch index-pack rework is quite nice; unfortunately
the last one in the series seems to make the test fail so it
is not included here, and I did not find enough time to see if
the other two are "next" material. They are parked in "pu" in
the meantime.
Junio C Hamano (7):
merge: loosen overcautious "working file will be lost" check.
merge-recursive: use abbreviated commit object name.
merge-recursive: make a few functions static.
git-commit: show --summary after successful commit.
para-walk: walk n trees, index and working tree in parallel
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
rev-list --left-right
Nicolas Pitre (2):
make index-pack able to complete thin packs.
add progress status to index-pack
Petr Baudis (1):
gitweb: Support for 'forks'
^ permalink raw reply
* Re: an option to make "git-diff Z A" prints Z's diff before A's
From: Karl Hasselström @ 2006-10-26 8:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jim Meyering, git
In-Reply-To: <7vd58g9pfs.fsf@assigned-by-dhcp.cox.net>
On 2006-10-25 12:16:07 -0700, Junio C Hamano wrote:
> The thing is, "git diff -- Z A" does *not* mean:
>
> I know I have a file called Z and a file called A; please give
> diff for these files.
>
> What it means is:
>
> Please give me the diff as usual, but I care about paths that
> match these patterns, Z or A.
A related question: is there a way to limit the path to Z, but
excluding Z/B? That is, I'm interested in the changes in Z, but not
the changes in its subdirectory B.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: [PATCH] Documentation: clarify refname disambiguation rules.
From: Jakub Narebski @ 2006-10-26 8:40 UTC (permalink / raw)
To: git
In-Reply-To: <7vhcxrqynx.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> -* A suffix '@' followed by a date specification enclosed in a brace
[...]
> +* A ref followed by the suffix '@' with a date specification
> + enclosed in a brace
> pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1
This introduces strange line breaking. Is it only in source?
Here diff didn't produce optimal for review patch, separating changed from
part and changed to part with large block of added code.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/2] New stg command: assimilate
From: Karl Hasselström @ 2006-10-26 8:32 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0610250941jfd5d11fk467ab586773ba205@mail.gmail.com>
On 2006-10-25 17:41:50 +0100, Catalin Marinas wrote:
> On 25/10/06, Karl Hasselström <kha@treskal.com> wrote:
>
> > I just realized, by means of an infinite loop, that "patchname"
> > should be replaced with just "name" in the body of this function.
> > Would you like me to resend the patch?
>
> I can do it, no need to resend. I'll push the patch tonight and you
> can check it (I also fixed the "reversed" call as it is not
> available in my Python implementation).
Aahh, I avoided using set() (and had to settle for a decidedly less
elegant dict-with-arbitrary-values) precisely so that the code
wouldn't require Python 2.4, but reversed() is also a new feature of
2.4.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Make new builtin cherry match documentation for "+" and "-"
From: Junio C Hamano @ 2006-10-26 8:22 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610260845.23850.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Wednesday 2006 October 25 19:41, Junio C Hamano wrote:
>
>> > "+" and "-" don't match the documentation, where "+" means the patch /is/
>> > in upstream, "-" means it isn't
>>
>> The documentation was utterly wrong. The comment at the
>> beginning of git-cherry.sh was better but slightly wrong.
>
> Seriously? In git-cherry output a "-" means that a patch is in? Seems
> counter-intuitive to me.
>
> Or is it meant to be analogous to a diff so "+" means "in order to make this
> branch like the comparison branch you would have to /add/ this patch"?
It's more like "This is still relevant and you need to
positively push your upstream for inclusion".
^ permalink raw reply
* [PATCH] Show [xxxx] suffix after non-"heads" branches in git-branch output
From: Andy Parkins @ 2006-10-26 8:18 UTC (permalink / raw)
To: git
This patch changes from showing only those refs in "heads/" to all non-"tags/"
refs.
For any ref that isn't a "heads/" ref (like "remotes/") a suffix of "[xxx]" is
added to the line.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
This patch is in preference to my earlier "Use "up/" prefix for all the
upstream branches" patch. Junio pointed out that that patch wasn't necessary
because git already supports the "--use-separate-remote" option. This patch
makes git-branch always show all the branches that are useable as references
in tree-ish, but highlights the remote branches.
git-branch.sh | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/git-branch.sh b/git-branch.sh
index f823c78..bddd189 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -87,17 +87,28 @@ done
case "$#" in
0)
- git-rev-parse --symbolic --branches |
+ git-rev-parse --symbolic --all |
sort |
- while read ref
+ grep -v "^refs/tags" |
+ sed -ne 's|^refs/\([^/]*\)/\(.*\)|\1 \2|p' |
+ while read type ref
do
+ case "$type" in
+ heads)
+ type=""
+ ;;
+ *)
+ type=" [$type]"
+ ;;
+ esac
+
if test "$headref" = "$ref"
then
pfx='*'
else
pfx=' '
fi
- echo "$pfx $ref"
+ echo "$pfx $ref$type"
done
exit 0 ;;
1)
--
1.4.2.3
^ permalink raw reply related
* [PATCH] Documentation: clarify refname disambiguation rules.
From: Junio C Hamano @ 2006-10-26 8:17 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610260814.05957.andyparkins@gmail.com>
Nobody should create ambiguous refs (i.e. have tag "foobar" and branch
"foobar" at the same time) that need to be disambiguated with these
rules to keep sanity, but the rules are there so document them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
>> Heh, I spoke too fast.
>>
>> "git log origin..master"
>>
>> If you do not have none of .git/origin, .git/refs/origin,
>> .git/refs/tags/origin, .git/refs/heads/origin, nor
>> .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is
>> what "origin" means (see get_sha1_basic() in sha1_name.c).
Something like this.
Documentation/git-rev-parse.txt | 25 +++++++++++++++++++++----
1 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 5d42570..ed938aa 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -122,14 +122,30 @@ blobs contained in a commit.
your repository whose object name starts with dae86e.
* An output from `git-describe`; i.e. a closest tag, followed by a
- dash, a 'g', and an abbreviated object name.
+ dash, a `g`, and an abbreviated object name.
* A symbolic ref name. E.g. 'master' typically means the commit
object referenced by $GIT_DIR/refs/heads/master. If you
happen to have both heads/master and tags/master, you can
explicitly say 'heads/master' to tell git which one you mean.
+ When ambiguous, a `<name>` is disambiguated by taking the
+ first match in the following rules:
-* A suffix '@' followed by a date specification enclosed in a brace
+ . if `$GIT_DIR/<name>` exists, that is what you mean (this is usually
+ useful only for `HEAD`, `FETCH_HEAD` and `MERGE_HEAD`);
+
+ . otherwise, `$GIT_DIR/refs/<name>` if exists;
+
+ . otherwise, `$GIT_DIR/refs/tags/<name>` if exists;
+
+ . otherwise, `$GIT_DIR/refs/heads/<name>` if exists;
+
+ . otherwise, `$GIT_DIR/refs/remotes/<name>` if exists;
+
+ . otherwise, `$GIT_DIR/refs/remotes/<name>/HEAD` if exists.
+
+* A ref followed by the suffix '@' with a date specification
+ enclosed in a brace
pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1
second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value
of the ref at a prior point in time. This suffix may only be
@@ -146,8 +162,9 @@ blobs contained in a commit.
* A suffix '{tilde}<n>' to a revision parameter means the commit
object that is the <n>th generation grand-parent of the named
commit object, following only the first parent. I.e. rev~3 is
- equivalent to rev{caret}{caret}{caret} which is equivalent to\
- rev{caret}1{caret}1{caret}1.
+ equivalent to rev{caret}{caret}{caret} which is equivalent to
+ rev{caret}1{caret}1{caret}1. See below for a illustration of
+ the usage of this form.
* A suffix '{caret}' followed by an object type name enclosed in
brace pair (e.g. `v0.99.8{caret}\{commit\}`) means the object
--
1.4.3.3.g43f1
^ permalink raw reply related
* Re: [PATCH 3/3] mimic unpack-objects when --stdin is used with index-pack
From: Junio C Hamano @ 2006-10-26 7:55 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610252330320.12418@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> It appears that git-unpack-objects writes the last part of the input
> buffer to stdout after the pack has been parsed. This looks a bit
> suspicious since the last fill() might have filled the buffer up to
> the 4096 byte limit and more data might still be pending on stdin,
> but since this is about being a drop-in replacement for unpack-objects
> let's simply duplicate the same behavior for now.
This seems to break t5300 when applied on top of everything
else. The other two numbered patches are Ok.
^ permalink raw reply
* Re: [PATCH 1/3] make index-pâck able to complete thin packs
From: Jakub Narebski @ 2006-10-26 7:50 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6wvr1ca.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> From: Nicolas Pitre <nico@cam.org>
> Subject: =?UTF-8?Q?=5BPATCH_1=2F3=5D_make_index-p=C3=A2ck_able_to_comp?=
> =?UTF-8?Q?lete_thin_packs?=
>
> Is this a new trick or something?
I see \hat{a} (or \^{a}) in "index-pack" (index-pâck) in subject.
That said, git-am should understand QP with coding in mail headers.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Make new builtin cherry match documentation for "+" and "-"
From: Andy Parkins @ 2006-10-26 7:45 UTC (permalink / raw)
To: git
In-Reply-To: <7vk62ob5mp.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2006 October 25 19:41, Junio C Hamano wrote:
> > "+" and "-" don't match the documentation, where "+" means the patch /is/
> > in upstream, "-" means it isn't
>
> The documentation was utterly wrong. The comment at the
> beginning of git-cherry.sh was better but slightly wrong.
Seriously? In git-cherry output a "-" means that a patch is in? Seems
counter-intuitive to me.
Or is it meant to be analogous to a diff so "+" means "in order to make this
branch like the comparison branch you would have to /add/ this patch"?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH 1/3] make index-pâck able to complete thin packs
From: Junio C Hamano @ 2006-10-26 7:19 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610252323100.12418@xanadu.home>
From: Nicolas Pitre <nico@cam.org>
Subject: =?UTF-8?Q?=5BPATCH_1=2F3=5D_make_index-p=C3=A2ck_able_to_comp?=
=?UTF-8?Q?lete_thin_packs?=
Is this a new trick or something?
^ permalink raw reply
* Re: (unknown)
From: Andy Parkins @ 2006-10-26 7:14 UTC (permalink / raw)
To: git
In-Reply-To: <7vwt6okpgr.fsf@assigned-by-dhcp.cox.net>
> > "git log remotes/origin..master" perhaps?
> >
> > The point being, remotes/origin when origin is a directory that
> > has HEAD that points at something, it stands for
> > remotes/origin/HEAD.
>
> Heh, I spoke too fast.
>
> "git log origin..master"
>
> If you do not have none of .git/origin, .git/refs/origin,
> .git/refs/tags/origin, .git/refs/heads/origin, nor
> .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is
> what "origin" means (see get_sha1_basic() in sha1_name.c).
Again: you guys have thought of everything.
I believe then, that my problem is that I didn't find this written anywhere -
would it be useful if I were to write a Documentation/ file about
commit-ish/tree-ish that covered these issues? Have I overlooked the
existence of such a file already?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH] diff-format.txt: Combined diff format documentation supplement
From: Junio C Hamano @ 2006-10-26 7:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <7v1wovsgkf.fsf@assigned-by-dhcp.cox.net>
This script minimally demonstrates a few interesting things an
evil merge can do. Run it in a throw-away directory and view
the resulting merge with "git-show" with or without the patch I
sent out earlier.
One thing that you would notice is that the combined-diff code
chooses not to show the original contents of a deleted
file. while showing the whole result of a new file. Strictly
speaking, this is inconsistent, but an evil merge is rare and
what ended up getting removed is not as interesting as what
remains as the result.
-- >8 --
#!/bin/sh
test -d .git && {
echo Run me in an empty directory please
exit 1
}
git init-db
echo one >file1.txt
git add file1.txt
git commit -m initial
git branch side
echo two >file2.txt
git add file2.txt
git commit -m second
git checkout side
echo uno >file1.txt
git commit -a -m side
git merge "Evil merge" HEAD master
rm -f file1.txt
echo added by the evil merge >file3.txt
echo modified by the evil merge >file2.txt
git update-index --add --remove file1.txt file2.txt file3.txt
EDITOR=: VISUAL=: git commit --amend
^ permalink raw reply
* Re: [PATCH] diff-format.txt: Combined diff format documentation supplement
From: Junio C Hamano @ 2006-10-26 7:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <7vac3jk3g7.fsf@assigned-by-dhcp.cox.net>
By the way, this is only minimally tested, but this patch fills
the blanks in your documentation.
The combine_diff_path structure _does_ keep track of the
original path in each parent, so renames _could_ be shown (we do
not keep the score, though), but the question is how. "rename to"
would obviously be "the path in the merge result", but "rename from"
needs to be shown for all parents when we have rename from any
of the parents. "rename from" line as in the usual one parent diff
does not have any place to say "which parent" (because there is
no need), so showing the usual "rename from" for only parents
that the result has rename from makes the output useless -- we
cannot tell "from which parent" from such an output. I feel
that an evil merge is rare enough that worrying about showing
rename line is probably not worth the effort.
-- >8 --
[PATCH] combine-diff: a few more finishing touches.
"new file" and "deleted file" were already reported in the
original code, but the logic was not as transparent as it could
have. This uses a few variables and more comments to clarify
the flow. The rule is: (1) if a path exists in the merge result
when no parent had it, we report "new" (otherwise it came from
the parents, as opposed to have added by the evil merge). (2) if
the path does not exist in the merge result, it is "deleted".
Since we can say "new" and "deleted", there is no reason not to
follow the /dev/null convention. This fixes it.
Appending function name after @@@ ... @@@ is trivial, so
implement it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
combine-diff.c | 48 +++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 46d9121..01a8437 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -489,6 +489,12 @@ static void show_parent_lno(struct sline
printf(" -%lu,%lu", l0, l1-l0);
}
+static int hunk_comment_line(const char *bol)
+{
+ int ch = *bol & 0xff;
+ return (isalpha(ch) || ch == '_' || ch == '$');
+}
+
static void dump_sline(struct sline *sline, unsigned long cnt, int num_parent,
int use_color)
{
@@ -508,8 +514,13 @@ static void dump_sline(struct sline *sli
struct sline *sl = &sline[lno];
unsigned long hunk_end;
unsigned long rlines;
- while (lno <= cnt && !(sline[lno].flag & mark))
+ const char *hunk_comment = NULL;
+
+ while (lno <= cnt && !(sline[lno].flag & mark)) {
+ if (hunk_comment_line(sline[lno].bol))
+ hunk_comment = sline[lno].bol;
lno++;
+ }
if (cnt < lno)
break;
else {
@@ -526,6 +537,22 @@ static void dump_sline(struct sline *sli
show_parent_lno(sline, lno, hunk_end, i);
printf(" +%lu,%lu ", lno+1, rlines);
for (i = 0; i <= num_parent; i++) putchar(combine_marker);
+
+ if (hunk_comment) {
+ int comment_end = 0;
+ for (i = 0; i < 40; i++) {
+ int ch = hunk_comment[i] & 0xff;
+ if (!ch || ch == '\n')
+ break;
+ if (!isspace(ch))
+ comment_end = i;
+ }
+ if (comment_end)
+ putchar(' ');
+ for (i = 0; i < comment_end; i++)
+ putchar(hunk_comment[i]);
+ }
+
printf("%s\n", c_reset);
while (lno < hunk_end) {
struct lline *ll;
@@ -707,6 +734,8 @@ static void show_patch_diff(struct combi
int use_color = opt->color_diff;
const char *c_meta = diff_get_color(use_color, DIFF_METAINFO);
const char *c_reset = diff_get_color(use_color, DIFF_RESET);
+ int added = 0;
+ int deleted = 0;
if (rev->loginfo)
show_log(rev, opt->msg_sep);
@@ -722,7 +751,10 @@ static void show_patch_diff(struct combi
printf("..%s%s\n", abb, c_reset);
if (mode_differs) {
- int added = !!elem->mode;
+ deleted = !elem->mode;
+
+ /* We say it was added if nobody had it */
+ added = !deleted;
for (i = 0; added && i < num_parent; i++)
if (elem->parent[i].status !=
DIFF_STATUS_ADDED)
@@ -731,7 +763,7 @@ static void show_patch_diff(struct combi
printf("%snew file mode %06o",
c_meta, elem->mode);
else {
- if (!elem->mode)
+ if (deleted)
printf("%sdeleted file ", c_meta);
printf("mode ");
for (i = 0; i < num_parent; i++) {
@@ -743,8 +775,14 @@ static void show_patch_diff(struct combi
}
printf("%s\n", c_reset);
}
- dump_quoted_path("--- a/", elem->path, c_meta, c_reset);
- dump_quoted_path("+++ b/", elem->path, c_meta, c_reset);
+ if (added)
+ dump_quoted_path("--- /dev/", "null", c_meta, c_reset);
+ else
+ dump_quoted_path("--- a/", elem->path, c_meta, c_reset);
+ if (deleted)
+ dump_quoted_path("+++ /dev/", "null", c_meta, c_reset);
+ else
+ dump_quoted_path("+++ b/", elem->path, c_meta, c_reset);
dump_sline(sline, cnt, num_parent, opt->color_diff);
}
free(result);
^ permalink raw reply related
* Re: [PATCH] diff-format.txt: Combined diff format documentation supplement
From: Junio C Hamano @ 2006-10-26 6:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610260544.50614.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> So here you have. It should perhaps get review on validity by someone
> well versed in the combined diff generation code. There are some guesses
> here...
Thanks.
I guess review by the original author would be good enough;
this is entirely my code -- it was done while Linus and gang
was having fun in NZ, if I recall correctly ;-).
> It compiles, but the output was not inspected.
I've done minimal asciidoc mark-up fixes. Troff man output look
horrible but that is not limited to this man page -- it looks
quite wrong whenever numbered list with displayed examples are
used.
^ permalink raw reply
* Re: [PATCH] Remove --syslog in git-daemon inetd documentation examples.
From: Junio C Hamano @ 2006-10-26 6:11 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20061026063307.45872277.chriscool@tuxfamily.org>
Thanks; will apply.
^ permalink raw reply
* [PATCH] Remove --syslog in git-daemon inetd documentation examples.
From: Christian Couder @ 2006-10-26 4:33 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
It is useless because --inetd implies --syslog.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/everyday.txt | 4 ++--
Documentation/git-daemon.txt | 6 ++----
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index b935c18..f1b2265 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -377,7 +377,7 @@ Run git-daemon to serve /pub/scm from in
------------
$ grep git /etc/inetd.conf
git stream tcp nowait nobody \
- /usr/bin/git-daemon git-daemon --inetd --syslog --export-all /pub/scm
+ /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
------------
+
The actual configuration line should be on one line.
@@ -397,7 +397,7 @@ service git
wait = no
user = nobody
server = /usr/bin/git-daemon
- server_args = --inetd --syslog --export-all --base-path=/pub/scm
+ server_args = --inetd --export-all --base-path=/pub/scm
log_on_failure += USERID
}
------------
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index d562232..4b2ea2d 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -165,8 +165,7 @@ git-daemon as inetd server::
+
------------------------------------------------
git stream tcp nowait nobody /usr/bin/git-daemon
- git-daemon --inetd --verbose
- --syslog --export-all
+ git-daemon --inetd --verbose --export-all
/pub/foo /pub/bar
------------------------------------------------
@@ -179,8 +178,7 @@ git-daemon as inetd server for virtual h
+
------------------------------------------------
git stream tcp nowait nobody /usr/bin/git-daemon
- git-daemon --inetd --verbose
- --syslog --export-all
+ git-daemon --inetd --verbose --export-all
--interpolated-path=/pub/%H%D
/pub/www.example.org/software
/pub/www.example.com/software
--
^ permalink raw reply related
* fetching packs and storing them as packs
From: Nicolas Pitre @ 2006-10-26 3:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
With the last few patches I just posted it is now possible to receive
(fetch) packs, validate them on the fly, complete them if they are thin
packs, and store them directly without exploding them into loose
objects.
There are advantages and inconvenients to both methods, so I think this
should become a configuration option and/or even a command line argument
to git-fetch. I think there are many more advantages to keeping packs
packed hence I think using index-pack should become the default.
But I'm a bit tired to play with it and the final integration is for
someone else to do. I've tested it lightly using the extremely crude
patch below to hook it in the fetch process.
Have fun!
diff --git a/fetch-clone.c b/fetch-clone.c
index 76b99af..28796c3 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -142,7 +142,8 @@ int receive_unpack_pack(int xd[2], const
dup2(fd[0], 0);
close(fd[0]);
close(fd[1]);
- execl_git_cmd("unpack-objects", quiet ? "-q" : NULL, NULL);
+ execl_git_cmd("index-pack", "--stdin", "--fix-thin",
+ quiet ? NULL : "-v", NULL);
die("git-unpack-objects exec failed");
}
close(fd[0]);
diff --git a/receive-pack.c b/receive-pack.c
index 1fcf3a9..7f6dc49 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -7,7 +7,7 @@
static const char receive_pack_usage[] = "git-receive-pack <git-dir>";
-static const char *unpacker[] = { "unpack-objects", NULL };
+static const char *unpacker[] = { "index-pack", "-v", "--stdin", "--fix-thin", NULL };
static int report_status;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox