You cannot fetch or push to the remote branch if you made some commits on the tracking branch ("broke the model") and remote branch has other commits. You can force the issue, but then either remote (for push) or local (for fetch) commits would be lost. Sidenote: for some branches you have to skip fast-forward check, because But one of those branches can be temporary "branch" FETCH_HEAD (if you Because usually you work with one branch with tracking (remote) + local branch workflow; I ...

We stashed away objects that we pretend to have, but did not save the actual data. Signed-off-by: Junio C Hamano <junkio@cox.net> --- * I wonder how recent merge-recursive with multiple merge bases (or an empty one) ever worked with this bug. Am I hallucinating? sha1_file.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/sha1_file.c b/sha1_file.c index b83f59f..2c87031 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -1545,11 +1545,13 @@ int ...

Actually, more efficient and to the point: list-all-boundary-sha1s | git-rev-list --stdin --not --all should return empty. Or something like that. Linus -

Using "test" is a style thing, but using "=" rather than "==" is a portability issue. "==" is accepted by bash as a synonym for "=", but its not valid elsewhere. I've made my fair share of patches with "==" in them, only to have someone else have a problem on their system and then submit a fix to What about: parents="$parents $(git-rev-list --max-count=1 --parents $c | cut -b42-)" ? I just used that trick recently. Oh yea it was in git-gui's GIT-VERSION-GEN script. Though I did ...

Yuck. I just went back and looked at the pack-objects source. Apparently we only accept ref names and SHA-1 values here, and `--not` on a line by itself. Nothing else is valid. The documentation is a little misleading, as usually when we say something is processed the same way as rev-list does it we usually also mean that any valid option to rev-list is also a valid option in that context. Here its not. -- Shawn. -

Signed-off-by: Mark Levedahl <mdl123@verizon.net> --- Documentation/git-unbundle.txt | 48 ++++++++++++++++++++++++++++++++++++++++ 1 files changed, 48 insertions(+), 0 deletions(-) create mode 100644 Documentation/git-unbundle.txt diff --git a/Documentation/git-unbundle.txt b/Documentation/git-unbundle.txt new file mode 100644 index 0000000..99713ce --- /dev/null +++ b/Documentation/git-unbundle.txt @@ -0,0 +1,48 @@ +git-unbundle(1) +=============== + +NAME +---- +git-unbundle - ...

Respun patch for git-bundle / git-unbundle. I am working a project using git where we have many repositories on machines that can never be directly connected, but which need to have the same objects and development history. Existing git protocols offer limited support: we can either a) publish and apply patch files branch by branch, or b) copy an entire repository from one machine to another and then do local push or fetch. While both are workable, neither is a completely satisfactory ...

Signed-off-by: Mark Levedahl <mdl123@verizon.net> --- Documentation/cmd-list.perl | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) mode change 100755 => 100644 Documentation/cmd-list.perl diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl old mode 100755 new mode 100644 index a2d6268..3a22083 --- a/Documentation/cmd-list.perl +++ b/Documentation/cmd-list.perl @@ -70,6 +70,7 @@ git-archive mainporcelain git-bisect ...

Documentation advertises the new `--depth <n>' parameter with an equal sign, while the usage notes (shown after `git-clone --help') do not. If I understood git-clone's source code correctly, the version without the equal sign is correct, which is why this patch syncs documentation to the usage note. Please note that I was not able to test the new shallow clone feature, as both git clone --depth=5 git://git2.kernel.org/pub/scm/git/git.git and git clone --depth 5 ...

Re-reading this, it sounds a little harsh. I meant less "screw you, if you want it, make a patch" and more "I don't have time to work on this now, but I would be happy to help guide you in making a patch." -Peff -

Sorry, I thought you were talking about v1.5. v1.4.* does not have the detached HEAD feature, and the default layout is to keep tracking and local branches in the same namespace. This means that you can checkout and commit to a tracking branch just as a local branch, and all changes will be saved. It will only bite you later, when you try to fetch into that tracking branch and realize that the fetch is not a fast-forward (remember the troubles you were having with fetches and pushes last week? ...

Granted, but this would be the same as creating the branch by hand, then going rock-climbing over the weekend, while my colleagues toiled, and coming back on Monday to find 15 checkins on that branch, right? At which point I could .... rebase? Do a pull? Bill -

We are about to switch to git 1.5 from git 1.4.4.1. I cannot remember if someone posted about this, but what is the danger of working on a tracking branch --- there are abundant cautions about doing this, but I can't recall and can't find the reason this is bad. Bill -

Ok, so I break the model, what is the harm in that? Can I no longer pull from or push to the remote branch? Do I corrupt something locally? Does something else break? I'm trying to formulate an explanation to our users why the 1.5 way is superior and I can't just say "if you do that you break the model". Bill -

Is this really the way 1.4.4.1 works? I have (mistakenly) been working on my tracking branch, committing to it, pushing it, pulling in from elsewhere, shifting to new branches, etc., and I haven't lost Sure, it is easy, but it's surprising to (our) users when they do a clone and can't "jump right in", and have to spend 3 seconds doing the above... Bill -

The commits you make will not actually go onto that tracking branch; they will be part of a "detached HEAD" (that is, your HEAD doesn't point to _any_ branch). Once you check out a different branch, you will potentially lose those commits (actually, they will still be available That's more or less correct. You don't really have to have two branches; doing a 'git pull /path/to/repo branch' will fetch the branch into the temporary FETCH_HEAD name, and merge from that. But yes, the way a ...

Hi, the attached patch removes the extra verbosity when cloning a http repository. I noticed this after some git upgrade in fedora. Please, consider applying it, getting tons of "got XXX", "walk XXX" lines by default is a little bit annoying. Salu2 PS: Thanks for this so great piece os software!

gitk is not using GTK v1 but TCL/TK. see your ~/.gitk and just change those option (9 to 13 or 15 will do): set mainfont {Helvetica 9} set textfont {Courier 9} set uifont {Helvetica 9 bold} -- Vincent Hanquez -

I'm nowhere near that impressive, unfortunately. Once upon a time, I was trying to build some package (I forget which) from its source distribution. It was an GNU-y Autoconf kind of thing. I didn't want to install it globally at that point, just in my home directory. So I said $ ./configure --prefix=~ $ make $ make install So far, so good. Now try to run the thing. $ foo bash: foo: command not found Oh. Where's it gone? $ ls That's annoying. Bad shell. It's ...

I've uploaded a binary installer to http://lilypond.org/git/binaries/mingw/ (untested, and will need magic to get the bash scripts working) -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen -

Do post, when ready. ;-) -- Shawn. -

Since cygwin used shortcuts for exactly this purpose, why not (in principle). In practice it is not the same however, since shortcuts aren't transparent to applications. Only apps that explicitly understand shortcuts can make any use of the, like the Explorer, and cygwin application since cygwin hide the things. The (presumed) lack of support in Win32 for these makes it harder to support them. A little feared commercial Git "alternative" uses copies and. You cannot "check out" a ...

Hi, Yes, indeed. And not only the bash scripts: AFAICT the command line option parsing is borked: whatever I do, a sh -c "git-config -l" from cmd does not pick up the option "-l". Which is funny, since a simple test program (outputting just the options passed to it) works. And so does "git-config -l" from "cmd". Could you please try making an installer which includes an exe for this simple program? -- snip -- #include <stdio.h> int main(int argc, char **argv) { ...

Hi, ATM it looks like this: -- snip -- git-gui/git-gui.sh | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh index f5010dd..ed5cd82 100755 --- a/git-gui/git-gui.sh +++ b/git-gui/git-gui.sh @@ -291,6 +291,11 @@ proc ask_popup {msg} { ## ## repository setup +if { [is_Windows] && ![is_Cygwin] } { + set repo_dir [tk_chooseDirectory -title "Choose a Git repository" -mustexist 1] + cd $repo_dir +} + if { [catch ...

Hi, [Cc'ed Duy, as he raised the same concerns.] Yes. However, you can safely call "git init" in an _existing_ repo. It "git clone" implicitly calls "git init"; Therefore you get the templates, too. But you're right, if you already edited .git/info/exclude, this will not overwrite it. Of course, you could fiddle with ~/.gitconfig, or even ~/.gitignore, but I suggest that you first think about a sane syntax. Also note that this opens the door for shooting-in-the-foot; files you ...

Oh.. that's enough for me :-) -- Duy -

Silly me; I forgot to write the last bit of my email :-) $ ln -sf $HOME/.git/exclude $GIT_DIR/info/exclude Do that in each of your working checkouts and voila. Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@gmail.com -

Correct me if I'm wrong (I didn't really find a documentation for templates), but I believe this would only apply to newly created project. Then, it doesn't apply if I clone the project of someone using another editor for example, nor to my old projects if I add something to the list of things I want to ignore. -- Matthieu -

Templates have no effect on previously created git repositories, does it? -- Duy -

Hi, Nope. This is per-repo, not per-user. Hth, Dscho -

Hi, How about going the full nine yards, and call it "fetchopt"? Then we would not check for the tag options, but instead parse $fetchopt _after_ "$@" in git-fetch. Ciao, Dscho -

Hi, Why not make a really dumb script which just _copies_ (or maybe optionally hard link) the objects from the alternate repo, and then kills the alternatives file? That should be easier. You always can repack after that. Ciao, Dscho -

How about this: 1) "I should like to clean up root's home directory" 2) cd /root; ls -la . 3) "Oh, there are a lot of config file in this directory that I don't need any more" 4) rm -rf .* Now start crying softly to yourself, when you realise that ".." is covered by ".*". Now go to every computer you work on and put export GLOBIGNORE=".:.." In your .bashrc. Boy, was my face red... Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@gmail.com -

Agreed. I often think stupid mistakes are a way of injecting random --- and at the time, unwelcome --- searches into creative solution spaces. As in other cases, this one involved an extremely simple answer very close to the start of the solution space, but (thanks to me), we drug this out all over the place and got to explore lots of things we otherwise wouldn't have. Bill -

Hi, I connected a tape drive. It was a SCSI tape drive, and I had a SCSI Zip drive, which was so often connected/disconnected in-flight that the plug wore out. So I thought that it should not be a problem to connect the SCSI tape drive to a running system. Right? RIGHT? BIG MISTAKE. The SCSI adapter also hosted two RAID systems, one as a SCSI RAID, i.e. managed by the adapter, and one as ATAPI RAID, i.e. managed by its own embedded computer simulating one (actually, two) SCSI ...

Hi, You're right. But instead of doing this with Python or by hand, why not make the It is only faster since you unpack the objects. Which makes almost every other operation slow. Ciao, Dscho -

Hi, It is not a usability issue if you are cleanly separating things which do Example: #!/bin/sh (echo Hallo; echo Bello; echo; echo blabla) | \ ( while read line; do echo "$line" if [ -z "$line" ]; then break fi done echo "xxx" cat ) In this case, shell reads the header until an empty line is encountered. The rest is piped through cat. And it does not matter if "blabla" is text or binary. Ciao, Dscho -

Perhaps a better solution would be to do git archive --format=tar --prefix=project/ | bzip2 -f9 | \ ssh user@remote -C "cat > project.tar.bz2" Then unpack and build as usual on the remote end. Works a treat and is currently the gist of the only line in my "push-to-web" script (the rest of it just extends the command to run to also unpack the tarball). -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 ...

GIT_CONFIG continues to work here with the latest git-svn + your hack -- Eric Wong -

Ok, Eric's example and yours made it clear that GIT_CONFIG is an interface meant to reuse (or abuse) git-config to read some file that is not at all related to git, and should never be used by other plumbing. As long as that is clear (could we have that in the documentation, by the way, please?), I have no problem with that. In fact, I am very happy that we do not have to do that insane "core.*" stuff, which I thought was needed purely because somebody was trying to use GIT_CONFIG to ...

Addendum. Judging from the way builtin-config.c::get_value() uses it, I think whoever invented $GIT_CONFIG_LOCAL as a parallel to $GIT_INDEX_FILE and $GIT_OBJECT_DIRECTORY, in other words, what usually appear under $GIT_DIR can be placed somewhere completely different. So I think the above "hack" I described still honors its intended use. I am still not sure what good GIT_CONFIG would be to completely override everything else, though. -

Isn't it more likely that on a multi-user machine all users are sharing one install of git - in which case you do want the upgrade of facilities to be system-wide. Otherwise you have to tell every user to edit their .gitconfig to enable the new facilities - users shouldn't have to care about that sort of thing, that's what admins are for. Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@gmail.com -

Not really. Some repositories would need to be accessible by people with older git coming over the network. Some don't. -

This time, the white spaces/tabs should be correct: --- git-gui.sh 2007-02-14 09:51:38.025781229 +0100 +++ git-gui 2007-02-15 06:53:40.262295256 +0100 @@ -1916,11 +1916,25 @@ return [lsort -unique $all_trackings] } +proc load_all_tags {} { + set all_tags [list] + set fd [open "| git for-each-ref --format=%(refname) refs/tags" r] + while {[gets $fd line] > 0} { + if {![regsub ^refs/tags/ $line {} name]} continue + lappend all_tags $name + } + close $fd + + return [lsort ...

I would have written: check_result () { rm -f current && git-ls-files --stage | ... && diff -u expected current } If the above still makes the tests pass for your environment, that would be good. I am not very happy about the lack of "&&" after "rm -f current" in your patch. It seems as if 'current' is sometimes writable and sometimes not, and when the shell couldn't open it to redirect sed output the whole test fails for you. That does not ...