So tonight on #git I think I answered for the 10th time why the working directory doesn't update after a push to its associated repository. We all know its somewhat dangerous to push into the current branch of a working directory, especially if that working directory contains uncommitted changes, as HEAD no longer matches the index. But we all also know its incredibly useful to be able to push into a repository with a working directory, so we certainly don't want to disallow it ...

It has been a while since I sent this message out the last time, and there seem to be some new people on the git list. This message talks about how git.git is managed, and how you can work with it. * IRC and Mailing list Many active members of development community hang around on #git IRC channel. Its log is available at: http://colabti.de/irclogger/irclogger_logs/git [jc: Does anybody know a shortcut for "Today's" page on this site? It irritates me having to click the latest ...

Or even in public ones, but where access by dumb clients isn't That's an interesting idea. Most users don't invoke init-db directly however, they are using clone to copy someone else's repository. But that option could easily be offered on both commands, with Actually I wonder if "--min-version=current" shouldn't just be the default. Most users are going to init-db or clone locally and use only the current version of Git (or later) against that repository. Though that probably would ...

For people in non-public development environments, where there's absolutely no possibility of someone hitting a repo with an old client, presumably these options should both be enabled. I wonder if it makes sense to add an option to git-init-db to create a configuration file with all the latest stuff enabled -- or better still, something like git-init-db --min-version=1.4.2 that would enable all the non-backward-compatible stuff in the newly created repository. And then a special case ...

A happy new year. I think this is more-or-less it to start the -rc1 cycle. I'll leave the window open for another week or so before people come back from the christmas and new year break. I have not been working on any of the potential changes other people talked about recently on the list, but things like detached HEAD and more generic per-branch customization may magically materialize from somewhere as a robust and usable set of patches. I also haven't reviewed the introductory ...

Hi and Happy New Year Things are happening wrt to support for working with multiple locales, which is nice to see. I've not had time to follow the development so these comments (and code) may be considered somewhat late in the process. What disturbes me is the complexity that the approach of storing multiple encodings in the same repository results in. I was hacking another solution earlier this autumn, that takes another approach, i.e. UTF-8 is the internal encoding. period. If you want ...

I'm getting this with git 1.4.4.3: remote: Generating pack... remote: Done counting 1294 objects. remote: Result has 916 objects. remote: Deltifying 916 objects. remote: 100% (916/916) done Unpacking 916 objects remote: Total 916, written 916 (delta 758), reused 0 (delta 0) error: failed to read delta-pack base object b47ceb21cfed93f410e6329040784d43864dab33 fatal: unpack-objects died with error code 1 Fetch failure: /mswg2/git/linux-2.6/.git -- MST -

This is a plumbing command which can be used by gitweb. It will scan a list of commits and/or refs and return the time in seconds for the youngest commit. This value can then be used to generate and check the Last-Modified and Is-Modified-Since HTTP headers. Signed-off-by: Robert Fitzsimons <robfitz@273k.net> --- The following two commands lines are similar: $ git for-each-ref --count=1 --sort=-committerdate '--format=%(committerdate)' refs/heads $ git last-modified --branches The ...

After a pull that results in a conflicted merge, a new user often tries another "git pull" in desperation. When the index is unmerged, merge backends correctly bail out without touching either index nor the working tree, so this does not make the wound any worse. The user will however see several lines of messsages during this process, such as "filename: needs merge", "you need to resolve your current index first", "Merging...", and "Entry ... would be overwritten by merge. Cannot merge.". ...

This removes some unnecessary 'svn up' calls throughout t9103-git-svn-graft-branches.sh: * removed an 'svn log' call that was leftover from debugging * removed multiple git-svn calls with a multi-init / multi-fetch combination (which weren't tested before, either) * replaced `rev-list ... | head -n1` with `rev-parse ...` (not sure what I was thinking when I wrote that) All this saves about 9 seconds from a test run (53s -> 44s for 'make t91*') on my 1.3GHz ...

Smells like another "newbie" protection. Let me understand, someone here installed git, didn't read the then man page of git-clone/pull/fetch, screwed up their repo, and decided to change established behavior. Regardless, I think addressable (named) branch specs are the way to go. This will as well, unify/reconcile remotes/ and local stuff, since it is already implemented for remotes/ . Luben -

See list archives. Because you are not required to use remote tracking branches. By the way, I think we allow the name of the remote tracking branch as well, but we do not advertise it -- always using No. Remote is not about mapping -- if mapping is there you can talk about it, but that is optional. -

Well, yes; since git-pull is implemented in terms of git-fetch followed by a git-merge, that's why I talked about git-fetch. It is git-fetch which uses remote.<non-URL>.{url,fetch}, not git-merge or What do you mean by <branch-match> and <symbolic-ref match>? Are you assuming some kind of glob match? If so, what are the git-pull is implemented in terms of git-fetch. So if we make the change to git-fetch, the changes naturally follow to git-pull. Or are you proposing to change ...

So is this no longer the case? Can someone please bring me up to date? What is going on? -

Absolutely correct. I just needed to respond to an obvious fact with More complicated and exotic examples exist. See my response No, no, no. Forget about the semantic attibute of "parent". I could've called it "xyz" for that matter. What I'm talking about is the concept of "branch spec". It is a well known concept in SCMs. We currently implement it, in git specific way, for remotes/ only, but not for local ("topic") branches. Another way to look at it is that a Topic, can have ...

Luben, Let me see if I can understand what you are asking for without using the term "branch spec", which I don't think has been adequately defined yet in this thread. (Where "the SCM industry has adopted" isn't a definition. :-) Currently, today, if you type: git fetch <non-URL> ... it will look up "<non-URL>" in a single global namespace, which (using only the new config scheme) is looked up in remote.<non-URL> and remote.<non-URL>.{url,fetch} is used to control the operation ...

Basically I want to _name_ the dependency, instead of having it be implicit. One can extend that dependency, in more complicated topic branch relationship, where for example, C extends B, B extends A, A extends master, but B' also extends A, consider B' a "version" of the extension which B implements. This is of course a trivial example and more complicated ones exist. Naming the dependency would give git greater coverage when it needs to implement complicated source development ...

Yes. I've outlined them at least twice in this thread already as well as in that same email of mine which you're replying I mean "git-pull", as opposed to "git-pull <symbolic-ref>". I.e. "branch.<branch-match>..{fetch,merge}" matches no symbolic No, not at all. Please see my last email to Junio in this thread. Depending on how this new functionlity is implemented for git 1.5, the concept of "branch spec" can be had by using a "dummy" [remote] spec, used only as a command line match, ...

Updated man page assuming that change; does this look any better? --b. [PATCH] Documentation: update git-pull.txt for new clone behavior Update examples, stop using branch named "origin" as an example. Remove large example of use of remotes; that particular case is nicely automated by default, so it's not so pressing to explain, and we can refer to git-repo-config for the details. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> --- Documentation/git-pull.txt | 69 ...

You lost me here; I am guessing this is some sarcasm not worth But what confuses me (and I think JBF shares the same confusion with me) is that you had only one example "parent". While I understand that it would make sense to define "parent" for each branch in a downstream developer's workflow, (1) I do not see the difference between your wording, "parent", and what we traditionally have called "origin", and (2) I do not think of relationship other than "parent" ("origin") that is ...

If I am reading you correctly, you have multiple directories, each with its own .git/ directory but major parts of these .git/ directories are shared (namely, objects/ and refs/). You would not be able to have separate checkout in these directories if you shared .git/HEAD and .git/index, so at least each of these directories has these two files for its own. Is that what you are doing? If that is the case, I think you do not even have to have the "branch spec" to express the patchflow ...

No, "origin" refers to the remote repository that you originally cloned from. Pulls always merge into the current branch. So it wouldn't make sense to specify the current branch on the command line. --b. -

I know your testing is saying this series may be slightly faster than the prior code in 'master', and at least on Linux can be so without using a lot of virtual address space as mmap() is so fast there. (Nice job kernel people!) Anyway, I haven't done any performance testing on this myself. It would be nice to know more about how I know you've stated a number of good reasons against "Avoid git-fetch in `git-pull .` when possible.". One way I've thought of trying to resolve that would be to ...

Probably not. `git --bare foo` is a Poreclain-ish level option which has been supported for several versions. Removing it may cause pain for users to retrain their fingers to just ignore it. Besides `git --bare` can be used in cases where the bare Git repository is actually located within another repository's working directory and the automatic detection is picking up the other repository's metadata and not the bare repository's metadata. So I think --bare is still here to stay for a ...