* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 7:55 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Jeff King, Theodore Tso, Petr Baudis, git
In-Reply-To: <48C8A9A4.7030906@gnu.org>
Paolo Bonzini wrote:
>> Being able to subvert the authenticity of git blame by providing fake
>> origin information is not very appealing.
>You could use a dummy submodule to ensure that each commit pointed to
>the right set of notes. It would force to create a separate commit
>whenever you modified the notes, which is actually not bad.
Possibly, yes. But we'd have to be careful not to incur too much
overhead because every indirection will cost, especially since the
origin link sometimes is checked for on every commit during a treewalk.
The fact that it rarely exists means that it should be fast to find out
that there are no origin links (which obviously is the common case).
>Alternatively, the header of the commit can be modified to add a pointer
>to a tree object for the notes; I suppose this is more palatable than
>the origin link.
This won't work for the original notes concept, because it makes the
notes immutable after commit. For the origin links this would be fine,
since they don't change once committed.
The problem with fitting the origin links in the notes is twofold:
- They become mutable, which is undesirable, I'd like to preserve
history as is (just like parent links).
- There is a performance hit, since origin links need to be found not to
exist on every commit (sometimes, depending on the operation of course).
> The tree could be organized in directories+blobs like
>..git/objects to speed up the lookup.
Yes, that was already in the latest proposal for notes, I believe.
>I actually like the commit notes idea, but then I wonder: why are the
>author and committer part of the commit object? How does the plumbing
>use them? Isn't that metadata that could live in the "notes"? And so,
It would fit with a non-mutable version of the notes. Then again, we
already *have* the non-mutable version of the notes, it's called the
header of the commit message.
>why should the origin link have less privileges?
They both belong in the non-mutable notes, and those happen to live in
the header of the commit (which *is* the most efficient spot, of course).
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: PATCH: git-p4 optional handling of RCS keywords
From: dhruva @ 2008-09-11 7:13 UTC (permalink / raw)
To: Tor Arvid Lund; +Cc: Simon Hausmann, Junio C Hamano, GIT SCM, Jing Xue
Hi,
The patch I have sent is 1 single patch.
----- Original Message ----
> From: Tor Arvid Lund <torarvid@gmail.com>
> To: dhruva <dhruva@ymail.com>
> Me guesses that Junio (who gets loads of patches) would be happy if you do:
>
> 1) Squash these changes down to one single commit
> 2) Run git format-patch -1
> 3) Send it to the list either with git send-email, or otherwise send
> the 0001-.patch to the list directly if your
> mailer supports it.
Let me start learning that now. I have added my own extensions on top of what I have submitted, I need to figure out a way to do all these stuff (I am still a newbie to git ;)
-dhruva
Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here http://in.promos.yahoo.com/address
^ permalink raw reply
* Re: [StGit PATCH 1/3] Auto-generate man pages for all StGit commands
From: Karl Hasselström @ 2008-09-11 6:58 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0809101456w3c74b86fm9d311fb2594bcf4f@mail.gmail.com>
On 2008-09-10 22:56:55 +0100, Catalin Marinas wrote:
> On 08/09/2008, Karl Hasselström <kha@treskal.com> wrote:
>
> > Auto-generate man pages based on the docs that are in each
> > stgit/commands/<cmd>.py file. That doc format is extended in order
> > to support both brief command help output and manpage text.
>
> Really great stuff. Thanks.
Glad you like it. Now all we have to do is feed the system with
high-quality input ... :-)
> I can see a slight difference in behaviour but I don't have any
> issue with it - previously "stg help <cmd>" showed the full
> description while "stg <cmd> --help" only the short one.
Yes, that's intentional. I tried to say something about it in the
commit message, but I guess I didn't do a very good job about it.
The interactive help now uses only the one-line command description;
the multiline description goes only to the man page/html. There are
two reasons for this:
1. The interactive help should be short and sweet. If the user wants
to spend a minute or more learning about a command, she is better
served by the "real" reference docs.
2. The multiline descriptions (both for the command itself and for
its flags) contain, or should contain, asciidoc markup. If we
wanted to display this text in the interactive help we'd need to
at least be able to strip the markup out, something which I
haven't even tried to do.
> An additional point on naming - should we use StGIT or StGit? The
> original name was StGIT since GIT looked like an acronym. It looks
> like now more people name it Git hence our tool moved slowly into
> StGit but not everywhere. I personally like StGIT but the last 3
> letters should really be the same as the official git (Git, GIT).
As you may or may not have noticed, I'm responsible for the vast
majority of "StGit"s. I prefer it because "git" isn't really an
acronym, and I happen to like camel case ... :-)
You're right that we ought to standardize on one of the spellings,
though.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: PATCH: git-p4 optional handling of RCS keywords
From: Tor Arvid Lund @ 2008-09-11 6:33 UTC (permalink / raw)
To: dhruva; +Cc: Simon Hausmann, Junio C Hamano, GIT SCM, Jing Xue
In-Reply-To: <880457.35643.qm@web95006.mail.in2.yahoo.com>
On Thu, Sep 11, 2008 at 6:06 AM, dhruva <dhruva@ymail.com> wrote:
> Hello,
>
>
> Commit message: Modifying RCS keywords prevents submitting to p4 from git due to missing hunks. Optional shrinking of RCS keywords in git-p4. New option git-p4.kwstrip set to true or false controls the behavior..
<snip away the diff>
Me guesses that Junio (who gets loads of patches) would be happy if you do:
1) Squash these changes down to one single commit
2) Run git format-patch -1
3) Send it to the list either with git send-email, or otherwise send
the 0001-<your-commit-summary>.patch to the list directly if your
mailer supports it.
The reason is simply that the maintainer can simply use git am
<your-raw-mail-message-file> to commit it, instead of having to
manually sift through the emails.
Otherwise, this is nice work. Thanks.
-Tor Arvid-
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 6:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809101733050.3384@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>> - However, if you explicitly pull D, the origin information from A to D can
>> be used. People doing a generic clone get all four branches, and
>> therefore have all the important commits which normally could contain
>> origin links. Note that even during a clone, commits pointed to by
>> origin links are not being transmitted (unless there already are other
>> reasons to send them along).
>IOW, it's not actually transferring them and saving them, since a simple
Correct.
>delete of the origin branch will basically make them unreachable.
False.
If you fetch just branches A, B and C, but not D, the origin link from A
to D is dangling. Once you have fetched D as well, the origin link from
A to D is not dangling anymore. Subsequently deleting branch D but
keeping branch A will keep everything in branch D up till the commits
the origin link is pointing to alive and prevent those from being
deleted.
>Fine. At least it works the same way as fetch, then. But it's still a huge
>mistake, because it really does mean that it is technically no different
>at all to just mentioning the SHA1 in the commit message, the way we
>already do for backports.
Not quite.
>The "origin" link has no _meaning_ for git, in other words.
Git will keep alive commits based on origin links once you (the fetcher)
has shown interest by fetching the appropriate branches.
As to "meaning" for git, it's there in the form of:
- --topo-order uses the information to order the output (but only if the
target commits of the link are present in the repository).
>> >No it's not. You can mention the backport explicitly in the commit
>> >message, and then you get hyperlinks in the graphical viewers. That works
>> >when people _want_ it to work, instead of in some hidden automatic manner
>> >that does entirely the wrong thing in all the common cases.
>> Could you spell out one of the common cases where it would do entirely
>> the wrong thing?
>It carries along information that is worthless and meaningless and hidden.
The common cases would be:
a. "hidden": It doesn't need to be hidden. It can be hidden if you want it
to be. We can decide if git hides it sometimes, always or never.
So this point is moot.
b. "meaningless": Git is all about taking snapshots of sourcetrees and
linking them in an orderly fashion. The origin link is all about
taking snapshots of patches and linking them in an orderly fashion.
This allows you to see the patch evolve over time, and it allows for
diffs between patches. We're not actually storing patches, we merely
store snapshots. As it happens, the snapshot of a patch is defined
by two commit hashes.
Doesn't sound meaningless to me. Just as one needs normal history
between commits in a branch to follow development, there is a history
of a backport as it "travels" from stable branch to stable branch.
c. "worthless": Without the tracking of a backport through a series of
well-defined patch-snapshots, it becomes kind of haphazard to
actually figure out which piece of code came from where. Having this
information in the form of a series of origin links increases the
efficiency of a developer maintaining the backports between branches.
Maybe you consider that worthless, I consider anything that improves
code quality because having access to a concise history of how the
code evolved a Good Thing. Having history of how code evolved is
actually one of the main reasons why people use git. It's just that
git lacks support in the tracking of backports. The origin link
fills that gap. If you don't do backports in your trees, then fine,
the origin link will never materialise in your repositories.
>I refuse to touch such an obviously braindamaged design. It has no sane
>_semantics_. If it doesn't have semantics, it shouldn't exist, certainly
>not as some architected feature.
It does have sane semantics, quite well defined, actually. I'm just not
good at explaining them apparently. Try reading the explanation I gave
above.
>Nobody has shown any actual sane meaning for it. The only ones that have
>been mentioned have been for things like avoiding re-picking commits
>during a "git rebase", but (a) the patch SHA1 does that already for things
>that are truly identical an (b) since that information isn't reliable
>_anyway_, and since it's apparently a user choice, it's just "random".
Quite frankly I don't see the application for rebase either (yet).
I'm focusing on sane semantics first, any implications that has for
usability by rebase will follow from that. The origin links track
content (patches), nothing else. They assist the developer in
understanding how patches evolve, any use cases follow from that.
>I'm sorry, but "good design" is a hell of a lot more important than some
>made-up use case that isn't even reliable, and doesn't match any actual
>real problems that anybody can explain.
Please focus on the semantics and on the *non*-made up use case of
development of several stable branches with backports between them.
Discussing made-up use cases is wasting energy at this point.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: RFC: perhaps a
From: Eric Raible @ 2008-09-11 6:15 UTC (permalink / raw)
To: git
In-Reply-To: <eafc0afe0809102305u6de85ef3ib2c08004dea8d6f9@mail.gmail.com>
Changsheng Jiang <jiangzuoyan <at> gmail.com> writes:
>
> I don't know what version of you git, my git with version 1.5.4.5
> doesn't delete the file file42 after git-reset.
All examples from me are version 1.6.0.1.436.g09e16c.dirty or later.
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Mike Hommey @ 2008-09-11 6:14 UTC (permalink / raw)
To: Eric Raible; +Cc: Git Mailing List
In-Reply-To: <279b37b20809101212g57e9ad99qbf6fa15888679894@mail.gmail.com>
On Wed, Sep 10, 2008 at 12:12:21PM -0700, Eric Raible wrote:
> In http://marc.theaimsgroup.com/?l=git&m=114917892328066
> (references by http://git.or.cz/gitwiki/GitFaq), Linus says:
>
> 'And "git reset" won't be deleting files it doesn't track (it had _better_
> not touch them), even more so when it has been told to ignore them, so it
> makes total sense to _not_ delete them when doing that reset.'
>
> Now consider this example:
>
> # Create a single commit in a new repo (so that we have a HEAD)
> mkdir xx
> cd xx
> git init
> git commit --allow-empty -m"initial"
> # Add an important file
> echo "Important stuff" > file42
> git add file42
> git status # -> new file: file42
> ls # -> file42, or course
> git reset --hard
> ls # -> nothing
>
> I would argue that as a "new file" (as reported by git status)
> that file42 was never actually tracked by git. Sure, it _would_
> have been tracked in the future, but git never actually tracked it
> (it's not part of any commits).
>
> So in this scenario wouldn't it make more sense for
> "git reset --hard" to handle file42 as "git reset" does
> instead of deleting it w/out a trace [1]?
>
> The same question goes for "git checkout -f", too, I suppose.
>
> I actually accidentally deleted hundred of newly added files yesterday
> doing just this. https://mozy.com/?code=V3D4MM) saved my butt,
> but it wasn't pleasant.
>
> - Eric
>
> [1] - There's not even a reflog entry. Sure, "git fsck" can be
> used, but that's hardly a friendly fallback.
Note that reflog only contains references to commit sha1s, so it can't
track index status. An index log could be interesting, though, but it
would need to expire much faster than reflog.
Mike
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Changsheng Jiang @ 2008-09-11 6:05 UTC (permalink / raw)
To: Eric Raible; +Cc: Git Mailing List
In-Reply-To: <279b37b20809101946k309ad113neb7d051f1c6c410e@mail.gmail.com>
I don't know what version of you git, my git with version 1.5.4.5
doesn't delete the file file42 after git-reset.
BTW, if you added the file42 to .gitignore, why git-status still
reported "new file" file42"?
Yours sincerely,
Changsheng Jiang
pubkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x40C37374
On Thu, Sep 11, 2008 at 10:46, Eric Raible <raible@gmail.com> wrote:
> On Wed, Sep 10, 2008 at 7:12 PM, Changsheng Jiang <jiangzuoyan@gmail.com> wrote:
>> I think the current behavior is better than you described. If you want to
>> ignore some files, you can added it to the exclude file. All files not
>> excluded in the repo directory is maintained by git.
>
> That doesn't really address the problem. This is an
> updated example that specifically ignores the file:
>
> # Create a single commit in a new repo (so that we have a HEAD)
> mkdir xx
> cd xx
> git init
> git commit --allow-empty -m"initial"
> # Add an important file
> echo "Important stuff" > file42
> git add file42
> echo file42 > .gitignore
> git status # -> new file: file42
> ls # -> file42, or course
> git reset --hard
> ls # -> nothing
>
> So not only was file42 never actually tracked by git
> (IMHO - I realize that this is debatable) but it was also
> specifically ignored, and it is _still_ deleted w/out a trace!
>
> I realize that "git reset" will simply unstage the new file
> in either case (w or w/out .gitignore), but the consequences
> of an accidental "git reset --hard" are pretty severe in this
> case. This behavior seems definitely contrary to Linus's
> explanation:
>
> And "git reset" won't be deleting files it doesn't track (it had _better_
> not touch them), even more so when it has been told to ignore them, so it
> makes total sense to _not_ delete them when doing that reset.
>
> - Eric
>
^ permalink raw reply
* Re: git svn segfaults in _Delta.so
From: Mike Hommey @ 2008-09-10 19:03 UTC (permalink / raw)
To: Thomas Harning; +Cc: git
In-Reply-To: <9B7A97D1-7175-4FCC-94CB-21EBE12E4F88@gmail.com>
On Wed, Sep 10, 2008 at 02:40:31PM -0400, Thomas Harning wrote:
> On Sep 10, 2008, at 2:21 PM, Thomas Harning wrote:
>
>> I just recently setup a new system and installed subversion 1.5.1 and
>> the latest git from head.
>>
>> On an existing repository (copied from the same system but slightly
>> older software) running git svn rebase will cause it to segfault in
>> _Delta.so (part of subversion's perl libraries).... even when there is
>> nothing to do... it even seems to successfully do all the operations.
>> I've built subversion and git with debugging enabled and cannot get any
>> useful stack-trace. the stacktrace is:
>>
>> #0 0x00007fbed7edd3a0 in ?? ()
>> #1 0x00007fbed99fa75d in ?? ()
>> #2 0x0000000000000001 in ?? ()
>> #3 0x00007fbed99fb217 in ?? ()
>> #4 0x00007fbed99e82d8 in ?? ()
>> #5 0x0000000000000001 in ?? ()
>> #6 0x000000000070e250 in cwd.17580 ()
>> #7 0x000000000070d7f8 in buffer.17586 ()
>> #8 0x0000000000f7f408 in ?? ()
>> #9 0x00007fbed99fb205 in ?? ()
>> #10 0x0000000000000000 in ?? ()
>>
>>
>> The only way I know that it is _Delta.so is that in 'dmesg' i get:
>> git-svn[1277]: segfault at 7f64fa7213a0 ip 7f64fa7213a0 sp
>> 7fff07a9a2b8 error 14 in _Delta.so[7f64fa92c000+22000]
>>
>> In another machine w/ very similar software (slightly older by a month
>> or so) I do not see these segfaults. However it is running svn 1.4.6
>> .. so it might be svn versions... will report on status after
>> downgrade
> svn 1.4.6 does not suffer the segfaults...
I would suggest you to try some other stuff that uses the svn perl
library (svk, for example). My guess is that it will crash similarly.
Mike
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Paolo Bonzini @ 2008-09-11 5:16 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jeff King, Theodore Tso, Petr Baudis, git
In-Reply-To: <20080910231900.GF22739@cuci.nl>
>>> - The origin information is no longer cryptographically protected (under
>>> certain circumstances this could be considered an advantage and a
>>> disadvantage at the same time).
>
>> I haven't thought enough about it to decide whether there is a scenario
>> where making such a "cherry-picked from" annotation might make use of
>> that property.
>
> Being able to subvert the authenticity of git blame by providing fake
> origin information is not very appealing.
You could use a dummy submodule to ensure that each commit pointed to
the right set of notes. It would force to create a separate commit
whenever you modified the notes, which is actually not bad.
Alternatively, the header of the commit can be modified to add a pointer
to a tree object for the notes; I suppose this is more palatable than
the origin link. The tree could be organized in directories+blobs like
.git/objects to speed up the lookup.
I actually like the commit notes idea, but then I wonder: why are the
author and committer part of the commit object? How does the plumbing
use them? Isn't that metadata that could live in the "notes"? And so,
why should the origin link have less privileges?
Paolo
^ permalink raw reply
* Re: PATCH: git-p4 optional handling of RCS keywords
From: dhruva @ 2008-09-11 4:06 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Junio C Hamano, GIT SCM, Jing Xue
Hello,
Commit message: Modifying RCS keywords prevents submitting to p4 from git due to missing hunks. Optional shrinking of RCS keywords in git-p4. New option git-p4.kwstrip set to true or false controls the behavior..
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 2216cac..ac8b7f7 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -16,6 +16,9 @@ from sets import Set;
verbose = False
+# Handling of RCS keyowrds. To ensure backward compatibility, the default
+# is to strip keywords. Default behavior is controlled here
+kwstrip = True
def p4_build_cmd(cmd):
"""Build a suitable p4 command line.
@@ -975,7 +978,9 @@ class P4Sync(Command):
sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
continue
- if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
+ if not kwstrip:
+ pass
+ elif stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
@@ -1850,6 +1855,16 @@ def main():
(cmd, args) = parser.parse_args(sys.argv[2:], cmd);
global verbose
verbose = cmd.verbose
+
+ global kwstrip
+ kwval = gitConfig("git-p4.kwstrip")
+ if len(kwval) > 0:
+ kwval = kwval.lower();
+ if kwval == "false":
+ kwstrip = False
+ elif kwval == "true":
+ kwstrip = True
+
if cmd.needsGit:
if cmd.gitdir == None:
cmd.gitdir = os..path.abspath(".git")
-dhruva
----- Original Message ----
> From: Simon Hausmann <simon@lst.de>
> > + kwval = kwval.lower();
> > + if "false" == kwval:
> > + kwstrip = False
> > + elif "true" == kwval:
> > + kwstrip = True
>
> I have another style nitpick, sorry :). Please use "kwval == "false" instead
> of the other way around.
There was a reason for keeping the constant as lvalue to avoid typos like '=' instead from '==' from 'C' school, I realize that python throws an error when such things happen. Must say that programming languages are becoming smarter and taking away the charm of programming...
> Otherwise your patch looks good to me, I think it's a very good option to add.
> Please resend with commit message so that Junio can include it.
Add more friends to your messenger and enjoy! Go to http://in.messenger.yahoo.com/invite/
^ permalink raw reply related
* What's cooking in git.git (Sep 2008, #02; Wed, 10)
From: Junio C Hamano @ 2008-09-11 3:49 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
Many 'maint' material to go through the usual 'next' to 'master' to
'maint' cycle..
* mh/maint-honor-no-ssl-verify (Thu Feb 21 15:10:37 2008 -0800) 1 commit
+ Don't verify host name in SSL certs when GIT_SSL_NO_VERIFY is set
* dp/maint-rebase-fix (Tue Sep 9 16:05:26 2008 +0400) 2 commits
+ git-rebase--interactive: auto amend only edited commit
+ git-rebase-interactive: do not squash commits on abort
* jc/maint-checkout-keep-remove (Sun Sep 7 19:49:25 2008 -0700) 1 commit
+ checkout: do not lose staged removal
* jc/maint-template-permbits (Thu Aug 21 19:31:50 2008 -0500) 1 commit
+ Fix permission bits on sources checked out with an overtight umask
* am/status (Mon Sep 8 00:05:03 2008 +0200) 2 commits
- wt-status: Teach how to discard changes in the working directory
- wt-status: Split header generation into three functions
This is what I commented as "making status output even chattier", but
parked here to see what people think.
* mv/commit-tree (Wed Sep 10 22:10:33 2008 +0200) 3 commits
- t7603: add new testcases to ensure builtin-commit uses
reduce_heads()
- builtin-commit: use commit_tree()
- commit_tree(): add a new author parameter
* pb/autocorrect-wrapper (Wed Sep 10 14:44:20 2008 -0700) 2 commits
- Fixup -- waiting for response
- git wrapper: also uses aliases to suggest mistyped commands
* jc/alternate-push (Tue Sep 9 01:27:10 2008 -0700) 4 commits
- push: receiver end advertises refs from alternate repositories
- push: prepare sender to receive extended ref information from the
receiver
- receive-pack: make it a builtin
- is_directory(): a generic helper function
----------------------------------------------------------------
[Graduated to "master"]
* jc/hide-cr-in-diff-from-less (Wed Aug 27 19:48:01 2008 -0700) 1 commit
+ diff: Help "less" hide ^M from the output
* jc/maint-checkout-fix (Fri Aug 29 13:40:36 2008 -0700) 1 commit
+ checkout: do not check out unmerged higher stages randomly
This is the same one as the bottom of "better conflict resolution" series.
* jc/cc-ld-dynpath (Sat Aug 16 15:01:23 2008 +0200) 2 commits
+ configure: auto detect dynamic library path switches
+ Makefile: Allow CC_LD_DYNPATH to be overriden
I decided to push this forward; it might break minority configurations,
but it appears nobody pays attention until it actually hurts, so let's see
what happens when this hits 'master'.
* ar/autospell (Sun Aug 31 15:54:58 2008 +0200) 2 commits
+ Add help.autocorrect to enable/disable autocorrecting
+ git wrapper: DWIM mistyped commands
----------------------------------------------------------------
[Stalled -- Needs Action to Proceed (or to be dropped)]
* bd/blame (Thu Aug 21 18:22:01 2008 -0500) 5 commits
- Use xdiff caching to improve git blame performance
- Allow xdiff machinery to cache hash results for a file
- Always initialize xpparam_t to 0
- Bypass textual patch generation and parsing in git blame
- Allow alternate "low-level" emit function from xdl_diff
Réne had good comments on how the callback should be structured.
* kb/am-directory (Fri Aug 29 15:27:50 2008 -0700) 1 commit
- git-am: Pass the --directory option through to git-apply
I think this is still buggy and drops the option when am stops with
conflicts.
* dk/emacs (Tue Aug 26 22:24:40 2008 -0500) 2 commits
- Teach git.el to mark/unmark files by regexp
- git.el: Diff only file at point by default
These are still queued but Alexandre had improvement requests so these
will likely be dropped.
----------------------------------------------------------------
[Will be merged to "master" soon]
* np/pack (Tue Sep 2 10:22:22 2008 -0400) 4 commits
+ t5300: improve SHA1 collision test
+ pack-objects: don't include missing preferred base objects
+ sha1write: don't copy full sized buffers
+ Merge branch 'np/maint-safer-pack' into np/pack
* bw/shortref (Fri Sep 5 23:16:23 2008 +0200) 1 commit
+ for-each-ref: `:short` format for `refname`
* rs/decorate (Thu Sep 4 23:40:03 2008 +0200) 3 commits
+ add '%d' pretty format specifier to show decoration
+ move load_ref_decorations() to log-tree.c and export it
+ log: add load_ref_decorations()
* tr/rev-list-reverse (Mon Sep 1 00:31:37 2008 +0200) 2 commits
+ t6013: replace use of 'tac' with equivalent Perl
+ rev-list: fix --reverse interaction with --parents
* cc/bisect (Sat Sep 6 07:27:03 2008 +0200) 3 commits
+ bisect: remove "checkout_done" variable used when checking merge
bases
+ bisect: only check merge bases when needed
+ bisect: test merge base if good rev is not an ancestor of bad rev
* jc/setlinebuf-setvbuf (Wed Sep 3 20:33:29 2008 -0700) 1 commit
+ daemon.c: avoid setlinebuf()
* jc/maint-diff-quiet (Mon Sep 1 23:20:26 2008 -0700) 2 commits
+ diff --quiet: make it synonym to --exit-code >/dev/null
+ diff Porcelain: do not disable auto index refreshing on -C -C
----------------------------------------------------------------
[Actively Cooking]
* ho/dirstat-by-file (Fri Sep 5 22:27:35 2008 +0300) 1 commit
+ diff --dirstat-by-file: count changed files, not lines
* jc/safe-c-l-d (Tue Sep 2 14:10:15 2008 -0700) 1 commit
+ safe_create_leading_directories(): make it about "leading"
directories
* jc/apply-include-exclude (Mon Aug 25 01:05:31 2008 -0700) 1 commit
- git-apply:--include=pathspec
* pb/commit-where (Mon Sep 8 01:05:41 2008 +0200) 1 commit
+ builtin-commit.c: show on which branch a commit was added
* jc/better-conflict-resolution (Thu Sep 4 23:48:48 2008 +0200) 15 commits
+ Fix AsciiDoc errors in merge documentation
+ git-merge documentation: describe how conflict is presented
+ checkout --conflict=<style>: recreate merge in a non-default style
+ checkout -m: recreate merge when checking out of unmerged index
+ Merge branch 'jc/maint-checkout-fix' into 'jc/better-conflict-
resolution'
+ git-merge-recursive: learn to honor merge.conflictstyle
+ merge.conflictstyle: choose between "merge" and "diff3 -m" styles
+ rerere: understand "diff3 -m" style conflicts with the original
+ rerere.c: use symbolic constants to keep track of parsing states
+ xmerge.c: "diff3 -m" style clips merge reduction level to EAGER or
less
+ xmerge.c: minimum readability fixups
+ xdiff-merge: optionally show conflicts in "diff3 -m" style
+ xdl_fill_merge_buffer(): separate out a too deeply nested function
+ checkout --ours/--theirs: allow checking out one side of a
conflicting merge
+ checkout -f: allow ignoring unmerged paths when checking out of
the index
* lt/time-reject-fractional-seconds (Sat Aug 16 21:25:40 2008 -0700) 1 commit
+ date/time: do not get confused by fractional seconds
* jc/maint-name-hash-clear (Sat Aug 23 13:05:10 2008 -0700) 1 commit
+ discard_cache: reset lazy name_hash bit
I spotted this by accident while working on something unrelated.
When a program calls discard_cache() to read the index again, we do not
properly re-initialize the name_hash structure that is used by the case
insensitivitly logic. This _might_ improve issues people may be having on
case insensitive filesystems. I dunno.
* jc/add-ita (Thu Aug 21 01:44:53 2008 -0700) 1 commit
+ git-add --intent-to-add (-N)
Teaches "git add" to record only the intent to add a path later.
I rerolled this without the fake empty blob object.
* mv/merge-recursive (Sat Sep 6 18:29:49 2008 +0200) 11 commits
+ builtin-merge: release the lockfile in try_merge_strategy()
+ merge-recursive: get rid of virtual_id
+ merge-recursive: move current_{file,directory}_set to struct
merge_options
+ merge-recursive: move the global obuf to struct merge_options
+ merge-recursive: get rid of the index_only global variable
+ merge-recursive: move call_depth to struct merge_options
+ cherry-pick/revert: make direct internal call to merge_tree()
+ builtin-merge: avoid run_command_v_opt() for recursive and subtree
+ merge-recursive: introduce merge_options
+ merge-recursive.c: Add more generic merge_recursive_generic()
+ Split out merge_recursive() to merge-recursive.c
* jc/diff-prefix (Mon Aug 18 20:08:09 2008 -0700) 1 commit
+ diff: vary default prefix depending on what are compared
As some people may have noticed, I've been running with this one when
sending out "How about this" patches to the discussion threads.
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
- revision --simplify-merges: incremental simplification
- revision --simplify-merges: prepare for incremental simplification
I started making this incremental but the progress is not so great.
----------------------------------------------------------------
[On Hold]
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
- git-am --forge: add Signed-off-by: line for the author
- git-am: clean-up Signed-off-by: lines
- stripspace: add --log-clean option to clean up signed-off-by:
lines
- stripspace: use parse_options()
- Add "git am -s" test
- git-am: refactor code to add signed-off-by line for the committer
The one at second from the tip needs reworking.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
* jc/merge-whitespace (Sun Feb 24 23:29:36 2008 -0800) 1 commit
- WIP: start teaching the --whitespace=fix to merge machinery
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet. Perhaps
in 1.7.0, but with the loud whining about moving git-foo out of $PATH we
have been hearing, it might not be a bad idea to drop this.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
^ permalink raw reply
* What's in git.git (Sep 2008, #02; Wed, 10)
From: Junio C Hamano @ 2008-09-11 3:49 UTC (permalink / raw)
To: git
There are still a few topics that are meant for 'maint' cooking in higher
stages; we will have 1.6.0.2 after they are merged down.
On the 'master' front, it looks like 1.6.1 will not have anything
particularly big like 1.6.0 did. Other than many s/git-foo/git foo/
updates in tests (finished -- the documentation needs to go through the
same process), there are many small bells and whistles enhancements, but
nothing earth shattering. I am expecting that we will go into 1.6.1-rc0
freeze in two weeks.
* The 'maint' branch has these fixes since the last announcement.
Arjen Laarhoven (1):
Use compatibility regex library for OSX/Darwin
Junio C Hamano (4):
checkout: do not check out unmerged higher stages randomly
diff: Help "less" hide ^M from the output
log --author/--committer: really match only with name part
Update draft release notes for 1.6.0.2
Marcus Griep (2):
Git.pm: Use File::Temp->tempfile instead of ->new
git-svn: Fixes my() parameter list syntax error in pre-5.8 Perl
Miklos Vajna (1):
t7501: always use test_cmp instead of diff
Nicolas Pitre (5):
pack-objects: improve returned information from write_one()
improve reliability of fixup_pack_header_footer()
pack-objects: use fixup_pack_header_footer()'s validation mode
index-pack: use fixup_pack_header_footer()'s validation mode
fixup_pack_header_footer(): use nicely aligned buffer sizes
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Add help.autocorrect to enable/disable autocorrecting
Andreas Ericsson (1):
Teach "git diff -p" to locate PHP class methods
Arjen Laarhoven (1):
t6023-merge-file: Work around non-portable sed usage
Christian Couder (1):
refs: improve comments about "reading" argument of "resolve_ref"
Dotan Barak (1):
Use xmalloc() and friends to catch allocation failures
Eric Wong (1):
git-svn: fix handling of even funkier branch names
Giovanni Funchal (1):
configure: auto detect dynamic library path switches
Heikki Orsila (1):
Start conforming code to "git subcmd" style part 2
Johannes Schindelin (1):
git wrapper: DWIM mistyped commands
Johannes Sixt (1):
Windows: git-shell can be compiled again
Junio C Hamano (2):
Makefile: Allow CC_LD_DYNPATH to be overriden
Fix git-diff-tree --stdin
Michael J Gruber (2):
allow installation of man and html doc from the man and html branches
separate build targets for man and html documentation
Mikael Magnusson (1):
Correct output of git-count-objects.
Nanako Shiraishi (8):
t/t91XX-svn: start removing use of "git-" from these tests
t/t91XX git-svn tests: run "git svn" not "git-svn"
t9200: use "git cvsexportcommit" without dash
t9300, t9301: use "git fast-import/fast-export" without dash
t9700: use "git config" without dash
tests: use "git foo" without dash in strings
t9101: use "git hash-object" without dash
Install git-cvsserver in $(bindir)
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Eric Raible @ 2008-09-11 2:46 UTC (permalink / raw)
To: Changsheng Jiang; +Cc: Git Mailing List
In-Reply-To: <eafc0afe0809101912v72916d3hce9ae5d6812f0db8@mail.gmail.com>
On Wed, Sep 10, 2008 at 7:12 PM, Changsheng Jiang <jiangzuoyan@gmail.com> wrote:
> I think the current behavior is better than you described. If you want to
> ignore some files, you can added it to the exclude file. All files not
> excluded in the repo directory is maintained by git.
That doesn't really address the problem. This is an
updated example that specifically ignores the file:
# Create a single commit in a new repo (so that we have a HEAD)
mkdir xx
cd xx
git init
git commit --allow-empty -m"initial"
# Add an important file
echo "Important stuff" > file42
git add file42
echo file42 > .gitignore
git status # -> new file: file42
ls # -> file42, or course
git reset --hard
ls # -> nothing
So not only was file42 never actually tracked by git
(IMHO - I realize that this is debatable) but it was also
specifically ignored, and it is _still_ deleted w/out a trace!
I realize that "git reset" will simply unstage the new file
in either case (w or w/out .gitignore), but the consequences
of an accidental "git reset --hard" are pretty severe in this
case. This behavior seems definitely contrary to Linus's
explanation:
And "git reset" won't be deleting files it doesn't track (it had _better_
not touch them), even more so when it has been told to ignore them, so it
makes total sense to _not_ delete them when doing that reset.
- Eric
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Nicolas Pitre @ 2008-09-11 2:46 UTC (permalink / raw)
To: Jeff King; +Cc: Stephen R. van den Berg, Theodore Tso, Petr Baudis, git
In-Reply-To: <20080910225518.GA24534@coredump.intra.peff.net>
On Wed, 10 Sep 2008, Jeff King wrote:
> On Thu, Sep 11, 2008 at 12:34:27AM +0200, Stephen R. van den Berg wrote:
>
> > I see. Indeed. That's a lot better.
> > Did the binary search inside tree objects ever get implemented?
>
> I believe it's still linear (and skimming tree-walk.c:find_tree_entry
> seems to confirm). However, one advantage of such an approach is that it
> will improve as tree lookup improves (e.g., I believe the pack v4 work
> included improvements in this area).
No, not yet. Actually that's the part that still needs serious
thinking.
Nicolas
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Elijah Newren @ 2008-09-11 2:38 UTC (permalink / raw)
To: Changsheng Jiang; +Cc: Eric Raible, Git Mailing List
In-Reply-To: <eafc0afe0809101914lff5b23ehaf625d702fbd9b5d@mail.gmail.com>
On Wed, Sep 10, 2008 at 8:14 PM, Changsheng Jiang <jiangzuoyan@gmail.com> wrote:
> I think the current behavior is better than you described. If you want
> to ignore some files, you can added it to the exclude file. All files
> not excluded in the repo directory is maintained by git.
No, there's a limbo state -- the "untracked" files shown by git status
(which is the default state; these are files that have not been
explicitly requested to be ignored or be tracked). Note the quote
from Linus at the beginning of Eric's email that specifically
references this.
Anyway, Eric wasn't really talking about ignoring files, since he was
explicitly adding them for the next commit. It's just that at some
point he changed his mind and decided he didn't want to include any of
the changes he had already made in the next commit, but was surprised
when git reset --hard deleted the files from both the index and
working copy instead of just the index. git reset --hard really is
meant for throwing away unwanted stuff (particularly including in the
working directory), but I can see how he may have expected behavior
more along the lines of git rm --cached for those particular files. I
don't agree with that viewpoint (I see files as tracked as soon as you
stage it, not once you commit it), but I can see where the expectation
comes from.
Just my thoughts,
Elijah
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Changsheng Jiang @ 2008-09-11 2:14 UTC (permalink / raw)
To: Eric Raible; +Cc: Git Mailing List
In-Reply-To: <eafc0afe0809101912v72916d3hce9ae5d6812f0db8@mail.gmail.com>
I think the current behavior is better than you described. If you want
to ignore some files, you can added it to the exclude file. All files
not excluded in the repo directory is maintained by git.
^ permalink raw reply
* git commands for 3rd-party commit/update hooks
From: Pavel Sanda @ 2008-09-11 1:22 UTC (permalink / raw)
To: git
hi,
please can you help me to figure out, whether the following task can
be accomplished by git?
imagine that:
1. user configures rcs in two different modes:
a) working in private
b) sharing work via some public repo
2. after configuration all rcs communication goes through some 3rd
party tool which API knows only commit and update(/merge) hooks.
all docs on git i have seen divide the workflow into the local part
eg. git commit and the sharing part eg. git pull/push.
is it somehow doable with git that after appropriate setup i will
get single git command for each commiting/updating operation
regardless of 1a or 1b scenario? something which can be stuffed
into that 3rd-party as external commands for rcs commit/update while
keeping it oblivious whether the work is stored locally or on some
remote place.
thanks,
pavel
^ permalink raw reply
* [PATCH] completion: git commit should list --interactive
From: Eric Raible @ 2008-09-11 0:40 UTC (permalink / raw)
To: spearce, Git Mailing List
Signed-off-by: Eric Raible <raible@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index d3fb6ae..2d8d1c3 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -750,7 +750,7 @@ _git_commit ()
--*)
__gitcomp "
--all --author= --signoff --verify --no-verify
- --edit --amend --include --only
+ --edit --amend --include --only --interactive
"
return
esac
--
1.6.0.1.436.g09e16c.dirty
^ permalink raw reply related
* Re: [RFC] origin link for cherry-pick and revert
From: Linus Torvalds @ 2008-09-11 0:39 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jakub Narebski, git
In-Reply-To: <20080910230906.GD22739@cuci.nl>
On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>
> - However, if you explicitly pull D, the origin information from A to D can
> be used. People doing a generic clone get all four branches, and
> therefore have all the important commits which normally could contain
> origin links. Note that even during a clone, commits pointed to by
> origin links are not being transmitted (unless there already are other
> reasons to send them along).
IOW, it's not actually transferring them and saving them, since a simple
delete of the origin branch will basically make them unreachable.
Fine. At least it works the same way as fetch, then. But it's still a huge
mistake, because it really does mean that it is technically no different
at all to just mentioning the SHA1 in the commit message, the way we
already do for backports.
The "origin" link has no _meaning_ for git, in other words.
> >No it's not. You can mention the backport explicitly in the commit
> >message, and then you get hyperlinks in the graphical viewers. That works
> >when people _want_ it to work, instead of in some hidden automatic manner
> >that does entirely the wrong thing in all the common cases.
>
> Could you spell out one of the common cases where it would do entirely
> the wrong thing?
It carries along information that is worthless and meaningless and hidden.
I refuse to touch such an obviously braindamaged design. It has no sane
_semantics_. If it doesn't have semantics, it shouldn't exist, certainly
not as some architected feature.
Nobody has shown any actual sane meaning for it. The only ones that have
been mentioned have been for things like avoiding re-picking commits
during a "git rebase", but (a) the patch SHA1 does that already for things
that are truly identical an (b) since that information isn't reliable
_anyway_, and since it's apparently a user choice, it's just "random".
I'm sorry, but "good design" is a hell of a lot more important than some
made-up use case that isn't even reliable, and doesn't match any actual
real problems that anybody can explain.
Linus
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-10 23:19 UTC (permalink / raw)
To: Jeff King; +Cc: Theodore Tso, Petr Baudis, git
In-Reply-To: <20080910225518.GA24534@coredump.intra.peff.net>
Jeff King wrote:
>On Thu, Sep 11, 2008 at 12:34:27AM +0200, Stephen R. van den Berg wrote:
>> - The origin information is no longer cryptographically protected (under
>> certain circumstances this could be considered an advantage and a
>> disadvantage at the same time).
>I haven't thought enough about it to decide whether there is a scenario
>where making such a "cherry-picked from" annotation might make use of
>that property.
Being able to subvert the authenticity of git blame by providing fake
origin information is not very appealing.
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-10 23:15 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Linus Torvalds, Jakub Narebski, git
In-Reply-To: <48C7EE71.8080305@gnu.org>
Paolo Bonzini wrote:
>> Btw, so far nobody has even _explained_ what the advantage of the origin
>> link is. It apparently has no effect for most things, and for other things
>> it has some (unspecified) effect when it can be resolved.
>> Apart from the "dotted line" in graphical history viewers, I haven't
>> actually heard any single concrete example of exactly what it would *do*.
It allows one to follow and view the evolvement of a patch over time during
the various backports.
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-10 23:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809100828360.3384@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>On Wed, 10 Sep 2008, Stephen R. van den Berg wrote:
>> But then how would someone who clones the repository get at the information?
>You just said it wouldn't get there with fetches.
True and still valid.
>If clone acts differently from a "full" fetch, something is really really
>wrong.
It does not act differently.
Let me elaborate:
- The origin field is part of the commit (and only present if
*consciously* added by the committer), and therefore is transmitted
along with the rest of a commit upon a fetch.
- The commits being referred to by the origin field are *not*
transmitted upon a fetch.
- Given a repository with 4 long lived published branches called A, B, C and D
and a backport from development branch D cherry-picked -o into branch A
which creates an origin field pointing back to (D^,D^^)
- Now you fetch just branch A from this repository. This will not cause
branch D to be pulled in as well.
- However, if you explicitly pull D, the origin information from A to D can
be used. People doing a generic clone get all four branches, and
therefore have all the important commits which normally could contain
origin links. Note that even during a clone, commits pointed to by
origin links are not being transmitted (unless there already are other
reasons to send them along).
>> The information is essential to understand backports between the various
>> stable branches.
>No it's not. You can mention the backport explicitly in the commit
>message, and then you get hyperlinks in the graphical viewers. That works
>when people _want_ it to work, instead of in some hidden automatic manner
>that does entirely the wrong thing in all the common cases.
Could you spell out one of the common cases where it would do entirely
the wrong thing?
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jeff King @ 2008-09-10 22:55 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Theodore Tso, Petr Baudis, git
In-Reply-To: <20080910223427.GB22739@cuci.nl>
On Thu, Sep 11, 2008 at 12:34:27AM +0200, Stephen R. van den Berg wrote:
> I see. Indeed. That's a lot better.
> Did the binary search inside tree objects ever get implemented?
I believe it's still linear (and skimming tree-walk.c:find_tree_entry
seems to confirm). However, one advantage of such an approach is that it
will improve as tree lookup improves (e.g., I believe the pack v4 work
included improvements in this area).
> The downsides when doing that are:
> - The lookup cost is small, but still noticable, since it is sometimes
> done on every commit; using the in-commit origin headerfield solves
> this at negligible cost.
> - The origin information is no longer cryptographically protected (under
> certain circumstances this could be considered an advantage and a
> disadvantage at the same time).
Yes, those are inherent in the scheme, as is the upside that one can
make and distribute such annotations separately from commit creation.
I haven't thought enough about it to decide whether there is a scenario
where making such a "cherry-picked from" annotation might make use of
that property.
-Peff
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-10 22:44 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Petr Baudis, Theodore Tso, git
In-Reply-To: <48C80ADC.60207@gnu.org>
Petr wrote:
>> However, having a commit -> nonessential_volatile_metadata database
>> would be useful for many other things as well!
Which brings us back to the "commit notes" proposal.
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
^ 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