* Re: [PATCH 4/4] diff.c: convert builtin funcname patterns to extended regular expressions
From: Gustaf Hendeby @ 2008-09-18 10:15 UTC (permalink / raw)
To: Johan Herland
Cc: Brandon Casey, Junio C Hamano, Git Mailing List, Giuseppe Bilotta
In-Reply-To: <200809181039.46954.johan@herland.net>
On 09/18/2008 10:39 AM, Johan Herland wrote:
> On Thursday 18 September 2008, Brandon Casey wrote:
>> This is a blind conversion removing \\ before ( and { etc.
>> and adding \\ before naked ( and { etc.
>>
>> I hope the authors who last touched these patterns will help with
>> testing:
>>
>> bibtex: Johan Herland
>
> This was moved by Junio when he applied my patch; the line was originally
> written by Gustaf Hendeby in 23b5beb28fdadbb1d80ebf686a35385609f7a180
I'm on the road the rest of this week and don't have access to a
suitable machine for testing until I get back. Will put testing this on
the list of things to do for Monday. The patch looks good, though, but
I haven't actually tested it.
/Gustaf
^ permalink raw reply
* Re: [PATCH 4/4] diff.c: convert builtin funcname patterns to extended regular expressions
From: Jonathan del Strother @ 2008-09-18 10:53 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Arjen Laarhoven, Mike Ralphson, Johannes Sixt,
Jeff King, Boyd Lynn Gerber, Git Mailing List, Avery Pennarun,
Johan Herland, Andreas Ericsson, Kirill Smelkov, Giuseppe Bilotta
In-Reply-To: <-f-gqL4SkA8Uh7hSuKT-JDY0g26jHn3fDQCE24MB1nKWUMLZWuSseg@cipher.nrlssc.navy.mil>
On Thu, Sep 18, 2008 at 1:21 AM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> ---
>
>
> This is a blind conversion removing \\ before ( and { etc.
> and adding \\ before naked ( and { etc.
>
> I hope the authors who last touched these patterns will help with testing:
None of the patterns using \\s seem to work for me. I had to replace
them with [ \t] - is this a problem with the darwin regex
compatibility library or something? I applied the patches on master
(97d7fee2cb), and am running OS X 10.5.5.
^ permalink raw reply
* Re: [PATCH (GIT-GUI,GITK) 0/8] Encoding support in GUI
From: Alexander Gavrilov @ 2008-09-18 11:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Shawn O. Pearce
In-Reply-To: <18641.31356.147503.708394@cargo.ozlabs.ibm.com>
On Thu, Sep 18, 2008 at 1:45 AM, Paul Mackerras <paulus@samba.org> wrote:
> Alexander Gavrilov writes:
>> Currently GUI tools don't provide any support for
>> viewing files that contain non-ASCII characters.
>
> Well, that's just not true, at least as far as gitk is concerned.
Somehow being able to show files in the system encoding is not good
enough for a tool that is supposed to be used for cross-platform
projects. It is only marginally better than always using ISO-8859-1,
as git-gui, in effect, did.
> If you feel there are deficiencies in how gitk handles encodings (and
> I'm quite willing to believe there are, since ASCII is sufficient for
> my needs), then please give us a detailed explanation of what you
> would like it to do or specifically what is wrong with what it does at
> the moment. I'd like to see several paragraphs, not just the one or
> two sentences you have put in the descriptions for patches 6-8.
I did not combine this set of patches into a single group without a
reason. This is a policy decision that spans the boundary of
individual tools, although it is initially implemented and documented
on the git-gui side. The gitk commits simply bring back changes to
code originally copied from gitk, tie in new logic that supports
per-file encoding, and fix some obvious breakage (of course, I can
write longer descriptions for them). By the way, patch 4 will apply to
gitk, if you replace 'lib/encoding.tcl' with 'gitk', and specify -C2.
P.S. All changes are build on top of these two commits:
http://repo.or.cz/w/git-gui.git?a=log;h=refs/heads/pu
Alexander
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Catalin Marinas @ 2008-09-18 11:24 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080918071020.GA12550@diana.vm.bytemark.co.uk>
2008/9/18 Karl Hasselström <kha@treskal.com>:
> On 2008-09-17 17:01:22 +0100, Catalin Marinas wrote:
>
>> 2008/9/17 Karl Hasselström <kha@treskal.com>:
>>
>> > Have you tried the benchmarks I committed a while back?
>>
>> No, I wanted to see how some real patches behave and I'm pretty
>> pleased with the result.
>
> In addition to the synthetic patch series you seem to have in mind,
> there is also a more than 1000 patches long series from the kernel
> history. Try running the setup.sh and take a look (it takes a few
> minutes to run, but you'll only have to do it once because the
> performance test script is careful not to wreck the repo it works on).
OK, I thought we only had the synthetic patches and haven't bothered
looking at the scripts.
--
Catalin
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Catalin Marinas @ 2008-09-18 11:31 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080918072450.GB12550@diana.vm.bytemark.co.uk>
2008/9/18 Karl Hasselström <kha@treskal.com>:
> On 2008-09-17 17:09:46 +0100, Catalin Marinas wrote:
>
>> I'm still confused by this and I don't think your new flag would
>> help. The meaning of stop_before_conflict is that it won't push the
>> conflicting patch but actually leave the stack with several patches
>> pushed or popped.
>>
>> What I want for sink (and float afterwards) is by default to cancel
>> the whole transaction if there is a conflict and revert the stack to
>> it's original state prior to the "stg sink" command.
>
> Ah, OK. Then I think you want something like this:
>
> try:
> trans.reorder_patches(applied, unapplied, hidden, iw)
> except transaction.TransactionHalted:
> if not options.conflict:
> trans.abort(iw)
> raise common.CmdException(
> 'Operation rolled back -- would result in conflicts')
> return trans.run(iw)
I tried this before but trans.abort(iw) seems to check out the iw
index which is the one immediately after the push conflict, though the
stack is unmodified, i.e. stg status shows some missing files (which
are added by subsequent patches after the conflicting one) and a
conflict.
What I would need is a way to save the original iw and and run
trans.abort(iw_original).
Or simply give up on the --conflict option and always stop after the
conflict (catch the exception and don't re-raise it). This way we
don't have to bother with checking out the initial state. With the
"undo" command in your branch, people could simply revert the stack to
the state prior to the sink command. Maybe that's a good idea so that
we don't complicate commands further with different conflict
behaviours.
--
Catalin
^ permalink raw reply
* Re: You don't exist, Go away! although user.name has been set
From: Marc Weber @ 2008-09-18 11:47 UTC (permalink / raw)
To: git
In-Reply-To: <48CF6277.4060807@op5.se>
> I can assure you that people are capable of fetching, pulling and
> committing with git. I do it all day long at least.
>
> Can you post your ~/.gitconfig (and/or .git/config) file, please?
> In conjunction, I also need to know the exact username you're using
> on your system.
Hmm I think it only occurs if you git clone the repo before adding the
identity to your global config.
If you clone the repository after having added your identity everything
is fine..
/ksa > git fetch origin
fatal: You don't exist. Go away!
~/.gitconfig:
[user]
name = sadflkj-sa
email = info@dflkje.de
The repo config is unchanged after cloning.
The HEAD pointer is invalid. But this shouldn't matter
Sincerly
Marc Weber
^ permalink raw reply
* Re: Help planning a git repo layout
From: Boaz Harrosh @ 2008-09-18 11:48 UTC (permalink / raw)
To: Leevi Graham, Git Mailing List
In-Reply-To: <938E7E5C-4FCB-4131-A5C4-254CEEC70673@leevigraham.com>
Leevi Graham wrote:
> Hey everyone,
>
> I'm after some advice on how to layout my git repo(s).
>
> Here's my current situation:
>
> I am developing 10 different ExpressionEngine addons that all live
> inside one ExpressionEngine installation. A simplified EE installation
> has the following folders (all cruft removed):
>
> |-root
> |-ee-admin
> |---extensions
> |---language
> |---modules
> |-themes
> |---site_themes
>
> My addons are a combination of files located in the extensions,
> language, modules and themes folders. An simple extension may look like:
>
> |-root
> |-ee-admin
> |---extensions
> |-----ext.lg_data_matrix.php
> |---language
> |-----english
> |---------lang.lg_data_matrix.php
> |---modules
> |-themes
> |---site_themes
>
> The extension above contains two files:
>
> - /ee-admin/extensions/ext.lg_data_matrix.php
> - /ee-admin/language/english/ext.lg_data_matrix.php
>
> I will be developing multiple extensions in the one EE install to make
> sure they all work with the core and do not conflict with each other.
> So my directory will have more than one addon in it:
>
> |-root
> |-ee-admin
> |---extensions
> |-----ext.lg_data_matrix.php
> |-----ext.lg_minify.php
> |-----ext.lg_better_meta_ext.php
> |---language
> |-----english
> |---------lang.lg_data_matrix.php
> |---------lang.lg_minify.php
> |---------lang.lg_better_meta.php
> |---------lang.lg_better_meta_ext.php
> |---modules
> |-----lg_better_meta
> |---------mcp.lg_better_meta.php
> |---------mod.lg_better_meta.php
> |-themes
> |---site_themes
>
> My problem comes when I want to tag and release an individual addon
> which is a collection of files in multiple folders.
>
> Just say I wanted to tag and release LG Better Meta. Ideally I would
> like to export a folder structure like:
>
> - /ee-admin/extensions/ext.lg_better_meta.php
> - /ee-admin/language/english/ext.lg_better_meta.php
> - /ee-admin/language/english/ext.lg_better_meta_ext.php
> - /ee-admin/modules/lg_better_meta/mcp.lg_better_meta.php
> - /ee-admin/modules/lg_better_meta/mod.lg_better_meta.php
>
> I would also like to give people the ability to clone each of the
> addons either as a full repo or part thereof.
>
> Any advice would be greatly appreciated.
>
> Cheers Leevi
>
Have branches with individual views of files like the above
LG-Better-Meta starts from a clean tree and only adds
- /ee-admin/extensions/ext.lg_better_meta.php
- /ee-admin/language/english/ext.lg_better_meta.php
- /ee-admin/language/english/ext.lg_better_meta_ext.php
- /ee-admin/modules/lg_better_meta/mcp.lg_better_meta.php
- /ee-admin/modules/lg_better_meta/mod.lg_better_meta.php
Other branches with other individual views of files.
Commits will have to be on the individual branches.
Lets call these product-branches
Then you have integration branches that merge from time
to time the product-branches, master been the merge of
all.
Users that only need a single product-branch will checkout
that one. Users needing all will checkout master.
For your convenience, you can locally clone the master
git, and have checkouts of single product-branches so
you can commit patches in parallel. Then push and merge.
Don't forget to give all empty branches at least one
common ancestor before adding files. Like with .gitignore
Boaz
^ permalink raw reply
* Re: Help planning a git repo layout
From: Boaz Harrosh @ 2008-09-18 13:25 UTC (permalink / raw)
To: Leevi Graham, Git Mailing List
In-Reply-To: <076A189D-66E9-4683-9C24-1C0A7A451892@leevigraham.com>
Leevi Graham wrote:
> Thanks for the advice Boaz,
>
> So to clarify:
>
> Create a new git repo in the root of the EE install. This will be the
> master branch.
>
> Then create branches (from the master branch) for each addon (product
> branches) that only shows the files that relate to that addon. How do
> I filter out the files I don't want to see?
>
> Work on each product branch independently merging as I go.
>
> Occasionally merge everything back into the master branch so I know
> that there are no conflicts with the product branches.
>
> I think I have it pretty clear in my head.
>
> Thanks for your patience and help
>
> Leevi
NP. Please don't top-post when on a mailing list. It's good
when chatting with individuals, but it is a mess, for people
that need to view it on a mailing list archives.
Basically yes. You start with master and commit some basic/common
files like:
$ git add .gitignore; git-commit ...
$ git tag BEGIN
then create a branch
$ git checkout -b foo
selectively add files
$ git add foo/ include/foo doc/foo
$ git-commit
You might want to add all these in a set of patches for readability.
Then
$ git-checkout -b bar BEGIN
Note that all foo's files vanished
$ git add bar/ include/bar ...
$ git-commit ...
and so on...
Then at the end
$ git-checkout master
Note that all files have vanished
$ git-merge foo
$ git-merge bar
All the files are back
then you can clone locally to trees, one with foo checked-out,
one with bar, if you need to commit to both at once. Then push
and merge at master
Good luck
Boaz
>
> On 18/09/2008, at 9:48 PM, Boaz Harrosh wrote:
>
>> Leevi Graham wrote:
>>> Hey everyone,
>>>
>>> I'm after some advice on how to layout my git repo(s).
>>>
>>> Here's my current situation:
>>>
>>> I am developing 10 different ExpressionEngine addons that all live
>>> inside one ExpressionEngine installation. A simplified EE
>>> installation
>>> has the following folders (all cruft removed):
>>>
>>> |-root
>>> |-ee-admin
>>> |---extensions
>>> |---language
>>> |---modules
>>> |-themes
>>> |---site_themes
>>>
>>> My addons are a combination of files located in the extensions,
>>> language, modules and themes folders. An simple extension may look
>>> like:
>>>
>>> |-root
>>> |-ee-admin
>>> |---extensions
>>> |-----ext.lg_data_matrix.php
>>> |---language
>>> |-----english
>>> |---------lang.lg_data_matrix.php
>>> |---modules
>>> |-themes
>>> |---site_themes
>>>
>>> The extension above contains two files:
>>>
>>> - /ee-admin/extensions/ext.lg_data_matrix.php
>>> - /ee-admin/language/english/ext.lg_data_matrix.php
>>>
>>> I will be developing multiple extensions in the one EE install to
>>> make
>>> sure they all work with the core and do not conflict with each other.
>>> So my directory will have more than one addon in it:
>>>
>>> |-root
>>> |-ee-admin
>>> |---extensions
>>> |-----ext.lg_data_matrix.php
>>> |-----ext.lg_minify.php
>>> |-----ext.lg_better_meta_ext.php
>>> |---language
>>> |-----english
>>> |---------lang.lg_data_matrix.php
>>> |---------lang.lg_minify.php
>>> |---------lang.lg_better_meta.php
>>> |---------lang.lg_better_meta_ext.php
>>> |---modules
>>> |-----lg_better_meta
>>> |---------mcp.lg_better_meta.php
>>> |---------mod.lg_better_meta.php
>>> |-themes
>>> |---site_themes
>>>
>>> My problem comes when I want to tag and release an individual addon
>>> which is a collection of files in multiple folders.
>>>
>>> Just say I wanted to tag and release LG Better Meta. Ideally I would
>>> like to export a folder structure like:
>>>
>>> - /ee-admin/extensions/ext.lg_better_meta.php
>>> - /ee-admin/language/english/ext.lg_better_meta.php
>>> - /ee-admin/language/english/ext.lg_better_meta_ext.php
>>> - /ee-admin/modules/lg_better_meta/mcp.lg_better_meta.php
>>> - /ee-admin/modules/lg_better_meta/mod.lg_better_meta.php
>>>
>>> I would also like to give people the ability to clone each of the
>>> addons either as a full repo or part thereof.
>>>
>>> Any advice would be greatly appreciated.
>>>
>>> Cheers Leevi
>>>
>> Have branches with individual views of files like the above
>> LG-Better-Meta starts from a clean tree and only adds
>> - /ee-admin/extensions/ext.lg_better_meta.php
>> - /ee-admin/language/english/ext.lg_better_meta.php
>> - /ee-admin/language/english/ext.lg_better_meta_ext.php
>> - /ee-admin/modules/lg_better_meta/mcp.lg_better_meta.php
>> - /ee-admin/modules/lg_better_meta/mod.lg_better_meta.php
>>
>> Other branches with other individual views of files.
>> Commits will have to be on the individual branches.
>> Lets call these product-branches
>>
>> Then you have integration branches that merge from time
>> to time the product-branches, master been the merge of
>> all.
>>
>> Users that only need a single product-branch will checkout
>> that one. Users needing all will checkout master.
>>
>> For your convenience, you can locally clone the master
>> git, and have checkouts of single product-branches so
>> you can commit patches in parallel. Then push and merge.
>>
>> Don't forget to give all empty branches at least one
>> common ancestor before adding files. Like with .gitignore
>>
>> Boaz
>>
>
^ permalink raw reply
* Re: [PATCH (GIT-GUI,GITK) 1/8] git-gui: Cleanup handling of the default encoding.
From: Dmitry Potapov @ 2008-09-18 15:02 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Shawn O. Pearce, Paul Mackerras
In-Reply-To: <1221685659-476-2-git-send-email-angavrilov@gmail.com>
On Thu, Sep 18, 2008 at 01:07:32AM +0400, Alexander Gavrilov wrote:
> - Make diffs and blame default to the system (locale)
> encoding instead of hard-coding UTF-8.
> - Add a gui.encoding option to allow overriding it.
> - gitattributes still have the final word.
The subject line of this patch is a bit misleading. I would not expect
from "clean up" to change the existing behavior and existing default.
> The rationale for this is Windows support:
>
> 1) Windows people are accustomed to using legacy encodings
> for text files. For many of them defaulting to utf-8
> will be counter-intuitive.
> 2) Windows doesn't support utf-8 locales, and switching
> the system encoding is a real pain. Thus the option.
I don't care much what is the default for Windows, but I wonder whether
this rationale is good enough to change the default for other platforms.
If you have systems configured with utf-8 and others (usually old ones)
with legacy encoding, you will store files in utf-8 in your repo, thus
having utf-8 as the default makes sense for non-Windows platforms.
BTW, when you said the system encoding above, what exactly encoding do
you mean? AFAIK, Windows has two legacy encodings OEM-CP and ANSI-CP.
If I write a console program and compile it using MS-VC then it should
use OEM-CP. However, if you write a GUI program or a console program
that is compiled using gcc from Cygwin, you have to use ANSI-CP. For
instance, if you use the Russian locale on Windows, ASNI-CP is 1251 and
OEM-CP is 866. So, my question is what exactly encoding do you call as
"system" above?
Dmitry
^ permalink raw reply
* Re: [PATCH] avoid gitweb uninitialized value warning
From: Jakub Narebski @ 2008-09-18 15:13 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20080905182629.GA22030@kodama.kitenet.net>
Joey Hess <joey@kitenet.net> writes:
> Subject: [PATCH] avoid gitweb uninitialized value warning
I would say _where_ this uninitialized value warning was, e.g.
Subject: [PATCH] gitweb: avoid warnings for commits with no body
>
> In the ususual case when there is no commit message, gitweb would
> output an uninitialized value warning.
Typo: s/ususual/unusual/
>
> Signed-off-by: Joey Hess <joey@kitenet.net>
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 29e2156..da474d0 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2123,7 +2123,7 @@ sub parse_commit_text {
> last;
> }
> }
> - if ($co{'title'} eq "") {
> + if (! defined $co{'title'} || $co{'title'} eq "") {
I would avoid space between logical negation operator '!' and
its operand, i.e. I would write:
+ if (!defined $co{'title'} || $co{'title'} eq "") {
> $co{'title'} = $co{'title_short'} = '(no commit message)';
> }
> # remove added spaces
> --
> 1.5.6.5
>
> --
> see shy jo
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH (GIT-GUI,GITK) 1/8] git-gui: Cleanup handling of the default encoding.
From: Alexander Gavrilov @ 2008-09-18 15:14 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Shawn O. Pearce, Paul Mackerras
In-Reply-To: <20080918150238.GC21650@dpotapov.dyndns.org>
On Thu, Sep 18, 2008 at 7:02 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> The subject line of this patch is a bit misleading. I would not expect
> from "clean up" to change the existing behavior and existing default.
Comments can be easily changed.
>> The rationale for this is Windows support:
>>
>> 1) Windows people are accustomed to using legacy encodings
>> for text files. For many of them defaulting to utf-8
>> will be counter-intuitive.
>> 2) Windows doesn't support utf-8 locales, and switching
>> the system encoding is a real pain. Thus the option.
>
> I don't care much what is the default for Windows, but I wonder whether
> this rationale is good enough to change the default for other platforms.
> If you have systems configured with utf-8 and others (usually old ones)
> with legacy encoding, you will store files in utf-8 in your repo, thus
> having utf-8 as the default makes sense for non-Windows platforms.
In fact, I think that the only reasonable default is the locale
encoding. If they want something different, they can do "git config
--global gui.encoding utf-8", that's what the option is there for.
> BTW, when you said the system encoding above, what exactly encoding do
> you mean? AFAIK, Windows has two legacy encodings OEM-CP and ANSI-CP.
> If I write a console program and compile it using MS-VC then it should
> use OEM-CP. However, if you write a GUI program or a console program
> that is compiled using gcc from Cygwin, you have to use ANSI-CP. For
> instance, if you use the Russian locale on Windows, ASNI-CP is 1251 and
> OEM-CP is 866. So, my question is what exactly encoding do you call as
> "system" above?
Whatever Tcl thinks the system encoding is. In this case it is cp1251.
CP866 is for DOS.
Alexander
^ permalink raw reply
* Re: [PATCH] Documentation: warn against merging in a dirty tree
From: Linus Torvalds @ 2008-09-18 15:15 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, Thomas Rast, git, Jakub Narebski, Miklos Vajna
In-Reply-To: <32541b130809151653w27d7876fp35e0967d597ae2a9@mail.gmail.com>
On Mon, 15 Sep 2008, Avery Pennarun wrote:
>
> But how do you abort a *failed* merge in a situation like Linus's
> example? "git reset --hard HEAD" would destroy the unstaged Makefile
> change.
As mentioned by others, sometimes you are simply willing to take the risk.
If I have dirty data, I still want to merge, because (a) my dirty data is
a _convenience_ and (b) the risk of me having to do a "git reset" is
pretty low anyway.
That said, it's actually kind of sad that we don't expose a real
capability that the git plumbing does have. Namely
git read-tree -u -m HEAD ORIG_HEAD
should do the right thing if you want to undo a merge (except it doesn't
actually write ORIG_HEAD to be the new head: you could use "git reset"
with --soft to do that, or just git update-ref).
So it _may_ be that something like
[alias]
undo = !git read-tree -u -m HEAD ORIG_HEAD && git reset --soft ORIG_HEAD
would actually give you "git undo".
So we have the technology, and we just don't _expose_ that capability as a
"git reset" thing. And we probably should. In fact, that is often the
thing people really want, and it would have made sense to have it as the
default action, but the initial design for "git reset" was literally as a
way to get you out of a sticky corner when you had unmerged entries and
you just wanted to throw away crud.
NOTE NOTE NOTE! I did _not_ test that the git read-tree thing actually
works, or that the above alias does the right thing. Caveat testor! You're
on your own. But I agree that we should have something like that.
Linus
^ permalink raw reply
* Help breaking up a large merge.
From: David Brown @ 2008-09-18 15:21 UTC (permalink / raw)
To: Git Mailing List
Say we have a tree that we've been working on for a few months. An
outside vendor has also been working on the same tree during this
time, and we need to merge with their work.
The difficulty I'm having is that there are a lot of conflicts
resulting from the merge (expected), and it would be nice to somehow
be able to work on a smaller set of these conflicts at a time.
Some of the conflicts are caused by a single change in the other tree.
This is easy to cherry-pick into my tree, resolve, and then test those
changes independently.
But other conflicts are caused by groups of commits that are
interleaved with others.
Ideally, I'd like to be able to divide this conflict resolution work
up among a small group of people, have everybody work on part, test
their part, and then I could bring all of the resolved versions
together, test that, and make that the actual merge commit in our
repo. I've had a few ideas, but none really seem to work all that
well.
- Do "git merge -s ours their-tree". Then, in another branch try
the merge, and resolve a group of files that go together. Put
these into the 'ours' tree and ammend these changes to the merge
commit. The problem here is that this misses all of the merges
that would happen automatically.
- "git branch -b tmp $(git merge-base our-head their-tree)", and
then: "git checkout their-tree filenames" for a small group of
conflicting files. Commit this, then in my regular tree, cherry
pick this change and resolve the conflict. Then, when finally
doing the merge with their tree, these files can be resolved by
just using our version. This still requires doing some tracking.
Any other ideas?
In the future, we're going to try and work more closely with the
vendor, but we have to get to the point of having something common to
start that.
Thanks,
David
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Karl Hasselström @ 2008-09-18 15:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0809180431x30c8f751g374732ee861ffe61@mail.gmail.com>
On 2008-09-18 12:31:35 +0100, Catalin Marinas wrote:
> 2008/9/18 Karl Hasselström <kha@treskal.com>:
>
> > Ah, OK. Then I think you want something like this:
> >
> > try:
> > trans.reorder_patches(applied, unapplied, hidden, iw)
> > except transaction.TransactionHalted:
> > if not options.conflict:
> > trans.abort(iw)
> > raise common.CmdException(
> > 'Operation rolled back -- would result in conflicts')
> > return trans.run(iw)
>
> I tried this before but trans.abort(iw) seems to check out the iw
> index which is the one immediately after the push conflict, though
> the stack is unmodified, i.e. stg status shows some missing files
> (which are added by subsequent patches after the conflicting one)
> and a conflict.
Hmm, strange. That's not what I thought it was supposed to do. Look at
how coalesce uses it, for example.
> Or simply give up on the --conflict option and always stop after the
> conflict (catch the exception and don't re-raise it). This way we
> don't have to bother with checking out the initial state. With the
> "undo" command in your branch, people could simply revert the stack
> to the state prior to the sink command. Maybe that's a good idea so
> that we don't complicate commands further with different conflict
> behaviours.
Yes, this is what every other command does, so it makes sense
consistency-wise.
But I liked the idea of your "roll-back-in-case-of-conflicts" flag; it
would be nice to have in many commands.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* How to supply "raw" bytes to git grep?
From: Johan Herland @ 2008-09-18 15:28 UTC (permalink / raw)
To: git
Hi,
I wanted to list all text files in my repo which contain carriage
returns, so I tried the following command-line:
git grep --cached -I -l -e <CR>
where <CR> is some magic incantation that I've yet to figure out. I've
tried all the obvious cases (\r, 0x0d, \015, etc.), but none of them
seem to DWIM...
The only working solution I've found so far is to create a file
(named "cr") in a hex editor that contains exactly one CR byte, and
then use the -f option to 'git grep':
git grep --cached -I -l -f cr
Is there an easier way? And if not, should I try to create one (e.g.
teaching 'git grep' to grok backslash escapes)?
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: How to supply "raw" bytes to git grep?
From: Jacob Helwig @ 2008-09-18 15:46 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200809181728.18597.johan@herland.net>
On Thu, Sep 18, 2008 at 08:28, Johan Herland <johan@herland.net> wrote:
> Hi,
>
> I wanted to list all text files in my repo which contain carriage
> returns, so I tried the following command-line:
>
> git grep --cached -I -l -e <CR>
>
> where <CR> is some magic incantation that I've yet to figure out. I've
> tried all the obvious cases (\r, 0x0d, \015, etc.), but none of them
> seem to DWIM...
>
> The only working solution I've found so far is to create a file
> (named "cr") in a hex editor that contains exactly one CR byte, and
> then use the -f option to 'git grep':
>
> git grep --cached -I -l -f cr
>
> Is there an easier way? And if not, should I try to create one (e.g.
> teaching 'git grep' to grok backslash escapes)?
>
>
> Have fun!
>
> ...Johan
>
> --
> Johan Herland, <johan@herland.net>
> www.herland.net
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Inserting a literal carriage return seems to do the trick for me, in bash.
git grep --cached -I -l -e <Ctrl-V><Ctrl-M>
^ permalink raw reply
* Re: Help breaking up a large merge.
From: Santi Béjar @ 2008-09-18 15:55 UTC (permalink / raw)
To: David Brown; +Cc: Git Mailing List
In-Reply-To: <20080918152154.GA27019@linode.davidb.org>
On Thu, Sep 18, 2008 at 5:21 PM, David Brown <git@davidb.org> wrote:
> Say we have a tree that we've been working on for a few months. An
> outside vendor has also been working on the same tree during this
> time, and we need to merge with their work.
>
> The difficulty I'm having is that there are a lot of conflicts
> resulting from the merge (expected), and it would be nice to somehow
> be able to work on a smaller set of these conflicts at a time.
If the two (or at least one) branches have sufficient isolated commits
you can recreate the merges that could have happened, as is explained
(for monotone) in:
http://www.venge.net/mtn-wiki/ZipperMerge
Another option is to rebase one branch onto the other.
Even another option is to merge the two branches but use the rebased
tree to resolve the conflicts.
They are not for parallel merge resolution, but at least you can do
them incrementally.
HTH,
Santi
^ permalink raw reply
* Re: [PATCH 4/4] diff.c: convert builtin funcname patterns to extended regular expressions
From: Brandon Casey @ 2008-09-18 15:48 UTC (permalink / raw)
To: Jonathan del Strother
Cc: Junio C Hamano, Arjen Laarhoven, Mike Ralphson, Johannes Sixt,
Jeff King, Boyd Lynn Gerber, Git Mailing List, Avery Pennarun,
Johan Herland, Andreas Ericsson, Kirill Smelkov, Giuseppe Bilotta
In-Reply-To: <57518fd10809180353q2564d873k98e5f6d9041d0a7@mail.gmail.com>
Jonathan del Strother wrote:
> On Thu, Sep 18, 2008 at 1:21 AM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
>> ---
>>
>>
>> This is a blind conversion removing \\ before ( and { etc.
>> and adding \\ before naked ( and { etc.
>>
>> I hope the authors who last touched these patterns will help with testing:
>
>
> None of the patterns using \\s seem to work for me. I had to replace
> them with [ \t] - is this a problem with the darwin regex
> compatibility library or something? I applied the patches on master
> (97d7fee2cb), and am running OS X 10.5.5.
I was going to say possibly \s is a gnu extension, but if by "compatibility
library", you mean compat/regex/regex.[ch] in the git source which is used
by default now on OSX, then that _is_ the gnu library.
I just tried the ruby pattern on IRIX6.5 and Solaris7 and \\s does not work.
I am not using compat/regex/regex.[ch]. Same pattern works on linux.
Looks like '\\s' needs to be changed to ' '.
-brandon
^ permalink raw reply
* [PATCH] generate-cmdlist.sh: avoid selecting synopsis at wrong place
From: Nguyễn Thái Ngọc Duy @ 2008-09-18 16:01 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In "common" man pages there is luckily no "NAME" anywhere except at
beginning of documents. If there is another "NAME", sed could
mis-select it and lead to common-cmds.h corruption. So better nail it
at beginning of line, which would reduce corruption chance.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
generate-cmdlist.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index a2913c2..75c68d9 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -14,7 +14,7 @@ sort |
while read cmd
do
sed -n '
- /NAME/,/git-'"$cmd"'/H
+ /^NAME/,/git-'"$cmd"'/H
${
x
s/.*git-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1"},/
--
1.6.0.96.g2fad1.dirty
^ permalink raw reply related
* Re: [PATCH] generate-cmdlist.sh: avoid selecting synopsis at wrong place
From: Santi Béjar @ 2008-09-18 16:09 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221753703-3331-1-git-send-email-pclouds@gmail.com>
On Thu, Sep 18, 2008 at 6:01 PM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> In "common" man pages there is luckily no "NAME" anywhere except at
> beginning of documents. If there is another "NAME", sed could
> mis-select it and lead to common-cmds.h corruption. So better nail it
> at beginning of line, which would reduce corruption chance.
>
You could narrow it even more with /^NAME$/
Santi
^ permalink raw reply
* [PATCH] make "git remote" report multiple URLs
From: Michael J Gruber @ 2008-09-18 16:11 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber
In-Reply-To: <7v4p4e0zpg.fsf@gitster.siamese.dyndns.org>
This patch makes "git remote -v" and "git remote show" report multiple URLs
rather than warn about them. Multiple URLs are OK for pushing into
multiple repos simultaneously.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
builtin-remote.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
This passes all tests, so I think the new output does not break anything.
diff --git a/builtin-remote.c b/builtin-remote.c
index 01945a8..ae560e7 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -652,10 +652,13 @@ static int get_one_entry(struct remote *remote, void *priv)
{
struct string_list *list = priv;
- string_list_append(remote->name, list)->util = remote->url_nr ?
- (void *)remote->url[0] : NULL;
- if (remote->url_nr > 1)
- warning("Remote %s has more than one URL", remote->name);
+ if (remote->url_nr > 0) {
+ int i;
+
+ for (i = 0; i < remote->url_nr; i++)
+ string_list_append(remote->name, list)->util = (void *)remote->url[i];
+ } else
+ string_list_append(remote->name, list)->util = NULL;
return 0;
}
--
1.6.0.2.249.g97d7f
^ permalink raw reply related
* Re: How to supply "raw" bytes to git grep?
From: Johan Herland @ 2008-09-18 16:18 UTC (permalink / raw)
To: Jacob Helwig; +Cc: git
In-Reply-To: <8c9a060809180846j25e4eb44h291b017aa01bbe36@mail.gmail.com>
On Thursday 18 September 2008, Jacob Helwig wrote:
> On Thu, Sep 18, 2008 at 08:28, Johan Herland wrote:
> > I wanted to list all text files in my repo which contain carriage
> > returns, so I tried the following command-line:
> >
> > git grep --cached -I -l -e <CR>
> >
> > where <CR> is some magic incantation that I've yet to figure out.
> > I've tried all the obvious cases (\r, 0x0d, \015, etc.), but none
> > of them seem to DWIM...
>
> Inserting a literal carriage return seems to do the trick for me, in
> bash.
>
> git grep --cached -I -l -e <Ctrl-V><Ctrl-M>
Thanks. That's exactly the incantation I was looking for. ;)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] generate-cmdlist.sh: avoid selecting synopsis at wrong place
From: Nguyen Thai Ngoc Duy @ 2008-09-18 16:20 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <adf1fd3d0809180909o2043ae36vda7ae2370f900169@mail.gmail.com>
On 9/18/08, Santi Béjar <santi@agolina.net> wrote:
> On Thu, Sep 18, 2008 at 6:01 PM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> > In "common" man pages there is luckily no "NAME" anywhere except at
> > beginning of documents. If there is another "NAME", sed could
> > mis-select it and lead to common-cmds.h corruption. So better nail it
> > at beginning of line, which would reduce corruption chance.
> >
>
>
> You could narrow it even more with /^NAME$/
That may miss "^NAME $", which is hard to recognize by eyes, although
I'm pretty sure there is no trailing spaces in git. It's up to Junio
to decide how strict he wants.
--
Duy
^ permalink raw reply
* Re: Help breaking up a large merge.
From: David Brown @ 2008-09-18 16:25 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0809180855l42af4fb6l67275daef0d2a529@mail.gmail.com>
On Thu, Sep 18, 2008 at 05:55:34PM +0200, Santi Béjar wrote:
>If the two (or at least one) branches have sufficient isolated commits
>you can recreate the merges that could have happened, as is explained
>(for monotone) in:
>
>http://www.venge.net/mtn-wiki/ZipperMerge
>
>Another option is to rebase one branch onto the other.
Either of these is likely to result in more work. Both branches have
intermediate results, and there has been some communication between
the developers of each branch, so some things are closer at the two
tips than they would be at intermediate stages.
I started with this approach, and started realizing that I was
resolving similar conflicts repeatedly (not the same, or rerere could
have helped).
Basically, I'm looking for a way to break the merge effort up by
groups of files/directories.
Thanks,
David
^ permalink raw reply
* Re: [PATCH (GIT-GUI,GITK) 1/8] git-gui: Cleanup handling of the default encoding.
From: Johannes Sixt @ 2008-09-18 16:29 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Alexander Gavrilov, git, Shawn O. Pearce, Paul Mackerras
In-Reply-To: <20080918150238.GC21650@dpotapov.dyndns.org>
Dmitry Potapov schrieb:
> On Thu, Sep 18, 2008 at 01:07:32AM +0400, Alexander Gavrilov wrote:
>> The rationale for this is Windows support:
>>
>> 1) Windows people are accustomed to using legacy encodings
>> for text files. For many of them defaulting to utf-8
>> will be counter-intuitive.
>> 2) Windows doesn't support utf-8 locales, and switching
>> the system encoding is a real pain. Thus the option.
>
> I don't care much what is the default for Windows, but I wonder whether
> this rationale is good enough to change the default for other platforms.
"The default" should not be hardcoded in the tool.
By setting the encoding to "system", "the default" is taken from whatever
the system's current locale is. If you are on modern Linux, your locale is
most likely set to UTF8, and everything is fine; you won't observe a
change in behavior.
But if you are on a system whose locale was not set to UTF8, then you very
likely did *not* produce UTF8 data, and the display in git-gui was screwed
because it assumed UTF8. With this change it uses the system's encoding,
and it is an improvement.
> If you have systems configured with utf-8 and others (usually old ones)
> with legacy encoding, you will store files in utf-8 in your repo, thus
> having utf-8 as the default makes sense for non-Windows platforms.
How can you know? For example, I've to work with systems that use "legacy
encodings", and I can't use UTF8 in my data. Hence, the default of UTF8
was not exactly useful. With this patch series there's now a mechanism
that allows me to state the encoding per file, and all platforms should be
able to show the data in the correct way.
-- Hannes
^ 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