* Applying changes across divergent branches
From: Tom Schutzer-Weissmann @ 2008-09-24 14:40 UTC (permalink / raw)
To: git
Hello all,
I am looking into how to apply git to some current working methods.
We tend to have two or three main branches: the development branch, and
one or two product branches. The development branch is the cutting edge,
and each product branches off from it.
While the product branch shares history with the development branch, not
all changes to the development branch will get applied to the product
branch. We tend to maintain two versions of a product at any time,
meaning two divergent product branches.
Could we use git, or a tool based on git, to change on the development
branch and selectively apply changes to the other branches - is it as
simple as using git cherry-pick?
Thanks in advance,
Tom SW
^ permalink raw reply
* Re: [PATCH] gitk: Update swedish translation.
From: Mikael Magnusson @ 2008-09-24 14:46 UTC (permalink / raw)
To: Peter Krefting; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0809241527170.22419@ds9.cixit.se>
2008/9/24 Peter Krefting <peter@softwolves.pp.se>:
> Mikael Magnusson:
>
> Looks good! A few corrections:
Thanks,
>> +#: gitk:327
>> +msgid "Error executing --argscmd command:"
>> +msgstr "Fel vid körning av --argscmd kommando:"
>
> The word is incorrectly split (särskrivning).
>
> "Fel vid körning av --argscmd-kommandot:"
>
> would be better (note the change to determined form).
Here I just looked at the form of the english phrase (no "the"),
but I agree the determined form is more natural.
>> +#: gitk:2218
>> +msgid "Blame parent commit"
>> +msgstr "Kör blame på föregående incheckning"
>
> "Blame" should probably be translated. git-gui uses "annotate", which
> is easier to understand, so possible:
>
> "Annotera föregående incheckning"
Didn't think to look at the git-gui translation here.. :)
>> +#: gitk:2997 gitk:3006
>> +#, tcl-format
>> +msgid "Error creating temporary directory %s:"
>> +msgstr "Fel vid skapande av tillfällig katalog %s:"
>
> The "-ande" form makes reading strange.
>
> "Fel när tillfällig katalog %s skapades:"
>
> or something similar
This is sort of incorrect, since there was an error the directory was
presumably never created. How about
"Fel när tillfällig katalog %s skulle skapas:"
Btw, according to google code search, the common case seems to be what
I wrote, though I didn't check before writing it:
http://www.google.com/codesearch?hl=en&lr=&q=error+creating.*directory+file%3Asv%5C.po&sbtn=Search
How about
"Fel vid skapande av den tillfälliga katalogen %s:"?
>> +#: gitk:3039
>> +msgid "No such commit"
>> +msgstr "Ingen sådan incheckning finns"
>
> It looks like it is constrained for space, but you should check that.
> If it is, something like "Incheckning saknas" would work.
Seems to be an error while blaming, in a pop up, so it should be fine
I think?
>> +#: gitk:3044
>> +msgid "git gui blame: command failed:"
>> +msgstr "git gui blame: kommando misslyckades"
>
> Your[sic ;)] missing a final colon, and it should be determined form:
>
> "git gui blame: kommandot misslyckades:"
Agreed.
--
Mikael Magnusson
^ permalink raw reply
* Re: [PATCH v2] maint: check return of split_cmdline to avoid bad config strings
From: Deskin Miller @ 2008-09-24 14:50 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, gitster
In-Reply-To: <20080924092847.GD23137@genesis.frugalware.org>
>From 0d52afa86d757220fefa2440c78c81bd2c8b790a Mon Sep 17 00:00:00 2001
From: Deskin Miller <deskinm@umich.edu>
Date: Mon, 22 Sep 2008 11:06:41 -0400
Subject: [PATCH] maint: check return of split_cmdline to avoid bad config strings
As the testcase demonstrates, it's possible for split_cmdline to return -1 and
deallocate any memory it's allocated, if the config string is missing an end
quote. In both the cases below, which are the only calling sites, the return
isn't checked, and using the pointer causes a pretty immediate segfault.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
On Wed, Sep 24, 2008 at 11:28:47AM +0200, Miklos Vajna wrote:
> On Wed, Sep 24, 2008 at 02:10:28AM -0400, Deskin Miller <deskinm@umich.edu> wrote:
> > As the testcase demonstrates, it's possible to have split_cmdline return -1 and
> > deallocate any memory it's allocated, if the config string is missing an end
> > quote. In both the cases below, the return isn't checked, causing a pretty
> > immediate segfault.
>
> I think this could go to the commit message.
Done in v2.
> > + git merge master || test \$? = 128
> > + "
>
> Why don't you use test_must_fail here?
Didn't know about it. Fixed in v2.
Thanks for the advice.
builtin-merge.c | 2 ++
git.c | 2 ++
t/t1300-repo-config.sh | 10 ++++++++++
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index b280444..dcaf368 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -442,6 +442,8 @@ static int git_merge_config(const char *k, const char *v, void *cb)
buf = xstrdup(v);
argc = split_cmdline(buf, &argv);
+ if (argc < 0)
+ die("Bad branch.%s.mergeoptions string", branch);
argv = xrealloc(argv, sizeof(*argv) * (argc + 2));
memmove(argv + 1, argv, sizeof(*argv) * (argc + 1));
argc++;
diff --git a/git.c b/git.c
index fdb0f71..5582c51 100644
--- a/git.c
+++ b/git.c
@@ -162,6 +162,8 @@ static int handle_alias(int *argcp, const char ***argv)
alias_string + 1, alias_command);
}
count = split_cmdline(alias_string, &new_argv);
+ if (count < 0)
+ die("Bad alias.%s string", alias_command);
option_count = handle_options(&new_argv, &count, &envchanged);
if (envchanged)
die("alias '%s' changes environment variables\n"
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 64567fb..11b82f4 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -741,4 +741,14 @@ test_expect_success 'symlinked configuration' '
'
+test_expect_success 'check split_cmdline return' "
+ git config alias.split-cmdline-fix 'echo \"' &&
+ test_must_fail git split-cmdline-fix &&
+ echo foo > foo &&
+ git add foo &&
+ git commit -m 'initial commit' &&
+ git config branch.master.mergeoptions 'echo \"' &&
+ test_must_fail git merge master
+ "
+
test_done
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: Locking binary files
From: Dmitry Potapov @ 2008-09-24 15:00 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Junio C Hamano, Mario Pareja, Andreas Ericsson, Git Mailing List
In-Reply-To: <alpine.LNX.1.00.0809232330050.19665@iabervon.org>
On Wed, Sep 24, 2008 at 12:15:39AM -0400, Daniel Barkalow wrote:
> On Wed, 24 Sep 2008, Dmitry Potapov wrote:
>
> >
> > What are you saying is that when I am locking some file on the current
> > branch, Git (or whatever script that performs this locking) should figure
> > out what is the original shared branch for it and lock the file there.
>
> Or you should have to say. But "git lock <filename>" should probably
> put the lock on whatever branch "git push" would push to, and similarly
> for the other argument combinations that "git push" permits.
It seems to me very fragile to rely on the push configuration in deciding
what can be locked and what cannot. Besides this configuration can change
over time. So what is going to happen with locks then? Another problem:
what if I don't push anyway but usually send pull-requests?
The fact is if you cannot get your locking working in _one_ repository
then any hope that it will work when you have more than one is nothing
but a pipe dream.
>
> > Maybe, it can work, but it sounds too complex to me. I believe that my
> > idea using SHA-1 is better. After all, what is file? It is its content.
> > At least, in Git, we always identify files by their content.
>
> Not at all; there are plenty of cases where what matters is the path, and
> some things are relevant by virtue of the form of the filename which names
> that content.
Whether it matters or not depends on a particular workflow and what the
developer wants to achieve. Such decisions should be taken by human
being, otherwise you are prone to do the wrong things too often.
>
> > Thus if you lock some file, you put a lock on certain SHA-1. Now,
> > regardless of branches and paths, this lock can work provided that you
> > have access to some shared location. Of course, this lock is purely
> > advisory, but it is good, because you may want to ignore it in some
> > case.
>
> In my design, the lock (on the shared repository) is not advisory; if
> someone else has it, you can't push if the new commit doesn't match the
> old commit for that path.
Hey, if someone wants to push this file, it means it is already late,
because you _already_ have the situation where two people have edited
exactly the same binary file. Isn't the situation that the lock was
intended to prevent?
So, the goal should be to warn someone who is going to edit file locked
by someone else. You cannot prevent him/her from doing so, only to warn
about that.
As to pushing, it can be different policies. IMHO, the update hook is
the best place to express what push you want to allow and what not, but
some workflow may not use push at all, yet ability to lock (perhaps,
'synchronize' would be a better word here) may still be needed.
Dmitry
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Shawn O. Pearce @ 2008-09-24 15:02 UTC (permalink / raw)
To: Alex Riesen
Cc: Dmitry Potapov, git, Johannes Sixt, Junio C Hamano,
Steffen Prohaska
In-Reply-To: <81b0412b0809240742g2918b300h9114579c4ebf05b4@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> 2008/9/24 Dmitry Potapov <dpotapov@gmail.com>:
>
> > Frankly, I don't have strong preference here neither for making this
> > fast version always work nor leave it conditional (perhaps, with the
> > default setting use-fast-version). So, whatever the majority decides
> > is fine with me.
>
> I'm voting for compile-time configuration then.
To be consistent with everything else, compile-time sounds like
what we should do, its how just about every other part of Git
is configured.
However Dmitry pointed out that he has cases where this faster
function doesn't work correctly, and it was path specific. Some
areas of the filesystem work, others don't, on the same system.
A current example of a feature more like this is core.filemode.
A compile-time option makes the feature useful only to those users
who don't ever have a repository which has a mount contained within
the working directory. My understanding of Dmitry's explanation
is he has such cases, which is why I was voting for a runtime
configuration.
A compile-time option means that Git will work fine for years, until
you put a mount in a working directory and *wham* it suddenly stops
working like it should, because of that compile-time optimization
you made long ago and forgot about.
> >> Besides it will remove your setup code, which looks bigger and provoked
> >> more discussion than the real subject itself.
> >
> > I believe Shawn wanted it to be configurable on per-repository basis.
>
> which, I believe, is pointless.
See above. I suggested configurable per-repository because
Dmitry seemed to be saying this feature only works in some of his
repositories and not others. Controlling it by an environment
variable isn't very easy to use as you move between repositories
on the same system.
Maybe I should have leaned more towards compile-time earlier in
the discussion, but Dmitry lead off the patch though with a remark
about users just running the Cygwin package, without building
their own Git. We can't expect the Cygwin maintainers to enable
a feature in a software package that makes it work on 90% of the
Cygwin installs out there; that's just asking for trouble.
But we can compile in a user-configurable switch, where the user can
shoot their own foot off in the name of speed, especially if they
can easily disable it on the oddball repositories where it fails.
Of course it might be even better if the code could auto-sense
when its busted and just switch itself off. E.g. if four or
more consecutive "fast" stat calls fail but the original Cygwin
call succeeds then just always use Cygwin calls for the rest of
the process.
--
Shawn.
^ permalink raw reply
* Re: Partial tree export and merging
From: Heiko Voigt @ 2008-09-24 15:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Jens Lehmann
In-Reply-To: <20080924143945.GN3669@spearce.org>
Shawn O. Pearce schrieb:
> Once the history is split into a new "doc+html" repository have
> developers _only_ edit the docs/html in the doc+html repository,
> don't make more edits in the source code repository.
The problem with committing into 2 repositories (only merging from one
side) is that the docs/html also contain localization files which make
it hard to work/test the code because localization strings are initially
added by the developers. They would then have to change in the 2nd repo
and pull for testing.
> You can use git-submodule or git-merge with the subtree strategy
> to pull changes from the doc+html repository into the main source
> repository.
Would git submodule work with this kind of layout? Same folders
containing different files. I thought submodules only work with
subdirectories which are itself a git repo.
cheers Heiko
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Alex Riesen @ 2008-09-24 15:09 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Dmitry Potapov, git, Johannes Sixt, Junio C Hamano,
Steffen Prohaska
In-Reply-To: <20080924150231.GO3669@spearce.org>
2008/9/24 Shawn O. Pearce <spearce@spearce.org>:
> Alex Riesen <raa.lkml@gmail.com> wrote:
>> 2008/9/24 Dmitry Potapov <dpotapov@gmail.com>:
>>
>> > Frankly, I don't have strong preference here neither for making this
>> > fast version always work nor leave it conditional (perhaps, with the
>> > default setting use-fast-version). So, whatever the majority decides
>> > is fine with me.
>>
>> I'm voting for compile-time configuration then.
>
> To be consistent with everything else, compile-time sounds like
> what we should do, its how just about every other part of Git
> is configured.
>
> However Dmitry pointed out that he has cases where this faster
> function doesn't work correctly, and it was path specific. Some
> areas of the filesystem work, others don't, on the same system.
Huh?! What are they? What paths require cygwin's handling
which aren't handled already? (the absolute paths are handled).
^ permalink raw reply
* Re: Partial tree export and merging
From: Shawn O. Pearce @ 2008-09-24 15:13 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann
In-Reply-To: <48DA5737.4030909@mahr.de>
Heiko Voigt <heiko.voigt@mahr.de> wrote:
> Shawn O. Pearce schrieb:
>> Once the history is split into a new "doc+html" repository have
>> developers _only_ edit the docs/html in the doc+html repository,
>> don't make more edits in the source code repository.
>
> The problem with committing into 2 repositories (only merging from one
> side) is that the docs/html also contain localization files which make
> it hard to work/test the code because localization strings are initially
> added by the developers. They would then have to change in the 2nd repo
> and pull for testing.
I can see how that would be difficult.
In think you are faced with either restructuring your tree so that
the docs/html/localization files are all under a single subdirectory,
or you have to keep splitting down the repository with something like
filter-branch (or your own tools) to update the localization tree.
Doing the latter risks more merge conflicts for developers when they
pull changes back from the localization team. Usually a developer
doesn't want to d3eal with merge conflicts from doc writers, and
they really don't want to deal with them in localized files if they
can't read/write that language.
>> You can use git-submodule or git-merge with the subtree strategy
>> to pull changes from the doc+html repository into the main source
>> repository.
>
> Would git submodule work with this kind of layout? Same folders
> containing different files. I thought submodules only work with
> subdirectories which are itself a git repo.
You are correct, a submodule requires that everything in that
directory be part of that submodule. If your source tree has the
"submodule files" spread all over, intermingled with sources,
you can't use submodule to manage them.
Typically the recommendation is to organize your source tree more
by functional responsibility, so you can delegate all files under
a single directory to the docs team. The project scales better to
more staff, and its easier to avoid merge conflicts.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Shawn O. Pearce @ 2008-09-24 15:16 UTC (permalink / raw)
To: Alex Riesen
Cc: Dmitry Potapov, git, Johannes Sixt, Junio C Hamano,
Steffen Prohaska
In-Reply-To: <81b0412b0809240809y4daa990cl5494d7b7398353f0@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> 2008/9/24 Shawn O. Pearce <spearce@spearce.org>:
> >
> > However Dmitry pointed out that he has cases where this faster
> > function doesn't work correctly, and it was path specific. Some
> > areas of the filesystem work, others don't, on the same system.
>
> Huh?! What are they? What paths require cygwin's handling
> which aren't handled already? (the absolute paths are handled).
Cygwin lets you mount a filesystem at a different part of the
filesystem. Sort of like Linux's mount -t bind (IIRC).
For example its possible to remap C:\foo\bar\widget\srcs into
C:\cygwin\home\lib, so you see the files under /home/lib in Cygwin,
even though that folder is empty (or flat out doesn't exist)
in Windows.
That filesystem remount stuff is part of the reason why the Cygwin
stat/lstat routines are so much slower than the native Windows ones.
They have to evaluate the path space twice (once in Cygwin, again
in the Windows kernel).
--
Shawn.
^ permalink raw reply
* [PATCH] vim syntax: highlight the diff in commit message template
From: SZEDER Gábor @ 2008-09-24 15:22 UTC (permalink / raw)
To: Jeff King; +Cc: git, SZEDER Gábor
The template generated by 'git commit -v' is much easier to read now.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/vim/syntax/gitcommit.vim | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/vim/syntax/gitcommit.vim b/contrib/vim/syntax/gitcommit.vim
index 332121b..0872e65 100644
--- a/contrib/vim/syntax/gitcommit.vim
+++ b/contrib/vim/syntax/gitcommit.vim
@@ -16,3 +16,5 @@ hi def link gitUntracked Comment
hi def link gitCommitFile Type
hi def link gitChangedFile Constant
hi def link gitUntrackedFile Constant
+
+source $VIMRUNTIME/syntax/diff.vim
--
1.6.0.2.323.gb1a20
^ permalink raw reply related
* Re: [TopGit PATCH] prev/next/tsort: commands to explore dependencies
From: Petr Baudis @ 2008-09-24 15:23 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git
In-Reply-To: <36ca99e90809221032x3003c1f7q8ef09cb92a0473ad@mail.gmail.com>
On Mon, Sep 22, 2008 at 07:32:50PM +0200, Bert Wesarg wrote:
> On Mon, Sep 22, 2008 at 17:36, Petr Baudis <pasky@suse.cz> wrote:
> > Hi,
> >
> > On Fri, Sep 19, 2008 at 11:55:00AM +0200, Bert Wesarg wrote:
> >> I hacked 3 commands to explore the dependencies of TopGit patches:
> >
> > thanks, the idea of all three commands is good,
> >
> >> I) tg prev [NAME]
> >> outputs the dependencies of NAME
> >>
> >> II) tg next [NAME]
> >> outputs patches that depends on NAME
> >
> > but I think it would be cleaner to add this functionality to
> > tg info...
> Right, but 'tg next' is shorter than any 'tg info --next'.
So, an alias? ;-) I wouldn't really like to clutter the UI with many
trivial commands for getting various sort of info. And I mean, ideally
you could just see all this in default 'tg info' output (or for
computationally expensive operations, maybe 'tg info -l'?).
> >
> >> III) tg tsort [PATTERN]
> >> outputs a topological order of all patches starting with PATTERN
> >
> > ...and tg summary (overally, to have a tree view of branches).
> Maybe something like the graph output from git rev-log --graph?
That would be excellent.
> >> + printf "%s\t%q\n" "${dep_rev}" "${dep}" >&3
> >> + printf "%s\t%s\n" "${topic_rev}" "${dep_rev}"
> >
> > %q?
>
> "and %q causes printf to output the corresponding argument in a
> format that can be reused as shell input."
>
> I thought that this would be needed.
Interesting, I didn't find that in my documentation. But as said later,
this quoting is probably unnecessary.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism,
but they have cold baths.
^ permalink raw reply
* Re: TopGit: how to deal with upstream inclusion
From: Petr Baudis @ 2008-09-24 15:29 UTC (permalink / raw)
To: martin f krafft; +Cc: git
In-Reply-To: <20080924112115.GA14841@piper.oerlikon.madduck.net>
On Wed, Sep 24, 2008 at 01:21:15PM +0200, martin f krafft wrote:
> also sprach Petr Baudis <pasky@suse.cz> [2008.09.23.1155 +0200]:
> > > Well, but what if upstream implemented our solution slightly
> > > differently, and if it's only because they used tabs instead of
> > > spaces? We wouldn't want -s ours then, huh?
> >
> > You still would want to get tabs in other patches that depended on
> > the merged one, no? Otherwise tg patch output will produce patches
> > that do not apply and tg export will change the tabs back to
> > spaces.
>
> I would want to have to resolve all dependent branches and change
> them to use tabs, right. But since I used spaces and they used tabs,
> using -s ours would give preference to spaces, no?
Please read again carefully :-) :
> (i) Take the RETIRED _base_ branch
>
> (ii) Merge in VANILLA
>
> (iii) Merge in RETIRED head branch with -s ours
>
> (iv) Now we have a commit that contains RETIRED topic branch, but
> with the RETIRED's changes taken from VANILLA instead of RETIRED
-s ours keeps vanilla version.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism,
but they have cold baths.
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Alex Riesen @ 2008-09-24 15:32 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Dmitry Potapov, git, Johannes Sixt, Junio C Hamano,
Steffen Prohaska
In-Reply-To: <20080924151653.GQ3669@spearce.org>
2008/9/24 Shawn O. Pearce <spearce@spearce.org>:
> Alex Riesen <raa.lkml@gmail.com> wrote:
>> 2008/9/24 Shawn O. Pearce <spearce@spearce.org>:
>> >
>> > However Dmitry pointed out that he has cases where this faster
>> > function doesn't work correctly, and it was path specific. Some
>> > areas of the filesystem work, others don't, on the same system.
>>
>> Huh?! What are they? What paths require cygwin's handling
>> which aren't handled already? (the absolute paths are handled).
>
> Cygwin lets you mount a filesystem at a different part of the
> filesystem.
Ewwww... Yes, you're right. Disgusting feature. Just when I
thought Cygwin cannot get any worse...
Config parameter looks like the only way to workaround that.
> Sort of like Linux's mount -t bind (IIRC).
Except that in Linux the binding is part of the filesystem namespace,
not a special knowledge of some stupid library.
^ permalink raw reply
* Re: please consider remove those tags named master, which is ambigous with master branch
From: Alex Riesen @ 2008-09-24 15:44 UTC (permalink / raw)
To: rae l; +Cc: Matthias Urlichs, Andrew Morton, git, linux-kernel
In-Reply-To: <91b13c310809230746o1c2cb694taebc814bea57c8c5@mail.gmail.com>
2008/9/23 rae l <crquan@gmail.com>:
> To Git developers:
> I found that different git subcommand have inconsitent processing
> about ambiguous refname,
>
> git show will take "master" tag first,
> while git tag -v will take "master" branch first,
>
> So what's your suggestion to fix this? Just simple remove ambiguous refnames?
You can use "refs/tags/master" and "refs/heads/master"...
^ permalink raw reply
* A note from the interim Git maintainer
From: Shawn O. Pearce @ 2008-09-24 15:46 UTC (permalink / raw)
To: git
As mentioned recently by Junio, Junio is away on family leave and
a much deserved vacation until ~Oct 6th. Until he gets back I am
offering up my services as patch monkey to keep us moving along.
My tree is being published here:
git: git://repo.or.cz/git/spearce.git
repo.or.cz/srv/git/git/spearce.git
http://repo.or.cz/r/git/spearce.git
gitweb: http://repo.or.cz/w/git/spearce.git
The usual maint/master/next/pu stuff applies. I'm basically just
picking up from where Junio left off.
I would appreciate it if anyone who normally tracks Junio's "next"
or "master" branch for their production work can switch over to my
next (or master) branch for the next few weeks. Something about
many eyeballs and fewer bugs.
Patches can be CC'd to me, or just sent to the list. If I have
dropped something, please feel free to give me a gentle prod.
I know that I am quite behind on git-gui patches. I think I'm going
to spend the better part of today just on Git to get everything
caught up.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] vim syntax: highlight the diff in commit message template
From: Jeff King @ 2008-09-24 15:57 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, git
In-Reply-To: <1222269726-15632-1-git-send-email-szeder@ira.uka.de>
On Wed, Sep 24, 2008 at 05:22:06PM +0200, SZEDER Gábor wrote:
> The template generated by 'git commit -v' is much easier to read now.
I think the goal of this change is good, but I'm not sure about the
implementation:
> +source $VIMRUNTIME/syntax/diff.vim
Despite having written the original gitcommit.vim, I am largely clueless
about vim syntax highlighting. However, the gitcommit.vim shipped with
vim 7.2 does this:
syn include @gitcommitDiff syntax/diff.vim
syn region gitcommitDiff start=/\%(^diff --git \)\@=/ end=/^$\|^#\@=/ contains=@gitcommitDiff
which seems a bit more robust to me. I have no idea if that syntax
introduces any limitations about which versions of vim can be used.
However, this brings up a more important question: is there any reason
for git to ship a vim syntax file when there is already a maintained
(and IMHO, much superior) one that ships with vim? The only people who
should need our file are people on versions of vim older than the ones
that ship gitcommit.vim. For those people, I suspect they are better off
going to vim.org and grabbing the up to date (and undoubtedly more
carefully constructed) syntax file rather than pulling what is in our
contrib/ area.
Is there any objection to simply removing it (and probably replacing it
with a note to go look at the official highlighting file)?
-Peff
^ permalink raw reply
* Re: [PATCH] Fix submodule sync with relative submodule URLs
From: Shawn O. Pearce @ 2008-09-24 16:19 UTC (permalink / raw)
To: Johan Herland; +Cc: git, David Aguilar, Junio C Hamano, Mark Levedahl
In-Reply-To: <200809241131.16327.johan@herland.net>
Johan Herland <johan@herland.net> wrote:
> On Wednesday 24 September 2008, David Aguilar wrote:
> > Instead of just doing an "|| exit" shouldn't it report an explanation
> > of the error?
> > Other than that, it looks good to me.
>
> Fixed. Thanks.
OK, time for the drive-by patch commenting. I've largely stayed
out of git-submodule related code, but I just looked at in the
context of applying this patch.
There are three callers to resolve_relative_url in master and next.
All three callers just "|| exit" when resolve_relative_url fails.
The only reason resolve_relative_url can fail is when there is no
remote.$remote.url configuration option set for the current default
remote ("origin"?).
I guess I'm unclear about why cmd_sync is different from the
existing callers.
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 1c39b59..f89bdbe 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -634,6 +634,15 @@ cmd_sync()
> do
> name=$(module_name "$path")
> url=$(git config -f .gitmodules --get submodule."$name".url)
> +
> + # Possibly a url relative to parent
> + case "$url" in
> + ./*|../*)
> + url=$(resolve_relative_url "$url") ||
> + die "failed to resolve relative submodule url for '$name'"
> + ;;
> + esac
> +
> if test -e "$path"/.git
> then
> (
--
Shawn.
^ permalink raw reply
* [BUG] git ls-files -m --with-tree does double output
From: Anders Melchiorsen @ 2008-09-24 16:19 UTC (permalink / raw)
To: git
I think that this is wrong? The combination of -m and --with-tree
shows duplicate entries. Git 1.6.0.2.
Cheers,
Anders.
and@dylle:~$ mkdir repo ; cd repo
and@dylle:~/repo$ git init
Initialized empty Git repository in /home/and/repo/.git/
and@dylle:~/repo$ date >a ; git add a ; git commit -m'Add 1'
Created initial commit c027435: Add 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
and@dylle:~/repo$ date >a
and@dylle:~/repo$ git ls-files -m --with-tree=HEAD
a
a
^ permalink raw reply
* [BUG] git merge does not prune empty directories
From: Anders Melchiorsen @ 2008-09-24 16:32 UTC (permalink / raw)
To: git
I got an empty directory left over today, and have reduced the problem
to this sequence. If I leave out the second add (so the merge is a
fast forward), the directory is removed as I would expect.
This is with Git 1.6.0.2.
Anders
and@dylle:~$ mkdir repo ; cd repo
and@dylle:~/repo$ git init
Initialized empty Git repository in /home/and/repo/.git/
and@dylle:~/repo$ mkdir a ; date >a/b ; git add a/b ; git commit -m'Add 1'
Created initial commit 72194c7: Add 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a/b
and@dylle:~/repo$ git checkout -b other
Switched to a new branch "other"
and@dylle:~/repo$ git rm a/b ; git commit -m'Remove 1'
rm 'a/b'
Created commit 9c0282c: Remove 1
1 files changed, 0 insertions(+), 1 deletions(-)
delete mode 100644 a/b
and@dylle:~/repo$ git checkout master
Switched to branch "master"
and@dylle:~/repo$ date >c ; git add c ; git commit -m'Add 2'
Created commit 39d60d4: Add 2
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 c
and@dylle:~/repo$ git merge other
Removed a/b
Merge made by recursive.
a/b | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
delete mode 100644 a/b
and@dylle:~/repo$ rmdir a
and@dylle:~/repo$ rmdir a
rmdir: failed to remove `a': No such file or directory
^ permalink raw reply
* Re: fatal: cannot store pack file (git 1.6.0.2 + sshfs)
From: Shawn O. Pearce @ 2008-09-24 16:34 UTC (permalink / raw)
To: Jhair Tocancipa Triana; +Cc: git
In-Reply-To: <87iqsmy8q7.fsf@sms.ed.ac.uk>
Jhair Tocancipa Triana <jhair.tocancipa@gmail.com> wrote:
> I'm getting the following when running git on a partition mounted with
> sshfs:
>
> $ git pull
...
> error: unable to write sha1 filename .git/objects/pack/pack-dc5c3614e795918f457a2f98a58f10134ebf246b.pack: Operation not permitted
> fatal: cannot store pack file
> fatal: index-pack failed
>
> git pull worked fine in the same repository yesterday (new files where
> committed in the meantime).
>
> I'm not sure if this is a problem in git or in sshfs (or somewhere
> else).
Its the size of the fetch. The day before you probably had a smaller
number of objects downloaded (<100) so Git used unpack-objects
instead of index-pack. Yesterday it was a larger download (>100),
so it used index-pack.
In 1.6.0.2 index-pack writes a temporary file to .git/objects but
later tries to rename it into .git/objects/pack. That renaming
must not be working on sshfs.
Latest "master" has a change from Pasky (8b4eb6b6 "Do not perform
cross-directory renames") that should fix this issue. Or just
don't use sshfs. Or teach sshfs to rename across directories.
--
Shawn.
^ permalink raw reply
* Re: Git submodule enhancements
From: René Scharfe @ 2008-09-24 16:39 UTC (permalink / raw)
To: P. Christeas; +Cc: Lars Hjemli, Git Mailing List, Mr. Meitar Moscovitz
In-Reply-To: <200809241314.29661.p_christ@hol.gr>
P. Christeas schrieb:
> On Wednesday 24 September 2008, Lars Hjemli wrote:
>> Btw: why doesn't
>> $ git submodule foreach 'git archive HEAD > somewhere/$path.tar'
>> work for you?
> In fact, it could. You could also replace HEAD with the $sha1 ..
By the way, have you tried git-archive-all.sh (announced here a month
ago and hosted here: http://github.com/meitar/git-archive-all.sh/wikis)?
René
^ permalink raw reply
* Re: [PATCH] Fix submodule sync with relative submodule URLs
From: Johan Herland @ 2008-09-24 16:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, David Aguilar, Junio C Hamano, Mark Levedahl
In-Reply-To: <20080924161902.GT3669@spearce.org>
On Wednesday 24 September 2008, Shawn O. Pearce wrote:
> I guess I'm unclear about why cmd_sync is different from the
> existing callers.
It's not any different as far as I'm concerned. We should probably add
helpful error messages to the other callers as well.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: out of memory problem
From: guo tang @ 2008-09-24 16:45 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git mailing list
In-Reply-To: <48D89FB7.3000509@op5.se>
It happened again. I cannot make a copy of repository and try bisect.
The repository is 2.5GB, too time consuming to make a copy.
When I tried bisect without start from fresh. The bisect failed to
find the bad commit since the bad commit it found out can work now
once the repository is packed.
I did notice 3 things.
1. When I have memory trouble, "git gc" cannot finish the count
objects stage. It appears to be in an infinite loop.
2. When I ran "git count-objects -v", it reported there is an error: 1
garbage object found. The garbage object is named something like
.git/objects/35/tmp_xxx. Even if "git gc" finished without error, it
won't delete that garbage object. I guess there might be some
difference on how garbage object is handled between v1.5.5.1 and
v1.6.2
3. If I manually remove that garbage object using "rm", everything
seems still fine.
I will give valgrid a shoot next time I am in trouble.
Thanks,
Guo
On Tue, Sep 23, 2008 at 12:50 AM, Andreas Ericsson <ae@op5.se> wrote:
> guo tang wrote:
>>
>> On Mon, Sep 22, 2008 at 12:32 AM, Andreas Ericsson <ae@op5.se> wrote:
>>
>>> Guo Tang wrote:
>>>
>>>> Gentlemen,
>>>>
>>>> I try to run "git gc" on linux kernel tree. The virtual memory keeps
>>>> going
>>>> up until over 3GB, then crash. Tried twice with the v1.6.0.2, same
>>>> result.
>>>> Then I used the git coming with FC9 (v1.5.5.1), the peak virutal memory
>>>> usage is about 1.5GB. "git gc" finished without any trouble.
>>>> Could there be a memory leak in v1.6.0.2?
>>>>
>>>>
>>> There could be, but most likely it's commit
>>> 38bd64979a2a3ffa178af801c6a62e6fcd658274 (Enable threaded delta
>>> search on BSD and Linux). Do you have multiple cpu's in the
>>> computer where 'git gc' was running? If so, and if you've set
>>> pack.threads = 0, or --threads=0 it will autodetect the number
>>> of CPU's you have and then saturate all of them with work. Each
>>> thread will however consume memory close to that of a single
>>> process running the repack, so for large repositories you might
>>> want to set pack.threads = 1 in such large repositories.
>>
>>
>> It is a Pentium M single core machine. But I am not sure whether it is
>> using
>> just a single thread or
>> multiple threads. I will try setting pack.threads parameter next I run
>> into
>> trouble.
>>
>
> Unless you explicitly told it to run multiple threads (which
> would be a bit silly on a single-core machine), it just ran
> one thread.
>
>>> It's a shame you didn't save the unpacked repository, or this could
>>> have been properly debugged. While it's possible there is a memory
>>> leak, it's a dismal project trying to locate it by staring at the
>>> code, and the time it takes to repack huge repositories with memory
>>> intensive parameters is sort of prohibitive for finding the possible
>>> leak by bisection.
>>
>>
>> Yes, the repository is already packed now. One question, beside the
>> bisecting method, do we have
>> this ability built into kernel:
>> 1. Turn a flag on for a process.
>> 2. OS will keep track off process malloc(), free() calls and the call
>> stack.
>>
>> 3. For the malloc() calls without the the free() call (a memory leak), OS
>> will keep it count based on malloc() call stack.
>> 4. After some time, be able to dump this information out based on biggest
>> leak spot.
>>
>
> No, there's not. The kernel isn't the one handing out the memory when you
> call malloc(). That's handled by the C library, which can (and usually does)
> allocate a larger area of memory than the application needs, so that it
> doesn't have to run a system call for every malloc() call you do.
>
> You can pre-load a different memory allocator though, which can do whatever
> it wants with calls to malloc(), including ofcourse logging which function
> called them and how much memory was requested.
>
> Google for "memory leak check linux" and you'll get something like 750000
> results.
>
>
>> The complain when I ran out of memory if from mmap failure. Is it the same
>> as malloc() failure?
>>
>
> Sort of. Read 'man 2 mmap' for a more exhaustive description.
>
>> This kind of tool is available in Windows with its umdh (user mode heap
>> dump) tool.
>>
>
> There are a number of tools to detect leaks under Linux/Unix as well.
> valgrind is probably the most frequently used of all such leak checkers.
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
>
^ permalink raw reply
* Re: [RFC PATCH (GIT-GUI)] git-gui: Add more integration options to citool.
From: Shawn O. Pearce @ 2008-09-24 16:52 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200809122243.50007.angavrilov@gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> - Make citool return nonzero exit code if it did not commit.
> - Add a mode where it does not actually commit and simply
> exits with zero code. Commit message is either disabled,
> or simply dumped to GITGUI_EDITMSG before exiting.
> - Add an option to immediately start it in amend mode.
...
> I think this functionality might be useful, in particular for some of
> my own scripts. But I'm not sure if this is the best way to do it.
This looks good to me, but I think we may want to add this as a
follow-up patch. Thoughts?
--8<--
git-gui: Hide commit related UI during citool --nocommit
If the user started git-gui as "git citool --nocommit" then they
don't need the new commit / amend commit radio buttons, or the sign
off button in the UI. Rather than use up space with options the
user cannot activate they are simply not installed into the UI.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-gui.sh | 104 ++++++++++++++++++++++++++++++++---------------------------
1 files changed, 56 insertions(+), 48 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index c4ccc66..1939001 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2271,23 +2271,25 @@ proc commit_btn_caption {} {
if {[is_enabled multicommit] || [is_enabled singlecommit]} {
menu .mbar.commit
- .mbar.commit add radiobutton \
- -label [mc "New Commit"] \
- -command do_select_commit_type \
- -variable selected_commit_type \
- -value new
- lappend disable_on_lock \
- [list .mbar.commit entryconf [.mbar.commit index last] -state]
-
- .mbar.commit add radiobutton \
- -label [mc "Amend Last Commit"] \
- -command do_select_commit_type \
- -variable selected_commit_type \
- -value amend
- lappend disable_on_lock \
- [list .mbar.commit entryconf [.mbar.commit index last] -state]
-
- .mbar.commit add separator
+ if {![is_enabled nocommit]} {
+ .mbar.commit add radiobutton \
+ -label [mc "New Commit"] \
+ -command do_select_commit_type \
+ -variable selected_commit_type \
+ -value new
+ lappend disable_on_lock \
+ [list .mbar.commit entryconf [.mbar.commit index last] -state]
+
+ .mbar.commit add radiobutton \
+ -label [mc "Amend Last Commit"] \
+ -command do_select_commit_type \
+ -variable selected_commit_type \
+ -value amend
+ lappend disable_on_lock \
+ [list .mbar.commit entryconf [.mbar.commit index last] -state]
+
+ .mbar.commit add separator
+ }
.mbar.commit add command -label [mc Rescan] \
-command ui_do_rescan \
@@ -2329,9 +2331,11 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {
.mbar.commit add separator
- .mbar.commit add command -label [mc "Sign Off"] \
- -command do_signoff \
- -accelerator $M1T-S
+ if {![is_enabled nocommit]} {
+ .mbar.commit add command -label [mc "Sign Off"] \
+ -command do_signoff \
+ -accelerator $M1T-S
+ }
.mbar.commit add command -label [commit_btn_caption] \
-command do_commit \
@@ -2657,9 +2661,11 @@ pack .vpane.lower.commarea.buttons.incall -side top -fill x
lappend disable_on_lock \
{.vpane.lower.commarea.buttons.incall conf -state}
-button .vpane.lower.commarea.buttons.signoff -text [mc "Sign Off"] \
- -command do_signoff
-pack .vpane.lower.commarea.buttons.signoff -side top -fill x
+if {![is_enabled nocommit]} {
+ button .vpane.lower.commarea.buttons.signoff -text [mc "Sign Off"] \
+ -command do_signoff
+ pack .vpane.lower.commarea.buttons.signoff -side top -fill x
+}
button .vpane.lower.commarea.buttons.commit -text [commit_btn_caption] \
-command do_commit
@@ -2667,15 +2673,10 @@ pack .vpane.lower.commarea.buttons.commit -side top -fill x
lappend disable_on_lock \
{.vpane.lower.commarea.buttons.commit conf -state}
-button .vpane.lower.commarea.buttons.push -text [mc Push] \
- -command do_push_anywhere
-pack .vpane.lower.commarea.buttons.push -side top -fill x
-
-if {[is_enabled nocommitmsg]} {
- .vpane.lower.commarea.buttons.signoff configure -state disabled
-}
-if {[is_enabled nocommit]} {
- .vpane.lower.commarea.buttons.push configure -state disabled
+if {![is_enabled nocommit]} {
+ button .vpane.lower.commarea.buttons.push -text [mc Push] \
+ -command do_push_anywhere
+ pack .vpane.lower.commarea.buttons.push -side top -fill x
}
# -- Commit Message Buffer
@@ -2684,20 +2685,24 @@ frame .vpane.lower.commarea.buffer
frame .vpane.lower.commarea.buffer.header
set ui_comm .vpane.lower.commarea.buffer.t
set ui_coml .vpane.lower.commarea.buffer.header.l
-radiobutton .vpane.lower.commarea.buffer.header.new \
- -text [mc "New Commit"] \
- -command do_select_commit_type \
- -variable selected_commit_type \
- -value new
-lappend disable_on_lock \
- [list .vpane.lower.commarea.buffer.header.new conf -state]
-radiobutton .vpane.lower.commarea.buffer.header.amend \
- -text [mc "Amend Last Commit"] \
- -command do_select_commit_type \
- -variable selected_commit_type \
- -value amend
-lappend disable_on_lock \
- [list .vpane.lower.commarea.buffer.header.amend conf -state]
+
+if {![is_enabled nocommit]} {
+ radiobutton .vpane.lower.commarea.buffer.header.new \
+ -text [mc "New Commit"] \
+ -command do_select_commit_type \
+ -variable selected_commit_type \
+ -value new
+ lappend disable_on_lock \
+ [list .vpane.lower.commarea.buffer.header.new conf -state]
+ radiobutton .vpane.lower.commarea.buffer.header.amend \
+ -text [mc "Amend Last Commit"] \
+ -command do_select_commit_type \
+ -variable selected_commit_type \
+ -value amend
+ lappend disable_on_lock \
+ [list .vpane.lower.commarea.buffer.header.amend conf -state]
+}
+
label $ui_coml \
-anchor w \
-justify left
@@ -2715,8 +2720,11 @@ proc trace_commit_type {varname args} {
}
trace add variable commit_type write trace_commit_type
pack $ui_coml -side left -fill x
-pack .vpane.lower.commarea.buffer.header.amend -side right
-pack .vpane.lower.commarea.buffer.header.new -side right
+
+if {![is_enabled nocommit]} {
+ pack .vpane.lower.commarea.buffer.header.amend -side right
+ pack .vpane.lower.commarea.buffer.header.new -side right
+}
text $ui_comm -background white -foreground black \
-borderwidth 1 \
--
1.6.0.2.471.g47a76
--
Shawn.
^ permalink raw reply related
* Re: [PATCH] vim syntax: highlight the diff in commit message template
From: SZEDER Gábor @ 2008-09-24 17:01 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20080924155745.GA3908@coredump.intra.peff.net>
Hi,
On Wed, Sep 24, 2008 at 11:57:45AM -0400, Jeff King wrote:
> Is there any objection to simply removing it (and probably replacing it
> with a note to go look at the official highlighting file)?
I'm for it, because I didn't know that there is an official git syntax
highlight file out there. Indeed, I haven't even know that vim 7.2 is
out.
Thanks,
Gábor
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox