- 17 1月, 2007 15 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
In general list at Wiki seems to be maintained a lot better than this list. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Also warn about format=flowed (aka 'flawed'). Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Take it from the tutorial, since not everybody necessarily reads it. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Chris Wedgwood 提交于
Trivial patch. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Talking about what the files contain without talking about where they are does not help new users. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This allows "git checkout -m <other-branch>" to notice renames and carry local changes in the working tree forward. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
... which was fixed since then. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
* Promiscous pull shows the distributed nature of git better. * Add a new step after that to teach "remote add". * Highlight that with the shorthand defined you will get remote tracking branches for free. * Fix Alice's workflow. Signed-off-by: NSanti Béjar <sbejar@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Santi Béjar 提交于
Then the newbies only have to understand one layout. Signed-off-by: NSanti Béjar <sbejar@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Johannes Schindelin 提交于
From time to time, I would get this error: [...] sed: -e expression #8, char 41: Unterminated `s' command make: *** [git-add--interactive] Error 1 Turns out that the function WriteMakefile() called in Makefile.PL outputs the message "Writing perl.mak for Git" to stdout! Thus, the output of "make -C perl -s --no-print-directory instlibdir" would be prefixed by that message whenever Makefile.PL was newer than perl.mak. This is fixed by redirecting stdout to stderr in Makefile.PL. Signed-off-by: NJohannes E. Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
The example section were talking about the old broken default behaviour. Correct it. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Mention --thin, --no-thin, --repo and -v. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Uwe Kleine-K,Av(Bnig 提交于
The text is just copied from git-send-pack.txt. Signed-off-by: NUwe Kleine-K,Av(Bnig <zeisberg@informatik.uni-freiburg.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 1月, 2007 8 次提交
-
-
由 Eric Wong 提交于
People that redirect STDOUT output should always see STDERR prompts interactively. STDERR should always be flushed without buffering, so they should always show up. If that is unset, we still explicitly flush by calling STDERR->flush. The svn command-line client prompts to STDERR, too. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jason Riedy 提交于
The reflog code clears empty directories when rename returns either EISDIR or ENOTDIR. Seems to be the only place. Signed-off-by: NJason Riedy <ejr@cs.berkeley.edu> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jason Riedy 提交于
Not all echos know -n. This was causing a test failure in t5401-update-hooks.sh, but not t3800-mktag.sh for some reason. Signed-off-by: NJason Riedy <ejr@cs.berkeley.edu> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jason Riedy 提交于
AIX 5.3 seems to need _ALL_SOURCE for struct addrinfo, but that introduces a struct list in grp.h. Signed-off-by: NJason Riedy <ejr@cs.berkeley.edu> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jason Riedy 提交于
My bash refused to run the two scripts missing a #!, and it's better to use the same line for all the scripts. Signed-off-by: NJason Riedy <ejr@cs.berkeley.edu> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jeff King 提交于
Instead, we complain to the user and suggest that they explicitly specify the remote and branch. We depend on the exit status of git-symbolic-ref, so let's go ahead and document that. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
When we are on a detached HEAD, there is no current branch. There is no reason to leak the error messages to the end user since this is a situation we expect to see. This adds -q option to git-symbolic-ref to exit without issuing an error message if the given name is not a symbolic ref. By the way, with or without this patch, there currently is no good way to tell failure modes between "git symbolic-ref HAED" and "git symbolic-ref HEAD". Both says "is not a symbolic ref". We may want to do something about it. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 15 1月, 2007 17 次提交
-
-
git://git.kernel.org/pub/scm/gitk/gitk由 Junio C Hamano 提交于
* git://git.kernel.org/pub/scm/gitk/gitk: [PATCH] Make gitk work when launched in a subdirectory [PATCH] gitk: add current directory to main window title
-
由 Shawn O. Pearce 提交于
Always call the current HEAD 'HEAD', and name the patch being cherry-picked or reverted by its oneline subject rather than its SHA1. This matches git am's behavior and is done because users most commonly are cherry-picking by SHA1 rather than by ref name. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This makes revert and cherry-pick to use merge-recursive, to allow them to notice renames. A pair of test scripts demonstrate that an old change before a rename happened can be applied (reverted) after a rename with cherry-pick (with revert). Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
We've squelched output from merge-recursive, and git-merge when used with recursive does not attempt the trivial one first anymore, so there won't be "Trying ... Nope." messages now. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Currently we don't use the util field of struct commit but we want fast access to the highest priority name that references any given commit object during our matching loop. A really simple approach is to just store the name directly in the util field. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
We really want to always favor an annotated tag over a lightweight tag when describing a commit. Unfortunately git-describe wasn't doing this as it was favoring the depth attribute of a possible_tag over the priority. Now priority is the highest sort and we only consider a lightweight tag if no annotated tags were identified. Rather than searching for the minimum tag using a simple loop we now sort them using a stable sort algorithm, this way the possible tags display in order if --debug gets used. The stable sort helps to preseve the inherit topology/date order that we obtain during our search loop. This fix allows the tests in t6120-describe.sh to pass. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
... with help from Shawn. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
My prior version of git-describe ran very slowly on even reasonably sized projects like git.git and linux.git as it tended to identify a large number of possible tags and then needed to generate the revision list for each of those tags to sort them and select the best tag to describe the input commit. All we really need is the number of commits in the input revision which are not in the tag. We can generate these counts during the revision walking and tag matching loop by assigning a color to each tag and coloring the commits as we walk them. This limits us to identifying no more than 26 possible tags, as there is limited space available within the flags field of struct commit. The limitation of 26 possible tags is hopefully not going to be a problem in real usage, as most projects won't create 26 maintenance releases and merge them back into a development trunk after the development trunk was tagged with a release candidate tag. If that does occur git-describe will start to revert to its old behavior of using the newer maintenance release tag to describe the development trunk, rather than the development trunk's own tag. The suggested workaround would be to retag the development trunk's tip. However since even 26 possible tags can take a while to generate a description for on some projects I'm defaulting the limit to 10 but offering the user --candidates to increase the number of possible matches if they need a more accurate result. I specifically chose 10 for the default as it seems unlikely projects will have more than 10 maintenance releases merged into a development trunk before retagging the development trunk, and it seems to perform about the same on linux.git as v1.4.4.4 git-describe. A large amount of debugging information was also added during the development of this change, so I've left it in to be toggled on with --debug. It may be useful to the end user to help them understand why git-describe took one particular tag over another. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
If a project has a really huge number of tags (such as several thousand tags) then we are likely to have nearly a hundred tags in some buckets. Scanning those buckets as linked lists could take a large amount of time if done repeatedly during history traversal. Since we are searching for a unique commit SHA1 we can sort all tags by commit SHA1 and perform a binary search within the bucket. Once we identify a particular tag as matching this commit we walk backwards within the bucket matches to make sure we pick up the highest priority tag for that commit, as the binary search may have landed us in the middle of a set of tags which point at the same commit. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
If a project has a very large number of tags then git-describe will spend a good part of its time looping over the tags testing them one at a time to determine if it matches a given commit. For 10 tags this is not a big deal, but for hundreds of tags the time could become considerable if we don't find an exact match for the input commit and we need to walk back along the history chain. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Several people have suggested that its always better to describe a commit using an annotated tag, and to only use a lightweight tag if absolutely no annotated tag matches the input commit. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
1) talk about "git merge" instead of "git pull ." 2) suggest "git repo-config" instead of directly editing config files 3) echo "URL: blah" > .git/remotes/foo is obsolete and should be "git repo-config remote.foo.url blah" 4) support for partial URL prefix has been removed (see commit ea560e6d) so drop mention of it. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
We say "this shows only the most often used ones"; so instead of teaching --max-number=<n> form, list -<n> form which is much easier to type. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Now that we are showing the output messages for verbosity levels <5 after all actions have been performed (due to the progress meter running during the actions) it can be confusing to see messages in the present tense when the user is looking at a '100% done' message right above them. Converting the messages to past tense will appear more correct in this case, and shouldn't affect a developer who is debugging the application and running it at a verbosity level >=5. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Because large merges on slow systems can take up to a minute to execute we should try to keep the user entertained with a progress meter to let them know how far we have progressed through the current merge. The progress meter considers each entry in the in-memory index to be a unit, which means a single recursive merge will double the number of units in the progress meter. Files which are unmerged after the 3-way tree merge are also considered a unit within the progress meter. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Buffering all message output until a merge invocation is complete is necessary to prevent intereferring with a progress meter that would indicate the number of files completely merged, and how many remain. This change does not introduce a progress meter, but merely lays the groundwork to buffer the output. To aid debugging output buffering is only enabled if verbosity is lower than 5. When using verbosity levels above 5 the user is probably debugging the merge program itself and does not want to see the output delayed, especially if they are stepping through portions of the code in a debugger. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Junio C Hamano <junkio@cox.net> writes: > > I think the output from merge-recursive can be categorized into 5 > verbosity levels: > > 1. "CONFLICT", "Rename", "Adding here instead due to D/F conflict" > (outermost) > > 2. "Auto-merged successfully" (outermost) > > 3. The first "Merging X with Y". > > 4. outermost "Merging:\ntitle1\ntitle2". > > 5. outermost "found N common ancestors\nancestor1\nancestor2\n..." > and anything from inner merge. > > I would prefer the default verbosity level to be 2 (that is, show > both 1 and 2). and this change makes it so. I think level 3 is probably pointless as its only one line of output above level 2, but I can see how some users may want to view it but not view the slightly more verbose output of level 4. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-