* Re: git status in clean working dir
From: Abhijit Menon-Sen @ 2008-07-22 2:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Bremner, git
In-Reply-To: <7vy73ur6pz.fsf@gitster.siamese.dyndns.org>
At 2008-07-21 19:30:16 -0700, gitster@pobox.com wrote:
>
> I think this is an instance of the c8af1de (make git-status use a
> pager, 2008-04-23) stupidity raising its ugly head again.
>
> Do people mind reverting that patch?
I think that is an excellent idea. I've found myself annoyed time and
again by "git status" starting the pager for just a couple of lines of
output.
-- ams
^ permalink raw reply
* Re: git status in clean working dir
From: Junio C Hamano @ 2008-07-22 2:30 UTC (permalink / raw)
To: David Bremner; +Cc: git
In-Reply-To: <0ttzeirft8.wl%bremner@pivot.cs.unb.ca>
David Bremner <bremner@unb.ca> writes:
> According to the manual page for git-status (version 1.5.6.3)
>
> If there is no path that is different between the index file
> and the current HEAD commit (i.e., there is nothing to commit
> by running git-commit), the command exits with non-zero status.
>
> But it doesn't seem to work that way for me.
>
> git status -a
>
> exits with 0
> ...
Try "git status -a >/dev/null" or "git --no-pager status -a".
I think this is an instance of the c8af1de (make git-status use a pager,
2008-04-23) stupidity raising its ugly head again.
Do people mind reverting that patch?
^ permalink raw reply
* Re: [PATCH for master] Rename path_list to string_list
From: Junio C Hamano @ 2008-07-22 2:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0807211904090.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> @@ -64,9 +65,10 @@ Functions
>
> `string_list_clear`::
>
> - Free a string_list. The `path` pointer of the items will be freed in case
> - the `strdup_strings` member of the string_list is set. The second parameter
> - controls if the `util` pointer of the items should be freed or not.
> + Free a string_list. The `path` pointer of the items will be freed in
> + case the `strdup_strings` member of the string_list is set. The second
> + parameter controls if the `util` pointer of the items should be freed
> + or not.
Missed 's/path/string/' here?
Everything else looked fine, thanks.
^ permalink raw reply
* extracting the history of a single file as a new project [Was: Re: making a branch with just one file and keeping its whole]
From: ncrfgs @ 2008-07-22 2:14 UTC (permalink / raw)
To: git; +Cc: madewokherd
In-Reply-To: <alpine.DEB.1.00.0807211937390.8986@racer>
[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]
On Mon, 21 Jul 2008 20:39:45 +0200
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> However, I think that the OP was talking about something completely
> different: extracting the history of a single file as a new branch.
Exactly, but rather than a new branch I'd like to start a new project.
I've just realized the original subject name could have been a bit
misleading; I took it from the description a guy on #git@freenode has
given of what he thought I wanted to do, but probably I didn't explain
myself properly at that time.
> This will not start a new branch, which is what I presume you want to
> do. The "correct" (as in: probably the best) way to do it is to make a
> new directory, initialize a new git repository in it, and when you
> have something, push that branch into the other repository.
As far as I could understand, that screencast demonstrates how to create
empty branches in Git; in other words branches that are not derivatives
of your main branches, but entirely new projects.
In my case I don't want to start an entirely new project, but rather
start a new project from a file of an existing project and keeping his
history.
In the screencast, the author creates an empty branch to store the
website code in for my project, so he doesn't have to store it as a
subdirectory of his main project.
What I want to do, I think, is kinda different.
Let's say we are at commit #3000, I have this content I want to start a
new project from, which has been put in three different files:
path1/filename1 from commit 1 to commit 1000
path2/filename1 from commit 1001 to commit 2000
path2/filename2 from commit 2001 to commit 3000
In the meanwhile path1/filename1 has been created on commit 2500 with
path1/filename1 having nothing to do with the new project I'd like to
start.
My first idea to accomplish what I'd like to do, was to use the ouput of
`git-log -p --follow path2/filename2` with another git command; on
#git@freenode I've been suggested to use git-clone and
git-filter-branch.
Both from search results on the web and from the man pages, I've found
examples of git-filter-branch usage which aim to delete just one file
(or a small group of files) from the existing project's history.
What I'd like to do instead is to keep just one file which has been
renamed a couple of time.
On #git I've been also told to use also another combination of commands
which included git-commit-tree but I haven't managed to understand what
they meant. Another combination of commands included git-am instead.
Any suggestion is welcome. :)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] checkout without arguments does not make sense
From: Johannes Schindelin @ 2008-07-22 0:57 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Avery Pennarun, Johannes Sixt, Junio C Hamano, git
In-Reply-To: <20080721214459.GJ32057@genesis.frugalware.org>
Hi,
On Mon, 21 Jul 2008, Miklos Vajna wrote:
> On Mon, Jul 21, 2008 at 05:36:59PM -0400, Avery Pennarun <apenwarr@gmail.com> wrote:
>
> > I think "git status" reports this information in recent versions,
> > doesn't it?
>
> Right. But that shows other infos as well, for example the untracked
> files, etc. So there are cases when git checkout is just better.
>
> However, you are right about it may not be the best habit from my side
> to use git checkout to get that info. ;-)
I usually call "git status" for that information. But Junio suggested
checkout recently on #git, for exactly that information, so you are not
alone at all.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation/git-ls-tree.txt: Add a caveat about prefixing pathspec
From: Junio C Hamano @ 2008-07-22 0:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080721210452.GP10151@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> commit. E.g.
>>
>> $ cd some/deep/path
>> $ git ls-tree --name-only -r HEAD~20
>>
>> will list the files in some/deep/path (i.e. where you are) 20
>> commits ago, just like running "/bin/ls" there will give you the
>> list of files you have right now.
>
> Frankly, I think this is overdoing it. I'm all for being positive, but
> it is obvious why this is good thing when you inspect a root tree and
> there's no need to be too wordy about it...
I mildly disagree.
If the person had truly understood that, why do we even have this thread
to begin with?
Description on *what* it does (i.e. "like what ls -a does in the current
working directory" we have in the Description section) obviously was not
good enough. It will be better understood if you describe *why* it does
it that way at the same time.
^ permalink raw reply
* git status in clean working dir
From: David Bremner @ 2008-07-21 23:13 UTC (permalink / raw)
To: git
According to the manual page for git-status (version 1.5.6.3)
If there is no path that is different between the index file
and the current HEAD commit (i.e., there is nothing to commit
by running git-commit), the command exits with non-zero status.
But it doesn't seem to work that way for me.
git status -a
exits with 0
but
git commit -a
exits with 1
Is the man page wrong, or is this a bug? Or, option #3 ?
David
P.S. Please CC me. I'm not on the list.
^ permalink raw reply
* Re: [PATCH 2/9] Makefile: Normalize $(bindir) and $(gitexecdir) before comparing
From: Johannes Schindelin @ 2008-07-21 23:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <1216667998-8879-3-git-send-email-johannes.sixt@telecom.at>
Hi,
On Mon, 21 Jul 2008, Johannes Sixt wrote:
> + bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
> + execdir=$$(cd '$(DESTDIR_SQ)$(gitexecdir_SQ)' && pwd) && \
These lack quotes, no?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/9] Make gitexecdir relative to $(bindir) on Windows
From: Johannes Schindelin @ 2008-07-21 23:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <1216667998-8879-1-git-send-email-johannes.sixt@telecom.at>
Hi,
On Mon, 21 Jul 2008, Johannes Sixt wrote:
> The problem was that argv[0] does not have a path in certain cases.
Note that the same holds true for Linux when calling a program that is in
the PATH:
-- snip --
#include <stdio.h>
int main(int argc, char **argv)
{
printf("%s\n", argv[0]);
return 0;
}
-- snap --
compiled and put into the PATH will output just what the user said, not
the full path.
I imagine that the proper solution would be to rip out lookup_prog() and
use it for non-Windows Git, too. Unless you want to limit the usefulness
of your patch series to Windows, that is.
In which case you could use lookup_prog() after unstatifying it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH for master] Rename path_list to string_list
From: Johannes Schindelin @ 2008-07-21 23:33 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <alpine.DEB.1.00.0807211904090.8986@racer>
Hi,
On Mon, 21 Jul 2008, Johannes Schindelin wrote:
> my-prepare-patch.sh | 2 +-
As was pointed out to me privately, this should not have been part of the
interdiff. It is the script I used to prepare the interdiff, and it
needed fixing in order to run without "git-apply" in the PATH. That is
how this change slipped in.
Please just ignore that file,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0
From: Johannes Schindelin @ 2008-07-21 23:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20080721194322.GA4013@blimp.local>
Hi,
On Mon, 21 Jul 2008, Alex Riesen wrote:
> Johannes Schindelin, Mon, Jul 21, 2008 20:20:43 +0200:
>
> > Alex wrote:
> >
> > > Can MSys folks please try it? I noticed it when the test
> > > t2103-update-index-ignore-missing.sh (the 5th case) started failing.
> >
> > Since M$' documentation says "This member does not have a meaning for
> > directories." about the member nFileSizeLow of
> > WIN32_FILE_ATTRIBUTE_DATA which we use to implement a sane "lstat()",
> > I think this bug hits MinGW (not MSys) as well.
>
> Could you, just for completeness, try?
No, I cannot. I have no Windows machine.
Ciao,
Dscho
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-21 22:57 UTC (permalink / raw)
To: Tim Harper; +Cc: Git Mailing List
In-Reply-To: <8C23FB54-A28E-4294-ABEA-A5766200768B@gmail.com>
[ git channel added back to cc, because this is an interesting question in
itself ]
On Mon, 21 Jul 2008, Tim Harper wrote:
>
> Another false impression I had is a merge conflict resolution would always be
> displayed in a merge commit. However, after running over the merges again, if
> you pick the right or left, discarding the one or the other, nothing is shown
> in "git log -p" for the merge commit. Is there a way to see what was chosen
> for a conflict resolution? Seeing that in the merge commit would have made
> things a little more clear.
The default behavior for showing merges is "--cc", which is the condensed
version that only shows _actual_ conflicts that got resolved differently
from either of the sources.
But note how this is an "after-the-fact" determination: it doesn't look
whether the merge _did_ conflict (because doing that would require
re-running the whole merge!), but it looks whether the end _result_ is
different from either side.
So you can easily have a merge that conflicts - but then you resolve that
merge by picking just one side of the merge as the result. And in that
case the "--cc" diff will not show anything at all - because the end
result did not conflict with the sources of the merge!
So "--cc" only shows output if: the merge itself actually changed
something from _all_ parents. This can happen if:
- there was a non-trivial conflict, and the end result really was a
"mixture" of the two. The result wasn't just a select of either side,
it was a combination of the two.
This is obviously one "common" case for a merge resolution.
But it's equally common that when you merge something you just say "Ok,
that other side did it better, I'll just pick that version". And in
that case, "--cc" won't show anything at all, because it's not really a
conflict any more once you've done that choice.
- There can also be an "evil merge" that actually adds/changes/deletes
code that didn't exist AT ALL in either side. And --cc is very much
designed to show that.
This is actually not always a bad thing (despite the name "evil
merge"), because it happens regularly that one branch had changed some
infrastructure setup or other, and the other branch had added a totally
new use of that infrastructure - and as a result the _merge_ needs to
add that setup code that didn't exist in either of the branches (in one
because the use wasn't there, in the other because the setup wasn't
needed).
Anyway, this all means that yes, "--cc" _often_ shows conflicts, but not
always - exactly because it doesn't show the ones that the merge had
committed as a non-conflict.
If you actually want to see the _real_ conflicts that happened as the
merge was done, you do have to re-do it.
Linus
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Tim Harper @ 2008-07-21 22:55 UTC (permalink / raw)
To: git
In-Reply-To: <E301C92A-8794-4E90-9C85-D73B94A2648C@gmail.com>
On Jul 21, 2008, at 4:53 PM, Tim Harper wrote:
>
> On Jul 21, 2008, at 2:37 PM, Linus Torvalds wrote:
>
>>
>>
>> On Mon, 21 Jul 2008, Tim Harper wrote:
>>>
>>> Anyone run into this before? Any idea what might have caused it?
>>> We're a bit
>>> concerned about this because if we don't know how to avoid this,
>>> we no longer
>>> can feel certain that when something is committed, it will make it
>>> out in our
>>> release.
>>
>> Read up on '--full-history'.
>>
>> By default, git simplifies the history for logs that have path
>> simplification: only walking down the side of a merge that all the
>> data
>> came from (ie the unchanged side). So it only leaves merges around if
>> there was changes from _all_ parents.
>>
>> So without --full-history, if any parent matches the state, it just
>> removes the merge and picks that parent that contained all the state.
>> Obviously, any changes to that file can be sufficiently explained by
>> walking just that limited history, because they must have changed in
>> _that_ history too!
>>
>> That default behaviour leads to a *much* simpler history, and is
>> usually
>> what you want - it avoids unnecessary duplication when something was
>> changed trivially the same way in both branches - 'git log' will
>> just pick
>> the first branch.
>>
>
> Agreed - this was an insightful decision.
>
>> So, if you had two (or more) commits that both fixed the same bug in
>> different branches, and thus both branches actually ended up with
>> the same
>> contents, it does mean that "git log <filename>" will only show
>> _one_ of
>> the fixes.
>>
>> In this case, it apparently showed another version than the one you
>> were
>> looking for.
>>
>> Linus
>
> Git has made me feel stupid on various occasions. This is no
> exception as the problem turned out being in the chair, not in git.
>
> After running through git bisect, and ran the command Alex Riesen
> suggested, it made it pretty crystal clear where things went wrong.
> It turned out to be a bad merge that was from a conflict related to
> white-space issues, and the wrong resolution was chosen (a
> resolution that also consequently turned out to be no change).
>
> Another false impression I had is a merge conflict resolution would
> always be displayed in a merge commit. However, after running over
> the merges again, if you pick the right or left, discarding the one
> or the other, nothing is shown in "git log -p" for the merge
> commit. Is there a way to see what was chosen for a conflict
> resolution? Seeing that in the merge commit would have made things
> a little more clear.
>
Actually, I found it:
http://www.kernel.org/pub/software/scm/git/docs/git-log.html
"git log -p -c" gives me what I was looking for
Tim
> Thank you for articulating git branch's behavior - all is clear as
> mud now :)
>
> Tim
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Tim Harper @ 2008-07-21 22:53 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.1.10.0807211331390.31863@woody.linux-foundation.org>
On Jul 21, 2008, at 2:37 PM, Linus Torvalds wrote:
>
>
> On Mon, 21 Jul 2008, Tim Harper wrote:
>>
>> Anyone run into this before? Any idea what might have caused it?
>> We're a bit
>> concerned about this because if we don't know how to avoid this, we
>> no longer
>> can feel certain that when something is committed, it will make it
>> out in our
>> release.
>
> Read up on '--full-history'.
>
> By default, git simplifies the history for logs that have path
> simplification: only walking down the side of a merge that all the
> data
> came from (ie the unchanged side). So it only leaves merges around if
> there was changes from _all_ parents.
>
> So without --full-history, if any parent matches the state, it just
> removes the merge and picks that parent that contained all the state.
> Obviously, any changes to that file can be sufficiently explained by
> walking just that limited history, because they must have changed in
> _that_ history too!
>
> That default behaviour leads to a *much* simpler history, and is
> usually
> what you want - it avoids unnecessary duplication when something was
> changed trivially the same way in both branches - 'git log' will
> just pick
> the first branch.
>
Agreed - this was an insightful decision.
> So, if you had two (or more) commits that both fixed the same bug in
> different branches, and thus both branches actually ended up with
> the same
> contents, it does mean that "git log <filename>" will only show
> _one_ of
> the fixes.
>
> In this case, it apparently showed another version than the one you
> were
> looking for.
>
> Linus
Git has made me feel stupid on various occasions. This is no
exception as the problem turned out being in the chair, not in git.
After running through git bisect, and ran the command Alex Riesen
suggested, it made it pretty crystal clear where things went wrong.
It turned out to be a bad merge that was from a conflict related to
white-space issues, and the wrong resolution was chosen (a resolution
that also consequently turned out to be no change).
Another false impression I had is a merge conflict resolution would
always be displayed in a merge commit. However, after running over
the merges again, if you pick the right or left, discarding the one or
the other, nothing is shown in "git log -p" for the merge commit. Is
there a way to see what was chosen for a conflict resolution? Seeing
that in the merge commit would have made things a little more clear.
Thank you for articulating git branch's behavior - all is clear as mud
now :)
Tim
^ permalink raw reply
* Re: [StGit PATCH] Test that we can add a new file to a non-topmost patch with refresh -p
From: Catalin Marinas @ 2008-07-21 22:01 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Jon Smirl
In-Reply-To: <20080718180109.GA14825@diana.vm.bytemark.co.uk>
2008/7/18 Karl Hasselström <kha@treskal.com>:
> On 2008-07-18 19:03:06 +0200, Karl Hasselström wrote:
>
>> We currently can't -- this is bug 12038, found by Jon Smirl. See
>>
>> https://gna.org/bugs/index.php?12038
>
> OK, the problem is that to pop the patches on top of the one we are to
> refresh, we call pop_patch(keep = True). This in turn calls
> git.switch(keep = True), which resets the index (but is careful to not
> touch the worktree).
Yes.
> I'm not quite sure how to fix this in a simple way -- the code simply
> assumes that the index contains nothing of interest. And since I
> already have a rewrite of refresh that handles this and a handful of
> other cases that the old code does not, I'm kind of disinclined to
> undertake a larger restructuring of the code.
>
> Catalin, what do you think?
I don't think we should spend time on fixing the current code as you
already have a new implementation. Maybe we could add a simple test
and refuse refreshing other than the topmost patch in case of files
added to the index.
--
Catalin
^ permalink raw reply
* Re: [PATCH] builtin-merge: missing structure bzero.
From: Pierre Habouzit @ 2008-07-21 21:49 UTC (permalink / raw)
To: Miklos Vajna, git, gitster
In-Reply-To: <20080721181850.GA2718@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 4378 bytes --]
On Mon, Jul 21, 2008 at 06:18:50PM +0000, Pierre Habouzit wrote:
> On Mon, Jul 21, 2008 at 05:21:19PM +0000, Miklos Vajna wrote:
> > On Mon, Jul 21, 2008 at 07:03:50PM +0200, Pierre Habouzit <madcoder@debian.org> wrote:
> > > This cause segfaults when replacing a directory with a submodule in a
> > > fast-forward.
> >
> > Thanks.
> >
> > > +test_expect_failure 'Replace a directory with a submodule, with a file conflict' '
> > > + mkdir test &&
> > > + cd test &&
> > > + : create our repository with a sub/a file &&
> > > + git init &&
> > > + mkdir sub && echo a > sub/a &&
> > > + git add sub && git commit -asm"initial repository" &&
> > > + : save this state in a new branch &&
> > > + git branch temp &&
> > > + : then replace sub with it &&
> > > + git rm -rf sub &&
> > > + git submodule add -- "$(pwd)/../submodule/.git/" sub &&
> > > + git commit -asm "replace sub/ with a submodule" &&
> > > + : then try to update the "temp" branch &&
> > > + git checkout temp &&
> >
> > It seems this one fails. I guess this will be a problem in the low-level
> > merge code (read-tree -m) and not in builtin-merge.
>
> Yeah, I saw that afterwards, the error was misleading (as it tells
> about some "merge" issue), but when I tried to debug it, it was indeed
> in git checkout. The easiest way to reproduce, is to have a submodule
> that replace a file that was previously versionned (which is something
> that will happen in real life when you take out a subdirectory of a
> project to make it live into a submodule) and that you then git checkout
> HEAD~1.
Actually, the issue is quite obvious when thinking. At git-checkout
time, git doesn't recurse (yet) into submodules, hence when we checkout
'temp' that is basically master~1 that basically does that:
"sub/" is a submodule, and gets replaced by sub/ a tree with "a" in it,
and the submodule _also_ has "a". As submodules are ignored silently, it
just:
(1) forgets about the submodule at once, leaving all the submodules
files into the wild, and sub/a (that was in the submodule) is now
an untracked file.
(2) tries to checkout sub/a and sees a file currently untracked and
barfs.
So it boils down to the fact that git-checkout does nothing with
submodules. I really think we should address that, it's a major issue
wrt submodules and usability.
I believe we should for now require that all submodules are clean for
checkout to be able to work, and then we have those cases:
* submodule -> directory: ignore any file that is either versionned or
ignored in the submodule wrt checkout issues. If no issue arises
with untracked non ignored files in the submodule, then basically:
(1) in the submodule: git ls-files | xargs rm -f ; rm -rf .git
(2) proceed with the checkout.
* submodule -> blob: refuse to proceed if there is any untracked non
ignored file in the submodule, else just rm -rf it, and proceed.
* submodule h1 -> h2: if "git checkout h2" will work in the submodule,
then we have no problem with the checkout, and do proceed. Though,
if the checkout isn't possible because "h2" is unknown, then instead
of a "cannot read h2" error, one should suggest the user to update
its submodules (he probably lacks some objects and needs to fetch).
Special case: if the submodule isn't initialized, proceed and warn
about the submodule being uninitialized.
* {blob,directory} -> submodule already work properly, though
suggesting the user to run "git submodule update -i" when we *know*
we have uninitialized submodules because of a checkout is a good
idea.
Note that uninitialized submodules are not special cases for the two
first cases, because uninitialized submodules are not different from a
directory with possibly untracked files in it. An uninitialized
submodule probably need to be dealt with as if it's clean from many
places actually.
The issue is that I tried to grok upack-trees.c, but the code is quite
dense, and how to hack this efficiently still eludes me, because I don't
really get the big picture enough yet.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 1/2] git-svn: teach dcommit about svn auto-props
From: Brad King @ 2008-07-21 21:40 UTC (permalink / raw)
To: git; +Cc: Eric Wong
[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]
Subversion repositories often require files to have properties such as
svn:mime-type and svn:eol-style set when they are added. Users
typically set these properties automatically using the SVN auto-props
feature with 'svn add'. This commit teaches dcommit to look at the user
SVN configuration and apply matching auto-props entries for files added
by a diff as it is applied to the SVN remote. A later commit will make
this feature optional.
Signed-off-by: Brad King <brad.king@kitware.com>
---
This change honors the user's enable-auto-props svn config setting.
The next patch will configure this at the git level and add the
corresponding documentation.
I've tested this by hand on an real SVN repo that checks for mime type.
Unfortunately I'm unable to run the git-svn test suite because I get
the error reported here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486527
(even without my changes).
git-svn.perl | 47 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
[-- Attachment #2: 31da8bfbf702861ed89b7c6fd307c99ebbd01165.diff --]
[-- Type: text/x-patch, Size: 2201 bytes --]
diff --git a/git-svn.perl b/git-svn.perl
index 2e0e552..1975b62 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3340,6 +3340,7 @@ sub new {
$self->{rm} = { };
$self->{path_prefix} = length $self->{svn_path} ?
"$self->{svn_path}/" : '';
+ $self->{config} = $opts->{config};
return $self;
}
@@ -3528,6 +3529,51 @@ sub ensure_path {
return $bat->{$c};
}
+# Subroutine to convert a globbing pattern to a regular expression.
+# From perl cookbook.
+sub glob2pat {
+ my $globstr = shift;
+ my %patmap = ('*' => '.*', '?' => '.', '[' => '[', ']' => ']');
+ $globstr =~ s{(.)} { $patmap{$1} || "\Q$1" }ge;
+ return '^' . $globstr . '$';
+}
+
+sub check_autoprop {
+ my ($self, $pattern, $properties, $file, $fbat) = @_;
+ # Convert the globbing pattern to a regular expression.
+ my $regex = glob2pat($pattern);
+ # Check if the pattern matches the file name.
+ if($file =~ m/($regex)/) {
+ # Parse the list of properties to set.
+ my @props = split(/;/, $properties);
+ foreach my $prop (@props) {
+ # Parse 'name=value' syntax and set the property.
+ if ($prop =~ /([^=]+)=(.*)/) {
+ $self->change_file_prop($fbat, $1, $2);
+ }
+ }
+ }
+}
+
+sub apply_autoprops {
+ my ($self, $file, $fbat) = @_;
+ my $conf_t = ${$self->{config}}{'config'};
+ no warnings 'once';
+ # Check [miscellany]/enable-auto-props in svn configuration.
+ if (SVN::_Core::svn_config_get_bool($conf_t,
+ $SVN::_Core::SVN_CONFIG_SECTION_MISCELLANY,
+ $SVN::_Core::SVN_CONFIG_OPTION_ENABLE_AUTO_PROPS,
+ 0)) {
+ # Auto-props are enabled. Enumerate them to look for matches.
+ my $callback = sub {
+ $self->check_autoprop($_[0], $_[1], $file, $fbat);
+ };
+ SVN::_Core::svn_config_enumerate($conf_t,
+ $SVN::_Core::SVN_CONFIG_SECTION_AUTO_PROPS,
+ $callback);
+ }
+}
+
sub A {
my ($self, $m) = @_;
my ($dir, $file) = split_path($m->{file_b});
@@ -3535,6 +3581,7 @@ sub A {
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
undef, -1);
print "\tA\t$m->{file_b}\n" unless $::_q;
+ $self->apply_autoprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
^ permalink raw reply related
* [PATCH 2/2] git-svn: make use of svn auto-props optional
From: Brad King @ 2008-07-21 21:40 UTC (permalink / raw)
To: git; +Cc: Eric Wong
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
In order to preserve existing default behavior, dcommit should use svn
auto-props only if instructed to do so. This commit creates a config
option 'svn.autoprops' to enable the behavior.
Signed-off-by: Brad King <brad.king@kitware.com>
---
Topics for discussion:
Should we instead call this option 'useAutoProps' or some other name?
Does a 'svn-remote.<name>.autoprops' version make sense?
(I'll need help with this one because I'm learning perl just for this).
Should we still honor/require the svn config option 'enable-auto-props',
or treat that as an option specific to 'svn add' and let this git-specific
one take over here?
Documentation/git-svn.txt | 7 +++++++
git-svn.perl | 7 +++++--
2 files changed, 12 insertions(+), 2 deletions(-)
[-- Attachment #2: 4c068ff135558651ac51de5771815b40e63a2c07.diff --]
[-- Type: text/x-patch, Size: 1985 bytes --]
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index e7c0f1c..300a9e0 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -448,6 +448,13 @@ svn-remote.<name>.rewriteRoot::
the repository with a public http:// or svn:// URL in the
metadata so users of it will see the public URL.
+svn.autoprops::
+
+ Tells 'dcommit' to use '[auto-props]' entries from the user
+ SVN configuration to set properties on added files. The
+ 'enable-auto-props' option in the user SVN configuration must
+ also be enabled.
+
--
Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps
diff --git a/git-svn.perl b/git-svn.perl
index 1975b62..9e8799d 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -73,6 +73,7 @@ my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'no-auth-cache' => \$Git::SVN::Prompt::_no_auth_cache );
my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
'authors-file|A=s' => \$_authors,
+ 'autoprops' => \$Git::SVN::_auto_props,
'repack:i' => \$Git::SVN::_repack,
'noMetadata' => \$Git::SVN::_no_metadata,
'useSvmProps' => \$Git::SVN::_use_svm_props,
@@ -1273,7 +1274,7 @@ use constant rev_map_fmt => 'NH40';
use vars qw/$default_repo_id $default_ref_id $_no_metadata $_follow_parent
$_repack $_repack_flags $_use_svm_props $_head
$_use_svnsync_props $no_reuse_existing $_minimize_url
- $_use_log_author $_add_author_from/;
+ $_use_log_author $_add_author_from $_auto_props/;
use Carp qw/croak/;
use File::Path qw/mkpath/;
use File::Copy qw/copy/;
@@ -3581,7 +3582,9 @@ sub A {
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
undef, -1);
print "\tA\t$m->{file_b}\n" unless $::_q;
- $self->apply_autoprops($file, $fbat);
+ if ($Git::SVN::_auto_props) {
+ $self->apply_autoprops($file, $fbat);
+ }
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
^ permalink raw reply related
* Re: [PATCH] checkout without arguments does not make sense
From: Miklos Vajna @ 2008-07-21 21:44 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Johannes Sixt, Junio C Hamano, git
In-Reply-To: <32541b130807211436h77bf5985xa61ed7b4941c47dc@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
On Mon, Jul 21, 2008 at 05:36:59PM -0400, Avery Pennarun <apenwarr@gmail.com> wrote:
> Eek, are we using "checkout" to get status information now? If that
> goes wrong, you could be blowing away your locally modified data by
> accident.
Hm, let's say I have uncommitted changes to Makefile, then I'll get:
$ git checkout
M Makefile
Your branch is ahead of the tracked remote branch 'junio/next' by 1 commit.
But it will not drop my local changes.
> I think "git status" reports this information in recent versions, doesn't it?
Right. But that shows other infos as well, for example the untracked
files, etc. So there are cases when git checkout is just better.
However, you are right about it may not be the best habit from my side
to use git checkout to get that info. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] checkout without arguments does not make sense
From: Avery Pennarun @ 2008-07-21 21:36 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Johannes Sixt, Junio C Hamano, git
In-Reply-To: <20080721204955.GI32057@genesis.frugalware.org>
On 7/21/08, Miklos Vajna <vmiklos@frugalware.org> wrote:
> Actually I think it _is_ useful, like this:
>
> $ git checkout
> Your branch is ahead of the tracked remote branch 'junio/next' by 1 commit.
>
> How will it be possible to get that info easily after your patch?
Eek, are we using "checkout" to get status information now? If that
goes wrong, you could be blowing away your locally modified data by
accident.
I think "git status" reports this information in recent versions, doesn't it?
Thanks,
Avery
^ permalink raw reply
* [PATCH] Allow pager of diff command be enabled/disabled
From: Alex Riesen @ 2008-07-21 21:28 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
See for example, status and show commands. Besides,
Documentation/RelNotes-1.6.0.txt mentions that pager.<cmd>
can be used to enable/disable paging behavior per command.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Also, really export check_pager_config, which just got another call
site.
builtin-diff.c | 3 ++-
builtin.h | 1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index faaa85a..7ffea97 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -296,7 +296,8 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
* If the user asked for our exit code then don't start a
* pager or we would end up reporting its exit code instead.
*/
- if (!DIFF_OPT_TST(&rev.diffopt, EXIT_WITH_STATUS))
+ if (!DIFF_OPT_TST(&rev.diffopt, EXIT_WITH_STATUS) &&
+ check_pager_config("diff") != 0)
setup_pager();
/*
diff --git a/builtin.h b/builtin.h
index 0e605d4..f3502d3 100644
--- a/builtin.h
+++ b/builtin.h
@@ -18,6 +18,7 @@ extern int fmt_merge_msg(int merge_summary, struct strbuf *in,
struct strbuf *out);
extern int commit_tree(const char *msg, unsigned char *tree,
struct commit_list *parents, unsigned char *ret);
+extern int check_pager_config(const char *cmd);
extern int cmd_add(int argc, const char **argv, const char *prefix);
extern int cmd_annotate(int argc, const char **argv, const char *prefix);
--
1.6.0.rc0.24.g1329.dirty
^ permalink raw reply related
* Re: [PATCH] checkout without arguments does not make sense
From: Johannes Sixt @ 2008-07-21 21:11 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Junio C Hamano
In-Reply-To: <20080721204955.GI32057@genesis.frugalware.org>
On Montag, 21. Juli 2008, Miklos Vajna wrote:
> Actually I think it _is_ useful, like this:
>
> $ git checkout
> Your branch is ahead of the tracked remote branch 'junio/next' by 1 commit.
Ah, yes, indeed; that makes sense. Scrap the patch.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Documentation/git-ls-tree.txt: Add a caveat about prefixing pathspec
From: Petr Baudis @ 2008-07-21 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1w1nvf7q.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 21, 2008 at 01:00:57AM -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > +Note that within a subdirectory of the working copy, 'git ls-tree'
> > +will automatically prepend the subdirectory prefix to the specified
> > +paths and assume just the prefix was specified in case no paths were
> > +given --- no matter what the tree object is!
>
> Don't be negative upfront. Explain why this is a good thing first.
>
> ... were given. This is useful when you are deep in a
> subdirectory and want to inspect the list of files in an arbitrary
> commit. E.g.
>
> $ cd some/deep/path
> $ git ls-tree --name-only -r HEAD~20
>
> will list the files in some/deep/path (i.e. where you are) 20
> commits ago, just like running "/bin/ls" there will give you the
> list of files you have right now.
Frankly, I think this is overdoing it. I'm all for being positive, but
it is obvious why this is good thing when you inspect a root tree and
there's no need to be too wordy about it - it should be enough to
acknowledge this later by the "as expected" as I note below.
The documentation should be detailed and complete, but not too chatty,
or it gets too hard to read again.
> > +Thus, within a subdirectory, 'git ls-tree' behaves as expected
> > +only when run on a root tree object (e.g. with a 'HEAD' tree-ish,
> > +but not anymore when passed 'HEAD:Documentation' instead).
> > +
> > +
> > OPTIONS
> > -------
> > <tree-ish>::
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH] checkout without arguments does not make sense
From: Miklos Vajna @ 2008-07-21 20:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <200807212206.32818.johannes.sixt@telecom.at>
[-- Attachment #1: Type: text/plain, Size: 665 bytes --]
On Mon, Jul 21, 2008 at 10:06:32PM +0200, Johannes Sixt <johannes.sixt@telecom.at> wrote:
> @@ -487,7 +487,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
> }
>
> return checkout_paths(source_tree, pathspec);
> - }
> + } else if (!new.name && !opts.new_branch)
> + usage_with_options(checkout_usage, options);
>
> if (new.name && !new.commit) {
> die("Cannot switch branch to a non-commit.");
Actually I think it _is_ useful, like this:
$ git checkout
Your branch is ahead of the tracked remote branch 'junio/next' by 1 commit.
How will it be possible to get that info easily after your patch?
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Alex Riesen @ 2008-07-21 20:42 UTC (permalink / raw)
To: Tim Harper; +Cc: git
In-Reply-To: <8502DF7C-5303-49E8-8C67-F837343E2F0C@gmail.com>
Tim Harper, Mon, Jul 21, 2008 22:26:06 +0200:
> I ran into a strange issue that has left me scratching my head.
>
> I have a commit in my history, that does indeed show up in my branch,
> named "sprint"
>
...
>
> Any help or clues VERY much apperciated. Thanks!
>
Try looking at the history graph in gitk
$ gitk --all -- app/controllers/events_controller.rb spec/fixtures/factors.yml
It usually shows the history in a very understandable way and
it can help to detect when the histories have diverged.
^ 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