* Re: Bug: git log --numstat counts wrong
From: Junio C Hamano @ 2011-09-23 19:23 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Alexander Pepper, git
In-Reply-To: <CALUzUxoujys1eWL6i6YJmFZZakcQx8oa8ZbRjixUzANB1Hpb3Q@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> On further thought, I think the patch merely side-steps the problem -
> ie. that -U0 generates "incorrect" diffs.
I do not know if there anything "incorrect" about it.
When the file have common blocks lines in different places that are not
modified, the comparison between preimage and postimage is free to choose
how these common blocks are matched, and for that reason it is incorrect
to expect that "diff -U0", "diff -U3" and "diff -U20" would produce the
identical results.
> 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.
I would prefer to keep that common trimming optimization, and also to see
the same common trimming logic extended to trim (and adjust offsets) at
the beginning as well in the longer term. If xdl_cleanup_records() and
xdl_clean_mmatch() need to become aware of the change in the total number
of lines made by trim_common_tail(), please make it so.
>
> -- >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 --
^ permalink raw reply
* Re: [PATCH 3/6] branch: teach --edit-description option
From: Junio C Hamano @ 2011-09-23 19:04 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <20110923094721.GA8397@duynguyen-vnpc>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Thu, Sep 22, 2011 at 03:09:19PM -0700, Junio C Hamano wrote:
>> + if (launch_editor(git_path(edit_description), &buf, NULL)) {
>> + strbuf_release(&buf);
>> + return -1;
>> + }
>> + stripspace(&buf, 1);
>> +
>> + strbuf_addf(&name, "branch.%s.description", branch_name);
>> + status = git_config_set(name.buf, buf.buf);
>
> I suppose a Windows editor mave save the description with \r\n
> ending. Perhaps a patch like this to avoid messing up config file?
Doesn't stripspace() cleanse that already?
^ permalink raw reply
* Re: [PATCH 1/1] get_sha1_hex(): do not read past a NUL character
From: Junio C Hamano @ 2011-09-23 18:59 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Thomas Rast
In-Reply-To: <1316785116-21831-1-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> 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.
Makes sense; thanks.
^ permalink raw reply
* Re: More Beginning Git Questions
From: Jakub Narebski @ 2011-09-23 18:59 UTC (permalink / raw)
To: Jon Forrest; +Cc: git@vger.kernel.org
In-Reply-To: <4E7CCCA0.50909@gmail.com>
BTW it is customary on git mailing list to send reply not only to git
mailing list, but also to all responders (to previous author, cc to
list and to others).
Jon Forrest <nobozo@gmail.com> writes:
> On 9/23/2011 10:42 AM, Jakub Narebski wrote:
>> Jon Forrest <nobozo@gmail.com> writes:
>>> 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.
If Alice have uncommitted changes, in working tree and/or in the
index, what git does is try to merge if possible; if conflict or new
versions from "theirs" touch changed file, git refuses to do a merge.
The idea is to do merge if possible, but abort if there is any chance
that user's changes would be lost.
>> 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.
Those are called "stages" inside one single staging area (the index).
>> You can see it using "git ls-files --abbrev --stage".
>
> That's very helpful.
Also in the case of conflict, "git diff" would show combined diff of
changes.
Try both on some example.
--
Jakub Narębski
^ permalink raw reply
* Re: More Beginning Git Questions
From: Junio C Hamano @ 2011-09-23 18:47 UTC (permalink / raw)
To: Jon Forrest; +Cc: git@vger.kernel.org
In-Reply-To: <4E7C9AAD.7060209@gmail.com>
Jon Forrest <nobozo@gmail.com> writes:
> "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?
We do not consider uncommitted changes part of _any_ history. You can
think of them as floating on top of the history of the branch that is
currently checked out [*1*].
> "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?
If you start from a clean working tree (i.e. no local changes), then after
any "mergy" operation (not just "git pull" and "git merge" but things like
"cherry-pick", "checkout -m", "rebase" and "am -3" that can stop due to
conflicts), one of the three things will happen to each of the paths in
the project:
1. If the result of the operation can be mechanically known, and if that
is the same as your current state (i.e. HEAD or "ours"), nothing
happens.
2. If the result of the operation can be mechanically known, and if that
is different from your current state (i.e. HEAD or "ours"), the index
entry for that path records the result, and the path in the working
tree is updated to match that result.
3. If the result of the operation cannot be mechanically known
(i.e. merge conflict), the index entry for that path will record up to
3 "stages", stage #1 representing the contents the conflicting sides
diverged from (i.e. common ancestor), stage #2 representing the
contents of your current state (i.e. HEAD or "ours") and stage #3
representing the contents of the other branch (i.e. MERGE_HEAD or
"theirs"), and the path in the working tree is updated to represent it
with conflict markers.
You conclude the "mergy" operation by resolving conflicts in the working
tree for paths in the category 3, tell Git that you are done with these
paths using "git add $path" (but paths in no other categories!!!).
Because cleanly merged paths are already updated in the index (see
2. above), that is all needed to bring the index to the state that
represents the desired result of the "mergy" operation.
Even if you have local changes in your working tree, as long as your index
exactly matches HEAD when you start your "mergy" operation, thanks to the
rule for "result matches the current HEAD" case (see 1. above), the result
of your "mergy" operation recorded by the procedure in the previous
paragraph will not be contaminated with your local changes.
The precondition for all of the above to work is that you start from a
clean index, and that is why "git merge" refuses to start if your index
already has changes relative to HEAD.
Also, for cases 2. and 3., updating the files in the working tree to match
the auto-merge result (case 2.) or to show the conflicted state (case 3.)
requires Git to overwrite the file, which is bad if you have local changes
to the files in the working tree. To prevent lossage, "mergy" operations
will notice if paths in categories 2. and 3. have local changes in the
working tree, and refuses to work if that is the case.
[Footnote]
*1* This incidentally is important to have in your mental model to
understand how to use "git checkout $branch" to switch branches.
^ permalink raw reply
* Re: Fwd: vcs-svn and friends
From: Jonathan Nieder @ 2011-09-23 18:45 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: David Michael Barr, Junio C Hamano, git
In-Reply-To: <CA+gfSn8UeqiLu3trecPzzqSLsUr3eNT0yVN=-991sL6oJHar2g@mail.gmail.com>
Dmitry Ivankov wrote:
> On Thu, Sep 15, 2011 at 7:00 PM, Dmitry Ivankov <divanorama@gmail.com> wrote:
>> 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.
Well, I think it's a good patch, and merge conflicts are really not a
big deal when one has a good patch, especially when it's clear how to
test that the tool still works after resolving. It's just missing a
clear description...
^ permalink raw reply
* Re: More Beginning Git Questions
From: Mihamina Rakotomandimby @ 2011-09-23 18:44 UTC (permalink / raw)
To: Jon Forrest; +Cc: git@vger.kernel.org
In-Reply-To: <4E7CCCA0.50909@gmail.com>
On 09/23/2011 09:14 PM, Jon Forrest wrote:
>
> Thanks to (almost) everyone who has responded. I'm hoping that
> others new to Git will benefit from this discussion.
It does, it does...
I'm working on an internal parallel documentation on using Hg and Git
and this conflict resolution topic is... important.
--
RMA.
^ permalink raw reply
* 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
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