Generate the CVS author names by taking the first eight characters of the user part of the email address. The resulting names are more likely to make sense (or at least reduce ambiguities) in "corporate" environments. Signed-off-by: Damien Diederen <dash@foobox.net> --- git-cvsserver.perl | 18 ++++++++++++++---- 1 files changed, 14 insertions(+), 4 deletions(-) diff --git a/git-cvsserver.perl b/git-cvsserver.perl index 3c97226..9d845c8 100755 --- a/git-cvsserver.perl +++ ...

The "File:" header of CVS status output only includes the basename of the file, even when generating a recursive listing; do the same. Signed-off-by: Damien Diederen <dash@foobox.net> --- git-cvsserver.perl | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/git-cvsserver.perl b/git-cvsserver.perl index 33d30c5..9101eef 100755 --- a/git-cvsserver.perl +++ b/git-cvsserver.perl @@ -1466,8 +1466,10 @@ sub req_status $status ||= "Unknown"; + my ...

This series was developed to improve interoperability between git-cvsserver and TkCVS, a CVS client that is fairly popular at least in some corporate environments. Patches 1-6 are "obvious" improvements, implementing missing features or fixing incorrect behaviour. 7 is more questionable, but likely to result in more intelligible log output in a majority of cases. Bear in mind that my perl-fu is not very high when reviewing this series; suggestions are more than welcome! ...

Cvs update -p -r <rev> <path> is the documented way to retrieve a specific revision of a file (similar to git show <rev>:<path>). Without this patch, the -p flag is ignored and status output is produced, causing clients to interpret it as the contents of the file. TkCVS uses update -p as a basis for implementing its various "View" and "Diff" commands. Signed-off-by: Damien Diederen <dash@foobox.net> --- git-cvsserver.perl | 36 ++++++++++++++++++++++++++++-------- 1 files changed, 28 ...

Hello, I cloned a repo from another with symbolic links. Now the symbolic links appear as modified files, and nor resetting, nor committing, nor ignoring, nor `rm --cache`ing will take them out of their dirty state. If I try to commit them, I get error: readlink("lib/systems/asdf-system-connections.asd"): Invalid argument fatal: unable to index file lib/systems/asdf-system-connections.asd The link, however, is fine: it points to a valid, existing file, which I can read through the ...

Not my mumbling, but I am quite open to slurp in guilt as a subdirectory in git.git at some point in the future just like we bundle git-gui and gitk if asked by the maintainer. The same applies to StGIT for that matter, although I somehow feel that is much less likely to happen, because it lived long enough as a standalone project with enough following to achieve sustainable momentum by itself. --

I always wondered what the difference between stgit and guilt is. Does anyone have a comparison up? --

It was Linus indeed, on the linux-arch mailing list: http://www.mail-archive.com/linux-arch@vger.kernel.org/msg05012.html -- Catalin --

Junio, That'd be great! Is there anything special you want me to do? Well, I want to finish up a merge I've been working on first. Josef 'Jeff' Sipek. -- Once you have their hardware. Never give it back. (The First Rule of Hardware Acquisition) --

Git rebasing is useful but using a patch management tool is much easier, especially when you need to post a series of patches multiple times while implementing others' comments. And this is not only for private branches but public ones that are meant for upstream merging. The problem with these tools is that they rewrite the history of the repository but they are OK if you aren't in a position where people need to base their work on your tree. I would much prefer to simply commit the ...

It's still using two-way diff apply, but I'd like to implement a three-way merge as a fallback. Josef 'Jeff' Sipek. -- The box said "Windows XP or better required". So I installed Linux. --

I would like to tell git log "Do not list, or list in very abbreviated form, commits with greater than N diffs". The man page does not seem to indicate that this could be done. Is there a way to do this? Bill --

Hi, I would like to merge the 3 git repositories of the history of linux, the one by Dave Jones from linux 0.01 to linux 2.4.0, the one by tglx from 2.4.0 to 2.6.12 and the one from 2.6.12 by torvalds until the last version of Linux. Right now there are 3 repos and I would like only one. I made some scripts to create a fresh repo, and incorporate each commit from the 3 repositories mentionned above (getting the changelog, setting the date), but it takes lots of time because for instance ...

Sorry, I really don't know where else to ask. I've been using Staminus for a while now and I've had it with the downtime. Basically I want a place to host my Ruby on Rails / Git projects, an IRC server as well as an internet radio channel. Simple website / control panel design is ofcourse a plus. None of that cpanel bullshit though, I prefer to meddle around with simple text files the way it's meant to be done. So, layeredtech.com? rackspace.com? And is there a place that reviews ...

If asked a couple weeks ago I would have suggested layeredtech, but I'd tend to discourage it now as I ran into a succession of issues that they took too many time to fix (ip addresses not routed to my box, almost 72h of downtime) Actually, if you aren't running a very critical service that you rely on, it is a pretty good service. It's just that when they fuck up, they fuck up big time :) Gilles -- Gilles Chehade --

Hi, Funny. I thought bare repositories were meant for public consumption. And for testing, you still can have a (non-public) repository with a work-tree. I'd rather not try to tell users that it is okay to mix the two. Ciao, Dscho --

Hi, It would not, because it is not activated by default. Only newly Okay, I am starting to see the light. How about receive.localBranches = (refuse | allow) with a default "allow"? Then we could add more rope later with the "update" option, which would run "git read-tree -u -m HEAD" if the current branch is updated, and simply allow all other branches being updated. Hmm? Ciao, Dscho --

For a while now, git-checkout has been more powerful than the man-page summary would suggest (the main text does describe the new features), so update the summary to hopefully better reflect the current functionality. Also update the glossary description of the word checkout. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> --- Ok, so more like this? I've updated the glossary entry for checkout too, though I'm thinking that there ought to be a clearer way to explain it ... ...

Note that you need to change also the corresponding string inside builtin-tag.c , the lines printed when you run "git tag -h". -- Carlos --

From: Dirk Süsserott <newsletter@dirk.my1.cc> Described that '-a' is implied when '-m' or '-F' is present. --- Oh, I see you already took my suggestion before I made it. :) The text looks good to me, but the patch would not apply here. I think there are some wrapping issues, and it looks like some tabs have been mangled to spaces. Also, it is generally a good idea to: - at least cc Junio on patch submissions to make sure he sees it - sign off your patch (either with commit -s or ...

Heh, and you did not sign it off when you forwarded? ;-) --

hmm... Sounds great! where's your git repos :) regards, junichi -- dancer@{debian.org,netfort.gr.jp} Debian Project --

Right click on patched file list view gives "External diff" popup menu entry, launching selected external diff tool. The diff tool is configurable through Edit/Preference/External diff tool. Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> --- Hi, Here is a patch to gitk that allows to run an external diff viewer. It can be configured in Edit/Preferences/External diff tool. To see the diff between two files: - select revisions to diff - right click on a file in the patched files ...

Ups, sorry, Wincent, not Vincent. --

Well, "no se puede" has 3 more characters than "no puedo", this was the primary reason why I switched to the first person form. Spanish is way more verbose than English. what about "Error analizando la salida de git log:"? it is impersonal and shorter than the original one. done. This is not a good thing, as it means that I lost changes with my poor git abilities :( I actually translated those lines, but the last changes got lost I think I have taken care of most/all of the ...

I use the most recent git from master, and simply do git-add and git-commit without arguments after having resolving the conflict. The commit message in MERGE_MSG, that I checked, does have the "cherry picked from commit <id>" mention (before the conflict list). --

So this patch fixes the docs to reflect that. Signed-off-by: Rafael Garcia-Suarez <rgarciasuarez@gmail.com> --- Documentation/git-cherry-pick.txt | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index f0beb41..475e168 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -29,8 +29,7 @@ OPTIONS -x:: When recording the commit, append to the original commit ...

OK, so I decided a few weeks back that the history page was not fast enough. I think I've spent the past 3 weeks writing true revision machinary for jgit, and now connecting it up to a UI visualizer. git://repo.or.cz/egit/spearce.git plotter The history page has been completely replaced. I saw Roger has some patches against the current history page. :-| There are huge benefits to this infrastructure: * Fast as snot. We are literally just 10-20 ms slower than C Git on the same ...

Did you lose compare? Ok, found it, but it only shows one file in the compare editor, so I cannot walk through all changes in the commit with Ctrl-. and Ctrl-, -- robin --

Add it in the source and the Italian translation, the German translation does not have the string. The Spanish translation already contains it. Without it the formatting of the help page is not right here. Signed-off-by: Santiago Gala <sgala@apache.org> --- gitk-git/gitk | 2 +- gitk-git/po/it.po | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/gitk-git/gitk b/gitk-git/gitk index 84ab02e..6fe454b 100644 --- a/gitk-git/gitk +++ b/gitk-git/gitk @@ -1370,7 ...

A while ago, there was some discussion about authenticating commits using gnupg signatures. (see http://kerneltrap.org/mailarchive/git/2008/1/29/634209). I have searched through all of the branches in the main git repo and I can't see any commits relating to this functionality, so I was wondering if the work had stalled or perhaps not even been started. If that's the case, I'm willing to give it a shot and would welcome some discussion on how to get started. The posts in the aforementioned ...

Good ui, but I don't like the filter (seem you didn't either from your comment) so I suggest inserting this patch before the 4/4 patch of yours. Then in your patch drop the filter and fix the call to getHistory. This will improve performance since the "current branch only" will be the view I (and probably most other people) will use the most. @@ -868,39 +865,10 @@ public class GitHistoryPage extends HistoryPage implements IAdaptable, .getHistoryFor(startingPoint, -1, ...

Signed-off-by: Roger C. Soares <rogersoares@intelinet.com.br> --- org.spearce.egit.ui/icons/elcl16/refs.gif | Bin 0 -> 340 bytes .../src/org/spearce/egit/ui/FindToolbar.java | 55 ++++++++++++++++++- .../src/org/spearce/egit/ui/FindToolbarThread.java | 58 ++++++++++++++++++-- .../src/org/spearce/egit/ui/GitHistoryPage.java | 2 +- .../src/org/spearce/egit/ui/UIIcons.java | 3 + .../src/org/spearce/egit/ui/UIText.java | 2 + ...

I overlooked this when doing the find toolbar. Fixing now. Signed-off-by: Roger C. Soares <rogersoares@intelinet.com.br> --- Hi Robin, Here goes some more patches for your review. Currently they are on top of the last patches I sent you. Patch 4/4 is the one that shows only the commits in the current branch. I don't see me going through Shawn's new machinery soon, so I'm just sending what I have today as a starting point for the feature. []s, Roger. ...

Last year's GitTorrent implementation never got off the ground. The student who we accepted was unable to actually participate due to legal problems, and we did not find out about it until too late in the program to select a replacement student. So in short, there's nothing wrong with last year's GitTorrent, as there was no last year's GitTorrent. Hence it is on the list again for this year. :) -- Shawn. --

In reviewing the patch just sent in by Santiago Gala (message-id: <1206316703-15481-1-git-send-email-sgala@apache.org >) I noticed the following little problem in the English version of the gitk preferences dialog: What do you think about changing "Select bg" to "Selection bg" (or even "Selection background") in the English version to avoid this kind of misunderstanding in the future? Cheers, Wincent --

Changes to Spanish translation after comments by Wincent Colaiuta in the git list, see http://thread.gmane.org/gmane.comp.version-control.git/77983/focus=78011 Signed-off-by: Santiago Gala <sgala@apache.org> --- gitk-git/po/es.po | 110 ++++++++++++++++++++++++++-------------------------- 1 files changed, 55 insertions(+), 55 deletions(-) diff --git a/gitk-git/po/es.po b/gitk-git/po/es.po index 1e28f11..8a60931 100644 --- a/gitk-git/po/es.po +++ b/gitk-git/po/es.po @@ -30,7 +30,7 @@ ...

Hi Santiago, this is my list of the missing things: Also, this should be "ruta" instead of "path". Below, you also wrote the message: "Limita las diferencias a los path seleccionados", that it will be better written as I also think that this should be better "Cambiar a esta rama" This is mine: I think here you can write something more to the point to avoid repetition, just something like "...o volver a empezar" or "...o reiniciar la búsqueda". How about translating "To" with ...

Hi, That would break this work flow: # machine A $ git push B master:refs/heads/tmp # machine B $ git merge tmp $ git branch -d tmp Besides, there is a _vital_ difference between the current branch, and any other local branch: pushing into other local branches cannot make your working tree stale. Ciao, Dscho --

Hi, http://article.gmane.org/gmane.comp.version-control.git/31896/match=git+merge+make+usable Hth, Dscho --

Interesting. The following patch will change the bahaviour to what your test script expects, but by looking at the original code, you can tell that it is indeed the intended behaviour of "-M' to _allow_ you to _prepend_ your own message to the standardized "Merge these" message, not _replace_ with it. I unfortunately do not recall why _prepend_, and not _replace_, had to be the right behaviour. Unless somebody can point out there was a valid reason but that reason is not relevant anymore, ...

Hi, On Mon, 24 Mar 2008, J

I'll extend this topic a bit for the last time, but first a word of caution. What I am going to draw is probably not what the current -p implementation does. They illustrate what I think should happen. Again, starting from this topology: o---o---o---o---o---Z / X---Y---A---B \ \ C---D---M---E and the goal is to rebase your development leading to E on top of the updated mainline Z. The earlier example was when you want to end up with this ...

Doesn't approxidate return ulong, not uint? --

Hi, Thanks! Ciao, Dscho --

Ooops. To be consistent, these should be OPT__DATE (with two underscores) instead (and in the commit message, too). --

There are quite a few places that will need to call approxidate(), when they'll adopt the parse-options system, so this patch adds the function parse_opt_approxidate_cb(), used by OPT_DATE, and converts the only user so far. Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> --- Oh, right. Somehow I thought it was simpler not to do this. Thank you for your review and suggestions. This is on top of [PATCH 2/2] builtin-prune.c: fix object parsing and use parse_options() ...

T24gU3VuLCBNYXIgMjMsIDIwMDggYXQgNDo1NiBQTSwgIkt5cnJlIE55Z8OlcmQiIDxreXJyZW55 QGJyb2FkcGFyay5ubz4gd3JvdGU6Cj4gSGkgdGhlcmUsCj4gIEhhc2FueWJvZHkgZXZlciB3cml0 dGVuIGEgc2NyaXB0IHRoYXQga2VlcHMgdHJhY2sgb2YgeW91ciBmYXZvcml0ZSBHaXQoYW5kIFNW TikgcHJvamVjdHM/IEUuZy4gc2VuZHMgeW91IGFuIGUtbWFpbCBldmVyeSB0aW1lIGEgcmV2aXNp b24gaGFzYmVlbiBtYWRlLCB3aXRoIGRldGFpbHMgbGlrZSB0aGUgc3VtbWFyeSwgdGltZSBhbmQg ZGF0ZSwgYXV0aG9yIGFuZGNvZGUgZGlmZmVyZW5jZXMuCgpNYXliZSBodHRwOi8va2l0ZW5ldC5u ZXQvfmpvZXkvY29kZS9tci8gPwoKai4K --

Why not subscribe to the gitweb of each one via your RSS reader? Avery --

probably i want too much, but it would be really nice if receive-pack could just make HEAD detached. so that the user later can do a 'git checkout -m master' to resolve possible conflicts.

Yeah, it's not at all intuitive. I've been using git for quite some time and had *absolutely* *no* *idea* that "git checkout <treeish> -- path" did what "bk revert" and "hg revert" does. In fact, I'm pretty sure I remember asking for this functionality a while back, and being told the right answer was "git show HEAD:pathname > pathname", and I kept on typing it until I got sick and tired of it, and so I created my short-hand shell script. And the fact that Peter was using "git reset ...

For a while now, git-checkout has been more powerful than the man-page summary would suggest (the main text does describe the new features), so update the summary to hopefully better reflect the current functionality. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> --- Something like this perhaps? Documentation/git-checkout.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index ...

There is a difference between "checkout HEAD -- $file" and "show HEAD:$file > $file". The former will also update the index, while the latter does not. Maybe you asked for not updating the index back then? Maybe it's just a misunderstanding on my side, but to me "checkout" means as much as "get me something out of the repo". And git checkout does exactly that. It can get you a branch (naturally switching your HEAD to it), or it can get you trees or blobs. The latter can come from either the ...

Texts between ~ and ~ will be subscripted during the asciidoc translation. Signed-off-by: Guanqun Lu <Guanqun.Lu@Gmail.com> --- Documentation/user-manual.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 40b0de0..565aeb9 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -4144,7 +4144,7 @@ commits one by one with the function `get_revision()`. If you are ...

I hadn't thought of that when I gave (1) as an example. I think (2) is Yes, see builtin-tag:430-433 (it is also implied by -F). Care to submit a documentation patch? -Peff --

Thanks for the help. Both (1) atag = !sh -c 'git tag -a -m "$0" "$0"' and (2) atag = !sh -c 'git tag -a -m "$1" "$1"' - work, but in the latter case the '-' is indeed crucial. If not given, $1 is not set and git tag complains badly. When called without any args, (1) sets a tag called "sh" whereas (2) complains about the missing value for the -m option. So I decided to use the second form. Shells are funny things. ;-) BTW: Is it true that "-a" is implicitely added to "git tag" when ...

Hi, I think I sent out a sensible patch, which does not change the behaviour in existing repositories. This should be safer (read: nicer) for Git old-timers. Ciao, Dscho --

I had an impression that that change would break the existing output that somebody other than you are depending on. I personally think it is plausible that everybody wants the new behaviour your patch propose, but that kind of change is not appropriate for 1.5.5 cycle (might be Ok for 1.6.0 after we see agreements on the list), and definitely not something we would want to apply after -rc0. --

Sorry, I may have been unclear but I was wondering more about the case the hook script errored out silently. --

NAK While I agree that preserving autocrlf may be a good idea, I don't like that the idea of making an exception for autocrlf and treating the global settings for it differently than for other variables -- as something that should be copied on init. We have templates for that, so autocrlf should be placed into templates/config and then it will be automatically copied when a new repository is created. I have tested that now, and it works. Dmitry --

Hi, I think I actually suggested something like that. But that gets only even more complicated: if you have a template for .git/config in $HOME/.gittemplates/, then the global template will be _disregarded_, even if the administrator puts something vital in there. Maybe the best idea would be an "init" hook, settable from the config, after all. Ciao, Dscho --

This variable, if set, specifies the path of a hook which is executed after every git-init. It can be used to override settings in the templates per-user. In case of a re-initialization, the hook gets called with the argument "reinit". Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- On Mon, 24 Mar 2008, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > If you want to run a specific script everytime git-init was > > ...

Maybe, because I cannot imagine what so vital the administrator can put in it, I really do not see that as a problem. I believe that any good administrator should notify all users about any vital changes anyway, because if these changes are vital, it may be necessary not only change templates in $HOME/.gittemplates/ (which very few users will probably I agree that seems to be the best solution as it is more flexible than having $HOME/.gittemplates/. Dmitry --

I've got your idea! Thank you :) -- Best regards, anton mailto:agladkov@sw.ru --

http://git.or.cz/gitwiki -Peff --

On 24. mars. 2008, at 16.10, Johannes Schindelin wrote: Sorry to hijack the thread. I've seen you mention using "--all" to filter-branch everything before, but I can't get it to work: % git filter-branch --all Usage: /usr/local/bin/git-filter-branch [--env-filter <command>] [-- tree-filter <command>] [--index-filter <command>] [--parent-filter <command>] [--msg-filter <command>] [--commit-filter <command>] [--tag- name-filter <command>] [--subdirectory-filter <directory>] ...

Try git filter-branch -- --all It is actually an option to rev-parse. -brandon --

Hi, The thing is: signed tags cannot be rewritten. As simple as that. They could be recreated if the committer happens to be the original tagger, but even then, it is a rewrite of _tags_, which are _not_ supposed to be moving targets. So it was very much on purpose to disallow rewriting them by default. Ciao, Dscho --

Hi, To be honest, I wanted to rip that part out before posting the initial filter-branch patches, and forgot/was too lazy. IMO there should be clean semantics first, and a default mode that does _not_ rewrite tags at all first. Maybe something as in fast-export. Ciao, Dscho --

That works! Thanks. I managed to figure out that "--all" is a rev-parse option, but it never occurred to me to protect it with a "--". -- Eyvind Bernhardsen --

This tag format is described in the documentation for git-mktag as follows: Tag Format ---------- A tag signature file has a very simple fixed format: four lines of object <sha1> type <typename> tag <tagname> tagger <tagger> followed by some 'optional' free-form message (some tags created [...] So, as long as git-cat-file succeeds, shouldn't we get this format piped to sed? The type is hard coded to "commit", since $new_ref will always be a commit ...

There isn't really a "default" mode for --tag-name-filter, a script must always be supplied. The name of the option (--tag- _name_ -filter) implies that it is intended for changing the names of tags. If the user decides not to change the name, then I think the user would expect the old tag to be replaced. So the user could choose to: Rewrite tag ref: --tag-name-filter cat or Give new tags a new name: --tag-name-filter 'sed -e s/$/.new/' ...

Hi, Yes. BUT. You can say "--all", and I actually expect quite a few people to do exactly that. And then you cannot really say "the user explicitely asked to have that signed tag rewritten". Ciao, Dscho --

I'll try to release 0.14.2 today or tomorrow as I'll be on holiday afterwards for 2.5 weeks. BTW, on the master branch, I noticed that StackTransaction.push_patch() checks whether the patch is empty before pushing it. The behaviour on stable is that it reports whether it's empty after push (just like "modified", so that you know that a patch no longer has data as a result of the merge). On the merging side during push, we have to add the plain patch applying first followed by a three-way ...

On Sat, Mar 22, 2008 at 7:35 AM, Johannes Schindelin All right. If I do end up having to recreate (thread-safe, multiple-git-dir-safe) logic for my project, I'll try to keep in mind --

i think when we want a good translation, we want somebody, who: 1) understands how git works (as a user), so he/she won't misunderstand the messages to translate 2) is a good translator. i think it's hard to find someone who is good in both. probably the current translations are 1)-like, and TranslationProject.org provides a 2)-like one. not sure which one is better.