From: Rob Clevenger <r...@google.com> Using the default rule factory instead of the pessimistic one makes it less likely that the UI will freeze in a modal dialog while Eclipse goes off and does builds. Signed-off-by: Rob Clevenger <r...@google.com> Signed-off-by: Shawn O. Pearce <sop@google.com> --- .../src/org/spearce/egit/core/GitProvider.java | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git ...

Sometimes its useful to export an entire directory tree, without needing to create git-daemon-export-ok everywhere. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> --- .../src/org/spearce/jgit/pgm/Daemon.java | 4 ++ .../src/org/spearce/jgit/transport/Daemon.java | 37 +++++++++++++++++++- 2 files changed, 40 insertions(+), 1 deletions(-) diff --git a/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/Daemon.java ...

The "save" subcommand usually removes the changes it stashed from the index and the work tree. Existing --keep-index option however keeps the changes to the index. This new option keeps the changes made to both the index and the work tree. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> --- Documentation/git-stash.txt | 7 +++++-- git-stash.sh | 35 +++++++++++++++++++++++++++++------ t/t3903-stash.sh | 22 ++++++++++++++++++++++ 3 files changed, 56 ...

There was a recent discussion on this. The index family uses glob, the tree family uses leading-path only. The one implemented for grep can do both, and attempts to unify both by providing possibly reusable interface so that the other two families can be ported to, but we haven't managed to trick anybody to take up the task ;-). --

Hallo, after reading Junio's nice blog today where he explained how to use git grep efficiently, I saw him using a glob to match for the interesting files: $ git grep -e ';;' -- '*.c' Is it possible to have the same feature in git diff and the revision machinery? Because I tried $ cd $path_to_your_git_src_dir $ git log master -p -- '*.h' .... No commit shown $ git diff --name-only v1.5.0 v1.6.0 -- '*.c' and both don't return anything. Grettings, Peter Baumann --

Some distributions include the Apache httpd server as just "httpd", but specifying the option --httpd=httpd doesn't work, as git-instaweb uses the program name to detect the type of server used. Now the output if $httpd -v is used to also detect the server type. Remove also the hard-coded path to apache2 modules, use apache2's compilation options. Signed-off-by: Luciano M. F. Rocha <luciano@eurotux.com> --- git-instaweb.sh | 137 +++++++++++++++++++++++++++++++----------------------- 1 ...

This one fails to compile, Description Resource Path Location Type fPreview cannot be resolved GitDecoratorPreferencePage.java org.spearce.egit.ui/src/org/spearce/egit/ui/internal/preferences line 279 Java Problem With patch 9 things build again, but swapping the patches does not help. Every patch should build and pass unit tests so we can perform bisect over the patches. -- robin --

Not all resources have corresponding labels that are visible, so by using LabelProviderChangedEvent() we ensure that only the visible labels are refreshed. The downside is that we lose project precition, so all projects are included, but only visible labels in those projects are re-decorated, so it is OK for now. Signed-off-by: Tor Arne Vestbø <torarnv@gmail.com> --- .../decorators/GitLightweightDecorator.java | 28 +++----------------- 1 files changed, 4 insertions(+), 24 ...

The option "Re-decorate ancestors..." controls if parents of a re-decorated resource also should be updated, for example to to signal that the containing folder is now concidered dirty. The option "Maximum number of levels..." controls how deep the container decoration algorithm will recurse when trying to determine the state (dirty, staged, etc.) of a container. Signed-off-by: Tor Arne Vestbø <torarnv@gmail.com> --- .../egit/ui/PluginPreferenceInitializer.java | 4 +- ...

Copied verbatim from org.eclipse.team.internal.ui and documented Signed-off-by: Tor Arne Vestbø <torarnv@gmail.com> --- .../src/org/spearce/egit/ui/internal/SWTUtils.java | 595 ++++++++++++++++++++ 1 files changed, 595 insertions(+), 0 deletions(-) create mode 100644 org.spearce.egit.ui/src/org/spearce/egit/ui/internal/SWTUtils.java diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/SWTUtils.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/SWTUtils.java new file ...

- Dirty - Staged - Conflict - Assume valid Signed-off-by: Tor Arne Vestbø <torarnv@gmail.com> --- org.spearce.egit.ui/icons/ovr/assume_valid.gif | Bin 0 -> 85 bytes org.spearce.egit.ui/icons/ovr/assumevalid.gif | Bin 64 -> 0 bytes org.spearce.egit.ui/icons/ovr/conflict.gif | Bin 64 -> 194 bytes org.spearce.egit.ui/icons/ovr/pending_add.gif | Bin 64 -> 0 bytes org.spearce.egit.ui/icons/ovr/pending_remove.gif | Bin 111 -> 0 bytes ...

Copied largly from org.eclipse.team.internal.ccvs.core (CVS) and org.tigris.subversion.subclipse.core (SVN), and then cleaned up. Signed-off-by: Tor Arne Vestbø <torarnv@gmail.com> --- .../src/org/spearce/egit/core/GitException.java | 168 ++++++++++++++++++++ 1 files changed, 168 insertions(+), 0 deletions(-) create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/GitException.java diff --git a/org.spearce.egit.core/src/org/spearce/egit/core/GitException.java ...

This series adds support for customizable label decorations, which is usefull for hiding selected decorations, or tweaking the format of the decoration text. Changes in v2: - Fixed layout issues in preference dialog - Icons replaced to match established conventions - 'Assume unchanged' icon is back - Added tooltips in the preference dialog - 'Added and dirty' is now decorated appropriately - Refactored container decorations. Now shares code path with files for more accurate ...

If that is the only gripe and otherwise if you are Ok with the patch, I'll queue the entire series with a fix-up here myself. --

Signed-off-by: Ted Pavlic <ted@tedpavlic.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> --- contrib/completion/git-completion.bash | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index f44f63c..6bbe09a 100755 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -80,7 +80,7 @@ __gitdir () # returns text to add to bash PS1 prompt (includes ...

Signed-off-by: Ted Pavlic <ted@tedpavlic.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> --- contrib/completion/git-completion.bash | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index f44f63c..6bbe09a 100755 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -80,7 +80,7 @@ __gitdir () # returns text to add to bash PS1 prompt (includes ...

Yes, this patch is fine, if you can hand-fix the whitespace damage, please feel free to add my Ack. -- Shawn. --

[Empty message]

> What's with this funny indentation? In Vim, I have "exapndtabs" set by default. I manually turned it off, but during testing, I must have closed Vim and re-opened and forgot to turn it back off. Some time ago, I suggested adding a vim modeline to the file to handle turning expandtabs off for everyone who edits it with vim. That change got denied. If you'd like, I can clean up the whitespace and resubmit with Shawn's Acks. --Ted -- Ted Pavlic <ted@tedpavlic.com> Please ...

The local coding convention in bash completion is to use [...] rather than test. Additionally, if [...]; then is preferred over if [...] then and so matching "if [...]\nthen" were changed accordingly. Signed-off-by: Ted Pavlic <ted@tedpavlic.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> --- contrib/completion/git-completion.bash | 31 +++++++++++-------------------- 1 files changed, 11 insertions(+), 20 deletions(-) diff --git ...

If .git/HEAD is not readable, __git_ps1 does nothing. If --is-in-git-dir, __git_ps1 returns " (GIT_DIR!)" as a cautionary note. The previous behavior would show the branch name (and would optionally attempt to determine the dirtyState of the directory, which was impossible because a "git diff" was used). If --is-in-work-tree, __git_ps1 returns the branch name. Additionally, if showDirtyState is on, the dirty state is displayed. Signed-off-by: Ted Pavlic <ted@tedpavlic.com> --- ...

What's with this funny indentation? As a general rule, it usually is a good idea to apply clean-up to the codebase before starting substantial work, but that holds true only when the clean-up is undisputed. Otherwise you would end up holding the later, more "interesting" work a hostage to an earlier potentially controversial "clean-up". I think this particular clean-up makes the odd-ball __git_ps1 more consnstent with the rest of the script, but it ultimately is Shawn's call. --

I can't reproduce the problem here. It looks like your receive-pack is somehow broken (which should be the only difference between pushing to a local repo and a remote one). Can you try with a vanilla version of git to be sure it is not your add-on patch responsible? -Peff --

Define "moving the repository". More often than not, people move their repositories with "git clone" than "tar cf - | tar xf -". No matter how you are moving it to a new location, you would want to have a working set of "regular environment" you normally work in. Why aren't you moving/copying your $HOME/bin at the same time to get a more familiar and useful environment? Viewed under this light, I think your "I move my repository to a new machine" is a made up example that is not ...

Hello all! I've encountered the following error situations: git fails to push a branch over ssh to localhost, even with file: protocol it has the same behaviour... Please see the transcript... (Git version is 1.6.1.1) I don't think I'm doing something wrong, because this works just fine with a real remote host... Thanks, Ciprian Craciun. P.S.: I'm using a slightly modified version of Git, but this patch affects only the PATH-like search mechanism for git ...

You are not answering my question. I questioned the sanity of putting the scripts in .git/bin/ per repository. Why shouldn't a useful script like your "branch-import" available to _all_ your repositories, possibly taking customization per repository from repository's .git/config file, so that it does what is appropriate in each repository? --

Indeed it gets called twice... Here is what I'm trying to accomplish: I want to add to the git search path also the folder ${GIT_DIR}/bin if this already exists... (This allows me to have repository specific commands...) So in order to obtain GIT_DIR (get_git_dir function), I have to call setup_git_directory_gently... Is there another way to obtain the right GIT_DIR? Ciprian. --

Indeed it seems it's from my patch... Because with a vanila 1.6.1.1 it works perfectly... I'll dig into what I've done, although I couldn't imagine that it was from my patch... For now I see that the problem comes from the function setup_git_directory_gentry which I call inside the setup_path function in exec_cmd.c Can someone help? (My patch is below...) Thanks, Ciprian Craciun. -------- diff --git a/exec_cmd.c b/exec_cmd.c index cdd35f9..1513ee0 100644 --- ...

Well, it is per-repo because I've left out to tell you that the git-branch-import command I use to track non-git source code distributions for other projects... And my command constructs the branch name in a certain way... Anyway, I don't see why it's wrong to have such a bin folder per repository... Let's for a moment assume that there is a use case for such a thing, I'm wondering what is wrong with this solution from a Git perspective??? Ciprian. P.S.: It seems that ...

By moving the repository I mean moving it on another machine... Let me give you an example... Thus (inspired by one of my current usages of Git) suppose I'm working at a scientific project (let's assume algorithmic nature) and after I succeed in having a working version of my algorithm, I decide to test it on a better hardware with bigger workloads... For this I make a tar of my repository, and un-tar it on the remote machine. (On this remote machine, as I don't have administrative ...

I'll merge both Junio's and Jeff's emails into one... My answers bellow. Indeed my problem could be solved by either of the solutions proposed (I'll summarize them for the sake of completeness): * using git alias to put simple inline scripts (without need of a new file), or to put the path to the real script; * putting the new command into a directory that is referenced from PATH; Both these solutions work fine, except one concern: when moving the repository I would ...

In the Compare With... menu, the "compare with index" action opens a diff editor that compares the workspace version of a file and its index version. Signed-off-by: Yann Simon <yann.simon.fr@gmail.com> --- My plan with the compare editor is to allow to add some contents into the index (partial commits). I do not know yet how to achieve this. I did not find how to commit only the index with the eclipse interface. So I guess comparing with index does not bring a lot of value for ...

So this trumps Documentation/CodingGuidelines, which says: - We prefer "test" over "[ ... ]". ? Thanks -- Ted -- Ted Pavlic <ted@tedpavlic.com> Please visit my ALS association page: http://web.alsa.org/goto/tedpavlic My family appreciates your support in the fight to defeat ALS. --

I see. At first, it seemed like it would be useful to know if the working directory was dirty even when you're within .git. However, I guess that's problematic when your working tree is in some completely unpredictable location. It's probably a bad idea to assume that work-tree=.. So you're right... there's a logical problem with having showDirtyState turned on when within .git. It should be disabled there. So I'll check for "git rev-parse --is-inside-git-dir" and disable ...

NAK. This script only runs in bash. bash supports [...]. The prevailing convention in the script is to use [...]. Only 4 tests inside of __git_ps1 use "test", the rest of the code is using [...]. I would agree to a test->[...] conversion patch as its fairly small, but not this one. Too large, too much code churn, no benefit. -- Shawn. --

Why ".."? What prevents you from "cd .git/refs/heads"? Your "is-inside-work-tree" might be a good change, but if you were to spend a letter to notify the users, "Warning: You are inside GIT_DIR! This is something unusual, proceed with caution." is a lot more important notice to give them than "You seem to have unstaged changes" notice. You have at least three possible states: * You are not in git repository at all; * You are somewhere in $GIT_DIR, perhaps in a bare repository, ...

In the single case of: if [...] || [...] changed to: if test ... || test ... However, if test ... -o ... might be favorable (although arguably less readable). Also changed: if test ... then to: if test ...; then Signed-off-by: Ted Pavlic <ted@tedpavlic.com> --- contrib/completion/git-completion.bash | 91 ++++++++++++++----------------- 1 files changed, 41 insertions(+), 50 deletions(-) diff --git a/contrib/completion/git-completion.bash ...

Several functions make use of "test -n" and "test -z". In many cases, the variables being tested were declared with "local." However, several __variables are not, and so they must be replaced with their ${__-} equivalents. Signed-off-by: Ted Pavlic <ted@tedpavlic.com> --- This patch depends on: <1234366634-17900-3-git-send-email-ted@tedpavlic.com> "[PATCH 2/3] completion: Change "if [...]" to "if test ..." to match git convention" If that patch is ...

Looks OK to me, but I NAK'd the dependency, so you'll have to rebase it without the dependency in there. Or talk me into why that much -- Shawn. --

Three more patches to git's bash completion script. The first two are non-critical: * The first patch changes two "git rev-parse" calls to "__gitdir" to match the convention used in the rest of the script. * The second patch changes "[...]" to "test ..." to match git convention. In the one case of "[...] || [...]", a "test || test" call is used. Alternatively, a "test ... -o ..." call could be used, but that might not be as readable. The third fixes an ugly error in the new ...

If a custom $filter_commit calls 'exit', there won't be an error message from git. Of course, there may be an error message from the custom $filter_commit, but I decided not to rely on that. Would you prefer me to remove the error message? I'll have another patch ready shortly, incorporating your suggestions. My apologies for giving credit in the wrong part of the commit message, and thank you for your feedback! Cheers, Eric --

The commit message is not a reception speech at Emmy Awards. If you want to do the speech, do so after the three-dash lines. Please just stick to what problem it tries to solve, how it does so, and That's a very good start for the description of the solution, which would Giving credits to others like this with a short sentence at the end is This goes after three-dashes; people who read "git log" output wouldn't know nor care what was in v1. Subject: Fix X under condition Z ...

In commit 9273b56278e64dd47b1a96a705ddf46aeaf6afe3, I fixed an error that had slipped by the test suites because of a missing check on 'git read-tree -u -m HEAD'. I mentioned to Johannes Schindelin that there were several bugs of this type in git-filter-branch, and he suggested that I send a patch. I've tested this patch using t/t7003-filter-branch.sh, and it passes all the existing tests. But it's entirely possible that this patch contains errors, and I would love input from people who have ...

I think it's OK to die if the commit filter fails. But generally, I think it is not necessary to use 'die with error message', a plain '|| exit' should be enough because an error will have Here you shouldn't die. But unlike elsewhere, this case warrants an explanation for the user: git read-tree -u -m HEAD || -- Hannes --

Hi, I haven't checked, but is "$tempdir" not the working directory? If so, this would lead to funny interaction with --tree-filter. Rather, I'd That's not how it is supposed to be used. Rather, test_expect_success $LABEL ' test_must_fail git filter-branc $OPTIONS ' Thanks, Dscho --

Hi, Thanks. Although it lacks a Sign-off, and part of the commit message is This will catch errors in the update-index call, but neither in diff-index nor ls-files. Otherwise, the patch looks good to me. Ciao, Dscho --

I'm interested if there is some document that specifies the approach of encoding non-ASCII file names used by the git and related issues. I'm particularly interested in cross-platform issues, since I'm writing plugin for cross-platform tool. My understanding based on previous discussions of the issue is that GIT saves file names as bytes in the tree objects without specifying actual encoding used. And there will be problem if different clients use different system encoding. The list of ...

This recipe sends gitk into an endless loop. In git.git do: cd t # remove chmod a+x A near the end of the file sed -i 's/chmod/: chmod/' t3400-rebase.sh sh t3400-rebase.sh --debug cd trash\ directory.t3400-rebase/ gitk master modechange modechange@{1} I briefly see the history chart, but the dot that should be modechange@{1} is missing. One automatically selected commit is shown in the diff section below. But then the commit list is cleared and gitk goes into an infinite loop. Things ...

hmm... These seem to work here. I have to use Cygwin. Do you use the native port? --

Very interesting. This test works unmodified here. On the other hand, I have to skip the entire t4129-apply-samemode.sh. -- Hannes --

Well, mostly these should work independent of the filesystem (except for the cases when the index is checked out later). They seem to, and they look like they should, too. See t4014-format-patch, for one. But you're right. I should have reviewed them earlier. Anyway, there is not many tests which have "--chmod" in them: t4006-diff-mode.sh, t4014-format-patch.sh, t6031-merge-recursive.sh, and t9500-gitweb-standalone-no-errors.sh. The t4006 does not bother to look at working tree (good), t4014 ...

I'm CC'ing a couple people who replied to the thread I referenced earlier, in case they're interested and would otherwise miss this message. Especially Marc Weber, who expressed interest in having a good solution to this problem. Does this address what you wanted? I like it because it allows you to transparently and automatically enforce style policy and: - it doesn't require modifying git, - it's efficient (no overhead except on commit), - it doesn't pretend to be a clean/smudge ...

I'm sorry about that. Appearently I was working with an out of date repository and plugin. I also agree that fixing it in the getter is a better idea. This was my first patch for egit, looking forward to more. I'll try to double check better though :-) --

It does, so this patch is redundant. I also thing Yann's patch was the correct place for the handling the problem. -- robin --

The `sort' Elisp function works destructively, causing anomalies where operations on multiple files would be performed on one file. This checkin works around that by doing a deep copy with `append'. Also, git-add-file needed to pass 'modified to git-marked-files-state, as otherwise, files that are modified but not yet in the index would not show up in the git-marked-files-state return value, which would then cause a prompt for file to show up when the files are clearly marked in the status ...

Yeah, I also saw a speed-up, though the difference was less pronounced -- 19.7 seconds versus 19.5 (that was the average for 5 runs, after first doing a run that I ignored to make sure I was comparing hot-cache to hot-cache). I'm a little surprised why my numbers were so much lower than yours, though. I don't think of my hard drive and CPU as being all that quick -- is this a difference in packing, by chance, with your repository not having recently been repacked? --

Nope. See how the CPU is more or less pegged in the numbers above? Cold cache looks like this: $ echo 3 >/proc/sys/vm/drop_caches $ time git fast-export --all --signed-tags=strip >/dev/null real 1m11.148s user 1m3.952s sys 0m0.760s So only 7 extra seconds paging in. Hooray for packing. :) -Peff --

Hi, ACK. Ciao, Dscho --

From: Elijah Newren <newren@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> --- I'm not certain this testcase will actually trigger the bug for everyone, since I don't know the order of commits used by git rev-list. It does trigger it for me. What you need is a history that looks like B--D / / A--C with the master branch pointing at D, and have "git rev-list --all" show these commits in the order C D B A If you have such a repository, "git fast-export ...

Hi, Or a warm against a cold cache? Hides, Dscho --

There is currently no porcelain for dealing with remote HEADs (i.e. $GIT_DIR/remotes/<remote>/HEAD). This series: 1) Teaches git remote a new "sethead" verb: To set a remote HEAD explicitly: $ git remote sethead <name> <branch> To set a remote HEAD to match the upstream repo: $ git remote sethead <name> -a To delete a remote HEAD: $ git remote sethead <name> -d 2) Teaches git remote show to display the remote HEAD: $ git remote show origin * remote origin URL: ...

The remote HEAD cannot be determined unambiguosly, so use the same heuristics as builtin-clone's locate_head(). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> --- builtin-remote.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 files changed, 39 insertions(+), 0 deletions(-) diff --git a/builtin-remote.c b/builtin-remote.c index 00e7ca5..0be8bfd 100644 --- a/builtin-remote.c +++ b/builtin-remote.c @@ -212,6 +212,7 @@ static void read_branches(void) struct ref_states { struct ...

I have some extremely large git repositories which I want to split into modules. This could be done using 'git filter-branch' and the following steps: 1) Create a submodule using --subdirectory-filter. 2) Create a superproject using an index filter to delete the submodule. 3) Commit the submodule to the latest version of the superproject. Unfortunately, this approach loses all the historical connections between the superproject and the submodule, breaking tools like 'git bisect', and ...

Aaah -- thanks! I should have known there'd be an easier way... :-) --

Sensors responding with 0x3B to WHO_AM_I only have one data register per direction, thus returning a signed byte from the position which is occupied by the MSB in sensors responding with 0x3A. We support both kind of sensors by checking for the sensor type on init and defining appropriate data-access routines and sensor limits (for the joystick) depending on what we find. Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> --- As pointed out by Eric, there's no need to jump through ...

On Wed, Feb 11, 2009 at 12:58 AM, Ulrik Sverdrup Ok I didn't test this. Stash creation fails because the add -N status is not quite "tracked but no content staged", but rather you _have_ to stage the files at a later point. git add -N is just a reminder thing? Error output: plugin-gui.log: not added yet fatal: git-write-tree: error building trees Cannot save the current index state Shame, I wish the above script worked. --

Thanks to Anton Gyllenberg <anton@iki.fi> for the bug report Signed-off-by: Eric Wong <normalperson@yhbt.net> --- Thanks Anton, I've made the following patch along with your testcase and pushed to git://git.bogomips.org/git-svn Can you let me know if it works on a real repo (or breaks anything else)? It's once again way past my bed time... git-svn.perl | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/git-svn.perl b/git-svn.perl index ...

I agree. I'm happy to hammer out and implement new output for 'remote show', but is there any chance that such a change would be accepted? How about something a bit tighter, merging the local branch list with the remote branch list: * remote origin URL: git://git.kernel.org/pub/scm/git/git.git Remote branches: html Not tracked master Tracked by local branches: master (merges) mywork (rebases) next Tracked by local branch: ...

I find this form more useful than the one below because of the clear -- Hannes --

Hi, Well, I think in the case of notes, we have to optimize for random access of dozens of blobs rather than for merging. I was well aware that the merging is more expensive when the hierarchy is not defined a priori. Ciao, Dscho --

That was my first thought, as well. Maybe your original implementation wasn't so bad, after all. :) I searched through the archive to find a list of criticisms, but I didn't see any. So I guess the problem was just a concern that it might end up too complex. -Peff --

Hmm, ok drop the error at that point. But maybe we'd need to save it so we can display it in case the recovery fails, in which case it may actually contain some useful hint about went wrong. -- robin --

A repack may or may not yield a better packed repo. In this case, not, but for a different reason than failing to find better deltas. Given the circumstances that is most likely to cause the "failure (repacking on windows), this is "normal" behaviour and no reason to scare the user with an error code. The unlink error might be enough. I think scripts should be able to continue too. The alternative would be to have a switch to repack that scripts and UI's could enable, like -q for "don't flag ...

'xmalloc' followed immediately by 'memset' is replaced with 'xcalloc', and a simple grep in this project seems to show that it's the only place. Signed-off-by: Guanqun Lu <guanqun.lu@gmail.com> --- sha1_file.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/sha1_file.c b/sha1_file.c index 8868b80..93e5fc0 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -858,8 +858,7 @@ unsigned char* use_pack(struct packed_git *p, static struct packed_git ...

Hmm, what does this line do, and why isn't it needed anymore? I don't know this part of StGit, I'm just curious ... -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle --

Yeah, I can't find anything more to complain about. :-) Acked-by: Karl Hasselström <kha@treskal.com> -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle --

Yes, one advantage of having it here is that if the user resolves the conflict, we can just continue. I'm not sure I personally like that mode of operation -- you might have guessed by now that I like noninteractive mechanisms -- but I can see how it's useful to someone who does. Another advantage of having it here is that it automatically just works for all commands, not just "stg push". The disadvantage that I see is that we ask the user to put work into resolving conflicts before ...

That's whitespace corruption. -- Shawn. --

The previous implementation made the assumption that the Signed-off-by is always on the last line. Correct this assumption and deal with Signed-off-by everywhere in the commit message. Signed-off-by: Yann Simon <yann.simon.fr@gmail.com> --- This patch should correct this assumption. -- yann .../egit/ui/internal/dialogs/CommitDialog.java | 65 ++++++++++++-------- 1 files changed, 40 insertions(+), 25 deletions(-) diff ...

Thanks, both. --

That's not the problem; the problem is calling free on a struct packed_git that has been given to unpack_entry(), because it raises the possibility of having the memory allocated to a different pack in the future and ending up with actively wrong entries in the delta cache, since it keys off of the pointer. I think free_pack_by_name() also needs to drop the entries that are from the freed pack, to avoid having repack able to get the same problem, although I wouldn't be surprised if ...

Yeah. I see your point and you may be right, that a 12/28 split hurts no-one, if we take this to the benchmarks. There's certainly savings in terms of total object count for the small users by using a smaller split. I just already wrote the code to handle an arbitrary split for the features written so far[1]. If *I* can write it, in C, it means it must not be that complicated ;-) So it comes down to how complicated things are when merging happens. If 12 is fixed in stone this is simple, ...

But what's the advantage of the added complexity? The non-fixed trie only helps for the case that doesn't matter - just a few annotations. If you have a thousand annotations or less, you _really_ don't care. Whatever you do will be fine. So the whole thing only matters once you have tens of thousands of entries, and then you do want to have fan-out. No? Linus --

Great idea! Glad I thought of it! ;-) http://thread.gmane.org/gmane.comp.version-control.git/106715/focus=107975 I hoped my approach allowed for smarter things later, such as splitting into smaller buckets whenever a directory gets more than N entries or periodically rebalancing if required. But the initial version is at least forward thinking to support reading it. Merging them will need to be savvy of this of course. Sam. --

That sounds unnecessarily complicated. It also really sucks for the case you want to optimize: small differences between trees, where you don't need to even linearize the common parts. Why not make it just a straight fixed 12-bit prefix, single-level trie. Sure, if you have less than 4k objects, it's going to add an unnecessary indirection, and close to an extra tree object for each object. But it should scale pretty well to a fairly huge numbe of notes. IOW, if you have less than ...

Yes. And also for an "--untracked" (as already suggested). Since stashes does not expire anymore (as correctly pointed by Brandon), a snapshot could be reduced to an alias for: git stash --no-reset --untracked (except for the branch storage) However, the rationale behind a new command was also to avoid the 'loss of identity' of stash (as currently implemented). I always saw stash as a way to allow a temporary hack or a pull. If we start adding a lot of switches into stash that ...

Sure, I was just responding to that particular statement about reset. But I think it generalizes. Why not "--untracked" as an option? In other words, there are several behaviors that people might not like about stash, and I think they can be combined in multiple ways. So one solution is to make another command which chooses a different set of behaviors. But what about the person who wants "--untracked" but not "--no-reset"? Do they make a third command? So it is much more flexible to make ...

Thanks, good idea. I changed the code to parse the required data, and we're now up to 1502 annotations. Unfortunately I noticed there's a bug in the mail input stage: Python's mailbox module assumes any '^From ' line starts a new mail, while gmane apparently uses a slightly different format based on the double newlines too (and they always have the same 'From news@gmane.org Tue Mar 04 03:33:20 2003' separator too), and doesn't quote '^From ' in the bodies. So any mail containing such body ...

cc0e6c5 (Handle return code of parse_commit in revision machinery, 2007-05-04) attempted to tighten error checking in the revision machinery, but it wasn't enough. When get_revision_1() was asked for the next commit to return, it tries to read and simplify the parents of the commit to be returned, but an error while doing so was silently ignored and reported as a truncated history to the caller instead. This resulted in an early end of "git log" output or a pack that lacks older commits from ...

As a bonus, this issues unwarranted warning when creating the initial commit in an empty repository. The following fixes it. -- >8 -- Subject: [PATCH] Squelch overzealous "ignoring dangling symref" in an empty repository 057e713 (Warn use of "origin" when remotes/origin/HEAD is dangling, 2009-02-08) tried to warn dangling refs/remotes/origin/HEAD only when "origin" was used to refer to it. There was one corner case a symref is expected to be dangling and this warning is unwarranted: ...

Hi, This could be the way branching/tagging is done with the repo. git-svn does not handle non-standard branching/tagging practices Hmm.. this is new. Is email_templates.yml an empty file by any chance? If it's an empty file, can you try pulling the latest from git://git.bogomips.org/git-svn and see if that fixes at least this for you? There was a bug that slipped in recently with trying to handle The malformed network data error has not been consistently reproducible for me. I've seen ...

OS X 10.4.11 iTerm 0.9.6.1201 TERM=xterm-color The problem only occurs with "j" and "k" when viewing multi-line displays. I do /not/ see the problem when viewing the one-line changeset history. It only causes a problem when I view the multi-line displays (e.g., when actually viewing a changeset). For example, in git.git, if I "tig" and then scroll through the changesets, I don't see the problem. If I <CR> on a changeset so that it opens in the bottom half of the screen, I see the ...

> What is tig? *) Is there any way for "tig" to emulate "less -R"? That is, if an output is already colorized, can tig just pass through the ANSI? *) When doing "git diff|tig" when there directory is clean, tig should probably exit immediately, right? *) Also, is there a way to configure "tig" to colorize and *exit* if the piped text doesn't fill a page? (in other words, I'd like "tig" to be able to replace my current "less -FRX" pager) Thanks -- Ted -- Ted Pavlic ...

[ Sorry for the late reply, I did not read my mail recently. ] On Fri, Jan 30, 2009 at 02:28:39PM +0100, Johannes Schindelin <Johannes.Sch= So in an "I know what I'm doing" mode, is "git config core.bare true" in a non-bare repo considered as a better workaround than using "git config receive.denyCurrentBranch ignore"?

On Fri, Feb 6, 2009 at 18:00, Giuseppe Bilotta Sorry the topic's cold, but... git reflog? Seems like one could find the oldest time the commit appears in the reflog, for the branch one is interested in. You can use the commit time to limit the search through the reflog, but there would be clock skew concerns. Deskin Miller --

Assuming that you have reflog enabled (yes, it is default now)... So you would have to provide fallback in the case there is no reflog. BTW. "git reflog" is porcelain; it would be better to parse reflog directly, I think. -- Jakub Narebski Poland --

I have not. I've seen only that it's POSIX, is on BSD and Linux, and Actually, since I haven't heard any continued interest in following up with the suggestion to use "cd -P", I don't see much benefit myself, and there is concern about it not being compatible enough, I'm content to just table this. I agree that keeping working setups working is important, and it seems like a major project to research portability of "cd -P" on a list of platforms that I'm guessing I'd have to collect ...