Ah, I misunderstood. I suspect you do not want to get random, unreliable executable bit from lstat(), even when previously index recorded non regular file for a path that is now a regular file. In builtin-update-index.c, add_file_to_cache() has this: ce->ce_mode = create_ce_mode(st.st_mode); if (!trust_executable_bit) { /* If there is an existing entry, pick the mode bits * from it, otherwise assume unexecutable. */ int pos = cache_name_pos(path, namelen); if (0 <= ...

Correct. But the breakage is still there. As you recall, the properties S_IFREG and S_IFLNK are recorded in the st_mode, and the line of code that I fixed trusts the index in too many cases, and copies the index's S_IFLNK over the the stat() result, which said S_IFREG. So the diff engine loses the information that it is should diff against a regular file, and thinks that the working copy is a symlink. Please change the last sentence of the commit message, which hopefully makes the issue ...

Hi, [jes: just stumbled over it: http://colabti.de/irclogger/irclogger_log/git?date=] Ciao, Dscho -

Hi, But does it cook dinner? Ciao, Dscho -

The private copy is only to help people who build from the source _and_ are lazy enough to install Error.pm from more official sources (either CPAN or officially pacakged ones). My preference is to never allow out private copy to leak into binary packages, and have our binary packages _always_ depend on the officially packaged ones. -

Hi Peter, Yes, I did try that, but the underlying "git-fetch" command complains about improper usage. So it seems that git-fetch-pack is not being called (or it is called from git-fetch and git-fetch is failing to understand -q). Thanks, Larry. -

I run a nightly script to build and test our product. I capture all the output and email it to interested parties. One very annoying thing is the "percent done" messages that come out of git pull. It results in log files that look like this: + git pull remote: Generating pack... remote: Done counting 204 objects. Result has 107 objects. Deltifying 107 objects. 0% (1/107) done 1% (2/107) done 2% (3/107) dremote: one 3% (4/107) done 4% (5/107) done 5% (6/107) done 6% ...

That is possible, but would be expensive similar to git-fsck-objects. All objects for each commit would need to be searched for the matching GIT adds a header of its own before object data. You therefore need to use git-hash-object not sha1sum to get the right sha1 value. Nicolas -

Here's a suggestion for a git feature, if git doesn't already have it. Since git generally doesn't use RCS-style keyword cookies (like "$Id$"), it'd be nice to have some other way to identify an installed file. Perhaps you'd want to know exactly what rev a user is running, for example. It seems like it should be fairly easy, given a blob (the file), for git to describe what it knows about it. For example, it could provide a list of commits that it's a part of, etc. It'd be *really* nice ...

Hi, Sorry. Still, it feels wrong to use two system calls when you need none. How about working on making status and commit a builtin instead? This would not only solve your issue, but portability issues as well. Ciao, Dscho -

Your analysis looks right to me. I think you would need to set GIT_PAGER_IN_USE in the environment whenever you turn on the pager in the git wrapper, and then set git's internal pager_in_use variable based on that. -Peff -

When running a shell script the value of pager_in_use is lost for later processes. Therefore pager_in_use is replaced by the environment variable GIT_PAGER_IN_USE. Signed-off-by: Matthias Lederhofer <matled@gmx.net> --- This patch replaces pager_in_use because pager_in_use was only used at two places (one sets it, the other reads it). --- cache.h | 1 - color.c | 2 +- environment.c | 1 - pager.c | 3 ++- 4 files changed, 3 insertions(+), 4 ...

git -p status starts the pager, then runs git-commit.sh (named git-status) which in turn runs git-runstatus. I guess the problem is that git-runstatus cannot check that the pager was started and just knows that stdout is no terminal. Has anyone an idea how to fix this? -

The syntax is: [include "filename"] which is somewhat branch/remote-alike. There are a few differences, though: filenames happen to be long, so a backslash is supported to split the names into multiple lines. No bare LF allowed, so this is illegal: [include "path/ name"] On the other hand, this is allowed: [include "path/\ name"] Backslash is just to quote characters (as in shell). Only one quoted string allowed, so this is bad too: [include "path/" ...

This one is easy, make tmp a directory, then build the tar file in that directory so the archive members don't include the tmp name, then just move the tar file to where it is needed... tmp="$GIT_DIR/bundle_tmp$$" references="$tmp/references" pack="$tmp/pack" trap 'rm -rf "$tmp"' 0 1 2 3 15 mkdir "$tmp" && echo "v1 git-bundle" > "$version" && ------ # create the tar file, clean up cd "$tmp" && tar cf bundle prerequisites references version pack && cd - && mv "$tmp/bundle" "$bfile" ...

Mark, how urgent do you want to have "bundle" in my tree? As I understand it, this came out of your working zip based implementation your group already use, so I am suspecting that you do not have urgent need to have a different one in git.git in a half-baked shape. The reason I say this is because I very much in favor of the general idea of an archive file that can be used to sneakernet repository updates, but I find the current bundle-unbundle interface a bit awkward to integrate into the ...

... I *tried* that, and it fails under Cygwin. Apparently cygwin's bash (or something) mangles data in the pipe (99% certain it will turn out to be a latent crlf issue)... cat "$bfile" ( read refs... git index-pack --stdin ) worked several times, it only failed twice out of 8 bundles I tried. That's just a trifle bit too high a failure rate for my taste. ;^) Mark -

you can try something like: sed -e '1,/^##DATA##$/d' "$bundle" | git-index-pack --stdin and see if it works better. no need to stream the bundle completely, it = can be read several times. cheers simon --=20 Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low =E2=82=AC=E2=82=AC=E2=82=AC NOW!1 +++= Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! ...

Signed-off-by: Jim Meyering <jim@meyering.net> --- builtin-update-index.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/builtin-update-index.c b/builtin-update-index.c index 1ac613a..5b2278e 100644 --- a/builtin-update-index.c +++ b/builtin-update-index.c @@ -121,8 +121,10 @@ static int add_file_to_cache(const char *path) ce->ce_mode = create_ce_mode(S_IFREG | 0666); } - if (index_path(ce->sha1, path, &st, !info_only)) + if (index_path(ce->sha1, ...

Hi *, I think it didn't get to the list due to the size limit. So I send it as a gziped attatchment, with the test inline. Regards, Santi --- t/t5515-fetch-merge-logic.sh | 124 ++++++++++++++++++++ diff --git a/t/t5515-fetch-merge-logic.sh b/t/t5515-fetch-merge-logic.sh new file mode 100755 index 0000000..8d8a71f --- /dev/null +++ b/t/t5515-fetch-merge-logic.sh @@ -0,0 +1,124 @@ +#!/bin/sh +# +# Copyright (c) 2007 Santi Béjar, based on t4013 by ...

On 2/16/07, Junio C Hamano <junkio@cox.net> wrote: > "Santi B

This series implements the split of the fetch and merge logic. The first patch adds tests for the merge logic. It is very extensive and expensive (in time), so I just post this to show that (almost) nothing changes (although some part of if could be included). And the third patch shows what changes. Santi Béjar (3): t/t5515-fetch-merge-logic.sh: Added tests for the merge login in git-fetch git-fetch: Split fetch and merge logic t/t5515: fixes for the separate fetch and ...

1) branch.*.merge no longer must exactly match the remote part of the branch fetched. Both are expanded in full (as refs/heads/...) and matched afterwards. 2) When the remote is specified with $GIT_DIR/branches/... and there is a branch.*.merge, the remote branch name must match to get them merged. Before the branch in $GIT_DIR/branches/... was always merged. In the documentation the $GIT_DIR/branches/ is documented as a short-hand for a corresponding file in ...

But that is a solved problem, isn't it? What else does it solve? The justification for moving around the logic could be something like "these three patches do not do that themselves, but it opens a door for further work such as ...", but without something concrete in "..." part, your response makes the patch look mostly needless code churn. I was hoping to hear something like "now git-fetch has to do much less than before, eventual C-rewrite of the command, which can borrow some code ...

Thanks. Sign-off? -

Hi, I planned this. However, I could not think of any sane way to handle the case in an intuitive manner where you want to compare two _tracked_ files. How would you do that in a consistent manner? BTW I also realized that `git diff bla` will _not_ complain when the file bla exists, but is untracked. Neither will it show a diff. I did not come Well, it should probably be lstat(), with an addremove when one or both You are right. But for the moment, I'll leave it, since it is one ...

I think it will always work with the example you gave, because you are simultaneously fetching into the tracking branch (which fails) and merging from FETCH_HEAD (which succeeds) into that same tracking branch. At best, though, the tracking branch you have is pointless (since you immediately overwrite it anyway). The point of a tracking branch generally is to allow you to do operations against your peer's idea of the branch (e.g., diffing against upstream's version of "topic"). But you can't ...

Ok, fair enough, but then I guess I'm back to my original question: how can I give a concrete demonstration to our developers that this is a bad thing? This is not 100% required, so if you are tired of answering my incessant questions, feel free to decline. I will be able to get our group to move forward, simply because we need to try to stay current, and there are lots of improvements in git besides this issue. Bill -

Ok, I'm trying to come up with an experiment that verifies this, so I can give a concrete example to our developers. I don't seem to be able to get it to fail, but I sure remember having severe problems with this in practice. Here is my attempt, again with git 1.4.4.1: # Create my repo and add a file A % mkdir my_repo % cd my_repo % git init-db defaulting to local storage area % echo A > A % git add A && git commit -a -m "Add A" Committing initial tree ...

Because your pull command really means "merge in the topic branch from peer_repo, and while you're at it, store it in my local tracking branch topic". Remember that pull is really a fetch+merge. But the fetch is actually doing _two_ things: putting the fetched branch into FETCH_HEAD, and putting it in into refs/heads/topic. The latter fails (because of a non-fastforward), but pull actually uses the FETCH_HEAD results to do the merge. Yes, this seems overly complex for what you're doing, but ...

Most definately. We never look at the pointer to an object's data if len == 0, which it does in this case of merge-recursive's empty tree. Aren't we using this for git-blame --contents? How'd that ever work for a non-empty file? -- Shawn. -

I'm not sure this will work on FreeBSD. Both 5.1 and 6.1 use tar that does not know about --absolute-names, --transform, --verbose, or --show-transformed-names. -- Shawn. -

What about passing $local as the final argument to update-ref, so that the ref won't be modified if someone changed it while an unbundle was running? Sure its mostly a manual operation, but imagine running it on a bare repository while someone else is pushing into it... -- Shawn. -

Some workflows require coordinated development between repositories on machines that can never be connected. This utility unpacks a bundle containing objects and associated references (heads or tags) into the current repository, effectively supporting git-push like operations between disconnected systems. Signed-off-by: Mark Levedahl <mdl123@verizon.net> --- git-unbundle.sh | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 68 insertions(+), 0 deletions(-) ...

Actually that's only if --force was not given. If --force was given, rev-parse wasn't run, so local is not populated. So maybe People do weird things. I agree, its probably unlikely to ever happen. But give a user a length of rope, they will find a way to hang themselves... I can see someone trying to use an update hook with bundle/unbundle to move stuff from one repository to another, despite the fact that are better ways to do that. Better that we fail when an update might lose ...

No. That's not the point. Yes, the object might be reachable, but you haven't proven that everything necessary to complete that object is already in the object store. We never trust existence of an object alone when doing an operation that updates a ref. Having unreferenced objects in the object store is a norm, but refs pointing at an object, some of whose prerequisites are missing, is a crime. For example, suppose an earlier http-fetch found that the updated master should be at commit ...

OK. I'm thinking though that this should go below the context that appears below it. The reason is, a "Desktop Icon" for git-gui embeds the repository path in it by setting up GIT_DIR, so that the user returns to the same repository when launching through that icon. In other words, maybe only prompt the user to select the directory I think I can answer this: Tcl (and thus wish too) on Windows does not pass its environment onto its children. If you poke around git-gui some and look for ...

[ARGH; hit r rather than f; cc-ing the list. -JimC] Wierd. I was /just/ about to inquire on what the best method was for disassociating. And then I read this thread. Effective mind reading! :) WRT Johannes's followup, I presume it will re-use the alternate packs, such that the computation is minimal? -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6 -

Really, no one knows ? Xavier -