* [PATCH/RFR&A] Do not rename read-only files during a push
From: Junio C Hamano @ 2008-10-19 7:07 UTC (permalink / raw)
To: Petr Baudis, Johannes Sixt, Shawn O. Pearce; +Cc: git
This is on the "merged to 'master' soon" list, but has a small amend by me
(namely, chmod of final pack is done only when we are writing the final
pack, i.e. reading from stdin) to fix breakages observed in tests. It
would be nice to get a final Ack before moving it to 'master'.
-- >8 --
From: Petr Baudis <pasky@suse.cz>
Win32 does not allow renaming read-only files (at least on a Samba
share), making push into a local directory to fail. Thus, defer
the chmod() call in index-pack.c:final() only after
move_temp_to_file() was called.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
index-pack.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index d3a4d31..aec11cb 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -790,7 +790,6 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
err = close(output_fd);
if (err)
die("error while closing pack file: %s", strerror(errno));
- chmod(curr_pack_name, 0444);
}
if (keep_msg) {
@@ -824,8 +823,9 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
if (move_temp_to_file(curr_pack_name, final_pack_name))
die("cannot store pack file");
}
+ if (from_stdin)
+ chmod(final_pack_name, 0444);
- chmod(curr_index_name, 0444);
if (final_index_name != curr_index_name) {
if (!final_index_name) {
snprintf(name, sizeof(name), "%s/pack/pack-%s.idx",
@@ -835,6 +835,7 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
if (move_temp_to_file(curr_index_name, final_index_name))
die("cannot store index file");
}
+ chmod(final_index_name, 0444);
if (!from_stdin) {
printf("%s\n", sha1_to_hex(sha1));
--
1.6.0.2.767.g8f0e
^ permalink raw reply related
* [PATCH/RFR&A] Fix reading of cloud tags
From: Junio C Hamano @ 2008-10-19 7:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
This is in 'next' but it would be nice to get acked before advancing it to
master.
-- >8 --
The projectroot path could have SP in it, in which case iterating over
<$git_dir/ctags/*> does not correctly enumerate the cloud tags files at
all.
This can be observed by creating an empty t/trash directory and running
t9500 test. The $projectroot ends with "trash directory.t9500-gitweb-/"
and <$glob> would give "trash", which can be opened and reading from it
immediately yields undef, which in turn gives an undef value warning to
the standard error stream upon attempt to chomp it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
gitweb/gitweb.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1116800..41b6866 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1805,7 +1805,10 @@ sub git_get_project_ctags {
my $ctags = {};
$git_dir = "$projectroot/$path";
- foreach (<$git_dir/ctags/*>) {
+ unless (opendir D, "$git_dir/ctags") {
+ return $ctags;
+ }
+ foreach (grep { -f $_ } map { "$git_dir/ctags/$_" } readdir(D)) {
open CT, $_ or next;
my $val = <CT>;
chomp $val;
@@ -1813,6 +1816,7 @@ sub git_get_project_ctags {
my $ctag = $_; $ctag =~ s#.*/##;
$ctags->{$ctag} = $val;
}
+ closedir D;
$ctags;
}
--
1.6.0.2.767.g8f0e
^ permalink raw reply related
* [PATCH/RFR&A] gitweb: Better processing format string in custom links in navbar
From: Junio C Hamano @ 2008-10-19 7:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
I was not around when this was posted and discussed; Shawn's note says
this is waiting for "some sort of response from Pasky", hence this request
for review and ack. It still is parked in 'pu'.
-- >8 --
Make processing format string in custom links in action bar ('actions'
feature) more robust. Now there would be no problems if one of
expanded values (for example project name, of project filename)
contains '%'; additionally format string supports '%' escaping by
doubling, i.e. '%%' expands to '%'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
gitweb/gitweb.perl | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1116800..cc6edbe 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -290,10 +290,10 @@ our %feature = (
# The 'default' value consists of a list of triplets in the form
# (label, link, position) where position is the label after which
- # to inster the link and link is a format string where %n expands
+ # to insert the link and link is a format string where %n expands
# to the project name, %f to the project path within the filesystem,
# %h to the current hash (h gitweb parameter) and %b to the current
- # hash base (hb gitweb parameter).
+ # hash base (hb gitweb parameter); %% expands to %.
# To enable system wide have in $GITWEB_CONFIG e.g.
# $feature{'actions'}{'default'} = [('graphiclog',
@@ -2866,14 +2866,19 @@ sub git_print_page_nav {
$arg{'tree'}{'hash_base'} = $treebase if defined $treebase;
my @actions = gitweb_check_feature('actions');
+ my %repl = (
+ '%' => '%',
+ 'n' => $project, # project name
+ 'f' => $git_dir, # project path within filesystem
+ 'h' => $treehead || '', # current hash ('h' parameter)
+ 'b' => $treebase || '', # hash base ('hb' parameter)
+ );
while (@actions) {
- my ($label, $link, $pos) = (shift(@actions), shift(@actions), shift(@actions));
+ my ($label, $link, $pos) = splice(@actions,0,3);
+ # insert
@navs = map { $_ eq $pos ? ($_, $label) : $_ } @navs;
# munch munch
- $link =~ s#%n#$project#g;
- $link =~ s#%f#$git_dir#g;
- $treehead ? $link =~ s#%h#$treehead#g : $link =~ s#%h##g;
- $treebase ? $link =~ s#%b#$treebase#g : $link =~ s#%b##g;
+ $link =~ s/%([%nfhb])/$repl{$1}/g;
$arg{$label}{'_href'} = $link;
}
--
1.6.0.2.767.g8f0e
^ permalink raw reply related
* Re: StGIT 0.14.3: extra space is added before e-mail on export after "stg edit"
From: Andrey Borzenkov @ 2008-10-19 8:09 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0810180148k4ba5bb2bgf3c5cdb2358b9419@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
On Saturday 18 October 2008, Catalin Marinas wrote:
> 2008/10/15 Andrey Borzenkov <arvidjaar@mail.ru>:
> > Funny problem. I have following export template:
> >
> > Subject: [PATCH] %(shortdescr)s
> > From: %(authname)s %(authemail)s
> >
> > %(longdescr)s
> > Signed-off-by: %(authname)s %(authemail)s
>
> The default templates contain "%(authname)s <%(authemail)s>", i.e.
> with the angle brackets arount authemail and I've never seen this
> problem. Does it work if you change them (or use the default
> templates)?
>
Well, my GIT_AUTHOR_EMAIL was with angle brackets. I do not remember, why
(apparently I had some issues in the past). I stripped brackets and changed
template, now it seems to work. I was never sure what exactly e-mail should
like like.
Thank you!
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCHv6 3/5] gitweb: use_pathinfo filenames start with /
From: Jakub Narebski @ 2008-10-19 8:43 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <cb7bb73a0810181657i67d6b9f8o66db9f57bcf01dd3@mail.gmail.com>
On Sun, 19 Oct 2008, Giuseppe Bilotta wrote:
> On Sun, Oct 19, 2008 at 1:26 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
>>
>>> When using path info, make filenames start with a / (right after the :
>>> that separates them from the hash base). This minimal change allows
>>> relative navigation to work properly when viewing HTML files in raw
>>> ('blob_plain') mode.
[...]
>> For example for http://repo.or.cz/w/git.git/html:/git.html links leads
>> to correct HTML pages, while for http://repo.or.cz/w/git.git/html:git.html
>> they lead to empty gitweb page (no errors, so link checker would be
>> fooled).
>
> An idea that could be taken into consideration, if the ability to
> navigate web documents is deemed of primary importance, would be a
> redirect from the no-slash URL (a hand-coded one, given that with this
> patch we only generate slashed URLs) to the slashed URL. Not sure it's
> worth the effort (and reparsing) though: it would obviously be MUCH
> nicer if we could change the URL without having to actually reload the
> document ...
I think that changing URL without reloading is impossible because of
security reasons. For example if you change document.location in
JavaScript changing the URL (you can add links to non-existing anchors
without reloading) then web browser reloads the page from new URL.
What you can do is early redirect using 301 Moved Permanently (or
similar) and Location: redirect, using $cgi->redirect() like in
git_object().
Also not sure if it is worth the effort...
--
Jakub Narebski
Poland
^ permalink raw reply
* need help stripping a repo to one file
From: Caleb Cushing @ 2008-10-19 10:27 UTC (permalink / raw)
To: git
here's what I've done so far (note: this is a public repo if anyone
wants to take a look)
git clone git@github.com:xenoterracide/dot_usr.git sql_iabbr
cd sql_iabbr/
git checkout db3c5ffb180f10dde8e539a81a6644760e098dcd
git branch -D master
git checkout -b master
git filter-branch --subdirectory-filter vim/ftplugin/ -- --all
that leaves me with this
html sgml sh tex vim xhtml xml sql_iabbr.vim xml.vim
all I want left is sql_iabbr.vim and it's history
I've used stuff like
git filter-branch --tree-filter 'rm -rf xml.vim' HEAD
to remove the files... but I notice that leaves the logs.
I'm thinking I could do that and then remove those commits but I
haven't figured out how to remove the commits, and even then I'm not
sure the repo would be in the state I want.
can anyone help me get to where I want to be? also is there an easier
way to do what I've done so far?
--
Caleb Cushing
^ permalink raw reply
* Re: [PATCH] Documentation: diff-filter=T only tests for symlink changes
From: Anders Melchiorsen @ 2008-10-19 10:29 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20081019100454.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> I see that you pushed out this change already, and you changed your
> mind and described them all. I think the result reads better.
While we are fixing up that paragraph, this part could also use some
elaboration:
Unknown (`X`), or have had their pairing Broken (`B`).
I would do it, but I have no idea what these two mean.
Regards,
Anders
^ permalink raw reply
* Re: [PATCH] feature request: git-mergetool --force
From: Jeff King @ 2008-10-19 11:47 UTC (permalink / raw)
To: Charles Bailey; +Cc: William Pursell, git
In-Reply-To: <48FA6E55.9030101@hashpling.org>
On Sun, Oct 19, 2008 at 12:16:37AM +0100, Charles Bailey wrote:
> I've recently been using git mergetool quite a bit and I'm currently
> cooking a couple of patches. The first, by coincidence, was a "-n"
> option which disabled the hit-return-to-actually-do-anything prompt. I,
> also, used the variable "NOPROMPT" to describe this behaviour.
>
> The other change that I am working was more of an issue for me. When I
> have a fair number of files to merge I sometimes want to skip a merge.
> Perhaps it's a tricky one and I want do the easy wins first.
> [...]
> Thoughts?
I think those are both reasonable behaviors. I also thought instantly of
the issue you mentioned, that people who really did want to abort would
get stuck in a loop of spawning the merge resolver. For that reason, I
think it makes sense to have both of them as options (either config,
command-line, or both). And if you do "git mergetool --no-prompt
--keep-going", then you are accepting the fact that you won't have a
chance to ask it to stop.
And I would suggest "-k, --keep-going" for the second option, as it
reminds me of the similar "make" option.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2008, #04; Sat, 18)
From: Jeff King @ 2008-10-19 12:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqrpabep.fsf@gitster.siamese.dyndns.org>
On Sat, Oct 18, 2008 at 01:36:14PM -0700, Junio C Hamano wrote:
> ----------------------------------------------------------------
> [Actively Cooking]
[...]
> * jk/diff-convfilter (Sun Oct 5 17:43:45 2008 -0400) 4 commits
> + diff: add filter for converting binary to text
> + diff: introduce diff.<driver>.binary
> + diff: unify external diff and funcname parsing code
> + t4012: use test_cmp instead of cmp
>
> A general cleanup on how diff drivers are implemented. Its still
> missing documentation updates and tests but doesn't break anything
> current as far as I can tell.
Hmm, I was planning on re-rolling this before it hit next to deal with
the issues brought up about the binary option, but I guess it is too
late now (yes, I was being slow about it...). I think I can salvage it
with some patches on top, though.
-Peff
^ permalink raw reply
* [PATCH 6/6] gitweb: retrieve snapshot format from PATH_INFO
From: Giuseppe Bilotta @ 2008-10-19 12:11 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224188831-17767-6-git-send-email-giuseppe.bilotta@gmail.com>
We parse requests for $project/snapshot/$head.$sfx as equivalent to
$project/snapshot/$head?sf=$sfx, where $sfx is any of the known
(although not necessarily supported) snapshot formats (or its default
suffix).
The filename for the resulting package preserves the requested
extensions (so asking for a .tgz gives a .tgz, and asking for a .tar.gz
gives a .tar.gz), although for obvious reasons it doesn't preserve the
basename (git/snapshot/next.tgz returns a file names git-next.tgz).
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Ok, I lied, there's a 6th patch ready. Its purpose is to allow embedding of
the snapshot format parameter in the URL, in the form of an extension
appended to the refname.
I have not prepared the corresponding URL generation code yet, because of
potential ambiguity that might arise: even though at URL generation time
the project does not have a head named $head.$sfx, it is possible (although
extremely unlikely) that such head is created later on, and the PATH_INFO
generation code cannot therefore guarantee the permalink nature of the
embedded snapshot format URL.
gitweb/gitweb.perl | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 99c8c20..7ffd10b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -609,6 +609,41 @@ sub evaluate_path_info {
$input_params{'hash_parent'} ||= $parentrefname;
}
}
+
+ # for the snapshot action, we allow URLs in the form
+ # $project/snapshot/$hash.ext
+ # where .ext determines the snapshot and gets removed from the
+ # passed $refname to provide the $hash.
+ #
+ # To be able to tell that $refname includes the format extension, we
+ # require some conditions to be satisfied:
+ # - the hash input parameter MUST have been set from the $refname part
+ # of the URL (i.e. they must be equal)
+ # - the snapshot format MUST NOT have been defined already
+ # - the $refname itself MUST NOT be a valid refname
+ if ($input_params{'action'} eq 'snapshot' && defined $refname &&
+ $refname eq $input_params{'hash'} &&
+ !defined $input_params{'snapshot_format'} &&
+ !parse_commit($refname)) {
+ # We loop over the known snapshot formats, checking for
+ # extensions. Allowed extensions are both the defined suffix
+ # (which includes the initial dot already) and the snapshot
+ # format key itself, with a prepended dot
+ while (my ($fmt, %opt) = each %known_snapshot_formats) {
+ my $hash = $refname;
+ my $sfx;
+ $hash =~ s/(\Q$opt{'suffix'}\E|\Q.$fmt\E)$//;
+ next unless $sfx = $1;
+ # a valid suffix was found, so set the snapshot format
+ # and reset the hash parameter
+ $input_params{'snapshot_format'} = $fmt;
+ $input_params{'hash'} = $hash;
+ # we also set the format suffix to the one requested
+ # in the URL: this way a request for e.g. .tgz returns
+ # a .tgz instead of a .tar.gz
+ $known_snapshot_formats{$fmt}{'suffix'} = $sfx;
+ }
+ }
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH v2] Fix testcase failure when extended attributes are in use
From: Deskin Miller @ 2008-10-19 12:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, heikki.orsila
In-Reply-To: <7vbpxig4fb.fsf@gitster.siamese.dyndns.org>
On Fri, Oct 17, 2008 at 04:58:16PM -0700, Junio C Hamano wrote:
> With 8ed0a74 (t1301-shared-repo.sh: don't let a default ACL interfere with
> the test, 2008-10-16) applied is this still needed, or can I drop it from
> my review box?
Apologies for a tardy response, was out of town and away from keyboard for a
day.
This patch is still needed, as my and Matt's patch are solving two different
issues with t1301. As he pointed out in the thread regarding his patch, the
issue was that the testcase was intended to specifically test Git's interaction
with permissions set via the umask, but a default ACL on the 'trash directory'
could interfere with this, since they'd override the umask settings. Remove
the ACL, no problem.
My patch, on the other hand, is to deal with 'ls' output in case a file has
certain filesystem extended attributes. These could be e.g. POSIX ACLs, or a
SELinux security context, or perhaps others. If such an extended attribute is
present, 'ls -l' will print permissions with a '+' appended, e.g.
-rw-r--r--+
Instead of
-rw-r--r--
However, t1301 reads permissions output by ls for several tests, and compares
them to string representations such as that above. Without removing the '+',
if present, the strings will not match. Furthermore, since this occurs for
other filesystem extended attributes, and not just ACLs, it is not possible to
simply strip all extended attributes from the file in question (with SELinux,
the kernel won't let you remove a file's security context anyway).
For what it's worth, I've experienced this failure on my Ubuntu 8.04 laptop
with SELinux permissive mode, so it's possible ls behaves slightly differently
on other systems; I've not been able to determine this one way or another.
However, I see no harm in accounting for this situation in the general case,
since the typical output of ls on other systems will not be affected nor
modified with this patch.
Hope that helps,
Deskin Miller
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Jeff King @ 2008-10-19 13:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matt Draisey, git
In-Reply-To: <7vfxmuhlad.fsf@gitster.siamese.dyndns.org>
On Fri, Oct 17, 2008 at 04:08:42PM -0700, Junio C Hamano wrote:
> I do not think that is a correct approach.
>
> The offending callchain is:
>
> update_ref(..., "HEAD", REF_NODEREF, ...);
> -> lock_any_ref_for_update("HEAD", ..., REF_NODEREF);
> -> lock_ref_sha1_basic("HEAD", ..., REF_NODEREF, ...);
> . calls resolve_ref() to read HEAD to arrive at
> refs/heads/master
> . however, it notices REF_NODEREF and adjusts the ref to be updated
> back to "HEAD";
> -> hold_lock_file_for_update(..., "HEAD", 1);
> -> lock_file(..., "HEAD");
> . resolves symlink "HEAD" to "refs/heads/master", and
> locks it! This creates "refs/heads/master.lock", that is
> then renamed to "refs/heads/master" when unlocked.
>
> In other words, the breakage is in lock_file() and not in resolve_ref().
> The latter gives the same output to the caller whether the HEAD is
> symbolic link or textual symref -- at least it should.
To be fair, my patch fixed the problem in lock_ref_sha1_basic, not
resolve_ref. It merely asked resolve_ref to annotate the resolution to
show whether a symlink was found, since it already had that information.
But if I am reading your patch right, you are actually enabling detached
HEAD in this instance, which is much better. Unfortunately, I had quite
a few conflicts in applying your patches on top of master (with or
without the patch from "checkout --track -b broken"), and when I thought
I had fixed up the result, the test actually still failed.
So I will take your word that it actually works, and that I screwed up
resolving the conflicts.
-Peff
PS If you are rebasing or resolving anyway, as I suspect you will have
to, there is a typo in the test: s/detch/detach/
^ permalink raw reply
* Re: [PATCH] -C/--chdir command line option
From: Jeff King @ 2008-10-19 13:17 UTC (permalink / raw)
To: Maciej Pasternacki; +Cc: git
In-Reply-To: <20081019000227.GA9423@charybdis.dreamhost.com>
On Sat, Oct 18, 2008 at 05:02:27PM -0700, Maciej Pasternacki wrote:
> In my project cl-librarian, which is a layer built upon different
> version control systems, I need to run git pull, but start it from
> outside of work tree; however, pull needs to be in work tree (as in
> getcwd()) in order to update said work tree. --git-dir and
> --work-tree options don't work; I discussed it on #git yesterday,
> and it turned out that this issue is nontrivial:
> [...]
> the best workaround that occured to me was adding -C/--chdir option to
> main git binary, like one that Make accepts. This fixed my problem, I
> paste the resulting patch below:
I'm not completely opposed to -C, as it does match some other tools,
but it does seem superfluous with --git-dir and --work-tree. Which makes
me feel like we are just papering over a bug instead of actually fixing
it (and to be honest, I always wondered what the point of "make -C" was
in the face of "cd dir && make").
I'm not sure if the actual problem is related to the oft-discussed,
unresolved work-tree startup woes, or is something much simpler to fix.
I'll try to look closer later today.
A few comments on your patch:
> From 4461cd1be99772c93a83bcdfe6e6a86e71abaa35 Mon Sep 17 00:00:00 2001
> From: Maciej Pasternacki <maciej@pasternacki.net>
> Date: Sun, 19 Oct 2008 01:33:49 +0200
> Subject: [PATCH] Add command line option --chdir/-C to allow setting git process work directory.
>
> Signed-off-by: Maciej Pasternacki <maciej@pasternacki.net>
Please follow the usual list conventions; this stuff should be the
actual headers of your mail, not in the body of the message. And some of
the justification you gave above should be part of the commit message.
> + } else if (!strcmp(cmd, "-C") || !strcmp(cmd, "--chdir")) {
> + chdir((*argv)[1]);
No error detection and reporting? I think I would be quite happy for
"git -C /some/path clean -dx" to bail out when it saw that it couldn't
change directory instead of just deleting the contents of wherever I
happened to be.
Also, the envchanged flag should probably be set, as for the git-dir and
work-tree options.
-Peff
^ permalink raw reply
* [JGIT PATCH] Encode/decode index and tree entries using UTF-8
From: Robin Rosenberg @ 2008-10-19 13:29 UTC (permalink / raw)
To: spearce; +Cc: git
Decoding uses the same strategy as for commit messages and other string
entities. Encoding is always done in UTF-8. This is incompatible with
Git for non-unicode unices, but it leads to the expected behavior on
Windows and cross-locale sharing of repositories.
Signed-off-by: Robin Rosenberg <robin.rosnberg@dewire.com>
---
Inpired by the recent thread on the gitml, I decideed to clean up jgit a little. I
know the GitIndex is soon to be obsoleted, but it it still the class that does
the dirty work when committing in Egit and the changes are fairly simple
anyway.
- Unicode paths will work on all platforms that support unicode, i.e. Windows
and any unix using a UTF-8 locale, with one small exception. Accented characters
on OS-X probably do not work well.
- Combined use of unicode on one platform is compatible with non-unicode locales
on other platforms as long as the characters in use are available in the local character
set.
A side note, invalid byte sequences in unix, e.g. ISO-latin-1 encoded file names cannot
work in Java. Such files are inaccessible. Jgit will allow you to rename them in the index,
but that is all.
-- robin
.../src/org/spearce/jgit/lib/GitIndex.java | 27 +++++++++++---------
.../src/org/spearce/jgit/lib/Tree.java | 11 +++----
.../src/org/spearce/jgit/lib/TreeEntry.java | 13 +++------
3 files changed, 25 insertions(+), 26 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java b/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
index 22935ab..3d37033 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
@@ -63,6 +63,7 @@
import org.spearce.jgit.errors.CorruptObjectException;
import org.spearce.jgit.errors.NotSupportedException;
import org.spearce.jgit.util.FS;
+import org.spearce.jgit.util.RawParseUtils;
/**
* A representation of the Git index.
@@ -178,8 +179,9 @@ public Entry add(File wd, File f) throws IOException {
* @param f
* the file whose path shall be removed.
* @return true if such a path was found (and thus removed)
+ * @throws IOException
*/
- public boolean remove(File wd, File f) {
+ public boolean remove(File wd, File f) throws IOException {
byte[] key = makeKey(wd, f);
return entries.remove(key) != null;
}
@@ -300,11 +302,11 @@ static boolean File_hasExecute() {
return FS.INSTANCE.supportsExecute();
}
- static byte[] makeKey(File wd, File f) {
+ static byte[] makeKey(File wd, File f) throws IOException {
if (!f.getPath().startsWith(wd.getPath()))
throw new Error("Path is not in working dir");
String relName = Repository.stripWorkDir(wd, f);
- return relName.getBytes();
+ return relName.getBytes(Constants.CHARACTER_ENCODING);
}
Boolean filemode;
@@ -376,7 +378,7 @@ Entry(TreeEntry f, int stage)
size = -1;
}
sha1 = f.getId();
- name = f.getFullName().getBytes("UTF-8");
+ name = f.getFullName().getBytes(Constants.CHARACTER_ENCODING);
flags = (short) ((stage << 12) | name.length); // TODO: fix flags
}
@@ -580,7 +582,7 @@ private File getFile(File wd) {
}
public String toString() {
- return new String(name) + "/SHA-1(" + sha1.name() + ")/M:"
+ return getName() + "/SHA-1(" + sha1.name() + ")/M:"
+ new Date(ctime / 1000000L) + "/C:"
+ new Date(mtime / 1000000L) + "/d" + dev + "/i" + ino
+ "/m" + Integer.toString(mode, 8) + "/u" + uid + "/g"
@@ -591,7 +593,7 @@ public String toString() {
* @return path name for this entry
*/
public String getName() {
- return new String(name);
+ return RawParseUtils.decode(Constants.CHARSET, name, 0, name.length);
}
/**
@@ -731,7 +733,7 @@ void readTree(String prefix, Tree t) throws IOException {
readTree(name, (Tree) te);
} else {
Entry e = new Entry(te, 0);
- entries.put(name.getBytes("UTF-8"), e);
+ entries.put(name.getBytes(Constants.CHARACTER_ENCODING), e);
}
}
}
@@ -743,7 +745,7 @@ void readTree(String prefix, Tree t) throws IOException {
* @throws IOException
*/
public Entry addEntry(TreeEntry te) throws IOException {
- byte[] key = te.getFullName().getBytes("UTF-8");
+ byte[] key = te.getFullName().getBytes(Constants.CHARACTER_ENCODING);
Entry e = new Entry(te, 0);
entries.put(key, e);
return e;
@@ -825,7 +827,7 @@ public ObjectId writeTree() throws IOException {
while (trees.size() < newName.length) {
if (!current.existsTree(newName[trees.size() - 1])) {
current = new Tree(current, newName[trees.size() - 1]
- .getBytes());
+ .getBytes(Constants.CHARACTER_ENCODING));
current.getParent().addEntry(current);
trees.push(current);
} else {
@@ -835,7 +837,7 @@ public ObjectId writeTree() throws IOException {
}
}
FileTreeEntry ne = new FileTreeEntry(current, e.sha1,
- newName[newName.length - 1].getBytes(),
+ newName[newName.length - 1].getBytes(Constants.CHARACTER_ENCODING),
(e.mode & FileMode.EXECUTABLE_FILE.getBits()) == FileMode.EXECUTABLE_FILE.getBits());
current.addEntry(ne);
}
@@ -880,7 +882,7 @@ int longestCommonPath(String[] a, String[] b) {
* Small beware: Unaccounted for are unmerged entries. You may want
* to abort if members with stage != 0 are found if you are doing
* any updating operations. All stages will be found after one another
- * here later. Currently only one stage per name is returned.
+ * here later. Currently only one stage per name is returned.
*
* @return The index entries sorted
*/
@@ -896,7 +898,8 @@ int longestCommonPath(String[] a, String[] b) {
* @throws UnsupportedEncodingException
*/
public Entry getEntry(String path) throws UnsupportedEncodingException {
- return (Entry) entries.get(Repository.gitInternalSlash(path.getBytes("ISO-8859-1")));
+ return (Entry) entries.get(Repository.gitInternalSlash(path
+ .getBytes(Constants.CHARACTER_ENCODING)));
}
/**
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Tree.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Tree.java
index 25a9a71..3fd3d30 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Tree.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Tree.java
@@ -44,6 +44,7 @@
import org.spearce.jgit.errors.CorruptObjectException;
import org.spearce.jgit.errors.EntryExistsException;
import org.spearce.jgit.errors.MissingObjectException;
+import org.spearce.jgit.util.RawParseUtils;
/**
* A representation of a Git tree entry. A Tree is a directory in Git.
@@ -281,8 +282,7 @@ public FileTreeEntry addFile(final byte[] s, final int offset)
final byte[] newName = substring(s, offset, slash);
if (p >= 0)
- throw new EntryExistsException(new String(newName,
- Constants.CHARACTER_ENCODING));
+ throw new EntryExistsException(RawParseUtils.decode(Constants.CHARSET, newName, 0, newName.length));
else if (slash < s.length) {
final Tree t = new Tree(this, newName);
insertEntry(p, t);
@@ -332,8 +332,8 @@ public Tree addTree(final byte[] s, final int offset) throws IOException {
final byte[] newName = substring(s, offset, slash);
if (p >= 0)
- throw new EntryExistsException(new String(newName,
- Constants.CHARACTER_ENCODING));
+ throw new EntryExistsException(RawParseUtils.decode(
+ Constants.CHARSET, newName, 0, newName.length));
final Tree t = new Tree(this, newName);
insertEntry(p, t);
@@ -355,8 +355,7 @@ public void addEntry(final TreeEntry e) throws IOException {
e.attachParent(this);
insertEntry(p, e);
} else {
- throw new EntryExistsException(new String(e.getNameUTF8(),
- Constants.CHARACTER_ENCODING));
+ throw new EntryExistsException(e.getName());
}
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/TreeEntry.java b/org.spearce.jgit/src/org/spearce/jgit/lib/TreeEntry.java
index 85dda1d..7f58056 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/TreeEntry.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/TreeEntry.java
@@ -39,9 +39,9 @@
package org.spearce.jgit.lib;
import java.io.IOException;
-import java.io.UnsupportedEncodingException;
import org.spearce.jgit.lib.GitIndex.Entry;
+import org.spearce.jgit.util.RawParseUtils;
/**
* This class represents an entry in a tree, like a blob or another tree.
@@ -126,13 +126,10 @@ public Repository getRepository() {
* @return the name of this entry.
*/
public String getName() {
- try {
- return nameUTF8 != null ? new String(nameUTF8,
- Constants.CHARACTER_ENCODING) : null;
- } catch (UnsupportedEncodingException uee) {
- throw new RuntimeException("JVM doesn't support "
- + Constants.CHARACTER_ENCODING, uee);
- }
+ if (nameUTF8 != null)
+ return RawParseUtils.decode(Constants.CHARSET, nameUTF8, 0,
+ nameUTF8.length);
+ return null;
}
/**
--
1.6.0.2.308.gef4a
^ permalink raw reply related
* Re: [PATCH] -C/--chdir command line option
From: Maciej Pasternacki @ 2008-10-19 13:47 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20081019131745.GA8643@coredump.intra.peff.net>
On 2008-10-19, at 15:17, Jeff King wrote:
> On Sat, Oct 18, 2008 at 05:02:27PM -0700, Maciej Pasternacki wrote:
>
>> In my project cl-librarian, which is a layer built upon different
>> version control systems, I need to run git pull, but start it from
>> outside of work tree; however, pull needs to be in work tree (as in
>> getcwd()) in order to update said work tree. --git-dir and
>> --work-tree options don't work; I discussed it on #git yesterday,
>> and it turned out that this issue is nontrivial:
>> [...]
>> the best workaround that occured to me was adding -C/--chdir option
>> to
>> main git binary, like one that Make accepts. This fixed my
>> problem, I
>> paste the resulting patch below:
>
> I'm not completely opposed to -C, as it does match some other tools,
> but it does seem superfluous with --git-dir and --work-tree. Which
> makes
> me feel like we are just papering over a bug instead of actually
> fixing
> it (and to be honest, I always wondered what the point of "make -C"
> was
> in the face of "cd dir && make").
The point of make -C is exactly my usage pattern: invoking make from
external program. I have seen, at least in Lisp (external-program)
and Python (os.spawn, subprocess), libraries to safely and portably
execute external program by giving literal list of arguments (an easy
to use wrapper to fork()+exec(); I don't know if such feature exists
for C). This allows me not to worry about quoting strange characters
in pathnames (think injections, if just making it possible to use "&"
character in directory name is not good enough a reason). The
equivalent of "cd dir && make" would be to use system() or invoke sh -
c; both would require shell-quoting the directory pathname, and would
carry portability issues -- how do I know that shell on target system
is actually called "sh" and it supports "&&"? At least Windows
systems would be problematic.
The -C option allows me to just specify the directory as it is, and
child process, after the fork, will take care of the chdir(). No
quoting, no portability problems, injection-safety included.
As for -C being superfluous: --git-dir and --work-tree seem to support
weird usage patterns (like work tree separate from git-dir), but it
seems to me that --work-tree could be just made a synonym of -C, and
it would behave as expected without creating chicken-and-egg problem
that doener on #git found (which I don't really understand, but I also
can't see what --work-tree allows that -C would not -- except creating
more fragility). I won't push on --work-tree and -C being
functionally synonymous, since I don't know git well enough, it's just
my impression at the moment.
> Please follow the usual list conventions; this stuff should be the
> actual headers of your mail, not in the body of the message. And
> some of
> the justification you gave above should be part of the commit message.
ACK. That was how I understood instructions linked from git.or.cz,
I'll paste message correctly for next version of the patch.
>> + } else if (!strcmp(cmd, "-C") || !strcmp(cmd, "--chdir")) {
>> + chdir((*argv)[1]);
>
> No error detection and reporting? I think I would be quite happy for
> "git -C /some/path clean -dx" to bail out when it saw that it couldn't
> change directory instead of just deleting the contents of wherever I
> happened to be.
Oops. Looks like I'm spoiled by high-level languages that would
automatically catch and display an error. I'll prepare patch v2 today.
> Also, the envchanged flag should probably be set, as for the git-dir
> and
> work-tree options.
OK. I thought it means literally environment change, as in setenv().
Thank you for your comments, off to make v2 patch,
Maciej.
--
-><- Maciej Pasternacki -><- http://www.pasternacki.net/ -><-
^ permalink raw reply
* Re: [msysGit] Re: Weird filename encoding issue
From: Alexander Gladysh @ 2008-10-19 14:11 UTC (permalink / raw)
To: johannes.sixt; +Cc: msysGit, git
In-Reply-To: <200810181951.53962.johannes.sixt@telecom.at>
On Sat, Oct 18, 2008 at 9:51 PM, Johannes Sixt <johannes.sixt@telecom.at> wrote:
> On Samstag, 18. Oktober 2008, Alexander Gladysh wrote:
>> 1. Git hooks do not work under msysgit.
>
> This is new to me. Why are you saying that? (IOW, please be more precise with
> your description. We can't help you if all you tell us is "Does not work" .)
Err. Sorry. I thought it is a known issue:
http://groups.google.com/group/msysgit/browse_thread/thread/956e555b8d515c66
I've got an impression that msysgit 1.5.6.1.1071.g76fb we use does not
contain this fix.
Of course, I may apply it by hand on each user's machine... Still have
to do it though.
Alexander.
^ permalink raw reply
* Re: [PATCH] -C/--chdir command line option
From: Jeff King @ 2008-10-19 14:16 UTC (permalink / raw)
To: Maciej Pasternacki; +Cc: git
In-Reply-To: <86685067-021C-4DC5-A462-AA6834208BDE@pasternacki.net>
On Sun, Oct 19, 2008 at 03:47:04PM +0200, Maciej Pasternacki wrote:
> As for -C being superfluous: --git-dir and --work-tree seem to support
> weird usage patterns (like work tree separate from git-dir), but it seems
Hmm. Yeah, thinking about it more, -C is not really superfluous with
respect to those options. You don't want to say "here is the work-tree,
and here is the git-dir". You want to say "find the work-tree and
git-dir for me using the usual rules, as if I were in this directory."
So you couldn't just say:
git --work-tree=/chdir/path
since that would assume your current directory was the git-dir. You
would need:
git --work-tree=/chdir/path --git-dir=/chdir/path/.git
but then you are overriding any usual lookup rules (e.g., somebody
having set GIT_DIR in the environment).
Though I am not clear from your original description if that is even
what you want. It sounds like you might be doing:
git -C /chdir/path --git-dir=/back/to/where/I/was
in which case I think work-tree _is_ a better fit.
> to me that --work-tree could be just made a synonym of -C, and it would
> behave as expected without creating chicken-and-egg problem that doener on
> #git found (which I don't really understand, but I also can't see what
> --work-tree allows that -C would not -- except creating more fragility).
--work-tree allows you say "I'm _already_ in the git-dir, but please use
this other place for the work-tree". So you can, for example, checkout
files from a bare repository.
>> Also, the envchanged flag should probably be set, as for the git-dir
>> and work-tree options.
>
> OK. I thought it means literally environment change, as in setenv().
It is really used to tell the options parser for aliases that some
options which change the operating environment should not be used in an
alias. I.e., something like:
git config alias.foo "--git-dir=/path/to/whatever log"
isn't allowed, because we have already done some work on setting up the
git-dir at this point. IMHO, this is a limitation of the current
approach to setting up the environment, but fixing it would be
nontrivial.
I'm not 100% sure that doing a chdir should be disallowed in this
instance, but I suspect it would cause problems. I think it is better in
this instance to be conservative and disallow it in aliases.
-Peff
^ permalink raw reply
* [PATHv2 6/8] gitweb: retrieve snapshot format from PATH_INFO
From: Giuseppe Bilotta @ 2008-10-19 14:24 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224188831-17767-6-git-send-email-giuseppe.bilotta@gmail.com>
We parse requests for $project/snapshot/$head.$sfx as equivalent to
$project/snapshot/$head?sf=$sfx, where $sfx is any of the known
(although not necessarily supported) snapshot formats (or its default
suffix).
The filename for the resulting package preserves the requested
extensions (so asking for a .tgz gives a .tgz, and asking for a .tar.gz
gives a .tar.gz), although for obvious reasons it doesn't preserve the
basename (git/snapshot/next.tgz returns a file names git-next.tgz).
This introduces a potential case for ambiguity if a project has a head
that ends with a snapshot-like suffix (.zip, .tgz, .tar.gz, etc) and the
sf CGI parameter is not present; however, gitweb only produces URLs with
the sf parameter, so this is only a potential issue for hand-coded URLs
for extremely unusual project.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
I had second thoughts on this. Now we always look for the snapshot extension if
the sf CGI parameter is missing, even if the project has a head that matches
the full pseudo-refname $head.$sfx.
The reason for this is that (1) there is no ambiguity for gitweb-generated
URLs (2) the only URLs that could fail are hand-made URLs for extremely
unusual projects and (3) it allows us to set gitweb up to generate
(unambiguous) URLs without the sf CGI parameter.
This also means that I can add 3 patches to the series, instead of just one:
* patch #6 that parses the new format
* patch #7 that generates the new URLs
* patch #8 for some code refactoring
gitweb/gitweb.perl | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 99c8c20..e9e9e60 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -609,6 +609,40 @@ sub evaluate_path_info {
$input_params{'hash_parent'} ||= $parentrefname;
}
}
+
+ # for the snapshot action, we allow URLs in the form
+ # $project/snapshot/$hash.ext
+ # where .ext determines the snapshot and gets removed from the
+ # passed $refname to provide the $hash.
+ #
+ # To be able to tell that $refname includes the format extension, we
+ # require the following two conditions to be satisfied:
+ # - the hash input parameter MUST have been set from the $refname part
+ # of the URL (i.e. they must be equal)
+ # - the snapshot format MUST NOT have been defined already
+ if ($input_params{'action'} eq 'snapshot' && defined $refname &&
+ $refname eq $input_params{'hash'} &&
+ !defined $input_params{'snapshot_format'}) {
+ # We loop over the known snapshot formats, checking for
+ # extensions. Allowed extensions are both the defined suffix
+ # (which includes the initial dot already) and the snapshot
+ # format key itself, with a prepended dot
+ while (my ($fmt, %opt) = each %known_snapshot_formats) {
+ my $hash = $refname;
+ my $sfx;
+ $hash =~ s/(\Q$opt{'suffix'}\E|\Q.$fmt\E)$//;
+ next unless $sfx = $1;
+ # a valid suffix was found, so set the snapshot format
+ # and reset the hash parameter
+ $input_params{'snapshot_format'} = $fmt;
+ $input_params{'hash'} = $hash;
+ # we also set the format suffix to the one requested
+ # in the URL: this way a request for e.g. .tgz returns
+ # a .tgz instead of a .tar.gz
+ $known_snapshot_formats{$fmt}{'suffix'} = $sfx;
+ last;
+ }
+ }
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATHv2 7/8] gitweb: embed snapshot format parameter in PATH_INFO
From: Giuseppe Bilotta @ 2008-10-19 14:24 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224426270-27755-1-git-send-email-giuseppe.bilotta@gmail.com>
When PATH_INFO is active, get rid of the sf CGI parameter by embedding
the snapshot format information in the PATH_INFO URL, in the form of an
appropriate extension.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e9e9e60..5fd5a1f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -795,6 +795,7 @@ sub href (%) {
# - action
# - hash_parent or hash_parent_base:/file_parent
# - hash or hash_base:/file_name
+ # - the snapshot_format as an appropriate suffix
# When the script is the root DirectoryIndex for the domain,
# $href here would be something like http://gitweb.example.com/
@@ -806,6 +807,10 @@ sub href (%) {
$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
delete $params{'project'};
+ # since we destructively absorb parameters, we keep this
+ # boolean that remembers if we're handling a snapshot
+ my $is_snapshot = $params{'action'} eq 'snapshot';
+
# Summary just uses the project path URL, any other action is
# added to the URL
if (defined $params{'action'}) {
@@ -845,6 +850,22 @@ sub href (%) {
$href .= esc_url($params{'hash'});
delete $params{'hash'};
}
+
+ # If the action was a snapshot, we can absorb the
+ # snapshot_format parameter too
+ if ($is_snapshot) {
+ my $fmt = $params{'snapshot_format'};
+ # snapshot_format should always be defined when href()
+ # is called, but just in case some code forgets, we
+ # fall back to the default
+ if (!$fmt) {
+ my @snapshot_fmts = gitweb_check_feature('snapshot');
+ @snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
+ $fmt = $snapshot_fmts[0];
+ }
+ $href .= $known_snapshot_formats{$fmt}{'suffix'};
+ delete $params{'snapshot_format'};
+ }
}
# now encode the parameters explicitly
--
1.5.6.5
^ permalink raw reply related
* [PATHv2 8/8] gitweb: make the supported snapshot formats array global
From: Giuseppe Bilotta @ 2008-10-19 14:24 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224426270-27755-2-git-send-email-giuseppe.bilotta@gmail.com>
The @snapshot_fmts array, containing the list of the supported snapshot
formats, was recreated locally in three different routines (with the
different name @supported_fmts in one of them).
Its local generation is particularly expensive because two of the
callers, href() and format_snapshot_links(), are often called many times
in a single page.
Simplify code and speed up page generation by making the array global.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 21 ++++++++-------------
1 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5fd5a1f..d1475b7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -748,6 +748,10 @@ if (defined $searchtext) {
our $git_dir;
$git_dir = "$projectroot/$project" if $project;
+# list of supported snapshot formats
+our @snapshot_fmts = gitweb_check_feature('snapshot');
+@snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
+
# dispatch
if (!defined $action) {
if (defined $hash) {
@@ -858,11 +862,7 @@ sub href (%) {
# snapshot_format should always be defined when href()
# is called, but just in case some code forgets, we
# fall back to the default
- if (!$fmt) {
- my @snapshot_fmts = gitweb_check_feature('snapshot');
- @snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
- $fmt = $snapshot_fmts[0];
- }
+ $fmt ||= $snapshot_fmts[0];
$href .= $known_snapshot_formats{$fmt}{'suffix'};
delete $params{'snapshot_format'};
}
@@ -1695,8 +1695,6 @@ sub format_diff_line {
# linked. Pass the hash of the tree/commit to snapshot.
sub format_snapshot_links {
my ($hash) = @_;
- my @snapshot_fmts = gitweb_check_feature('snapshot');
- @snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
my $num_fmts = @snapshot_fmts;
if ($num_fmts > 1) {
# A parenthesized list of links bearing format names.
@@ -4898,20 +4896,17 @@ sub git_tree {
}
sub git_snapshot {
- my @supported_fmts = gitweb_check_feature('snapshot');
- @supported_fmts = filter_snapshot_fmts(@supported_fmts);
-
my $format = $input_params{'snapshot_format'};
- if (!@supported_fmts) {
+ if (!@snapshot_fmts) {
die_error(403, "Snapshots not allowed");
}
# default to first supported snapshot format
- $format ||= $supported_fmts[0];
+ $format ||= $snapshot_fmts[0];
if ($format !~ m/^[a-z0-9]+$/) {
die_error(400, "Invalid snapshot format parameter");
} elsif (!exists($known_snapshot_formats{$format})) {
die_error(400, "Unknown snapshot format");
- } elsif (!grep($_ eq $format, @supported_fmts)) {
+ } elsif (!grep($_ eq $format, @snapshot_fmts)) {
die_error(403, "Unsupported snapshot format");
}
--
1.5.6.5
^ permalink raw reply related
* Re: What's cooking in git.git (Oct 2008, #04; Sat, 18)
From: Thomas Rast @ 2008-10-19 15:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqrpabep.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
Junio C Hamano wrote:
> * tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits
> + Documentation: Refer to git-rebase(1) to warn against rewriting
> + Documentation: new upstream rebase recovery section in git-rebase
>
> Expecting an update.
Note that the branch name is somewhat misleading; my fault for causing
confusion by grouping these two together with the gitworkflows.txt
RFCs. The two topics are independent.
And needless to say, I also managed to confuse myself. The above two
are already the final version. As far as I can tell, you've also made
two small corrections of your own; much appreciated.
I'll send an updated version of the gitworkflows.txt draft shortly,
which is what I meant in my last mail.
- Thomas
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [Interdiff] [RFC PATCH v3] Documentation: add manpage about workflows
From: Thomas Rast @ 2008-10-19 15:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, santi, Dmitry Potapov
In-Reply-To: <1224429622-1548-1-git-send-email-trast@student.ethz.ch>
---
Documentation/gitworkflows.txt | 72 ++++++++++++++++++++-------------------
1 files changed, 37 insertions(+), 35 deletions(-)
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 037ace5..7fe9f72 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -72,15 +72,15 @@ Graduation
As a given feature goes from experimental to stable, it also
"graduates" between the corresponding branches of the software.
-`git.git` uses the following 'main branches':
+`git.git` uses the following 'integration branches':
* 'maint' tracks the commits that should go into the next "maintenance
release", i.e., update of the last released stable version;
* 'master' tracks the commits that should go into the next release;
-* 'next' is intended as a testing branch for topics not stable enough
- for master yet.
+* 'next' is intended as a testing branch for topics being tested for
+ stability for master.
There is a fourth official branch that is used slightly differently:
@@ -107,7 +107,7 @@ the unstable branch into the stable one. Hence the following:
[caption="Rule: "]
=====================================
Always commit your fixes to the oldest supported branch that require
-them. Then (periodically) merge the main branches upwards into each
+them. Then (periodically) merge the integration branches upwards into each
other.
=====================================
@@ -124,28 +124,32 @@ Topic branches
Any nontrivial feature will require several patches to implement, and
may get extra bugfixes or improvements during its lifetime.
-Committing everything directly on the main branches leads to many
+Committing everything directly on the integration branches leads to many
problems: Bad commits cannot be undone, so they must be reverted one
by one, which creates confusing histories and further error potential
when you forget to revert part of a group of changes. Working in
parallel mixes up the changes, creating further confusion.
-The key concept here is "topic branches". The name is pretty self
-explanatory, with a caveat that comes from the "merge upwards" rule
-above:
+Use of "topic branches" solves these problems. The name is pretty
+self explanatory, with a caveat that comes from the "merge upwards"
+rule above:
.Topic branches
[caption="Rule: "]
=====================================
Make a side branch for every topic (feature, bugfix, ...). Fork it off
-at the oldest main branch that you will eventually want to merge it
+at the oldest integration branch that you will eventually want to merge it
into.
=====================================
Many things can then be done very naturally:
-* To get the feature/bugfix into a main branch, simply merge it. If
- the topic has evolved further in the meantime, merge again.
+* To get the feature/bugfix into an integration branch, simply merge
+ it. If the topic has evolved further in the meantime, merge again.
+ (Note that you do not necessarily have to merge it to the oldest
+ integration branch first. For example, you can first merge a bugfix
+ to 'next', give it some testing time, and merge to 'maint' when you
+ know it is stable.)
* If you find you need new features from the branch 'other' to continue
working on your topic, merge 'other' to 'topic'. (However, do not
@@ -154,35 +158,33 @@ Many things can then be done very naturally:
* If you find you forked off the wrong branch and want to move it
"back in time", use linkgit:git-rebase[1].
-Note that the last two points clash: a topic that has been merged
-elsewhere should not be rebased. See the section on RECOVERING FROM
-UPSTREAM REBASE in linkgit:git-rebase[1].
+Note that the last point clashes with the other two: a topic that has
+been merged elsewhere should not be rebased. See the section on
+RECOVERING FROM UPSTREAM REBASE in linkgit:git-rebase[1].
We should point out that "habitually" (regularly for no real reason)
-merging a main branch into your topics -- and by extension, merging
-anything upstream into anything downstream on a regular basis -- is
-frowned upon:
+merging an integration branch into your topics -- and by extension,
+merging anything upstream into anything downstream on a regular basis
+-- is frowned upon:
.Merge to downstream only at well-defined points
[caption="Rule: "]
=====================================
-Do not merge to downstream except:
-
-* with a good reason: upstream API changes affect your branch; your
- branch no longer merges to upstream cleanly; etc.
-
-* at well-defined points such as when an upstream release has been tagged.
+Do not merge to downstream except with a good reason: upstream API
+changes affect your branch; your branch no longer merges to upstream
+cleanly; etc.
=====================================
-Otherwise, the many resulting small merges will greatly clutter up
-history. Anyone who later investigates the history of a file will
-have to find out whether that merge affected the topic in development.
-An upstream might even inadvertently be merged into a "more stable"
-branch. And so on.
+Otherwise, the topic that was merged to suddenly contains more than a
+single (well-separated) change. The many resulting small merges will
+greatly clutter up history. Anyone who later investigates the history
+of a file will have to find out whether that merge affected the topic
+in development. An upstream might even inadvertently be merged into a
+"more stable" branch. And so on.
-Integration branches
-~~~~~~~~~~~~~~~~~~~~
+Throw-away integration
+~~~~~~~~~~~~~~~~~~~~~~
If you followed the last paragraph, you will now have many small topic
branches, and occasionally wonder how they interact. Perhaps the
@@ -193,7 +195,7 @@ cannot easily be undone.
The solution, of course, is to make a merge that we can undo: merge
into a throw-away branch.
-.Integration branches
+.Throw-away integration branches
[caption="Rule: "]
=====================================
To test the interaction of several topics, merge them into a
@@ -204,7 +206,7 @@ If you make it (very) clear that this branch is going to be deleted
right after the testing, you can even publish this branch, for example
to give the testers a chance to work with it, or other developers a
chance to see if their in-progress work will be compatible. `git.git`
-has such an official integration branch called 'pu'.
+has such an official throw-away integration branch called 'pu'.
DISTRIBUTED WORKFLOWS
@@ -259,7 +261,7 @@ You will still have to tell people by other means, such as mail. (Git
provides the linkgit:request-pull[1] to send preformatted pull
requests to upstream maintainers to simplify this task.)
-If you just want to get the newest copies of the main branches,
+If you just want to get the newest copies of the integration branches,
staying up to date is easy too:
.Push/pull: Staying up to date
@@ -272,8 +274,8 @@ Then simply fork your topic branches from the stable remotes as
explained earlier.
If you are a maintainer and would like to merge other people's topic
-branches to the main branches, they will typically send a request to
-do so by mail. Such a request looks like
+branches to the integration branches, they will typically send a
+request to do so by mail. Such a request looks like
-------------------------------------
Please pull from
--
1.6.0.2.916.g8e7f4
^ permalink raw reply related
* [RFC PATCH v3] Documentation: add manpage about workflows
From: Thomas Rast @ 2008-10-19 15:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, santi, Dmitry Potapov
In-Reply-To: <7v8wsyortf.fsf@gitster.siamese.dyndns.org>
This attempts to make a manpage about workflows that is both handy to
point people at it and as a beginner's introduction.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
> > +Integration branches
> > +~~~~~~~~~~~~~~~~~~~~
>
> Nomenclature. I think we use the word "integration branches" to mean the
> stable branches such as maint/master/next, not the ones you use for
> throw-away test merges.
I renamed those, and now call 'pu' a "throw-away integration branch",
which is sort of unwieldy but I can't think of a good short name.
Full interdiff follows, as before.
Documentation/Makefile | 2 +-
Documentation/gitworkflows.txt | 364 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 365 insertions(+), 1 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index ded0e40..e33ddcb 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -6,7 +6,7 @@ MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
gitrepository-layout.txt
MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
- gitdiffcore.txt
+ gitdiffcore.txt gitworkflows.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
new file mode 100644
index 0000000..7fe9f72
--- /dev/null
+++ b/Documentation/gitworkflows.txt
@@ -0,0 +1,364 @@
+gitworkflows(7)
+===============
+
+NAME
+----
+gitworkflows - An overview of recommended workflows with git
+
+SYNOPSIS
+--------
+git *
+
+
+DESCRIPTION
+-----------
+
+This document attempts to write down and motivate some of the workflow
+elements used for `git.git` itself. Many ideas apply in general,
+though the full workflow is rarely required for smaller projects with
+fewer people involved.
+
+We formulate a set of 'rules' for quick reference, while the prose
+tries to motivate each of them. Do not always take them literally;
+you should value good reasons for your actions higher than manpages
+such as this one.
+
+
+SEPARATE CHANGES
+----------------
+
+As a general rule, you should try to split your changes into small
+logical steps, and commit each of them. They should be consistent,
+working independently of any later commits, pass the test suite, etc.
+This makes the review process much easier, and the history much more
+useful for later inspection and analysis, for example with
+linkgit:git-blame[1] and linkgit:git-bisect[1].
+
+To achieve this, try to split your work into small steps from the very
+beginning. It is always easier to squash a few commits together than
+to split one big commit into several. Don't be afraid of making too
+small or imperfect steps along the way. You can always go back later
+and edit the commits with `git rebase \--interactive` before you
+publish them. You can use `git stash save \--keep-index` to run the
+test suite independent of other uncommitted changes; see the EXAMPLES
+section of linkgit:git-stash[1].
+
+
+MANAGING BRANCHES
+-----------------
+
+There are two main tools that can be used to include changes from one
+branch on another: linkgit:git-merge[1] and
+linkgit:git-cherry-pick[1].
+
+Merges have many advantages, so we try to solve as many problems as
+possible with merges alone. Cherry-picking is still occasionally
+useful; see "Merging upwards" below for an example.
+
+Most importantly, merging works at the branch level, while
+cherry-picking works at the commit level. This means that a merge can
+carry over the changes from 1, 10, or 1000 commits with equal ease,
+which in turn means the workflow scales much better to a large number
+of contributors (and contributions). Merges are also easier to
+understand because a merge commit is a "promise" that all changes from
+all its parents are now included.
+
+There is a tradeoff of course: merges require a more careful branch
+management. The following subsections discuss the important points.
+
+
+Graduation
+~~~~~~~~~~
+
+As a given feature goes from experimental to stable, it also
+"graduates" between the corresponding branches of the software.
+`git.git` uses the following 'integration branches':
+
+* 'maint' tracks the commits that should go into the next "maintenance
+ release", i.e., update of the last released stable version;
+
+* 'master' tracks the commits that should go into the next release;
+
+* 'next' is intended as a testing branch for topics being tested for
+ stability for master.
+
+There is a fourth official branch that is used slightly differently:
+
+* 'pu' (proposed updates) is an integration branch for things that are
+ not quite ready for inclusion yet (see "Integration Branches"
+ below).
+
+Each of the four branches is usually a direct descendant of the one
+above it.
+
+Conceptually, the feature enters at an unstable branch (usually 'next'
+or 'pu'), and "graduates" to 'master' for the next release once it is
+considered stable enough.
+
+
+Merging upwards
+~~~~~~~~~~~~~~~
+
+The "downwards graduation" discussed above cannot be done by actually
+merging downwards, however, since that would merge 'all' changes on
+the unstable branch into the stable one. Hence the following:
+
+.Merge upwards
+[caption="Rule: "]
+=====================================
+Always commit your fixes to the oldest supported branch that require
+them. Then (periodically) merge the integration branches upwards into each
+other.
+=====================================
+
+This gives a very controlled flow of fixes. If you notice that you
+have applied a fix to e.g. 'master' that is also required in 'maint',
+you will need to cherry-pick it (using linkgit:git-cherry-pick[1])
+downwards. This will happen a few times and is nothing to worry about
+unless you do it very frequently.
+
+
+Topic branches
+~~~~~~~~~~~~~~
+
+Any nontrivial feature will require several patches to implement, and
+may get extra bugfixes or improvements during its lifetime.
+
+Committing everything directly on the integration branches leads to many
+problems: Bad commits cannot be undone, so they must be reverted one
+by one, which creates confusing histories and further error potential
+when you forget to revert part of a group of changes. Working in
+parallel mixes up the changes, creating further confusion.
+
+Use of "topic branches" solves these problems. The name is pretty
+self explanatory, with a caveat that comes from the "merge upwards"
+rule above:
+
+.Topic branches
+[caption="Rule: "]
+=====================================
+Make a side branch for every topic (feature, bugfix, ...). Fork it off
+at the oldest integration branch that you will eventually want to merge it
+into.
+=====================================
+
+Many things can then be done very naturally:
+
+* To get the feature/bugfix into an integration branch, simply merge
+ it. If the topic has evolved further in the meantime, merge again.
+ (Note that you do not necessarily have to merge it to the oldest
+ integration branch first. For example, you can first merge a bugfix
+ to 'next', give it some testing time, and merge to 'maint' when you
+ know it is stable.)
+
+* If you find you need new features from the branch 'other' to continue
+ working on your topic, merge 'other' to 'topic'. (However, do not
+ do this "just habitually", see below.)
+
+* If you find you forked off the wrong branch and want to move it
+ "back in time", use linkgit:git-rebase[1].
+
+Note that the last point clashes with the other two: a topic that has
+been merged elsewhere should not be rebased. See the section on
+RECOVERING FROM UPSTREAM REBASE in linkgit:git-rebase[1].
+
+We should point out that "habitually" (regularly for no real reason)
+merging an integration branch into your topics -- and by extension,
+merging anything upstream into anything downstream on a regular basis
+-- is frowned upon:
+
+.Merge to downstream only at well-defined points
+[caption="Rule: "]
+=====================================
+Do not merge to downstream except with a good reason: upstream API
+changes affect your branch; your branch no longer merges to upstream
+cleanly; etc.
+=====================================
+
+Otherwise, the topic that was merged to suddenly contains more than a
+single (well-separated) change. The many resulting small merges will
+greatly clutter up history. Anyone who later investigates the history
+of a file will have to find out whether that merge affected the topic
+in development. An upstream might even inadvertently be merged into a
+"more stable" branch. And so on.
+
+
+Throw-away integration
+~~~~~~~~~~~~~~~~~~~~~~
+
+If you followed the last paragraph, you will now have many small topic
+branches, and occasionally wonder how they interact. Perhaps the
+result of merging them does not even work? But on the other hand, we
+want to avoid merging them anywhere "stable" because such merges
+cannot easily be undone.
+
+The solution, of course, is to make a merge that we can undo: merge
+into a throw-away branch.
+
+.Throw-away integration branches
+[caption="Rule: "]
+=====================================
+To test the interaction of several topics, merge them into a
+throw-away branch. You must never base any work on such a branch!
+=====================================
+
+If you make it (very) clear that this branch is going to be deleted
+right after the testing, you can even publish this branch, for example
+to give the testers a chance to work with it, or other developers a
+chance to see if their in-progress work will be compatible. `git.git`
+has such an official throw-away integration branch called 'pu'.
+
+
+DISTRIBUTED WORKFLOWS
+---------------------
+
+After the last section, you should know how to manage topics. In
+general, you will not be the only person working on the project, so
+you will have to share your work.
+
+Roughly speaking, there are two important workflows: merge and patch.
+The important difference is that the merge workflow can propagate full
+history, including merges, while patches cannot. Both workflows can
+be used in parallel: in `git.git`, only subsystem maintainers use
+the merge workflow, while everyone else sends patches.
+
+Note that the maintainer(s) may impose restrictions, such as
+"Signed-off-by" requirements, that all commits/patches submitted for
+inclusion must adhere to. Consult your project's documentation for
+more information.
+
+
+Merge workflow
+~~~~~~~~~~~~~~
+
+The merge workflow works by copying branches between upstream and
+downstream. Upstream can merge contributions into the official
+history; downstream base their work on the official history.
+
+There are three main tools that can be used for this:
+
+* linkgit:git-push[1] copies your branches to a remote repository,
+ usually to one that can be read by all involved parties;
+
+* linkgit:git-fetch[1] that copies remote branches to your repository;
+ and
+
+* linkgit:git-pull[1] that does fetch and merge in one go.
+
+Note the last point. Do 'not' use 'git-pull' unless you actually want
+to merge the remote branch.
+
+Getting changes out is easy:
+
+.Push/pull: Publishing branches/topics
+[caption="Recipe: "]
+=====================================
+`git push <remote> <branch>` and tell everyone where they can fetch
+from.
+=====================================
+
+You will still have to tell people by other means, such as mail. (Git
+provides the linkgit:request-pull[1] to send preformatted pull
+requests to upstream maintainers to simplify this task.)
+
+If you just want to get the newest copies of the integration branches,
+staying up to date is easy too:
+
+.Push/pull: Staying up to date
+[caption="Recipe: "]
+=====================================
+Use `git fetch <remote>` or `git remote update` to stay up to date.
+=====================================
+
+Then simply fork your topic branches from the stable remotes as
+explained earlier.
+
+If you are a maintainer and would like to merge other people's topic
+branches to the integration branches, they will typically send a
+request to do so by mail. Such a request looks like
+
+-------------------------------------
+Please pull from
+ <url> <branch>
+-------------------------------------
+
+In that case, 'git-pull' can do the fetch and merge in one go, as
+follows.
+
+.Push/pull: Merging remote topics
+[caption="Recipe: "]
+=====================================
+`git pull <url> <branch>`
+=====================================
+
+Occasionally, the maintainer may get merge conflicts when he tries to
+pull changes from downstream. In this case, he can ask downstream to
+do the merge and resolve the conflicts themselves (perhaps they will
+know better how to resolve them). It is one of the rare cases where
+downstream 'should' merge from upstream.
+
+
+Patch workflow
+~~~~~~~~~~~~~~
+
+If you are a contributor that sends changes upstream in the form of
+emails, you should use topic branches as usual (see above). Then use
+linkgit:git-format-patch[1] to generate the corresponding emails
+(highly recommended over manually formatting them because it makes the
+maintainer's life easier).
+
+.format-patch/am: Publishing branches/topics
+[caption="Recipe: "]
+=====================================
+* `git format-patch -M upstream..topic` to turn them into preformatted
+ patch files
+* `git send-email --to=<recipient> <patches>`
+=====================================
+
+See the linkgit:git-format-patch[1] and linkgit:git-send-email[1]
+manpages for further usage notes.
+
+If the maintainer tells you that your patch no longer applies to the
+current upstream, you will have to rebase your topic (you cannot use a
+merge because you cannot format-patch merges):
+
+.format-patch/am: Keeping topics up to date
+[caption="Recipe: "]
+=====================================
+`git pull --rebase <url> <branch>`
+=====================================
+
+You can then fix the conflicts during the rebase. Presumably you have
+not published your topic other than by mail, so rebasing it is not a
+problem.
+
+If you receive such a patch series (as maintainer, or perhaps as a
+reader of the mailing list it was sent to), save the mails to files,
+create a new topic branch and use 'git-am' to import the commits:
+
+.format-patch/am: Importing patches
+[caption="Recipe: "]
+=====================================
+`git am < patch`
+=====================================
+
+One feature worth pointing out is the three-way merge, which can help
+if you get conflicts: `git am -3` will use index information contained
+in patches to figure out the merge base. See linkgit:git-am[1] for
+other options.
+
+
+SEE ALSO
+--------
+linkgit:gittutorial[7],
+linkgit:git-push[1],
+linkgit:git-pull[1],
+linkgit:git-merge[1],
+linkgit:git-rebase[1],
+linkgit:git-format-patch[1],
+linkgit:git-send-email[1],
+linkgit:git-am[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite.
--
tg: (50ea8e5..) t/doc-workflows (depends on: origin/master t/doc-rebase-warn t/doc-rebase-refer)
^ permalink raw reply related
* Re: [PATCH] -C/--chdir command line option
From: Maciej Pasternacki @ 2008-10-19 15:24 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081019141634.GA8997@coredump.intra.peff.net>
On 2008-10-19, at 16:16, Jeff King wrote:
> Though I am not clear from your original description if that is even
> what you want. It sounds like you might be doing:
>
> git -C /chdir/path --git-dir=/back/to/where/I/was
>
> in which case I think work-tree _is_ a better fit.
No. I have a regular "git clone"'d work tree inside some "shelf"
directory containing many repos (not only from git), and I'd like to
pull changes into this work tree. As simple as "cvs up". But -- I
don't want to chdir() there myself, and I had no problem with cvs, svn
and darcs (didn't do other VC systems yet). So, -C would do exactly
what I need.
>>> Also, the envchanged flag should probably be set, as for the git-dir
>>> and work-tree options.
>>
>> OK. I thought it means literally environment change, as in setenv().
>
> It is really used to tell the options parser for aliases that some
> options which change the operating environment should not be used in
> an
> alias. I.e., something like:
>
> git config alias.foo "--git-dir=/path/to/whatever log"
>
> isn't allowed, because we have already done some work on setting up
> the
> git-dir at this point. IMHO, this is a limitation of the current
> approach to setting up the environment, but fixing it would be
> nontrivial.
>
> I'm not 100% sure that doing a chdir should be disallowed in this
> instance, but I suspect it would cause problems. I think it is
> better in
> this instance to be conservative and disallow it in aliases.
In this case, I think envchanged should not be set -- I would expect -
C dir to work *exactly* like "cd dir && git ...", including
configuration, environment variables and so on. OTOH, option like "--
no-env" may be useful in my case -- I want git to behave consistently
on users' machines, regardless of their configuration. This, however,
is only a minor issue.
Regards,
Maciej.
--
-><- Maciej Pasternacki -><- http://www.pasternacki.net/ -><-
^ permalink raw reply
* [PATCH] Documentation: Spelling fix
From: Fredrik Skolmli @ 2008-10-19 16:09 UTC (permalink / raw)
To: gitster; +Cc: git
Signed-off-by: Fredrik Skolmli <fredrik@frsk.net>
---
Documentation/git-checkout.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 2b344e1..ea05a7a 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -88,7 +88,7 @@ This would tell us to use "hack" as the local branch when branching
off of "origin/hack" (or "remotes/origin/hack", or even
"refs/remotes/origin/hack"). If the given name has no slash, or the above
guessing results in an empty name, the guessing is aborted. You can
-exlicitly give a name with '-b' in such a case.
+explicitly give a name with '-b' in such a case.
--no-track::
Ignore the branch.autosetupmerge configuration variable.
--
1.5.6.5
^ 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