* Re: deleting non-existent ref via push
From: Junio C Hamano @ 2011-09-23 18:16 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <CAMK1S_gksrR800yJHSnQWDNeDvD75+3Rp+qRWCuUrQyWmNDMsA@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> Pushing to delete a non-existent ref (git push origin :refs/heads/foo)
> works without error, except for a warning that the remote is "Allowing
> deletion of corrupt ref". By "works" I mean all hooks are also
> executed.
>
> Is this expected/supported behaviour? Can I rely on it continuing to
> work, especially in terms of executing hooks.
This most definitely is just "we didn't bother checking the error too
carefully, especially because the result of deleting something that did
not exist in the first place is a no-op; anybody who tries to delete a
non-existing thing is a moron and deserves whatever random result he
gets".
It would be a good idea to tighten it.
^ permalink raw reply
* Re: More Beginning Git Questions
From: Jon Forrest @ 2011-09-23 18:14 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <m3ipojqhpm.fsf@localhost.localdomain>
On 9/23/2011 10:42 AM, Jakub Narebski wrote:
> I recommend reading "Pro Git" book (http://progit.org)
I'm reading that too. I have some similar pedantic questions
about that book but I don't want to be a pest so I'll
stick with the tutorial now. Maybe some of my questions
about "Pro Git" will get answered.
>> Does this include both changes that Alice has checked in to
>> her repository and uncommitted changes in her working tree?
>
> Generally Alice shouldn't have uncommitted changes when doing
> "git pull".
That's what the tutorial said but I'm trying to understand
what happens if she does have uncommitted changes. I'm
trying to understand the total picture.
> When there is a merge conflicts, the index gets populated by more than
> one version: "ours" (i.e. Alice version) in stage 2, "theirs"
> (i.e. Bob version) in stage 3, and "base" (common ancestor version) in
> stage 1. The stage 0, where "git add" / "git stage" puts contents of
> file, is empty.
I didn't know there were multiple staging areas.
> You can see it using "git ls-files --abbrev --stage".
That's very helpful.
Thanks to (almost) everyone who has responded. I'm hoping that
others new to Git will benefit from this discussion.
Jon
^ permalink raw reply
* Re: What's The Right Way to Do This?
From: Junio C Hamano @ 2011-09-23 18:13 UTC (permalink / raw)
To: Jon Forrest; +Cc: git
In-Reply-To: <loom.20110923T064720-366@post.gmane.org>
Jon Forrest <nobozo@gmail.com> writes:
> I'm just now starting to use git for more than trivial things.
> Today I got myself in trouble. Here's what happened:
>
> 1) I pulled the master branch from the IT repository from our
> main git server.
>
> 2) I created a branch from this called "J" and started making changes.
>
> 3) Other people pulled master from IT and then pushed changes back.
>
> 4) I merged J with my master branch.
>
> 5) I tried pushing my master back to origin but this failed with
> the usual message saying I first needed to pull from origin.
> So, I pulled and then pushed. This worked.
>
> 6) On another server where I was going to use my changes I pulled
> master from IT.
Up to this point you are doing perfectly fine as far as I can tell.
> 6) It turned out that my changes were incorrect. So, I tried to revert
> using various methods I found by googling "git revert". What happened
> was that when I tried to revert back to the commit before the one I
> made,...
Now, in git you do not "revert back TO the commit". You could reset back
to the commit but that is to discard everything that is done since that
commit.
Imagine this history (time flows from left to right).
At point 4, 'master' in your working repository is at M, and you haven't
seen others' work 'o' yet:
---M---o---o---o (others' work)
\
x---y---z (your work on J branch)
You merge your work your master and then your 'master' now points at 'z'.
If you push and replace 'master' at the central repository with your
'master', others' work 'o' will be lost. So you pulled in point 5 to make
the history look like this:
---M---o---o---o (others' work)
\ \
x---y---z---X
You pulled to grab these 'o' commits, and made a merge with your master
(now at J) to create 'X', and then pushed it as 'master' at the central
repository.
Time passes and there may be more changes on top of 'X' now and the
current tip of the shared 'master' may be 'A'.
---M---o---o---o (others' work)
\ \
x---y---z---X---o---o---A
Even if the changes 'x', 'y', and 'z' later turns out to be unwanted, you
do not want discard others' work 'o'. Rewinding the history to make the
'master' point at 'M' is not what you want.
Instead, you would make commits that revert the effect of them on top of
the current history. That is what "git revert" does.
---M---o---o---o (others' work)
\ \
x---y---z---X---o---o---A-(z)-(y)-(x)
That is, on top of 'A', you would run "git revert z" to create an "anti-z"
commit "(z)" to cancel the effect of 'z', and do the same for y and x, to
eradicate them.
Another possibility is to revert the merge 'X', but I'll leave it as an
advanced exercise to the readers.
^ permalink raw reply
* Re: [PATCH 2/5] git-p4: handle utf16 filetype properly
From: Luke Diamand @ 2011-09-23 18:01 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Vitor Antunes, Chris Li, Junio C Hamano
In-Reply-To: <20110918012831.GB4619@arf.padd.com>
On 18/09/11 02:28, Pete Wyckoff wrote:
> One of the filetypes that p4 supports is utf16. Its behavior is
> odd in this case. The data delivered through "p4 -G print" is
> not encoded in utf16, although "p4 print -o" will produce the
> proper utf16-encoded file.
>
> When dealing with this filetype, discard the data from -G, and
> intstead read the contents directly.
"intstead" - should be "instead", or perhaps "int32_tstead".
>
> An alternate approach would be to try to encode the data in
> python. That worked for true utf16 files, but for other files
> marked as utf16, p4 delivers mangled text in no recognizable encoding.
>
> Add a test case to check utf16 handling, and +k and +ko handling.
>
> Reported-by: Chris Li<git@chrisli.org>
> Signed-off-by: Pete Wyckoff<pw@padd.com>
> ---
> contrib/fast-import/git-p4 | 11 +++++
> t/t9802-git-p4-filetype.sh | 107 ++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 118 insertions(+), 0 deletions(-)
> create mode 100755 t/t9802-git-p4-filetype.sh
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 2f7b270..e69caf3 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -1238,6 +1238,15 @@ class P4Sync(Command, P4UserMap):
> data = ''.join(contents)
> contents = [data[:-1]]
>
> + if file['type'].startswith("utf16"):
> + # p4 delivers different text in the python output to -G
> + # than it does when using "print -o", or normal p4 client
> + # operations. utf16 is converted to ascii or utf8, perhaps.
> + # But ascii text saved as -t utf16 is completely mangled.
> + # Invoke print -o to get the real contents.
> + text = p4_read_pipe('print -q -o - "%s"' % file['depotFile'])
> + contents = [ text ]
> +
> if self.isWindows and file["type"].endswith("text"):
> mangled = []
> for data in contents:
> @@ -1245,6 +1254,8 @@ class P4Sync(Command, P4UserMap):
> mangled.append(data)
> contents = mangled
>
> + # Note that we do not try to de-mangle keywords on utf16 files,
> + # even though in theory somebody may want that.
> if file['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
> contents = map(lambda text: re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text), contents)
> elif file['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
> diff --git a/t/t9802-git-p4-filetype.sh b/t/t9802-git-p4-filetype.sh
> new file mode 100755
> index 0000000..f112eaa
> --- /dev/null
> +++ b/t/t9802-git-p4-filetype.sh
> @@ -0,0 +1,107 @@
> +#!/bin/sh
> +
> +test_description='git-p4 p4 filetype tests'
> +
> +. ./lib-git-p4.sh
> +
> +test_expect_success 'start p4d' '
> + kill_p4d || :&&
> + start_p4d&&
> + cd "$TRASH_DIRECTORY"
> +'
> +
> +test_expect_success 'utf-16 file create' '
> + cd "$cli"&&
> +
> + # p4 saves this verbatim
> + echo -e "three\nline\ntext"> f-ascii&&
> + p4 add -t text f-ascii&&
> +
> + # p4 adds \377\376 header
> + cp f-ascii f-ascii-as-utf16&&
> + p4 add -t utf16 f-ascii-as-utf16&&
> +
> + # p4 saves this exactly as iconv produced it
> + echo -e "three\nline\ntext" | iconv -f ascii -t utf-16> f-utf16&&
> + p4 add -t utf16 f-utf16&&
> +
> + # this also is unchanged
> + cp f-utf16 f-utf16-as-text&&
> + p4 add -t text f-utf16-as-text&&
> +
> + p4 submit -d "f files"&&
> +
> + # force update of client files
> + p4 sync -f&&
> + cd "$TRASH_DIRECTORY"
> +'
> +
> +test_expect_success 'utf-16 file test' '
> + test_when_finished cleanup_git&&
> + "$GITP4" clone --dest="$git" //depot@all&&
> + cd "$git"&&
> +
> + cmp "$cli/f-ascii" f-ascii&&
> + cmp "$cli/f-ascii-as-utf16" f-ascii-as-utf16&&
> + cmp "$cli/f-utf16" f-utf16&&
> + cmp "$cli/f-utf16-as-text" f-utf16-as-text
> +'
> +
> +test_expect_success 'keyword file create' '
> + cd "$cli"&&
> +
> + echo -e "id\n\$Id\$\n\$Author\$\ntext"> k-text-k&&
> + p4 add -t text+k k-text-k&&
> +
> + cp k-text-k k-text-ko&&
> + p4 add -t text+ko k-text-ko&&
> +
> + cat k-text-k | iconv -f ascii -t utf-16> k-utf16-k&&
> + p4 add -t utf16+k k-utf16-k&&
> +
> + cp k-utf16-k k-utf16-ko&&
> + p4 add -t utf16+ko k-utf16-ko&&
> +
> + p4 submit -d "k files"&&
> + p4 sync -f&&
> + cd "$TRASH_DIRECTORY"
> +'
> +
> +ko_smush() {
> + cat>smush.py<<-EOF&&
> + import re, sys
> + sys.stdout.write(re.sub(r'(?i)\\\$(Id|Header):[^$]*\\\$', r'$\1$', sys.stdin.read()))
> + EOF
> + python smush.py< "$1"
> +}
> +
> +k_smush() {
> + cat>smush.py<<-EOF&&
> + import re, sys
> + sys.stdout.write(re.sub(r'(?i)\\\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\\\$', r'$\1$', sys.stdin.read()))
> + EOF
> + python smush.py< "$1"
> +}
> +
> +test_expect_success 'keyword file test' '
> + test_when_finished cleanup_git&&
> + "$GITP4" clone --dest="$git" //depot@all&&
> + cd "$git"&&
> +
> + # text, ensure unexpanded
> + k_smush "$cli/k-text-k"> cli-k-text-k-smush&&
> + cmp cli-k-text-k-smush k-text-k&&
> + ko_smush "$cli/k-text-ko"> cli-k-text-ko-smush&&
> + cmp cli-k-text-ko-smush k-text-ko&&
> +
> + # utf16, even though p4 expands keywords, git-p4 does not
> + # try to undo that
> + cmp "$cli/k-utf16-k" k-utf16-k&&
> + cmp "$cli/k-utf16-ko" k-utf16-ko
> +'
> +
> +test_expect_success 'kill p4d' '
> + kill_p4d
> +'
> +
> +test_done
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Junio C Hamano @ 2011-09-23 18:00 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <CAP2yMaL3rewYZSXQFxkSLkiNbaBAP8r707x2dScVK1zeVr8hXQ@mail.gmail.com>
Scott Chacon <schacon@gmail.com> writes:
> It appears that you're no longer pushing the 'html' branch to the
> GitHub repo,...
It is not even "no longer".
Unlike the other public mirrors that are designed to mimic what my
repository at k.org looks like, https://github.com/gitster/git is
primarily meant to mirror my internal development repository, with the
full set of topic branches.
As I do not have 'html' as a branch in my development repository, the
result "git push --mirror" there never had refs/heads/html, either.
My workflow used to be:
- push 4 integration branches from the development repository to k.org,
and have its update hook update html and man branches there;
- optionally push todo from a different private repository to k.org;
- fetch back refs/heads/* from k.org to refs/remotes/ko/*;
- verify that my refs/heads/* and refs/remotes/ko/* match for 4 integration
branches;
- push stuff under refs/remotes/ko/* to public mirrors (sourceforge does
not get next and pu);
- push --mirror to https://github.com/gitster/git.
Now the interim workflow, until k.org comes back, is tentatively:
- in a separate local "formatting" repository, pull 'master' from my
development repository, build html and man there, and push them back
to refs/docs/{html,man} to my development repository;
- push refs/heads/{master,maint,next,pu} and refs/docs/{html,man} to
public mirrors (sourceforge does not get next and pu);
- push --mirror to https://github.com/gitster/git.
I am hoping that I do not have to keep doing this and refs/docs/ can
eventually go away. I specifically do _not_ want the administrative
non-source branches html/man/todo to be my local branches.
> Since the k.org hosting of the man pages is down, I was working on
> putting them on git-scm.com, where you could select which version of
> the docs you want to see and could search through them and whatnot.
What is the expected the end-user page-flow?
Would people come to https://github.com/gitster/git first, find "doc" link
there, and start browsing the html version of the documentation?
Or do people come to http://github.com/, find a link "documentation for
the scm this site supports", your machinery kicks in and serves the blobs
from https://github.com/gitster/git under the hood, without letting users
know where the pages they are looking at really come from?
What I am getting at is that if these users do not need to know about my
repository, then you do not _need_ to see html branch in my repository,
either. You only need to find it _somewhere_, and that somewhere does not
have to be https://github.com/gitster/git repository.
You may think you could use refs/docs/html but I would rather want to
avoid letting you guys rely on refs/docs/ I started using just a few days
ago as an interim measure. I may later change my mind and get rid of that
from my development repository, but that would break your machinery to
show preformatted documentation pages.
I could add a _separate_ repository at github, and treat it just like
other public mirrors like repo.or.cz, so that you can find html branch
there. That would be consistent with my wish to use "push --mirror" to at
least one place (https://github.com/gitster/git), and would be easier to
manage for me.
Would that work?
^ permalink raw reply
* Re: [PATCH 0/5] git-p4 filetype handling
From: Luke Diamand @ 2011-09-23 17:56 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Vitor Antunes, Chris Li, Junio C Hamano
In-Reply-To: <20110918012634.GA4578@arf.padd.com>
On 18/09/11 02:26, Pete Wyckoff wrote:
> Here's a series that includes some changes to make
> git-p4 handle p4 filetypes better. This work was
> inspired by Chris Li, and includes some refactoring
> of the git-p4 tests that grew out of looking at
> Vitor's branch changes.
>
> It could use review for generic test beauty, as well
> as for the git-p4 filetype specifics in the code.
Modulo Junio's other comments, this looks sensible to me. I tried it on
a sizeable tree and it didn't scramble anything (but that will only have
tested the 'normal' filetypes).
Do we use $(some_command) rather than `some_command` now?
A few other small comments to follow.
Regards!
Luke
>
> contrib/fast-import/git-p4 | 91 +++++++++++++-----
> t/lib-git-p4.sh | 55 +++++++++++
> t/t9800-git-p4.sh | 108 ++--------------------
> t/t9801-git-p4-branch.sh | 221 ++++++++++++++++++++++++++++++++++++++++++++
> t/t9802-git-p4-filetype.sh | 107 +++++++++++++++++++++
> 5 files changed, 457 insertions(+), 125 deletions(-)
>
> Thanks,
>
> -- Pete
>
^ permalink raw reply
* Re: More Beginning Git Questions
From: Jakub Narebski @ 2011-09-23 17:42 UTC (permalink / raw)
To: Jon Forrest; +Cc: git@vger.kernel.org
In-Reply-To: <4E7C9AAD.7060209@gmail.com>
Jon Forrest <nobozo@gmail.com> writes:
> I'm reading the git tutorial at
> http://schacon.github.com/git/gittutorial.html
I recommend reading "Pro Git" book (http://progit.org)
> I'm a very literal reader so if something isn't clear
> to me, I try to make the effort to understand it.
>
> In reading about what happens when Alice pulls from Bob,
> it says:
>
> "Note that in general, Alice would want her local changes committed
> before initiating this "pull"."
>
> This is an interesting statement. I'll come back to it shortly.
>
> "If Bob’s work conflicts with what Alice did since their histories forked,"
>
> Does this include both changes that Alice has checked in to
> her repository and uncommitted changes in her working tree?
Generally Alice shouldn't have uncommitted changes when doing
"git pull".
> "Alice will use her working tree and the index to resolve conflicts,"
>
> How does Alice use her working tree and index? Does this mean
> she makes changes to her working tree so that the conflicts
> no longer exist? How does the index play a part in this?
> I thought that the index gets populated only when a
> "git add" is done. Does Alice need to do "git add" as part
> of the conflict resolution process?
This is actually a very important information.
When there is a merge conflicts, the index gets populated by more than
one version: "ours" (i.e. Alice version) in stage 2, "theirs"
(i.e. Bob version) in stage 3, and "base" (common ancestor version) in
stage 1. The stage 0, where "git add" / "git stage" puts contents of
file, is empty.
You can see it using "git ls-files --abbrev --stage".
The working area gets populated with version that contains both "ours"
and "theirs" hunks using conflict markers (the 3-way textual merge,
like 'rcsmerge' or 'diff3 -E' does). Sidenote: you can use "git
checkout --conflict=merge <file>" to re-create this version if you
messed up conflict resolution, or even --conflict=diff3 if you want
"base" (ancestor) version to be shown in conflict markers as
well... but this would discard your changes.
After resolving conflict you do "git add" on resolved file to mark it
as done. This leaves you with only newly add-ed stage 0 in the index!
The pre-commit hook might check if you didn't accidentally marked as
resolved (added) file with [something that looks like] conflict
markers in it.
HTH
--
Jakub Narębski
^ permalink raw reply
* Re: Fwd: permission to re-license strbuf subsystem as LGPL
From: Jakub Narebski @ 2011-09-23 17:12 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <CA+sFfMcmsKkKM7C0g4vKmjmCCNqRHuvz-hwEHAm=+stqnOPpAw@mail.gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> ---------- Forwarded message ----------
> From: Brandon Casey <drafnel@gmail.com>
> Date: Thu, Sep 22, 2011 at 11:21 PM
> Subject: permission to re-license strbuf subsystem as LGPL
>
> To those who have contributed to git's strbuf subsystem,
>
> I'd like to turn git's strbufs into a library. So with your consent
> I'd like to re-license the code in strbuf.c and strbuf.h, and any
> compat/ dependencies as LGPL so that I can create a strbuf library.
That's a laudable goal. Do you plan on librarizing other universal
mini-libraries, like parseopt or test-lib?
I wonder if for example "perf" tool in Linux kernel sources (userspace
companion to perf events subsystem) will move to using it; currently
it reuses some of internal git minilibraries, IIRC strbuf and parseopt
included.
By the way, how the 'strbuf' from git (which I think was created among
others to avoid additional external dependencies) differs from
existing C (not C++) string libraries, like 'bstring'[1], The Better
String Library, or the C libraries in http://bstring.sourceforge.net/features.html?
[1]: http://bstring.sourceforge.net
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH 2/2] diff_index: honor in-index, not working-tree, .gitattributes
From: Junio C Hamano @ 2011-09-23 16:44 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Jeff King, Michael Haggerty
In-Reply-To: <CAG+J_Dyh=t2VAZ6rAqcF2meEgBCN5c+J_m_YvVQbKfvXeJ8WGA@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> This area of git is still black magic to me. My best guess is
> something like this:
>
> diff --git a/tree-diff.c b/tree-diff.c
> index b3cc2e4753..6fd84eb2bb 100644
> --- a/tree-diff.c
> +++ b/tree-diff.c
> @@ -280,6 +282,19 @@ int diff_tree_sha1(const unsigned char *old,
> const unsigned char *new, const cha
> die("unable to read destination tree (%s)", sha1_to_hex(new));
> init_tree_desc(&t1, tree1, size1);
> init_tree_desc(&t2, tree2, size2);
> +
> + if (is_bare_repository()) {
> + struct unpack_trees_options unpack_opts;
> + memset(&unpack_opts, 0, sizeof(unpack_opts));
> + unpack_opts.index_only = 1;
> + unpack_opts.head_idx = -1;
> + unpack_opts.src_index = &the_index;
> + unpack_opts.dst_index = &the_index;
> + unpack_opts.fn = oneway_merge;
> + if (unpack_trees(1, DIFF_OPT_TST(opt, REVERSE_DIFF) ? &t1 : &t2,
> &unpack_opts) == 0)
> + git_attr_set_direction(GIT_ATTR_INDEX, &the_index);
> + }
This is hooking at too low a level in the callchain. diff_tree_sha1() is
meant to be a general purpose "I have two tree-ish objects and I want the
comparison machinery to work on them" library function [*1*].
- One of the more important uses is the history simplification done
during revision traversal by checking if the subtrees and the blobs
have the same SHA-1, and we should not pay penalty of reading the index
for each and every tree here.
- The caller may be using the index for its own purposes, and your use of
"the_index" here will break them.
If you want to allow use of in-tree attributes in _all_ callers of
diff_tree_sha1(), then the right approach is to add an instance of "struct
index_state" to "struct diff_options", have the caller _explicitly_ ask
for use of in-tree attributes by setting a bit somewhere in "struct
diff_options", and read the tree into that separate index_state using
tree.c::read_tree(). I however doubt it is worth it.
I would think it makes more sense to add a codeblock like that at the
beginning of builtin/diff.c::builtin_diff_tree() when a new command option
asks for it. In that codepath, you _know_ that we are not using the index
at all, and reading the index there will not interfere with other uses of
the index in the program.
[Footnote]
*1* which means that it is not a good justification to say "no current
caller is broken by this change". We need to make the library usable
for future callers.
^ permalink raw reply
* Re: Bug: git log --numstat counts wrong
From: Tay Ray Chuan @ 2011-09-23 16:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Pepper, git
In-Reply-To: <CALUzUxrswZ+AREq+OeqpTsnoB4J+_aExfmAA6X3cauJqj8RnpQ@mail.gmail.com>
On Fri, Sep 23, 2011 at 5:18 PM, Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Fri, Sep 23, 2011 at 1:51 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> [snip]
>> Applying the following patch should make the last two use the default
>> context or -U$num given from the command line to be consistent with the
>> codepath where we generate textual patches.
>>
>> diff.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/diff.c b/diff.c
>> index 9038f19..302ef33 100644
>> --- a/diff.c
>> +++ b/diff.c
>> @@ -2251,6 +2251,8 @@ static void builtin_diffstat(const char *name_a, const char *name_b,
>> memset(&xpp, 0, sizeof(xpp));
>> memset(&xecfg, 0, sizeof(xecfg));
>> xpp.flags = o->xdl_opts;
>> + xecfg.ctxlen = o->context;
>> + xecfg.interhunkctxlen = o->interhunkcontext;
>> xdi_diff_outf(&mf1, &mf2, diffstat_consume, diffstat,
>> &xpp, &xecfg);
>> }
>
> Thanks Junio.
>
> But wait, where does this patch go? Before or after 27af01d? If I'm
> understanding the situation correctly, this patch won't change the
> reporting 10/9 for --numstat, no?
I think I can answer this - on to v1.7.6, which is before 27af01d was merged in.
> Anyway, this patch looks right.
On further thought, I think the patch merely side-steps the problem -
ie. that -U0 generates "incorrect" diffs.
Further digging reveals a xdiff-interface.c::trim_common_tail();
commenting its one and only call (patch below) gives back 10/9. Note
that it only has effect when -U0.
I think this function is incorrect. xdl_cleanup_records() and
xdl_clean_mmatch() may potentially look into common tail lines, so it
may not be "safe" to drop all common tail lines.
-- >8 --
diff --git a/xdiff-interface.c b/xdiff-interface.c
index 0e2c169..da4fab6 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -131,7 +131,7 @@
mmfile_t a = *mf1;
mmfile_t b = *mf2;
- trim_common_tail(&a, &b, xecfg->ctxlen);
+/* trim_common_tail(&a, &b, xecfg->ctxlen); */
return xdl_diff(&a, &b, xpp, xecfg, xecb);
}
-- >8 --
--
Cheers,
Ray Chuan
^ permalink raw reply related
* Re: permission to re-license archive-zip.c and zlib.c as LGPL
From: René Scharfe @ 2011-09-23 16:34 UTC (permalink / raw)
To: Brandon Casey; +Cc: Junio C Hamano, git, dpotapov, vagabon.xyz
In-Reply-To: <CA+sFfMdzMCJut385jCJ88Z8sUw3E2Bs2A1SiECORQsFJjsb=Qg@mail.gmail.com>
Am 23.09.2011 05:51, schrieb Brandon Casey:
> To those who have contributed to archive-zip.c and zlib.c,
>
> I'd like to make a library for writing zip files. I really don't see
> another library out there that does it as easily as archive-zip. So,
> with your consent, I'd like to re-license the code in archive-zip.c
> and zlib.c as LGPL so that I can create an archive-zip library. The
> reason for LGPL, of course, is so that it can be linked with non-GPL
> code.
>
> Please offer your consent to re-license your contributions under LGPL
> by replying to this email.
Fine with me; BSD or MIT style licenses would be OK as well.
Actually I'm a bit surprised that libarchive didn't grow ZIP write
support by now.
René
^ permalink raw reply
* Re: More Beginning Git Questions
From: Matthieu Moy @ 2011-09-23 16:11 UTC (permalink / raw)
To: Jon Forrest; +Cc: git@vger.kernel.org
In-Reply-To: <4E7C9AAD.7060209@gmail.com>
Jon Forrest <nobozo@gmail.com> writes:
> "If Bob’s work conflicts with what Alice did since their histories forked,"
>
> Does this include both changes that Alice has checked in to
> her repository and uncommitted changes in her working tree?
Git will not allow you to do a "git pull" if your uncommited changes
touch the same files as the pull. So, you basically can't have conflicts
about uncommited changes with "git pull".
That's by design: solving conflicts can be hard, and you want the "last
commit" safety net while doing it. If you mess up your conflict
resolution, you can still "git reset --merge" and try again.
> "Alice will use her working tree and the index to resolve conflicts,"
>
> How does Alice use her working tree and index? Does this mean
> she makes changes to her working tree so that the conflicts
> no longer exist?
Yes.
> How does the index play a part in this?
Once the conflict is fixed in the working tree, you run "git add" to
mark the conflict as resolved.
And before this, the index contains half-merged versions of your file,
and "git diff" can show you the difference between them and your
worktree. See the user manual :
http://schacon.github.com/git/user-manual.html#resolving-a-merge
(BTW, that's not the official place for Git documentation, but since
kernel.org is down now ...)
> "and existing local changes will interfere with the conflict
> resolution process"
Probably this should have been "would have interfered" (and therefore
are forbidden by Git, as the following sentence says):
> "(git will still perform the fetch but will refuse to merge
> --- Alice will have to get rid of her local changes in
> some way and pull again when this happens)."
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 2/2] diff_index: honor in-index, not working-tree, .gitattributes
From: Jay Soffian @ 2011-09-23 15:50 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <4E7C5DC3.8030409@alum.mit.edu>
On Fri, Sep 23, 2011 at 6:21 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 09/23/2011 12:39 AM, Junio C Hamano wrote:
>> [...] It
>> would be a regression if the attributes mechanism is used for auditing
>> purposes (as we start reading from a tree that is being audited using the
>> very attributes it brings in), though.
>
> I'm confused by this comment.
>
> If an auditing system can be subverted by altering .gitattributes, then
> I can do just as much harm by changing the .gitattributes in one commit
> and making the "nasty" change in a second. So any rigorous auditing
> system based on .gitattributes would have to prevent me from committing
> modifications to .gitattributes, in which case my commit will be
> rejected anyway.
>
> If by "auditing" you mean other less rigorous checks to which exceptions
> are *allowed*, then it is preferable to add the exception in the same
> commit as the otherwise-offending content, and therefore it is
> *required* that the .gitattributes of the new tree be used when checking
> the contents of that tree.
Currently, an auditing hook that cares about attributes, and which
runs in a bare repo, ignores the in-repo .gitattributes, considering
only the attributes set outside of the repo.
So by making git care about .gitattributes in a bare repo, such a hook
can suddenly be bypassed.
j.
^ permalink raw reply
* Re: permission to re-license strbuf subsystem as LGPL
From: Michael Witten @ 2011-09-23 15:36 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <CA+sFfMcmsKkKM7C0g4vKmjmCCNqRHuvz-hwEHAm=+stqnOPpAw@mail.gmail.com>
On Fri, Sep 23, 2011 at 15:01, Brandon Casey <drafnel@gmail.com> wrote:
> Jonathan Nieder suggested using a more permissive license than LGPL.
> BSD seems to have the most support. If the remaining contributors
> agree, then I'm fine with licensing under BSD.
BSD is more permissive for only the upstream; the downstream
('end-users') get nothing.
In fact, the downstream may ultimately get a license that is more
restrictive on further developments---possibly even restrictions that
might hinder the development of your own upstream work should you find
yourself in some sort of downstream position relative to a fork.
^ permalink raw reply
* Fwd: permission to re-license strbuf subsystem as LGPL
From: Brandon Casey @ 2011-09-23 15:01 UTC (permalink / raw)
To: git
In-Reply-To: <CA+sFfMeRDQiqGhO9Y=k3tEnzdXjMx59huFE_fx6Y14cJxj1J=Q@mail.gmail.com>
Oops. I forgot to include the git mailing list on the email below. I
intended to include the git mailing list for two reasons. 1) so that
when people replied giving there permission it would become part of
the public record, and 2) because maybe someone had already done this
and they could speak up before I duplicated their effort.
The following people have already given their consent:
Jeff King (LGPL)
Avery Pennarun (LGPL)
Jonathan Neider (LGPL, ZLIB, Expat, BSD)
Johannes Schindelin (LGPL, BSD)
Linus Torvalds (LGPL)
Alex Riesen (LGPL)
Marco Costalba (LGPL)
Lukas Sandström (LGPL, BSD)
Michal Rokos (LGPL, BSD)
Thomas Rast (LGPL, BSD)
The following have not yet responded (the email just went out last night):
Pierre Habouzit
René Scharfe
Junio C Hamano
Kristian Høgsberg
Johannes Sixt
Frank Li
Shawn O. Pearce
Jonathan Nieder suggested using a more permissive license than LGPL.
BSD seems to have the most support. If the remaining contributors
agree, then I'm fine with licensing under BSD.
Anyway, here is my original email requesting permission to re-license
strbuf et al so that it can be made into a library...
---------- Forwarded message ----------
From: Brandon Casey <drafnel@gmail.com>
Date: Thu, Sep 22, 2011 at 11:21 PM
Subject: permission to re-license strbuf subsystem as LGPL
To those who have contributed to git's strbuf subsystem,
I'd like to turn git's strbufs into a library. So with your consent
I'd like to re-license the code in strbuf.c and strbuf.h, and any
compat/ dependencies as LGPL so that I can create a strbuf library.
Just skimming through strbuf.c, I'm thinking the other files that may
be needed include ctype.c, compat/snprintf.c, and as little of
wrapper.c as necessary (hopefully only xread). I think all of the
authors are included in this email. The reason for LGPL, of course,
is so that it can be linked with non-GPL code.
Please offer your consent to re-license your contributions under LGPL
by replying to this email.
All comments welcome.
Thanks,
-Brandon
p.s. sorry for the mostly cut-n-paste email for those who also
received my email about archive-zip
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Scott Chacon @ 2011-09-23 14:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa9xyxpf.fsf@alter.siamese.dyndns.org>
Hey,
On Wed, Sep 21, 2011 at 10:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Here are the topics that have been cooking. Commits prefixed with '-' are
> only in 'pu' while commits prefixed with '+' are in 'next'.
>
> Here are the repositories that have my integration branches:
>
> With maint, master, next, pu and todo:
>
> url = git://repo.or.cz/alt-git.git
> url = https://code.google.com/p/git-core/
>
> With only maint and master:
>
> url = git://git.sourceforge.jp/gitroot/git-core/git.git
> url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
>
> With all the topics and integration branches:
>
> url = https://github.com/gitster/git
>
It appears that you're no longer pushing the 'html' branch to the
GitHub repo, but you are to some of the other ones, which is sort of
strange because *everything* else is there.
Since the k.org hosting of the man pages is down, I was working on
putting them on git-scm.com, where you could select which version of
the docs you want to see and could search through them and whatnot.
Can you push 'html' to GitHub too? I want to pull my data out of it
on an ongoing basis and it's the only one with a git object level API.
Thanks,
Scott
^ permalink raw reply
* More Beginning Git Questions
From: Jon Forrest @ 2011-09-23 14:41 UTC (permalink / raw)
To: git@vger.kernel.org
I'm reading the git tutorial at
http://schacon.github.com/git/gittutorial.html
I'm a very literal reader so if something isn't clear
to me, I try to make the effort to understand it.
In reading about what happens when Alice pulls from Bob,
it says:
"Note that in general, Alice would want her local changes committed
before initiating this "pull"."
This is an interesting statement. I'll come back to it shortly.
"If Bob’s work conflicts with what Alice did since their histories forked,"
Does this include both changes that Alice has checked in to
her repository and uncommitted changes in her working tree?
"Alice will use her working tree and the index to resolve conflicts,"
How does Alice use her working tree and index? Does this mean
she makes changes to her working tree so that the conflicts
no longer exist? How does the index play a part in this?
I thought that the index gets populated only when a
"git add" is done. Does Alice need to do "git add" as part
of the conflict resolution process?
"and existing local changes will interfere with the conflict resolution
process"
Are "local changes" the changes in the working tree, the
uncommitted changes that Alice has added to her index, or
changes that Alice has committed to her local repository?
"(git will still perform the fetch but will refuse to merge
--- Alice will have to get rid of her local changes in
some way and pull again when this happens)."
Again, I'm not clear on which local changes this is talking
about. In other words, when the merge part of the pull is
done, what is examined locally? The first sentence about
Alice committing her local changes before pulling is what
got me thinking about all this.
I'm sorry if these are too pedantic.
Jon Forrest
^ permalink raw reply
* Re: What's The Right Way to Do This?
From: Jon Forrest @ 2011-09-23 13:45 UTC (permalink / raw)
To: Luke Diamand; +Cc: git
In-Reply-To: <4E7C27A0.9030900@diamand.org>
On 9/22/2011 11:30 PM, Luke Diamand wrote:
> Someone will be along soon to correct me, but I think you should have
> rebased against the master branch rather than merged. Something like:
>
> % git rebase origin
>
> That way your changes would remain appended to the tip of the master
> branch. That will in general make your life much easier for all sorts of
> reasons.
In considering this, I'm having trouble understanding when to do a merge
as opposed to a rebase. Let's say that other people weren't putting
changed back in the remote master. So, my changes would always be at the
tip. Is that when I should merge? If so, then this suggest that knowing
what to do depends on knowing what other people are doing. But, doesn't
this go against the philosophy of a distributed SCM?
> At a guess, git revert created a commit that undid your _merge_, rather
> than your commit. The merge included all those other changes....
>
> It's a good idea to take a look at what a commit does before pushing it
> - "git show HEAD" is your friend.
IIRC, I did this and I saw the collection of the changes I had
made plus what other people had made. I didn't know how to revert
only my changes.
> Use git rebase (*) to keep your changes nicely arranged at the top of
> the main branch.
Thanks. I'll study up on this.
> I think you could award yourself a nice cup of tea after an experience
> like that though, having been on both sides of it, I can imagine you
> need it :-P
It certainly wasn't my finest hour!
Jon
^ permalink raw reply
* [PATCH 1/1] get_sha1_hex(): do not read past a NUL character
From: Michael Haggerty @ 2011-09-23 13:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Thomas Rast, Michael Haggerty
In-Reply-To: <4E7C857D.8000304@alum.mit.edu>
Previously, get_sha1_hex() would read one character past the end of a
null-terminated string whose strlen was an even number less than 40.
Although the function correctly returned -1 in these cases, the extra
memory access might have been to uninitialized (or even, conceivably,
unallocated) memory.
Add a check to avoid reading past the end of a string.
This problem was discovered by Thomas Rast <trast@student.ethz.ch>
using valgrind.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
It is suggested to apply this bugfix before mh/check-ref-format-3;
otherwise the latter triggers the bug, leading to a valgrind error.
This patch could optionally be applied to maint (to which it can be
rebased cleanly), though the bug that it fixes is relatively benign.
cache.h | 9 +++++++++
hex.c | 10 +++++++++-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git cache.h cache.h
index 607c2ea..e7bbc0d 100644
--- cache.h
+++ cache.h
@@ -819,7 +819,16 @@ static inline int get_sha1_with_context(const char *str, unsigned char *sha1, st
{
return get_sha1_with_context_1(str, sha1, orc, 0, NULL);
}
+
+/*
+ * Try to read a SHA1 in hexadecimal format from the 40 characters
+ * starting at hex. Write the 20-byte result to sha1 in binary form.
+ * Return 0 on success. Reading stops if a NUL is encountered in the
+ * input, so it is safe to pass this function an arbitrary
+ * null-terminated string.
+ */
extern int get_sha1_hex(const char *hex, unsigned char *sha1);
+
extern char *sha1_to_hex(const unsigned char *sha1); /* static buffer result! */
extern int read_ref(const char *filename, unsigned char *sha1);
extern const char *resolve_ref(const char *path, unsigned char *sha1, int, int *);
diff --git hex.c hex.c
index bb402fb..9ebc050 100644
--- hex.c
+++ hex.c
@@ -39,7 +39,15 @@ int get_sha1_hex(const char *hex, unsigned char *sha1)
{
int i;
for (i = 0; i < 20; i++) {
- unsigned int val = (hexval(hex[0]) << 4) | hexval(hex[1]);
+ unsigned int val;
+ /*
+ * hex[1]=='\0' is caught when val is checked below,
+ * but if hex[0] is NUL we have to avoid reading
+ * past the end of the string:
+ */
+ if (!hex[0])
+ return -1;
+ val = (hexval(hex[0]) << 4) | hexval(hex[1]);
if (val & ~0xff)
return -1;
*sha1++ = val;
--
1.7.7.rc2
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Michael Haggerty @ 2011-09-23 13:31 UTC (permalink / raw)
To: Stephen Bash
Cc: git discussion list, Jay Soffian, Jeff King, Jakub Narebski,
Junio C Hamano
In-Reply-To: <33047451.27244.1316782148569.JavaMail.root@mail.hq.genarts.com>
On 09/23/2011 02:49 PM, Stephen Bash wrote:
> We're in the process of a similar change over (we're dealing with EOL
> rather than indents), but I attacked it from a different angle... I
> wrote our update script to examine modified files and ensure
> compliance (diff-tree -r, iterate over blobs). That way legacy files
> are left alone (even in master), but active development must live up
> to the current rules. Is there a reason you need to go tree-by-tree
> rather than file-by-file?
I want to avoid code churn, especially in third-party code. With your
solution, I believe that we would be forced to entirely clean up any
file that we needed to touch. The resulting code churn would make
integrating future upstream releases a nightmare.
For some kinds of checks, one could only check that the *lines* changed
satisfy the new rules.
But rather than thinking up workarounds, it seems like a better idea to
fix git to handle .gitattributes correctly.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Fwd: vcs-svn and friends
From: Dmitry Ivankov @ 2011-09-23 13:29 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: David Michael Barr, Junio C Hamano, git
In-Reply-To: <CA+gfSn8UeqiLu3trecPzzqSLsUr3eNT0yVN=-991sL6oJHar2g@mail.gmail.com>
On Fri, Sep 23, 2011 at 7:27 PM, Dmitry Ivankov <divanorama@gmail.com> wrote:
> On Thu, Sep 15, 2011 at 7:00 PM, Dmitry Ivankov <divanorama@gmail.com> wrote:
>>> - 3bba32e9 ("fast-import: allow top directory as an argument for some
>>> commands"): I'm not sure what the motivation is --- is this just
>>> about the principle of least surprise, or did it come up in practice
>>> somewhere?
>> (to ease one's reading, commands are ls, copy and move top directory)
>>
>> Haven't seen them in practice. It seemed possible with svn import: if there were
>> no branches at start, and then someone did svn mv . trunk. But it
>> turns out that my
>> svn client doesn't allow such move. So more like a least surprise purpose.
> I think now that this commit should go separately if at all.
> Especially considering
> my other activity on fast-import (and thus possible merge conflicts) that isn't
> strictly necessary for vcs-svn and friends.
And the same for 3bba32e9^ "fast-import: be saner with temporary trees", which
is only needed for 3bba32e9.
^ permalink raw reply
* Re: Fwd: vcs-svn and friends
From: Dmitry Ivankov @ 2011-09-23 13:27 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: David Michael Barr, Junio C Hamano, git
In-Reply-To: <CA+gfSn9KVN2iDCevd0s+TjYHNupDez8NiKZycP3pgBCkYiraFQ@mail.gmail.com>
On Thu, Sep 15, 2011 at 7:00 PM, Dmitry Ivankov <divanorama@gmail.com> wrote:
>> - 3bba32e9 ("fast-import: allow top directory as an argument for some
>> commands"): I'm not sure what the motivation is --- is this just
>> about the principle of least surprise, or did it come up in practice
>> somewhere?
> (to ease one's reading, commands are ls, copy and move top directory)
>
> Haven't seen them in practice. It seemed possible with svn import: if there were
> no branches at start, and then someone did svn mv . trunk. But it
> turns out that my
> svn client doesn't allow such move. So more like a least surprise purpose.
I think now that this commit should go separately if at all.
Especially considering
my other activity on fast-import (and thus possible merge conflicts) that isn't
strictly necessary for vcs-svn and friends.
^ permalink raw reply
* Re: [PATCH v3 13/22] resolve_ref(): turn buffer into a proper string as soon as possible
From: Michael Haggerty @ 2011-09-23 13:11 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Junio C Hamano, cmn, A Large Angry SCM, Daniel Barkalow,
Sverre Rabbelier
In-Reply-To: <201109231017.55996.trast@student.ethz.ch>
On 09/23/2011 10:17 AM, Thomas Rast wrote:
> Michael Haggerty wrote:
>> Immediately strip off trailing spaces and null-terminate the string
>> holding the contents of the reference file; this allows the use of
>> string functions and avoids the need to keep separate track of the
>> string's length. (get_sha1_hex() fails automatically if the string is
>> too short.)
>>
>> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
>
> I'm getting valgrind failures in t1450-fsck and t3800-mktag which
> blame to this commit. For t1450 it looks as follows:
>
> ok 5 - object with bad sha1
>
> expecting success:
> git rev-parse HEAD^{tree} >.git/refs/heads/invalid &&
> test_when_finished "git update-ref -d refs/heads/invalid" &&
> git fsck 2>out &&
> cat out &&
> grep "not a commit" out
>
> ==19623== Use of uninitialised value of size 8
> ==19623== at 0x4B6747: hexval (cache.h:798)
> ==19623== by 0x4B6797: get_sha1_hex (hex.c:42)
> ==19623== by 0x4DD12A: resolve_ref (refs.c:588)
Thanks for finding this.
The problem comes from passing get_sha1_hex() an arbitrary
NUL-terminated string. get_sha1_hex() calls hexval(), which returns -1
if it finds a NUL character, and therefore (correctly) rejects any
string that is less than 40 characters. The problem is that
get_sha1_hex() reads characters pairwise, and even if the first
character in a pair is NUL, the second character is read anyway.
Therefore, for strings whose strlen is an even number less than 40,
get_sha1_hex() reads past the terminating NUL.
I don't know whether get_sha1_hex() is *supposed* to work for arbitrary
NUL-terminated strings because it is not documented. But other callers
seem to make the same assumption that I did, so I think that I will fix
get_sha1_hex() to not read past a NUL value (albeit at the cost of an
extra check in each iteration of the loop).
The fix is trivial and will be sent shortly.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH] use -h for synopsis and --help for manpage consistently
From: Clemens Buchacher @ 2011-09-23 11:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa9xyxpf.fsf@alter.siamese.dyndns.org>
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
On Wed, Sep 21, 2011 at 10:04:28PM -0700, Junio C Hamano wrote:
>
> * cb/send-email-help (2011-09-12) 1 commit
> (merged to 'next' on 2011-09-14 at ae71999)
> + send-email: add option -h
>
> A separate set of patches to remove the hidden fully-spelled "help" from
> other commands would be nice to have as companion patches as well.
This should do it.
Clemens
Documentation/blame-options.txt | 1 -
git-cvsserver.perl | 4 ++--
git-difftool.perl | 2 +-
git-pull.sh | 2 +-
git-sh-setup.sh | 2 +-
git-svn.perl | 2 +-
6 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index e76195a..d4a51da 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -117,5 +117,4 @@ commit. And the default value is 40. If there are more than one
take effect.
-h::
---help::
Show help message.
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 1b8bff2..6c5185e 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -109,14 +109,14 @@ my $usage =
" --strict-paths : Don't allow recursing into subdirectories\n".
" --export-all : Don't check for gitcvs.enabled in config\n".
" --version, -V : Print version information and exit\n".
- " --help, -h, -H : Print usage information and exit\n".
+ " -h : Print usage information and exit\n".
"\n".
"<directory> ... is a list of allowed directories. If no directories\n".
"are given, all are allowed. This is an additional restriction, gitcvs\n".
"access still needs to be enabled by the gitcvs.enabled config option.\n".
"Alternately, one directory may be specified in GIT_CVSSERVER_ROOT.\n";
-my @opts = ( 'help|h|H', 'version|V',
+my @opts = ( 'h', 'version|V',
'base-path=s', 'strict-paths', 'export-all' );
GetOptions( $state, @opts )
or die $usage;
diff --git a/git-difftool.perl b/git-difftool.perl
index ced1615..09b65f1 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -97,7 +97,7 @@ sub generate_command
$prompt = 'yes';
next;
}
- if ($arg eq '-h' || $arg eq '--help') {
+ if ($arg eq '-h') {
usage();
}
push @command, $arg;
diff --git a/git-pull.sh b/git-pull.sh
index 63da37b..8c1370f 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -120,7 +120,7 @@ do
--d|--dr|--dry|--dry-|--dry-r|--dry-ru|--dry-run)
dry_run=--dry-run
;;
- -h|--h|--he|--hel|--help|--help-|--help-a|--help-al|--help-all)
+ -h|--help-all)
usage
;;
*)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 8e427da..1fba6c2 100644
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -90,7 +90,7 @@ $LONG_USAGE"
fi
case "$1" in
- -h|--h|--he|--hel|--help)
+ -h)
echo "$LONG_USAGE"
exit
esac
diff --git a/git-svn.perl b/git-svn.perl
index 89f83fd..a019f55 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -294,7 +294,7 @@ read_git_config(\%opts);
if ($cmd && ($cmd eq 'log' || $cmd eq 'blame')) {
Getopt::Long::Configure('pass_through');
}
-my $rv = GetOptions(%opts, 'help|H|h' => \$_help, 'version|V' => \$_version,
+my $rv = GetOptions(%opts, 'h' => \$_help, 'version|V' => \$_version,
'minimize-connections' => \$Git::SVN::Migration::_minimize,
'id|i=s' => \$Git::SVN::default_ref_id,
'svn-remote|remote|R=s' => sub {
--
1.7.6.1
^ permalink raw reply related
* Re: How to use git attributes to configure server-side checks?
From: Stephen Bash @ 2011-09-23 12:49 UTC (permalink / raw)
To: Michael Haggerty
Cc: git discussion list, Jay Soffian, Jeff King, Jakub Narebski,
Junio C Hamano
In-Reply-To: <4E7C44C8.10000@alum.mit.edu>
----- Original Message -----
> From: "Michael Haggerty" <mhagger@alum.mit.edu>
> Sent: Friday, September 23, 2011 4:35:20 AM
> Subject: Re: How to use git attributes to configure server-side checks?
>
> On 09/22/2011 07:26 PM, Junio C Hamano wrote:
> > Michael Haggerty <mhagger@alum.mit.edu> writes:
> >
> >> I would like the checking configuration to be *versioned* along with the
> >> code. For example, suppose my project decides to enforce a rule that
> >> all Python code needs to be indented with spaces. It might be that not
> >> all of our old code adheres to this rule, and that we only want to clean
> >> up the code in master.
> >
> > You want to sneak in a badly formatted code? Add an entry to the
> > in-tree attributes file to disable whitespace checking to cover that file!
>
> No, the scenario that I was trying to describe is a project that wants
> to tighten up its code formatting rules after years of laxity. It is
> convenient to support legacy branches that still contain nonconforming
> code without having to reformat it all, just as it is convenient to
> fix the current code incrementally rather than requiring all of the
> cleanup to be done in one big bang. Thus it is important that new rules not be
> enforced retroactively on old code.
We're in the process of a similar change over (we're dealing with EOL rather than indents), but I attacked it from a different angle... I wrote our update script to examine modified files and ensure compliance (diff-tree -r, iterate over blobs). That way legacy files are left alone (even in master), but active development must live up to the current rules. Is there a reason you need to go tree-by-tree rather than file-by-file?
Thanks,
Stephen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox