* Re: setting up tracking on push
From: Nanako Shiraishi @ 2009-03-11 10:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Jay Soffian, Marc Branchaud, Miles Bader, git
In-Reply-To: <7vwsaw7jzy.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> The only use case I've heard in this thread and nearby is where you are
> the one who started the history of the branch, and pushed it into a public
> repository as a new branch, making the result _the_ most authoritative
> one. After that, everybody else will be able to have a local branch that
> tracks the authoritative one with "branch --track frotz origin/frotz", and
> you will be the only one left unable to do so because you already have
> that frotz branch.
>
> And for that use case, I find it sensible if we had a way to easily say
> "This branch hasn't been tracking anything so far (because it is the
> originator of the history), but now it will give up its authority and
> start tracking the one it is pushing into", and it would make sense to
> somehow link that to the invocation of "git push".
>
> Side note. I would also accept "It is only one person in the world,
> who can edit .git/config and be done with it; why bother complicate
> the UI for other people" as a valid argument against it, though ;-).
>
> In that "my private branch gave autority to the branch at my public
> repository" case, it is of course easy to re-clone (or "branch -m" away
> and then re-fetch) like everybody else, but then you would lose the reflog
> from the time before the branch went public, so it is not a solution but a
> poor workaround.
I'm sorry, but I don't understand why you want to keep the entries in the reflog that were made before you pushed your branch to make it public in this scenario.
Especially because you are relinquishing the authority to the public repository by wishing to be able to "track" it, you can't rewind the branch beyond the point you initially pushed out any more. At that point, wouldn't it make more sense to drop the old reflog data and pretend as if the branch were fetched from the branch from your public repository it now follows, just like everybody else does?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Confusing `stash apply` behavior
From: Nanako Shiraishi @ 2009-03-11 10:02 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0903101246n1eff50d4rc819e5fe7586a974@mail.gmail.com>
Quoting Tim Visher <tim.visher@gmail.com>:
> When I do `git stash apply`, it deletes the file I'm working with.
>
> $ ls
> featureList.txt* keycontrol.mdb*
>
> $ git show stash@{0}
> commit b3c0f4b9b3c3ef7741a03fb27174f5838abc939d
> Merge: 9fb9886 112bba9
> Author: Tim Visher <timothy.visher@fms.treas.gov>
> Date: Tue Mar 10 15:25:04 2009 -0400
>
> WIP on dev: 9fb9886 Added DB Lock file to .gitignore. EOM
>
> diff --cc keycontrol.mdb
> index 68a9bac,68a9bac..0000000
> --- a/keycontrol.mdb
> +++ b/keycontrol.mdb
>
> $ git stash apply
> Removing keycontrol.mdb
> # On branch refactoring
> # Changed but not updated:
> # (use "git add/rm <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working
> directory)
> #
> # deleted: keycontrol.mdb
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> Considering the output of `git show` I would expect that the contents
> of the stash are, well, what I expect them to be: a new version of
> keycontrol.mdb.
The 'index' line in your 'diff --cc' output says that back when you created that stash, the HEAD and your index both held a blob object 68a9bac and your working tree didn't have that file, ie, removed. It is very natural that the file is removed when you apply that stash.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 1/3] bash completion: fix completion issues with fetch, pull, and push
From: Nanako Shiraishi @ 2009-03-11 10:02 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Jay Soffian, git, Markus Heidelberg, Sverre Rabbelier,
Junio C Hamano
In-Reply-To: <20090306155814.GG16213@spearce.org>
Quoting Shawn O. Pearce <spearce@spearce.org>:
> Jay Soffian <jaysoffian@gmail.com> wrote:
>> Sverre Rabbelier noticed a completion issue with push:
>>
>> $ git push ori<tab>
>> git push origin
>>
>> $ git push -f ori<tab>
>> git push -f origin/
>>
>> Markus Heidelberg pointed out that the issue extends to fetch and pull.
>>
>> The reason is that the current code naively assumes that if
>> COMP_CWORD=2, it should complete a remote name, otherwise it should
>> complete a refspec. This assumption fails if there are any --options.
>>
>> This patch fixes that issue by instead scanning COMP_CWORDS to see if
>> the remote has been completed yet (we now assume the first non-dashed
>> argument is the remote). The new logic is factored into a function,
>> shared by fetch, pull, and push.
>>
>> The new function also properly handles '.' as the remote.
>>
>> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
While people's attention is on the completion, there is one case I wish the completion worked better.
"git log origin..mas[TAB]" and "git log origin...mas[TAB]" work as expected, but the same completion does not work for "git diff". I don't miss the two-dot format but it's often useful to say "git diff origin...master".
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 2/2] winansi: support ESC [ K (erase in line)
From: Johannes Schindelin @ 2009-03-11 10:22 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, gitster, Peter Harris, Sebastian Schuberth, Nicolas Pitre
In-Reply-To: <200903102258.09521.j6t@kdbg.org>
Hi,
On Tue, 10 Mar 2009, Johannes Sixt wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> This is your patch without the write() part.
Thanks! All of a sudden, this patch does not look hacky anymore...
Ciao,
Dscho
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Jakub Narebski @ 2009-03-11 10:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0902171745320.6185@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Dear fans of Git,
>
> a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> how to
>
> Use Git For What It Is Not Indended
[...]
> Number 2:
>
> At the GitTogether, Sam Vilain presented his idea to use Git as a DB backend:
>
> http://utsl.gen.nz/talks/git-db
>
> Just think about it: committing by "INSERT INTO"!
And something very similar: "Using Git as a versioned data store
in Python" by John Wiegley (similar to 'shelve' which uses database)
http://www.newartisans.com/2008/05/using-git-as-a-versioned-data-store-in-python.html
http://github.com/jwiegley/git-issues/
And similar solution for Ruby
http://github.com/georgi/git_store
by the way of GitHub Blog:
http://github.com/blog/374-git-as-a-data-store-in-python-and-ruby
P.S. When there would be next round of UGFWIINI contest?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Removed unnecessary use of global variables.
From: Johannes Schindelin @ 2009-03-11 10:30 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
In-Reply-To: <1236730168-7164-1-git-send-email-kusmabite@gmail.com>
Hi,
On Wed, 11 Mar 2009, Erik Faye-Lund wrote:
> git_config() now takes a third data-parameter that is passed back
> to the callback-function. At the time this code was written, that
> parameter did not exist, so a somewhat nasty (but by all means
> correct) use of global variables was introduced. In commit
> ef90d6d4208a5130185b04f06e5f90a5f9959fe3 Johannes Schindelin
> <Johannes.Schindelin@gmx.de> introduced a parameter for similar
> purposes.
We tend to quote commits in this form: ef90d6d(Provide git_config with a
callback-data parameter)
> I've changed the code to utilize this parameter to pass the
> string. In addition, I've made the function calculate the string
> length on usage instead, to reduce the parameters needed to what
> the callback-interface supplies.
Usually, commit messages are held in a more imperative form than a
subjective one:
Utilize this parameter to pass the string.
> diff --git a/connect.c b/connect.c
> index 2f23ab3..98fbaea 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -371,14 +371,13 @@ static void git_tcp_connect(int fd[2], char *host, int flags)
> fd[1] = dup(sockfd);
> }
>
> -
> static char *git_proxy_command;
> -static const char *rhost_name;
> -static int rhost_len;
> -
> static int git_proxy_command_options(const char *var, const char *value,
> - void *cb)
> + void *data)
> {
> + const char *rhost_name = data;
> + const size_t rhost_len = strlen(rhost_name);
> +
git_proxy_command_options is called for each and every config variable.
The idea of having the length in a local variable was to avoid
recalculating the length each and every time. I think I'd actually use a
strbuf for that.
BTW I would not rename "cb", as it is only distracting the reader of the
patch.
But I like the idea of your patch (as you can see from me replying ;-)
Thanks,
Dscho
^ permalink raw reply
* Re: Removed unnecessary use of global variables.
From: Johannes Schindelin @ 2009-03-11 10:31 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
In-Reply-To: <55ef48ab-403d-41b8-bf16-203bb0f73fc7@b16g2000yqb.googlegroups.com>
Hi,
On Tue, 10 Mar 2009, Erik Faye-Lund wrote:
> Sorry about the whole double-post thing, this whole submitting patches
> over email thing is new to me, and I'm making too many mistakes right
> now. Hopefully, I'll improve in the future ;)
No need to be sorry. Thanks for your contribution!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFD] builtin-revert.c: release index lock when cherry-picking an empty commit
From: Mike Ralphson @ 2009-03-11 11:08 UTC (permalink / raw)
To: Jeff King; +Cc: Chris Johnsen, Junio C Hamano, git, Miklos Vajna
In-Reply-To: <20090311003022.GA22273@coredump.intra.peff.net>
2009/3/11 Jeff King <peff@peff.net>:
> OK, then nothing to worry about there. I have no idea which shell
> OpenBSD and NetBSD use these days, and I don't have access to a box.
> Anybody?
OpenBSD uses pdksh in Bourne shell mode for non-root shells (ksh mode
for root) [1].
NetBSD >=4 uses a Bourne shell but I don't know the exact provenance.
[2] "A sh command appeared in Version 1 AT&T UNIX. It was, however,
unmaintainable so we wrote this one."
[1] http://www.openbsd.org/faq/faq10.html#ksh
[2] http://www.netbsd.org/docs/misc/index.html#shells
^ permalink raw reply
* Re: [PATCH] Include log_config module in apache.conf
From: Johannes Schindelin @ 2009-03-11 11:46 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LNX.1.00.0903102320170.19665@iabervon.org>
Hi,
On Tue, 10 Mar 2009, Daniel Barkalow wrote:
> The log_config module is needed for at least some versions of apache to
> support the LogFormat directive.
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> ---
> Johannes, you added the LogFormat line without this; does the test still
> work for you with this added, or do we need something clever to decide
> whether the module needs to be loaded or needs to not be loaded?
Sorry, no:
-- snip --
apache2: Syntax error on line 7 of
/home/schindelin/git/t/lib-httpd/apache.conf: module log_config_module is
built-in and can't be loaded
-- snap --
Ciao,
Dscho
^ permalink raw reply
* [PATCH v2] Include log_config module in apache.conf
From: Johannes Schindelin @ 2009-03-11 11:47 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0903111240150.10279@pacific.mpi-cbg.de>
From: Daniel Barkalow <barkalow@iabervon.org>
The log_config module is needed for at least some versions of apache to
support the LogFormat directive.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
This one works.
t/lib-httpd/apache.conf | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index af6e5e1..f460e40 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -4,6 +4,9 @@ DocumentRoot www
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog access.log common
ErrorLog error.log
+<IfModule !mod_log_config.c>
+ LoadModule log_config_module modules/mod_log_config.so
+</IfModule>
<IfDefine Darwin>
LoadModule log_config_module modules/mod_log_config.so
--
1.6.2.363.g9793e
^ permalink raw reply related
* Re: [PATCH v2] connect.c: remove a few globals by using git_config callback data
From: Johannes Schindelin @ 2009-03-11 11:52 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
In-Reply-To: <1236739092-8280-1-git-send-email-kusmabite@gmail.com>
Hi,
On Wed, 11 Mar 2009, Erik Faye-Lund wrote:
> Since ef90d6d (Provide git_config with a callback-data parameter,
> 2008-05-14), git_config() takes a callback data pointer that can be
> used to pass extra parameters to the parsing function. The codepath
> to parse configuration variables related to git proxy predates this
> facility and used a pair of file scope static variables instead.
>
> This patch removes the need for these global variables by passing the
> name of the host we are trying to access as the callback data.
>
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Thanks!
> @@ -383,6 +381,8 @@ static int git_proxy_command_options(const char *var, const char *value,
> const char *for_pos;
> int matchlen = -1;
> int hostlen;
> + const char *rhost_name = cb;
> + int rhost_len = strlen(rhost_name);
I see that you still calculate the length everytime
git_proxy_command_options() is called -- which is for every config
variable.
> @@ -426,11 +426,8 @@ static int git_proxy_command_options(const char *var, const char *value,
>
> static int git_use_proxy(const char *host)
> {
> - rhost_name = host;
> - rhost_len = strlen(host);
> git_proxy_command = getenv("GIT_PROXY_COMMAND");
> - git_config(git_proxy_command_options, NULL);
> - rhost_name = NULL;
> + git_config(git_proxy_command_options, (void*)host);
The (void *) should not be needed.
Thanks,
Dscho
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-11 11:55 UTC (permalink / raw)
To: David Symonds; +Cc: Saurabh Gupta, git
In-Reply-To: <ee77f5c20903110159l1cda4c3dnc9588c1352905932@mail.gmail.com>
Hi,
On Wed, 11 Mar 2009, David Symonds wrote:
> On Wed, Mar 11, 2009 at 3:52 PM, Saurabh Gupta
> <saurabhgupta1403@gmail.com> wrote:
>
> > *1) Domain specific merge helpers* Intelligence in the merger can be
> > put which modifies the source file according the format. Different
> > file formats can be put in the merger to support.
>
> I don't think that's Git specific, though it still might be reasonable
> to be done as a Git GSoC project. I'm sure other VCSs would find that
> useful, and even folk who aren't using VCSs might benefit from it.
It has been suggested on the GSoC mentor list, and IMHO Git is as good as
any organization to host that project.
Ciao,
Dscho
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: David Symonds @ 2009-03-11 11:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Saurabh Gupta, git
In-Reply-To: <alpine.DEB.1.00.0903111254410.10279@pacific.mpi-cbg.de>
On Wed, Mar 11, 2009 at 10:55 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> It has been suggested on the GSoC mentor list, and IMHO Git is as good as
> any organization to host that project.
Yeah, I think Git would be a good host for such a project. I'd still
like to see it VCS-neutral, though.
Dave.
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-11 11:58 UTC (permalink / raw)
To: Saurabh Gupta; +Cc: git
In-Reply-To: <49B74373.3090609@gmail.com>
Hi,
Welcome, Saurabh!
On Wed, 11 Mar 2009, Saurabh Gupta wrote:
> /*About GSoC GIT ideas; */Here are the ideas which I found to be
> interested in. Although, I would like to discuss any other idea than
> these in GIT organization.
>
> *1) Domain specific merge helpers* Intelligence in the merger can be put
> which modifies the source file according the format. Different file
> formats can be put in the merger to support.
You said that you are interested in this project, but from your mails I do
not see what are the specific reasons why.
IMHO this project can only fly if you have a specific file format that you
absolutely want to be able to merge; otherwise, it will be an uphill
fight.
Personally, I would _love_ to see a good graphical tool (maybe written
in Tcl/Tk) to help merging conflicts in LaTeX files, but I just do not
have the time...
Ciao,
Dscho
^ permalink raw reply
* Re: [BUG] - git-read-tree segfaults
From: Johannes Schindelin @ 2009-03-11 12:04 UTC (permalink / raw)
To: Jiri Olsa; +Cc: git
In-Reply-To: <35476bd20903110059v7d6d8aa0g93af17a940c91919@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1603 bytes --]
Hi,
On Wed, 11 Mar 2009, Jiri Olsa wrote:
> On Tue, Mar 10, 2009 at 9:21 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Tue, 10 Mar 2009, Jiri Olsa wrote:
> >
> >> mb=$($GIT merge-base HEAD yyy)
> >> $GIT read-tree $mb HEAD yyy
> >
> > While I agree that it is a bad thing for Git to segfault, I think this
> > here is a pilot error. You try to read 3 trees at the same time, but
> > not perform a merge. IMHO you want to add -m at least.
>
> agreed, I've already said I executed it like this by an accident...
Hey, you did the right thing! And you even provided a script to recreate,
so that it was really easy to see what is happening.
> it was easy to recreate so I shared... I'm not saying it is a show
> stopper :)
Well, Git should not crash. But read-tree is real low-level, so I am
torn. OTOH, something like this may be the correct thing to do:
-- snipsnap --
Subject: [PATCH] Make read-tree with multiple trees imply -m
Noticed by Jiri Olsa.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-read-tree.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 8e02738..547ac25 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -221,6 +221,11 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
opts.head_idx = 1;
}
+ if (nr_trees > 1 && !o->merge) {
+ warning("Assuming -m with multiple trees");
+ o->merge = 1;
+ }
+
for (i = 0; i < nr_trees; i++) {
struct tree *tree = trees[i];
parse_tree(tree);
^ permalink raw reply related
* Re: Generalised bisection
From: Johannes Schindelin @ 2009-03-11 12:05 UTC (permalink / raw)
To: John Tapsell; +Cc: Ealdwulf Wuffinga, Christian Couder, Git List, Ingo Molnar
In-Reply-To: <43d8ce650903110235q5e2a59f6t201d5e65a4937476@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1161 bytes --]
Hi,
On Wed, 11 Mar 2009, John Tapsell wrote:
> 2009/3/11 Ealdwulf Wuffinga <ealdwulf@googlemail.com>:
> > On Tue, Mar 10, 2009 at 7:08 AM, Christian Couder
> > <chriscool@tuxfamily.org> wrote:
> >
> >> I will try to have a look at the end of this week.
> >> But do you want it to be integrated with Git or do you want it to be an
> >> independant project that works with many different version control system?
> >
> > Hmm. Whatever works, I guess. On the one hand the code does seem
> > naturally generic. On the other hand, it's good if users don't
> > have to separately obtain an extra package to use it. Supposing that
> > the algorithm proves useful, would the git project be okay with an
> > extra dependency, or would you want to integrate it? Right now it's in
> > python, which I understand is an obstacle to integration.
>
> There used to be a dependency on python. git-merge-recursive for
> example, before it was converted to C.
Not "for example". It was the only dependency of git.git on Python, and
the rewrite of merge-recursive was only done to break that dependency, as
I had a platform where I could not install Python.
Ciao,
Dscho
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Johannes Schindelin @ 2009-03-11 12:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3wsawgxto.fsf@localhost.localdomain>
Hi,
On Wed, 11 Mar 2009, Jakub Narebski wrote:
> P.S. When there would be next round of UGFWIINI contest?
Whenever I collected ten new participants... You are helping ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Generalised bisection
From: John Tapsell @ 2009-03-11 12:08 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Ealdwulf Wuffinga, Christian Couder, Git List, Ingo Molnar
In-Reply-To: <alpine.DEB.1.00.0903111304520.10279@pacific.mpi-cbg.de>
2009/3/11 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Wed, 11 Mar 2009, John Tapsell wrote:
>
>> 2009/3/11 Ealdwulf Wuffinga <ealdwulf@googlemail.com>:
>> > On Tue, Mar 10, 2009 at 7:08 AM, Christian Couder
>> > <chriscool@tuxfamily.org> wrote:
>> >
>> >> I will try to have a look at the end of this week.
>> >> But do you want it to be integrated with Git or do you want it to be an
>> >> independant project that works with many different version control system?
>> >
>> > Hmm. Whatever works, I guess. On the one hand the code does seem
>> > naturally generic. On the other hand, it's good if users don't
>> > have to separately obtain an extra package to use it. Supposing that
>> > the algorithm proves useful, would the git project be okay with an
>> > extra dependency, or would you want to integrate it? Right now it's in
>> > python, which I understand is an obstacle to integration.
>>
>> There used to be a dependency on python. git-merge-recursive for
>> example, before it was converted to C.
>
> Not "for example". It was the only dependency of git.git on Python, and
> the rewrite of merge-recursive was only done to break that dependency, as
> I had a platform where I could not install Python.
But installing perl was no problem? (Just curious)
John
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-11 12:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903111255470.10279@pacific.mpi-cbg.de>
On Wed, Mar 11, 2009 at 5:28 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi,
>
> Welcome, Saurabh!
>
> On Wed, 11 Mar 2009, Saurabh Gupta wrote:
>
> > /*About GSoC GIT ideas; */Here are the ideas which I found to be
> > interested in. Although, I would like to discuss any other idea than
> > these in GIT organization.
> >
> > *1) Domain specific merge helpers* Intelligence in the merger can be put
> > which modifies the source file according the format. Different file
> > formats can be put in the merger to support.
>
> You said that you are interested in this project, but from your mails I do
> not see what are the specific reasons why.
>
All right. May be I lacked in my mail to specify the reason for my
interest. The reason is that from my past experience, I got the notion
that this project is according to my interest and is doable in the
three months time period.
Another reason is that I have been using the versioning tools like svn
and now perforce for a long time and this added up to my interest.
> IMHO this project can only fly if you have a specific file format that you
> absolutely want to be able to merge; otherwise, it will be an uphill
> fight.
>
Well, as suggested on the wiki, I would like to work on the xml file
formats as I have quite experience of working with xml files and
parsing them using msxml and nsxml libraries and some of personal
wrappers.
How about my idea of making the support of new file formats in the
plug-ins (suggested in my last post). I would like to discuss more on
this and any new suggestions or methods are welcome.
> Personally, I would _love_ to see a good graphical tool (maybe written
> in Tcl/Tk) to help merging conflicts in LaTeX files, but I just do not
> have the time...
Ok. What I am thinking is to implement something like that of
graphical *diff* command output but in these special file formats, it
ought to have intelligence to bring out the difference of two files
(like latex or xml) in a readable manner. For example, in case of xml
files, if one file contains an inner tag block , then merger GUI
should notify the user in a readable manner about this added tag
rather than only the difference in lines.
>
> Ciao,
> Dscho
>
Regards...
--
Saurabh Gupta
Senior,
NSIT,New Delhi, India
^ permalink raw reply
* Wrong, misleading error message when "branch.<name>.merge" is invalid
From: Matthieu Poullet @ 2009-03-11 12:27 UTC (permalink / raw)
To: git
Hi,
today I've tried to update a repo I haven't used for a while (see
complete log below).
When trying to pull changes for my remote tracking branch, I've got an
error message suggesting that my config was wrong instead of
suggesting that this branch was gone on the remote.
As people (thanks to them) explain me on #git, fetch doesn't remove
stale tracking branches, and so in this case the error message is
pretty misleading.
Maybe "Error: ref 'refs/heads/omap3' does not exist in remote repo
'origin'" (suggested by Ilari on #git) would be more appropriate?
Regards,
Matthieu.
mpoullet@LU84-mpoullet:~/src/u-boot-arm$ git branch -a
* master
omap3
origin/20070326_ene
origin/HEAD
origin/master
origin/mm
origin/next
origin/old-next
origin/omap3
origin/testing
mpoullet@LU84-mpoullet:~/src/u-boot-arm$ git pull
Already up-to-date.
mpoullet@LU84-mpoullet:~/src/u-boot-arm$ git checkout omap3
Switched to branch "omap3"
mpoullet@LU84-mpoullet:~/src/u-boot-arm$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch.omap3.merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.omap3.remote = <nickname>
branch.omap3.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
mpoullet@LU84-mpoullet:~/src/u-boot-arm$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://git.denx.de/u-boot-arm.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "omap3"]
remote = origin
merge = refs/heads/omap3
^ permalink raw reply
* Re: Confusing `stash apply` behavior
From: Tim Visher @ 2009-03-11 12:45 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090311190217.6117@nanako3.lavabit.com>
On Wed, Mar 11, 2009 at 6:02 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Tim Visher <tim.visher@gmail.com>:
>
>> When I do `git stash apply`, it deletes the file I'm working with.
>>
>> $ ls
>> featureList.txt* keycontrol.mdb*
>>
>> $ git show stash@{0}
>> commit b3c0f4b9b3c3ef7741a03fb27174f5838abc939d
>> Merge: 9fb9886 112bba9
>> Author: Tim Visher <timothy.visher@fms.treas.gov>
>> Date: Tue Mar 10 15:25:04 2009 -0400
>>
>> WIP on dev: 9fb9886 Added DB Lock file to .gitignore. EOM
>>
>> diff --cc keycontrol.mdb
>> index 68a9bac,68a9bac..0000000
>> --- a/keycontrol.mdb
>> +++ b/keycontrol.mdb
>>
>> $ git stash apply
>> Removing keycontrol.mdb
>> # On branch refactoring
>> # Changed but not updated:
>> # (use "git add/rm <file>..." to update what will be committed)
>> # (use "git checkout -- <file>..." to discard changes in working
>> directory)
>> #
>> # deleted: keycontrol.mdb
>> #
>> no changes added to commit (use "git add" and/or "git commit -a")
>>
>> Considering the output of `git show` I would expect that the contents
>> of the stash are, well, what I expect them to be: a new version of
>> keycontrol.mdb.
>
> The 'index' line in your 'diff --cc' output says that back when you created that stash, the HEAD and your index both held a blob object 68a9bac and your working tree didn't have that file, ie, removed. It is very natural that the file is removed when you apply that stash.
Huh. I don't know how that would have happened, but I guess I should
have been more careful with the stash command. Oh well.
Thanks for your help!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-11 12:52 UTC (permalink / raw)
To: David Symonds; +Cc: Saurabh Gupta, git
In-Reply-To: <ee77f5c20903110455p6926b580i8c8e92b051328d18@mail.gmail.com>
Hi,
On Wed, 11 Mar 2009, David Symonds wrote:
> On Wed, Mar 11, 2009 at 10:55 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > It has been suggested on the GSoC mentor list, and IMHO Git is as good
> > as any organization to host that project.
>
> Yeah, I think Git would be a good host for such a project. I'd still
> like to see it VCS-neutral, though.
Yeah, I cannot see this begin Git-specific, either. But it may be
integrated with Git so that it works best using Git...
Ciao,
Dscho
^ permalink raw reply
* Re: git-p4 workflow suggestions?
From: Pete Wyckoff @ 2009-03-11 12:58 UTC (permalink / raw)
To: Sam Hocevar; +Cc: git
In-Reply-To: <20090309142108.GK12880@zoy.org>
sam@zoy.org wrote on Mon, 09 Mar 2009 15:21 +0100:
> I have modified git and git-p4 to a point where they are usable in
> my work environment. I am now faced with a new problem: Perforce's
> composite workspaces. They allow you to "mount" parts of the repo onto
> other directories, even nonempty ones.
>
> Take the following example repository, where a "framework" project
> contains an example subdirectory with build files and other directories,
> and a "project1" project contains subdirectories that are meant to
> replace the ones in "example":
>
> //work/framework/example/src/
> /include/
> /Makefile
> /...
> //work/project1/src/
> /include/
In perforce terms, your "view mapping" looks like:
//work/framework/example/src/... //client/src/...
//work/project1/src/include/... //client/src/include/...
?
I'm not a pro with p4, but do deal with many-line mappings like
this. Stock git-p4 handles these, except doesn't map correctly to
the right-hand side. I haven't tried to see if it would correctly
use the include files from project1 instead of framework in your
example.
If you can get git-p4 to figure out the mapping correctly, I don't
expect any problems with respect to atomicity of commits. As far as
perforce goes, a server seems to manage its entire p4 space as one
big single project. Similarly with the git side of things---it's
just a matter of getting this mapping correct.
I too hacked the getClientSpec() part of git-p4 to put files into
the correct directories in the git side. My changes are a bit
messy, and may interfere with other usage models, hence not
submitted. Maybe we should make an effort to get this right though.
Do you have any changes to show how you are modifying things?
-- Pete
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-11 12:58 UTC (permalink / raw)
To: saurabh gupta; +Cc: git
In-Reply-To: <ab9fa62a0903110511u63e7d46dr3bb783ee891ca4ae@mail.gmail.com>
Hi,
On Wed, 11 Mar 2009, saurabh gupta wrote:
> On Wed, Mar 11, 2009 at 5:28 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Wed, 11 Mar 2009, Saurabh Gupta wrote:
> >
> > > /*About GSoC GIT ideas; */Here are the ideas which I found to be
> > > interested in. Although, I would like to discuss any other idea than
> > > these in GIT organization.
> > >
> > > *1) Domain specific merge helpers* Intelligence in the merger can be
> > > put which modifies the source file according the format. Different
> > > file formats can be put in the merger to support.
> >
> > You said that you are interested in this project, but from your mails
> > I do not see what are the specific reasons why.
>
> All right. May be I lacked in my mail to specify the reason for my
> interest.
Oh, sorry, I did not mean to imply any offense...
> The reason is that from my past experience, I got the notion that this
> project is according to my interest and is doable in the three months
> time period.
>
> Another reason is that I have been using the versioning tools like svn
> and now perforce for a long time and this added up to my interest.
Sounds good!
> > IMHO this project can only fly if you have a specific file format that
> > you absolutely want to be able to merge; otherwise, it will be an
> > uphill fight.
>
> Well, as suggested on the wiki, I would like to work on the xml file
> formats as I have quite experience of working with xml files and parsing
> them using msxml and nsxml libraries and some of personal wrappers.
As I am known to not exactly like Microsoft's products, if you wanted to
have me as a mentor, you'd need to use Open Source libraries to do the
parsing.
> How about my idea of making the support of new file formats in the
> plug-ins (suggested in my last post).
Sorry, I missed that idea. Could you describe it again?
> > Personally, I would _love_ to see a good graphical tool (maybe written
> > in Tcl/Tk) to help merging conflicts in LaTeX files, but I just do not
> > have the time...
>
> Ok. What I am thinking is to implement something like that of
> graphical *diff* command output but in these special file formats, it
> ought to have intelligence to bring out the difference of two files
> (like latex or xml) in a readable manner. For example, in case of xml
> files, if one file contains an inner tag block , then merger GUI
> should notify the user in a readable manner about this added tag
> rather than only the difference in lines.
A diff would be a first step, but the real issue are the merge helpers.
And they need first and foremost a thought-through user interface design.
The technical issues are all solveable, I am sure.
Ciao,
Dscho
^ permalink raw reply
* Re: Generalised bisection
From: Johannes Schindelin @ 2009-03-11 13:04 UTC (permalink / raw)
To: John Tapsell; +Cc: Ealdwulf Wuffinga, Christian Couder, Git List, Ingo Molnar
In-Reply-To: <43d8ce650903110508o3d12f32m8202fae750d215a@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1220 bytes --]
Hi,
On Wed, 11 Mar 2009, John Tapsell wrote:
> 2009/3/11 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Wed, 11 Mar 2009, John Tapsell wrote:
> >
> >> There used to be a dependency on python. git-merge-recursive for
> >> example, before it was converted to C.
> >
> > Not "for example". It was the only dependency of git.git on Python,
> > and the rewrite of merge-recursive was only done to break that
> > dependency, as I had a platform where I could not install Python.
>
> But installing perl was no problem? (Just curious)
Perl was installed, albeit in an ancient version, and compiling Perl
modules written in C was out. It just did not work.
But the good part was: after converting rerere to be a builtin, there
were no Perl scripts left that I wanted/needed to use.
These days, we only have these Perl scripts left: add--interactive,
archimport, cvsexportcommit, cvsimport, cvsserver, relink, send-email and
svn.
Ignoring the scripts to interact with other SCMs (which I can do on
another computer), that leaves add--interactive, relink (which could be
moved to contrib/ AFAIAC) and send-email.
I use "add -e" instead of "add -i", and stay away from send-email...
Ciao,
Dscho
^ 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