Ok, this is interesting. Try this sequence (which is a good sequence for showign how something like "git blame -C" _should_ work, but only ends up showing that it doesn't at all, because of some bug ;^): # # create 'testing' repository # mkdir testing cd testing/ git init-db # # copy git.c and sha1_file.c there and commit initial # (Just to get _some_ initial state) # cp ~/git/git.c . cp ~/git/sha1_file.c . git add git.c sha1_file.c git commit -m Initial # # mo...

When calculating the string to be used in the From: field, don't require it to come from the configuration file. Instead, reuse already known authname and authemail values as the default. They can be taken from the GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL environment variables. Signed-off-by: Pavel Roskin <proski@gnu.org> --- stgit/commands/mail.py | 15 +++++---------- 1 files changed, 5 insertions(+), 10 deletions(-) diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py index ...

This argument has its converse. What you should _not_ have to worry about all the time is whether your index really includes all the changes you want included in your next commit. And whether wanting to leave local changes in the working directory without commiting them actually happen more often than wanting to commit every changes is arguable. What should be pretty consensual though, is the fact that having experienced GIT users add an alias for "commit" actually becoming "comit -i" t...

Eliminate 'commit' from some places and plug 'dcommit' more. Also update the section --id (GIT_SVN_ID) usage since we have multi-init/multi-fetch now. Signed-off-by: Eric Wong <normalperson@yhbt.net> --- Documentation/git-svn.txt | 40 +++++++++++++++++++--------------------- 1 files changed, 19 insertions(+), 21 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index a764d1f..a45067e 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt ...

Thanks for the informative response. It helped but I'm still slightly confused by git - I think I need to play around with it a bit more to understand and get more familiar with the concepts... Purely from an initial usage point of view though, for me at least, the bzr output needed no explanation which I think is indicative of a good user interface whereas the git was not so clear or obvious - there must be room for improvement in git's user friendliness here surely. But that might just be because...

Well, there you start depending on everyone using bzr and providing metadata-added patches. Git is really good at dealing with scenarios where not everyone is using Git.. so the content-is-kind-and-metadata-be-damned pays off handsomely. And the "scenarios where not everyone is using Git" are everytime that we are tracking a project that uses a different SCM. For me, the "killer-app" of git is that, as it does not rely on magic metadata, it is perfectly useful on projects that I track that use CV...

Well, if you look in the git toolset, you'll find things like git-svn which is geared to make it almost transparent to use git to work on a project where the upstream is using svn and push patches into SVN (if you have write access, naturally). And git-cvsexportcommit which is a lot less useful but helps me push series of patches from git into cvs Sounds roughly like git-svn ;-) converge, ye DSCMs martin -

finish_report does seem to return a useful value indicating success or failure, so we'll just set a flag when close_edit is called (it is not called on failures, nor is abort_edit) and check the flag before proceeding. Thanks to Pazu for pointing this out. Signed-off-by: Eric Wong <normalperson@yhbt.net> --- git-svn.perl | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/git-svn.perl b/git-svn.perl index 7942bba..c3ad5ec 100755 --- a/git-svn.perl +++ b/g...

Er? What about merge printed? $ git pull . branch Trying really trivial in-index merge... fatal: Merge requires file-level merging Nope. Merging HEAD with c59706ee42aa7b6b2b203d4219210a684f5581f2 Merging: 8f43c37 Moved hello.txt to hello_master.txt c59706e Moved hello.txt to hello_branch.txt found 1 common ancestor(s): b7d5f1a Initial commit CONFLICT (rename/rename): Rename hello.txt->hello_master.txt in branch HEAD rename hello.txt->hello_branch.txt in c5970...

Don't force the user to specify more than one revision parameter, thus making git-shortlog behave more like git-log. 'git-shortlog master' will now produce the expected results; the other end of the range simply is the (oldest) root commit. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> diff --git a/builtin-shortlog.c b/builtin-shortlog.c index b5b13de..f1124e2 100644 --- a/builtin-shortlog.c +++ b/builtin-shortlog.c @@ -298,9 +298,7 @@ int cmd_shortlog(int argc, const char **a...

Well, there are two cases where this might be not enough. On is following file renames for history tracking. git-blame does that, but git-log and friends does not; the <path> is just revision limiter. There is an idea of --follow option to git-log (and friends), to be implemented. Second is rename detection for 3way merges: only ancestor and final states are considered, so the above would not help. And rename detection might fail if ancestor is not similar enough to end states; well, the ...

Git supports renames/moves in different way. Instead of recording renames (which has trouble on it's own, for example rename via applying patch) There are trouble with file-ids. Most common example is trouble with file which was created in two branches (two repositories) independently, then branches got merged. Most (all?) file-id based rename detection has trouble with repeated merging of those branches, even if there are no true conflicts. Read Linus post about file-id based rename detectio...

Not so rare in a true DSCM scenario where people submit patches via email or a bug tracker. Say two developers apply the same patch to their trees, and one of them tweaks it a bit. While I don't personally do kernel development, I understand that's reasonably common in the linux dev team. It also happens quite a bit if you cherry pick across branches patches that create files. In such cases, I find GIT does the right thing 99% of the time, including spotting situations where the file got added...

Ehh. It told you exactly what happened when you actually did the merge, didn't it? Yeah, "git status" won't tell you _why_ it results in unmerged paths, but the merge will have told you. You must have seen that, but decided to just ignore it and not post it, because it didn't support the conclusion you wanted to get, did it? There are lots of reasons why "git status" may tell you that something isn't merged. The most common one by far being an actual data conflict, not a name confli...

I'd suggest just re-doing the merge. Something like git reset --hard git merge -m "dummy message" MERGE_HEAD will do it for you (that's the new "nicer syntax" for doing a merge, in No, it's actually there, but "git status" doesn't really explain it to you. The go-to command tends to be "git diff", which after a merge will not show anything that already merged correctly (because it will have been updated in the git index _and_ updated in the working tree, so there will be no dif...

Side note, to clarify: in the _simple_ cases it's all actually there. I can well imagine that in more complex cases, involving multiple different files, you may well want to re-do the merge and let the merge tell you why it refused to merge something. So the index, for example, contains just a "final end result" of what the merge gave up on, and while for a simple rename conflict like your example you could certainly see that directly from the index state (and thus we could, for exampl...

Except when you are doing a large merge, your terminal scrollback is really short, and there's a lot of conflicts. Then you can't see what merge said about any given file. :-( Fortunately its easy to back out of the merge and redo it with large enough scrollback, or redirecting it to a file for later review, but its annoying that we don't save that information off for later review. -- Shawn. -

This can't be fail safe though. I would prefer to also have the option to be able to *explicitly* tell the RCS that a file was renamed and not have it try to detect from the content which is bound to have corner cases that fail. When I know I renamed a file why can't I explicitly tell the RCS and it records the change with the *file identifier*. If I change the content then the change is not recorded with the file identifier but with the line/content identifier. Nick -

Do you mean if the 2 files should be merged into 1 file? If they should be 2 files with different names there is no problem using file identifiers but if they should be merged into one file then I can see that this would cause problems. You would have to delete one of the files and copy its changes into the other which would create conflicts when that file is modified in the other branch. This is a problem if you *only* have file identifiers. But if you tracked both file identifiers *and* c...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There's no question that determining content movement could involve opening a lot of revisions, but you wouldn't need to examine: 1. revisions that didn't alter any lines being examined 2. revisions that altered only the file in question 3. revisions with multiple parents, because any lines attributed to that merge will be the outcome of conflict resolution. (Other lines will be attributed to one of the parents) I'll admit though, that when I w...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 $ time bzr annotate builtins.py > /dev/null real 0m1.479s user 0m1.430s sys 0m0.030s builtins.py has 953 ancestor revisions (i.e. revisions that modified it) and 3016 lines. That's on a machine with 4141.87 Bogomips. I did optimize annotate slightly, but I'm submitting the optimization for our 0.14.0 release. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http:/...

Commit 35e65ecc broke completion of local refs, e.g. "git pull . fo<tab>" no longer would complete to "foo". Instead it printed out an internal git error ("fatal: Not a git repository: '.'"). The break occurred when I tried to improve performance by switching from git-peek-remote to git-for-each-ref. Apparently git-peek-remote will drop into directory "$1/.git" (where $1 is its first parameter) if it is given a repository with a working directory. This allowed the bash completion code to w...

This conflicts a bit with later "Create a topic branch" statement. The statement should be I think twofold: "Never work out of tracking branches" (if you use separate remotes, git takes care of that for yourself), and for typical workflow "Always work out of master or merge changes into master". This of course deopends on the structure of your repo. For example, how many development branches are there. Git repository uses four development branches: 'maint' (maintenance, stable, bugfixes), 'mast...

We could simplify things, and assume that remote name is _never_ hierarchical, so that remote branches names are: remotes/<remote>/<branch> where <remote> does not contain '/'. Additional problem is for "summary" view: should we limit number of heads per remote, should we sort heads inside remote, or should we also sort remotes, or should we sort remotes by time without grouping into repos? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

That can be streamlined slightly: git fetch git checkout -b <new-topic> origin as fetch would by default download from remote 'origin' and update the tracking branches. And of course developers may not want to create their new branch from origin, e.g. if they are doing a bug fix to an earlier release of the product. I think its a good habit to be in to always specify the origination point for a branch when Yes, that works and will get you a merge message like Merge branch ...