Hello! I see there is an active discussion about branch attributes. It would be nice to have an attribute to prevent git from changing the branch head in any way. The reason is that it interferes with StGIT on StGIT managed branches. If StGIT is fine with the change, it would remove or override the lock temporarily. StGIT could also unlock the branch permanently if there are no applied patches. Another use of the branch lock would be to prevent damage to remote branches, such as ...

Hi, sorry: bad patch. This is needed on top. diff --git a/config.c b/config.c index 6765186..452b587 100644 --- a/config.c +++ b/config.c @@ -261,6 +261,10 @@ int git_config_from_file(config_fn_t fn, config_offset = 0; in_fd = open(filename, O_RDONLY); + if (in_fd < 0 && ENOENT != errno ) + die("opening %s: %s", config_file_name, + strerror(errno)); + fstat(in_fd, &st); if (contents) { @@ -288,9 +292,6 @@ int git_config_from_file(config_fn_t fn, } else { ...

This makes it possible to rewrite the config without accessing the config file twice. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> --- Linus said he'd prefer this. One thing I am not quite sure about: should we remember the file's mtime and check it to see if the config file has changed since we mmap()ed it? BTW this patch is on top of next, and does not yet contain Sean's bug fix. config.c | 102 ...

I'm not at all convinced we want to do somethng like this. get_pathspec() is a one-time event. It doesn't "leak" memory. To me, "leaking" is when you continually lose a bit of memory, and you eventually run out. I don't see that happening here. It's like saying that calling an initialization routine "leaks" memory, because it doesn't free the memory that contains the function that is now no longer ever used. It's clearly leaving that memory unused, "dangling". But the fact is, the ...

Unfortunately, prefix_path() sometimes returns a newly xmalloc()ed buffer, and in other cases it returns a substring! For example, when calling git update-index ./hello.txt prefix_path() returns "hello.txt", but does not allocate a new buffer. The original code only checked if the result of prefix_path() was different from what was passed in, and thusly trigger a segmentation fault. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> --- checkout-index.c | 4 ++-- ...

Careful, that "X^..X" thing does entirely the wrong thing for merges. Not Maybe not. I've actually cursed the fact that I made "git diff X" mean "diff from X to current working tree", because it almost never makes any sense at all when X is anything but "HEAD". I probably _should_ have made "git diff X" mean basically "git show X", and not what it means now. Oh, well. Linus -

Funny, when tracking other projects I use (sometimes path-filtered) "git diff origin" often, but I find "git show origin" utterly uninteresting. OG. -

When calling "git fmt-patch HEAD~5", you now get the same as if you would have said "git fmt-patch HEAD~5..". This makes it easier for my fingers which are so used to the old syntax. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> --- I wonder: would it make sense to make add_pending_object() and get_reference() in revision.c non-static? builtin-diff.c | 2 +- builtin-log.c | 8 ++++++++ 2 files changed, 9 insertions(+), 1 deletions(-) diff --git ...

- correctly insert a new variable into a section that only contains a single (different) variable. - correctly insert a new section that matches the initial substring of an existing section. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> --- Both tests fail with v1.3.2 and pass with latest patches. t/t1300-repo-config.sh | 31 +++++++++++++++++++++++++++++++ 1 files changed, 31 insertions(+), 0 deletions(-) ef2178a10e27f43d4120884bc587c460e9b1bfcb diff --git ...

Hi, Thanks to both of you! Ciao, Dscho -

Or rather structure, which for given file F in given revision A, for given other revision B would tell ALL the files in the revision B which are source of contents (via history/commit tree) of the file F. -- Jakub Narebski Warsaw, Poland -

Yeah, I actually made a start at a sequel to tutorial.txt, with the goal that after reading the sequel a user would have encountered the main concepts necessary to read any of the man pages--mainly the object database and the index file. My work so far is in the "advanced-tutorial" branch of git://linux-nfs.org/~bfields/exports/git.git but it needs some cleaning up. I was hoping I'd be able to replace some of the README or core-tutorial.txt in the process, but the latter has a lot ...

On Sat, 06 May 2006 13:09:03 -0700 Junio C Hamano <junkio@cox.net> wrote: It doesn't mention git log, show or status which are important for the first day. Also an example of git commit --amend would be a nice touch. Part of the problem people new to git are having arise by reading documentation in the wrong order and coming to the conclusion that git is an ugly beast. Also many people are still finding out-of- date information before anything else (eg. git isn't an scm only an object ...

Have fun implementing that ;-). -

I agree that it could be interesting to have a such thing. But that's increndibly stupid and moreover a rare case. -- Beber #e.fr@freenode -

Basically, it boils down to the end result. If you design things for "people", then things tend to become hard to automate, and it's hard to make wrappers around it. Maybe you've even made the interfaces interactive, and thus any wrappers around it are simply screwed, or need to do insane things. On the other hand, if you design things for automation, doing a "people wrapper" that uses the automation should be trivial if the design is even remotely any good at all. In other ...

I share the same reasoning and that is why I am carrying the series in "next". I think per branch attributes are wonderful In my day job, I maintain a base code for a generic application in "master", various topics, mostly branched from "master" but sometimes from another topic branch, and one branch each per customer installation, which pulls from the master, topics and contains specific customizations. While on master or any one of generic topic branch, I need to remember not to pull ...

Hi, It was done because the very syntax of the config suggests it be a user-editable file. I do not want to mess with the comments more than Does it really hurt? I think not. Anyway, I'll look into this. Ciao, Dscho -

Thanks Linus and Sean for bringing this up and fixing it. I have a vague feeling that this may not be the last breakage of the repo-config command. My first reaction to the repo-config code was "eek". It tries to reuse as much the existing material as possible -- I understand it was done that way in order to preserve the comments and blank lines from the original config file intact, but it just felt very error prone (demonstrated by cases like this and the other one Sean brought up) and ...

After running 'git-update-index' for some paths, you may want to do the update on the same set of paths again. The new flag --again checks the paths whose index entries are are different from the HEAD commit and updates them from the working tree contents. This was brought up by Carl Worth on #git. Signed-off-by: Junio C Hamano <junkio@cox.net> --- * I want to reorganize index file to contain both blob and tree entries in not so distant future, so I probably should not be ...

Would it make sense to make all the shallow clone clone machinery walk everything and trim only blob objects? In that case, all the machinery that walks commits/trees would remain intact -- we only have to deal with the case of not having blob objects, which affects less codepaths. It means that for a merge or checkout involving stuff we "don't have", it's trivial to know we are missing, and so we can attempt a fetch of the missing objects or tell the user how to request them them ...

FYI rerere is a totally unrelated voodoo. It remembers the conflict marker pattern <<< === >>> immediately after it runs "merge" (ah, that reminds me -- I should replace them with diff3), and then remembers the result of the manual resolution just before the user makes a commit. Then, when next time it runs "merge" for something and notices <<< === >>> pattern it has seen before, it runs a three-way merge between the previous resolution result and the current conflicted state, using the ...