Hmm. The logic introduced by the blamed commit makes the --index-info unreliable (I'd rather see it fail reliably if it does not have enough information rather than pretending everything is Ok), and I think the patch makes it slightly more so. If new_name that is not related at all to old_name happens to exist in the current tree you are applying the patch to, you can grab the contents of the unrelated file as the preimage and try to merge the changes in. When running --index-info for the pu...

With diff.renames = copies, a 3-way merge (e.g. "git rebase") with a file move would fail with the following error: fatal: mode change for <file>, which is not in current HEAD Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001. The bug is a logic error added in ece7b749, which attempts to find an sha1 for a patch with no index line in build_fake_ancestor(). Instead of failing unless an sha1 is found for bo...

This message was addressed to me, but is it meant for inclusion? I do not recall seeing an agreement on what the desired behaviour should be from (ex-)Cogito users, if this change of behaviour hurts real world usage of existing git users, andr if so how we ease this change in to the release. While I'd personally agree matching with whatever cg-push used to do might make the most sense in the end, I am not sure changing of behaviour abruptly like this is a good idea. I am also not so sure url...

It is a feature misfiring. Rebase is essentially a repeated cherry-pick, and a cherry-pick of commit A on top of commit B is done by a simplified 3-way merge between A and B using the parent of A as the common ancestor. A A' / / A^... pseudo history ...---B When your history has renamed Makefile to Makefile2 (thereby losing Makefile) while transition from A^ to A modified Makefile, the difference between A^ to A that is applied t...

Simplified one is not _smarter_. It is merely _faster_, exactly because it only looks at the paths between A^..A and nothing else. And that is why it cannot tell between the case where both A^ and A have Makefile2 or they both lack it. And that is exactly why application of this change on top of B is mistaken as a patch to a renamed path. From B's point of view: - Incoming change says "I changed Makefile from this shape to that shape", and nothing else; - B does not have Makefile, bu...

Thanks. Looked alright from a cursory reading. By the way, I've been meaning to suggest that we should straighten out the semantics of "unpacked" vs "incremental". What the latter means is quite clear. We are creating a new packfile to bundle loose ones into one, and after the new packfile is installed we can remove the loose objects. But what --unpacked means often confuses people, primarily because it is a performance heuristics that makes certain assumptions on how the objects are packe...

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- Documentation/git-remote.txt | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index 7b227b3..fad983e 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -66,6 +66,10 @@ was passed. Rename the remote named <old> to <new>. All remote tracking branches and configuration settings for the remote are updated. ...

Daniel Lowe wrote: Perhaps these should by changed to use fputs() instead. and these should use strlcpy. -brandon --

In xdiff-interface.c, the FIRST_FEW_BYTES macro is defined, is never used anwhere else, so we might as well undefine it after we're done with it. --- xdiff-interface.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/xdiff-interface.c b/xdiff-interface.c index e8ef46d..2cf30cd 100644 --- a/xdiff-interface.c +++ b/xdiff-interface.c @@ -226,6 +226,7 @@ int buffer_is_binary(const char *ptr, unsigned long size) size = FIRST_FEW_BYTES; return !!memch...

Hmwell, this is a twofold argument, I guess... * for: the macro is defined, not undefined: it means that potentially, it can be used somewhere else in the file; but it isn't (in this case); * against: macros defined in a C file only ever have scope in said file (unless so mischievous Makefile cats two C files together before compile and file order is important -- but git doesn't do that), so why #undefine anything? Personally, I'm with the first argument. YMMV, of course. -- fge -- ...

Well, in that case using `ident` attribute would be enough (but cryptic). # set `ident` attribute for all files $ echo '* ident' > .gitattributes # check that it is set for file 'foo' $ git check-attr ident -- foo foo: ident: set # edit file to contain '$Id$' keyword $ cat foo ... ... $Id$ ... ... # make a commit $ git commit -a # $Id$ keyword is replaced on checkout $ git add foo $ git checkout foo # and check that it got replaced $ cat foo ... ... $I...

Well, _some_ command has to be invoked to expand keywords. "git add" doesn't do that (perhaps it should?), so you need to use checkout. And checkout doesn't touch file if it is identical, so you need to remove it first; nevertheless you don't need to use commit in betwen, as "git checkout bar" would checkout file out of index (you added contents of file to index with "git add bar"). -- Jakub Narebski Poland --

If I remember correctly there was idea to add 'pre-add' or 'post-add' hook... -- Jakub Narebski Poland --

Just wondering, has there been any looking into whether the git-notes concept can track rebases? Reading over what git-notes is leads me to think it could be a good mechanism for the distributed bug-tracking idea I had some time ago. The only gotcha I see is that there would have to be some reverse mapping / fast lookup to track the commit objects that given notes are attached to.... and to facilitate individual assignment... notes applied to notes. Example structure: Commits A ...

Hi, I guess he means that you could have something like this rebased from <SHA-1> in the notes for any given commit, so that _if_ you have the commit, e.g. gitk could show that connection (maybe dashed in the graphical history display, and as a "Rebased from:" link). Ciao, Dscho --

You don't really need "notes" for that, though, since you can put that information into the commit message (or headers) if you choose. I guess it has the advantage of not polluting the commit for others. -Peff --

Does it make sense to teach "git rebase" the -x option from "git cherry-pick"? As with "git cherry-pick -x" it only makes sense to use it if your rebasing from a public branch. Have fun! ...Johan -- Johan Herland, <johan@herland.net> www.herland.net --

Sorry, I wasn't clear enough: I am talking about a copy-rebase, that is, the original public branch is unchanged, but you copy patches from it by making a local temporary branch that starts out in the same place and then rebasing it onto the other public branch where your want the patches to end up (followed by fast-forwarding the target branch and removing the temp branch). This is basically identical to cherry-picking a range of commits, but since "git cherry-pick" does not support cherry-pi...

Sorry, I don't quite understand what the problem is. From reading your subject line, I expected that "git commit -v" would show the diff in your editor, but then accidentally also include it in the final commit message. But I can't seem to reproduce that. Can you describe the problem in more detail? -Peff --

Guess in the dark... by any chance are you enabling color unconditionally? --

I thought cherry-picking needs to be done in terms of 3-way merge, not diff piped to patch, for correctness's sake. --

Yea, the 3-way merge cherry-pick is better. But in a pinch you can (usually) get correct results from a "diff | patch" pipeline. Of course that doesn't always work, resulting in patches that don't apply cleanly, or worse, that apply at the wrong place silently. -- Shawn. --

Hi, Do not forget creating efficient packs. They also need an efficient diff Nice. As was pointed out already, it is more meant to work on text than I'd like to, and it also seems to have cute DWIMery for HTML. I did not find any implementation, so I started implementing my own version of Gene Myers' algorithm, with the plan to extend it with a patience diff option. My code so far can generate a diff between two files, but does not use O(D) space (where D is the number of differen...

Our approach was to do just that, for the very reasons you mention. I'll have a look. Thanks for doing some research for us. That project was unknown to me.. -- robin --

We might want a byte-oriented version. Converting to char first is way too slow. -- robin --