Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
Overall, I like this better than the log --follow hack; as the
revision traversal is done without any pathspec when being careful
and slow (aka -M), you do not suffer from the just use a singleton
pathspec
On Tue, Feb 26, 2013 at 01:41:54PM -0800, Junio C Hamano wrote:
Isn't this a repeat of:
http://thread.gmane.org/gmane.comp.version-control.git/202440/focus=212316
[...]
Yeah, I think the patch in your message is a good starting point to
solve a half of the issue (i.e. unmerged
Hello,
Would it make sense to add the option --ignore-submodules (currently
available in git-status) to git-describe when the later is used with
--dirty option ?
Thanks
--
Francis
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Hi,
I found a problem when using GIT-SVN.
In inproperly merges in SVN causes that the ranges contains additional
character *.
Attached patch fix this issue, I have it already tested for several months.
Regards,
Jan
Kind regards / S pozdravem
Jan Pešta
SW Engineer Sr.
CertiCon a.s.,
Jan Pešta jan.pe...@certicon.cz writes:
Attached patch fix this issue,
Nothing attached, it seems ;-).
Please, read Documentation/SubmittingPatches in Git's source code.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the
Sorry,
My fault :)
Here is a patch atached.
Jan
Kind regards / S pozdravem
Jan Pešta
SW Engineer Sr.
CertiCon a.s., www.certicon.cz
Vaclavska 12
12000 Prague 2
Czech Republic
Office Prague: +420 224 904 406
Mobile: +420 604 794 306
E-mail: jan.pe...@certicon.cz
-Original
Jan Pešta jan.pe...@certicon.cz writes:
Sorry,
My fault :)
Here is a patch atached.
Still, please, read Documentation/SubmittingPatches. Your patch cannot
be included as it is because of lack of sign-off.
Also, please write a commit message describing why this change is
needed. Where is
Hi again,
Finally I created patch according to document.
Please have a look on referenced site for more details.
Currently I have a problems in our project, where SVN is main repository and
merge-info contains * which causes troubles in SVN.pm.
Regards,
Jan
Kind regards / S pozdravem
Jan
Jan Pešta jan.pe...@certicon.cz writes:
Hi again,
Finally I created patch according to document.
This is much better, but you still haven't taken into account some
important parts of Documentation/SubmittingPatches (the part about
attachments Vs inline patch, and the part about sign-off).
In inproperly merges, the ranges contains additional character *.
See http://www.open.collab.net/community/subversion/articles/merge-info.html
Extract:
The range r30430:30435 that was added to 1.5.x in this merge has a '*'
suffix for 1.5.x\www.
This '*' is the marker for a non-inheritable
Preben Liland Madsen venit, vidit, dixit 26.02.2013 20:53:
Hello,
I'm trying to investigate some what changes have been done between two
versions of a software with the name IP.Board.
This proves more troublesome than I thought, since their release builder
appearantly updates the
Thomas Rast tr...@student.ethz.ch writes:
Junio C Hamano gits...@pobox.com writes:
I notice that careful and slow is just too slow
to be usable even on a small tree like ours. Try running
$ git log -M -L:get_name:builtin/describe.c
and see how long you have to wait until you hit the
I'm trying to figure out the most efficient way to keep an up to
date `todo` branch checked out in Meta [1]. I've tried a few
things like:
$ git submodule add -b refs/remotes/origin/todo --reference ./ -- ./ Meta
and:
$ git clone --single-branch --branch refs/remotes/origin/todo ./ Meta
Hello.
I'm working on a small project that talks to external git and fossil
repositories. I've run into a bizarre this cannot happen problem and
am completely mystified as to what's causing it.
Essentially, the problem is that a particular git command, run as part
of the unit tests for the
Jeff King p...@peff.net writes:
PS I wonder if the initial_checkout hack can just go away under this
new rule. Although we don't seem to use o-reset for the initial
checkout. Which seems kind of weird. I would think the initial
checkout would actually just be a oneway merge. Is the
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
Documentation/githooks.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 8181e4e..eab9b35 100644
--- a/Documentation/githooks.txt
+++
Francis Moreau francis.m...@gmail.com writes:
Would it make sense to add the option --ignore-submodules (currently
available in git-status) to git-describe when the later is used with
--dirty option ?
I think the spirit of describe --dirty is to allow people who
gives out binaries this
Jan Pešta jan.pe...@certicon.cz writes:
In inproperly merges, the ranges contains additional character *.
Thanks, but -ECANNOTPARSE. What are inproperly merges?
See http://www.open.collab.net/community/subversion/articles/merge-info.html
Extract:
The range r30430:30435 that was added to
W. Trevor King wk...@tremily.us writes:
Any suggestions for an elegant solution would be appreciated :).
My Meta checkout is not a submodule of anything. It is a totally
independent repository and is not linked with git.git in any way.
It started as an independent repository, and it still is.
Thanks. grep linkgit *.html in the installed documentation area
tells me that this is the only instance that needs to be fixed.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Am 01.03.2013 18:46, schrieb Junio C Hamano:
I think what is missing from --dirty is not --ignore-submodules,
but --do-not-ignore-untracked option [*1*]. describe --dirty
ignores untracked files in the superproject by default, and we
should ignore untracked files in submodule working trees,
Before 82dce99 (attr: more matching optimizations from .gitignore,
2012-10-15), .gitattributes did not have any special treatment of a
leading '!'. The docs, however, always said
The rules how the pattern matches paths are the same as in
`.gitignore` files; see linkgit:gitignore[5].
By
Thomas Rast tr...@student.ethz.ch writes:
Before 82dce99 (attr: more matching optimizations from .gitignore,
2012-10-15), .gitattributes did not have any special treatment of a
leading '!'. The docs, however, always said
The rules how the pattern matches paths are the same as in
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@student.ethz.ch writes:
Before 82dce99 (attr: more matching optimizations from .gitignore,
2012-10-15), .gitattributes did not have any special treatment of a
leading '!'. The docs, however, always said
The rules how the pattern
On 2/26/2013 10:17 PM, Jeff King wrote:
On Tue, Feb 26, 2013 at 04:08:55PM -0700, J.V. wrote:
I was on my master branch, I then checked out a branch (
origin/somebranch ), made no updates
but did a few git pulls on the branch over about a week; then made a
small change to only a single file
Thomas Rast tr...@student.ethz.ch writes:
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@student.ethz.ch writes:
Before 82dce99 (attr: more matching optimizations from .gitignore,
2012-10-15), .gitattributes did not have any special treatment of a
leading '!'. The docs,
On Fri, Mar 1, 2013 at 2:28 AM, Kindjal kind...@gmail.com wrote:
David Michael Barr b at rr-dav.id.au writes:
From a quick survey, it appears there are no more than 55 patches
squashed into the submitted patch.
As I have an interest in git-subtree for maintaining the out-of-tree
version of
The latest maintenance release Git v1.8.1.5 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
3349a15de7c5501715bda9b68301d0406272f8e0 git-1.8.1.5.tar.gz
All,
I've been using git for a while and this is the first time I've had to
use `git am` and I've got a 16 patch patchset that I'm looking to apply.
The files were copied to a separate maildir by mutt to keep things
clean, and then I ran `git am -i /path/to/maildir/` expecting things to
start
William Giokas 1007...@gmail.com writes:
All,
I've been using git for a while and this is the first time I've had to
use `git am` and I've got a 16 patch patchset that I'm looking to apply.
The files were copied to a separate maildir by mutt to keep things
clean, and then I ran `git am -i
On Fri, Mar 01, 2013 at 08:57:03AM -0800, Junio C Hamano wrote:
An initial checkout is *supposed* to happen in an empty working
tree, so if we code it not to overwrite an existing path in the
working tree, the user cannot lose possibly precious contents with
an mistaken initial checkout (they
On Fri, Mar 01, 2013 at 02:27:32PM -0800, Junio C Hamano wrote:
I've been using git for a while and this is the first time I've had to
use `git am` and I've got a 16 patch patchset that I'm looking to apply.
The files were copied to a separate maildir by mutt to keep things
clean, and
On Fri, Mar 01, 2013 at 05:52:31PM -0500, Jeff King wrote:
Note to bystanders. This is coming from populate_maildir_list() in
builtin/mailsplit.c; the function claims to know what maildir
should look like, so it should be enforcing the ordering as
necessary by sorting the list, _if_ the
Jeff King p...@peff.net writes:
On Fri, Mar 01, 2013 at 08:57:03AM -0800, Junio C Hamano wrote:
Nobody seems to use that combination, either from scripts or from C
(i.e. when opts.update==1 and opts.merge==1, opts.reset is not set)
with a twoway merge, other than git am --abort/--skip.
I
On Fri, Mar 01, 2013 at 03:06:57PM -0800, Junio C Hamano wrote:
I can believe it. So do we want to do that fix, then? Did you want to
roll up the two halves of it with a test and write a commit message? I
feel like you could write a much more coherent one than I could on this
subject.
Jeff King p...@peff.net writes:
On Fri, Mar 01, 2013 at 05:52:31PM -0500, Jeff King wrote:
...
The maildir spec explicitly says that readers should not make
assumptions about the content of the filenames. Mutt happens to write
them as:
${epoch_seconds}.${pid}_${seq}.${host}
so in
Hi list,
I'd like to suggest a very simple, but IMHO quite useful, additional
option to git-update-ref: an option --ff-only which would cause the
command to refuse unless the current ref is an ancestor of the new
one.
The reason I think it would be useful: I occasionally wish to perform
a
David Madore david+n...@madore.org writes:
Hi list,
I'd like to suggest a very simple, but IMHO quite useful, additional
option to git-update-ref: an option --ff-only which would cause the
command to refuse unless the current ref is an ancestor of the new
one.
Mild NAK.
What you want may
On Fri, Mar 01, 2013 at 03:24:42PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Fri, Mar 01, 2013 at 05:52:31PM -0500, Jeff King wrote:
...
The maildir spec explicitly says that readers should not make
assumptions about the content of the filenames. Mutt happens to
Jeff King p...@peff.net writes:
I actually was wondering if we can remove that sole uses of two-way
merge with --reset -u from git am and replace them with something
else. But we do want to keep local change that existed before am
started, so we cannot avoid use of two-way merge, I guess...
Jeff King p...@peff.net writes:
diff --git a/builtin/mailsplit.c b/builtin/mailsplit.c
index 2d43278..772c668 100644
--- a/builtin/mailsplit.c
+++ b/builtin/mailsplit.c
@@ -130,6 +130,26 @@ static int populate_maildir_list(struct string_list
*list, const char *path)
return 0;
}
On Fri, Mar 01, 2013 at 03:57:39PM -0800, Junio C Hamano wrote:
The epoch_seconds are the time of writing into the maildir. They will
typically all be the same, unless your system is very slow, or you are
writing a really long patch series. The PID likewise should be the same
for a given
On Fri, Mar 01, 2013 at 04:08:04PM -0800, Junio C Hamano wrote:
+static int maildir_filename_cmp(const char *a, const char *b)
+{
+ while (1) {
It is somewhat funny that we do not need to check !*a or !*b in this
loop. As long as readdir() does not return duplicates, we won't be
Hi,
I was trying git am -3 with a patch that touched files that didn't exist
in the branch I was on. Obviously it failed badly, so I wanted to abort
out of the git am state with git am --abort. Unfortunately, it seems
that git am --abort in this scenario fails with this error:
error: cache entry
On Fri, Mar 01, 2013 at 03:49:23PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I actually was wondering if we can remove that sole uses of two-way
merge with --reset -u from git am and replace them with something
else. But we do want to keep local change that existed
On Fri, Mar 01, 2013 at 04:52:16PM -0800, Stephen Boyd wrote:
I was trying git am -3 with a patch that touched files that didn't exist
in the branch I was on. Obviously it failed badly, so I wanted to abort
out of the git am state with git am --abort. Unfortunately, it seems
that git am
On Sat, Mar 02, 2013 at 12:18:59AM +0100, David Madore wrote:
I'd like to suggest a very simple, but IMHO quite useful, additional
option to git-update-ref: an option --ff-only which would cause the
command to refuse unless the current ref is an ancestor of the new
one.
The reason I think
On Sat, Mar 2, 2013 at 3:06 AM, Thomas Rast tr...@student.ethz.ch wrote:
Before 82dce99 (attr: more matching optimizations from .gitignore,
2012-10-15), .gitattributes did not have any special treatment of a
leading '!'. The docs, however, always said
The rules how the pattern matches
8b1bd02 (Make !pattern in .gitattributes non-fatal - 2013-03-01)
raises the fact that even though '!' should have been a negative
pattern indicator, people have been misusing for plain '!' and old Git
versions accept that. This makes the leading '!' a de facto
literal. We can't ever make it
49 matches
Mail list logo
