- 02 1月, 2007 2 次提交
-
-
由 Junio C Hamano 提交于
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.". They are unnecessarily alarming, and cause useful conflict messages from the first pull scroll off the top of the terminal. This changes pull and merge to run "git-ls-files -u" upfront and stop them much earlier than we currently do. Old timers may know better and would not to try pulling again before cleaning things up; this change adds extra overhead that is unnecessary for them. But this would be worth paying for to save new people from needless confusion. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
The pipeline was much more complex and needed documentation, but now it is trivial and straightforward. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 01 1月, 2007 10 次提交
-
-
由 Eric Wong 提交于
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 Athlon Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
We don't support the svn command-line client anymore; nor do we support anything before SVN 1.1.0, so we can be certain symlinks will be supported in the SVN repository. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
We require the libraries now, so we can create repositories using them (and save some executable load time while we're at it). Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
We special case the case where encoding recorded in the commit and the output encoding are the same and do not call iconv(). But we should drop 'encoding' header for this case as well for consistency. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
When your fetch configuration has only the wildcards, we would pick the lexicographically first ref from the remote side for merging, which was complete nonsense. Make sure nothing except the one that is specified with branch.*.merge is merged in this case. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Theodore Tso 提交于
Updated to make the nroff'ed man pages look nicer. Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 J. Bruce Fields 提交于
Update tutorial's discussion of origin branch to reflect new defaults, and include a brief mention of git-repo-config. Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 J. Bruce Fields 提交于
Update glossary entry for "origin" to reflect fact that it normally now refers to a remote repository, not a branch. Also, warning not to work on remote-tracking branches is no longer necessary since git doesn't allow that. Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 J. Bruce Fields 提交于
Fix a couple remaining references to the origin branch. Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 J. Bruce Fields 提交于
I couldn't think of a really quick way to give all the details, so just refer readers to the git-repo-config man page instead. I haven't tested recent cvs import behavior--some time presumably it should be updated to do something more similar to clone. Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 31 12月, 2006 19 次提交
-
-
由 Junio C Hamano 提交于
This means one less process in the pipeline to worry about, and removes about 1/8 of the code. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Everybody else uses is_null_sha1() -- there is no point to have its own is_zero_sha1() anymore. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
* jc/send-pack-pipeline: Documentation: illustrate send-pack pipeline. send-pack: fix pipeline.
-
由 Shawn O. Pearce 提交于
Verify that the update hooks work as documented/advertised. This is a simple set of tests to check that the update hooks run with the parameters expected, have their STDOUT and STDERR redirected to the client side of the connection, and that their STDIN does not contain any data (as its actually /dev/null). Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Sometimes its necessary to supply a value as a power of two in a configuration parameter. In this case the user may want to use the standard suffixes such as K, M, or G to indicate that the numerical value should be multiplied by a constant base before being used. Shell scripts/etc. can also benefit from this automatic option parsing with `git repo-config --int`. [jc: with a couple of test and a slight input tightening] Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Currently the update hook invoked by receive-pack has its stdin connected to the pushing client. The hook shouldn't attempt to read from this stream, and doing so may consume data that was meant for receive-pack. Instead we should give the update hook /dev/null as its stdin, ensuring that it always receives EOF and doesn't disrupt the protocol if it attempts to read any data. The post-update hook is similar, as it gets invoked with /dev/null on stdin to prevent the hook from reading data from the client. Previously we had invoked it with stdout also connected to /dev/null, throwing away anything on stdout, to prevent client protocol errors. Instead we should redirect stdout to stderr, like we do with the update hook. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
If an update hook outputs to stdout then that output will be sent back over the wire to the push client as though it were part of the git protocol. This tends to cause protocol errors on the client end of the connection, as the hook output is not expected in that context. Most hook developers work around this by making sure their hook outputs everything to stderr. But hooks shouldn't need to perform such special behavior. Instead we can just dup stderr to stdout prior to invoking the update hook. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
The argc parameter is never used by the run_command_v family of functions. Instead they require that the passed argv[] be NULL terminated so they can rely on the operating system's execvp function to correctly pass the arguments to the new process. Making the caller pass the argc is just confusing, as the caller could be mislead into believing that the argc might take precendece over the argv, or that the argv does not need to be NULL terminated. So goodbye argc. Don't come back. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Many users find it unfriendly that they can create a bare git repository easily with `git clone --bare` but are then unable to run simple commands like `git log` once they cd into that newly created bare repository. This occurs because we do not check to see if the current working directory is a git repository. Instead of failing out with "fatal: Not a git repository" we should try to automatically detect if the current working directory is a bare repository and use that for GIT_DIR, and fail out only if that doesn't appear to be true. We test the current working directory only after we have tried searching up the directory tree. This is to retain backwards compatibility with our previous behavior on the off chance that a user has a 'refs' and 'objects' subdirectories and a 'HEAD' file that looks like a symref, all stored within a repository's associated working directory. This change also consolidates the validation logic between the case of GIT_DIR being supplied and GIT_DIR not being supplied, cleaning up the code. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
We tend to use the nice constant GIT_DIR_ENVIRONMENT when we are referring to the "GIT_DIR" constant, but git.c didn't do so. Now it does. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
For easier portability we prefer PATH_MAX over seemingly random constants like 1024. Make it so. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Many users have noticed that core.filemode doesn't appear to be automatically set right on Cygwin when using a repository stored on NTFS. The issue is that Cygwin and NTFS correctly supports the executable mode bit, and Git properly detected that, but most native Windows applications tend to create files such that Cygwin sees the executable bit set when it probably shouldn't be. This is especially bad if the user's favorite editor deletes the file then recreates it whenever they save (vs. just overwriting) as now a file that was created with mode 0644 by checkout-index appears to have mode 0755. So we introduce NO_TRUSTABLE_FILEMODE, settable at compile time. Setting this option forces core.filemode to false, even if the detection code would have returned true. This option should be enabled by default on Cygwin. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Theodore Ts'o 提交于
The line: [remote "<remote>"] was getting swallowed up by asciidoc, causing a critical line in the explanation for how to store the .git/remotes information in .git/config to go missing from the git-fetch, git-pull, and git-push manpages. Put all of the examples into delimited blocks to fix this problem and to make them look nicer. Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Johannes Schindelin 提交于
In very obscure cases, a merge can hit an unexpected code path (where the original code went as far as saying that this was a bug). This failing merge was noticed by Alexandre Juillard. The problem is that the original file contains something like this: -- snip -- two non-empty lines before two empty lines after two empty lines -- snap -- and this snippet is reduced to _one_ empty line in _both_ new files. However, it is ambiguous as to which hunk takes the empty line: the first or the second one? Indeed in Alexandre's example files, the xdiff algorithm attributes the empty line to the first hunk in one case, and to the second hunk in the other case. (Trimming down the example files _changes_ that behaviour!) Thus, the call to xdl_merge_cmp_lines() has no chance to realize that the change is actually identical in both new files. Therefore, xdl_refine_conflicts() finds an empty diff script, which was not expected there, because (the original author of xdl_merge() thought) xdl_merge_cmp_lines() would catch that case earlier. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
After re-coding the commit message into the encoding the user specified (either with core.logoutputencidng or --encoding option), this drops the "encoding" header altogether. The output is after re-coding as the user asked (either with the config or --encoding=<encoding> option), and the extra header becomes redundant information. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
People can spell config.commitencoding differently from what we internally have ("utf-8") to mean UTF-8. Try to accept them and treat them equally. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This way, git-rev-list and git-diff-tree with --pretty can use it. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 30 12月, 2006 9 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Telling the git-log family not to do any character conversion is done with --encoding=none, which sets log_output_encoding to an empty string. However, logmsg_reencode() confused this with log_output_encoding and commit_encoding set to NULL. The latter means we should use the default encoding (i.e. utf-8). Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
send-pack builds a pipeline that runs "rev-list | pack-objects" and sends the output from pack-objects to the other side, while feeding the input side of that pipe from itself. However, the file descriptor that is given to this pipeline (so that it can be dup2(2)'ed into file descriptor 1 of pack-objects) is closed by the caller before the complex fork+exec dance! Worse yet, the caller already dup2's it to 1, so the child process did not even have to. I do not understand how this code could possibly have been working, but it somehow was working by accident. Merging the sliding mmap() code reveals this problem, presumably because it keeps one extra file descriptor open for a packfile and changes the way file descriptors are allocated. I am too tired to diagnose the problem now, but this seems to be a sensible fix. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
* jc/curl: Work around http-fetch built with cURL 7.16.0
-
由 Junio C Hamano 提交于
When '*.ig' is ignored, and you have two files f.ig and d.ig/foo in the working tree, $ git add . correctly ignored f.ig but failed to ignore d.ig/foo. This was caused by a thinko in an earlier commit 4888c534, when we tried to allow adding otherwise ignored files. After reverting that commit, this takes a much simpler approach. When we have an unmatched pathspec that talks about an existing pathname, we know it is an ignored path the user tried to add, so we include it in the set of paths directory walker returned. This does not let you say "git add -f D" on an ignored directory D and add everything under D. People can submit a patch to further allow it if they want to, but I think it is a saner behaviour to require explicit paths to be spelled out in such a case. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This reverts commit 4888c534.
-