Hi,
and it does so if .gitignore has not been committed yet. This is with
git version 2.6.3. To reproduce:
mkdir test
cd test
git init
echo "test" > test
echo "something.txt" > .gitignore
git add test .gitignore
git commit -a -m "init"
mkdir node_modules
echo "something" > node_modules/file.tx
On Sun, Dec 13, 2015 at 11:32 AM, Karthik Nayak wrote:
> On Sun, Dec 13, 2015 at 6:23 AM, Eric Sunshine
> wrote:
>> On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote:
>>> Introduce remote_ref_atom_parser() which will parse the '%(upstream)'
>>> and '%(push)' atoms and store information into
On Sun, Dec 13, 2015 at 3:32 AM, Karthik Nayak wrote:
>> On Sun, Dec 13, 2015 at 6:23 AM, Eric Sunshine
>> wrote:
>>> On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak
>>> wrote:
Introduce remote_ref_atom_parser() which will parse the '%(upstream)'
and '%(push)' atoms and store informat
On Sun, Dec 13, 2015 at 2:15 PM, Eric Sunshine wrote:
> On Sun, Dec 13, 2015 at 3:32 AM, Karthik Nayak wrote:
>>> On Sun, Dec 13, 2015 at 6:23 AM, Eric Sunshine
>>> wrote:
On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak
wrote:
> Introduce remote_ref_atom_parser() which will parse
On Sun, Dec 13, 2015 at 11:10 AM, Eric Sunshine wrote:
> On Fri, Dec 11, 2015 at 5:49 PM, Junio C Hamano wrote:
>> Karthik Nayak writes:
>>> ref-filter: introduce a parsing function for each atom in valid_atom
>>> ref-filter: introduce struct used_atom
>>> ref-fitler: bump match_atom() nam
A user, Alexey A, reported
(https://groups.google.com/forum/#!topic/git-users/msev4KsQGFc, Warning:
gui.recentrepo has multiply values while executing) on the Git User list
that the Git Gui start-up could barf if there were duplicate entries in the
user's recent repo list within their --global .gi
Hi Junio & Peff,
On Fri, 11 Dec 2015, Jeff King wrote:
> On Fri, Dec 11, 2015 at 11:37:54AM -0800, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > On Wed, Aug 12, 2015 at 07:43:01PM +0200, Johannes Sixt wrote:
> > >
> > >> 27e1e22d (prune: factor out loose-object directory traversal, 2
It seems my Patch got no attention yet, is there anything wrong?
Do I need to ping someone in particular?
On 12/02/2015 08:19 PM, Daniel Fahlke wrote:
> but still depending on the added --show-signature as argument
>
> longer explanation:
> git supports for some time now signed commits, and also
"git grep" can now be configured (or told from the command line)
how many threads to use when searching in the working tree files.
Changes to default behavior: number of threads now doesn't depend
on online_cpus(), e.g. if specific number is not configured
GREP_NUM_THREADS_DEFAULT (8) threads
null_oid is the struct object_id equivalent to null_sha1.
Signed-off-by: brian m. carlson
---
cache.h | 1 +
sha1_file.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/cache.h b/cache.h
index 5ab6cb50..c63fcc11 100644
--- a/cache.h
+++ b/cache.h
@@ -831,6 +831,7 @@ extern const char *
git format-patch is often used to create patches that are then stored in
version control or displayed with diff. Having the commit hash in the
"From " line usually just creates diff noise in these cases, so this
series introduces --zero-commit to set that to all zeros.
Changes from v1:
* Rename t
The format of the "From " header line is very specific to allow
utilities to detect Git-style patches. Add a test that the patches
created are in the expected format.
Signed-off-by: brian m. carlson
---
t/t4014-format-patch.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/t/t4014-fo
Oftentimes, patches created by git format-patch will be stored in
version control or compared with diff. In these cases, two otherwise
identical patches can have different commit hashes, leading to diff
noise. Teach git format-patch a --zero-commit option that instead
produces an all-zero hash to
Hi,
I am confused with git merge working.
Suppose I have these 3 files in master branch-
a.txt
b.txt
d.txt
I create a branch, add c.txt to it and commit. So its final contents
are-
a.txt
b.txt
c.txt
d.txt
Then, I checkout master branch, delete a.txt, add e.txt and commit. So
final contents are
On Sun, Dec 13, 2015 at 9:15 AM, Daniel Fahlke wrote:
> It seems my Patch got no attention yet, is there anything wrong?
> Do I need to ping someone in particular?
>
gitk patches should cc +Paul Mackerras who maintains gitk
--
To unsubscribe from this list: send the line "unsubscribe git" in
the
On Sun, Dec 13, 2015 at 05:55:59PM +, rohit gupta wrote:
> Hi,
> I am confused with git merge working.
>
> Suppose I have these 3 files in master branch-
> a.txt
> b.txt
> d.txt
>
> I create a branch, add c.txt to it and commit. So its final contents
> are-
> a.txt
> b.txt
> c.txt
> d.txt
>
On Sun, Dec 13, 2015 at 11:35 AM, Eric Sunshine wrote:
> On Thu, Dec 3, 2015 at 8:35 AM, Karthik Nayak wrote:
>> On Wed, Dec 2, 2015 at 4:57 AM, Eric Sunshine
>> wrote:
>>> On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak
>>> wrote:
@@ -833,11 +846,10 @@ static void populate_value(struct r
On 12 December 2015 at 02:52, James Farwell wrote:
>
> Reproduction Steps:
>
> 1. Have a git repo cloned from a perforce repo using multiple depot paths
> (e.g. //depot/foo/ and //depot/bar/).
> 2. Add changes to the perforce repo in both depot paths. (e.g. 5 changes in
> each)
> 2. Do a "git p4
On Sun, Dec 13, 2015 at 10:17 AM, Victor Leschuk wrote:
> "git grep" can now be configured (or told from the command line)
> how many threads to use when searching in the working tree files.
>
> Changes to default behavior: number of threads now doesn't depend
> on online_cpus(), e.g. if speci
[Please don't top-post.]
On Mon, Dec 14, 2015 at 12:03:18AM +0530, Rohit Gupta wrote:
> Thanks brian. I understood my mistake in understanding the working of git
> merge.
> But isn't it wrong? As after merging, branch's logic can't work. How to get
> that right then ?
If you know that the merge d
Hello Eric:
Hmm, v7 doesn't seem to address any of the v6 review comments here[1].
Was that review merely overlooked or did you disagree with the
reviewer?
[1]: http://article.gmane.org/gmane.comp.version-control.git/281817
Sorry, it looks like I missed that letter. My bad.
History of change
On Sun, Dec 13, 2015 at 8:40 AM, Eric Sunshine wrote:
> On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote:
>> Introduce contents_atom_parser() which will parse the '%(contents)'
>> atom and store information into the 'used_atom' structure based on the
>> modifiers used along with the atom.
>>
On Sun, Dec 13, 2015 at 10:11 AM, Eric Sunshine wrote:
> On Sat, Dec 12, 2015 at 10:10 PM, Eric Sunshine
> wrote:
>> On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote:
>>> +void contents_atom_parser(struct used_atom *atom)
>>> +{
>>> + const char * buf;
>>> +
>>> + if (match_atom
On Sun, Dec 13, 2015 at 10:19 AM, Eric Sunshine wrote:
> On Wed, Nov 25, 2015 at 8:44 AM, Karthik Nayak wrote:
>> Introduce objectname_atom_parser() which will parse the
>> '%(objectname)' atom and store information into the 'used_atom'
>> structure based on the modifiers used along with the atom
James Farwell reported that with multiple depots git-p4 would
skip changes.
http://article.gmane.org/gmane.comp.version-control.git/282297
Add a failing test case demonstrating the problem.
Signed-off-by: Luke Diamand
---
t/t9818-git-p4-block.sh | 28 +++-
1 file change
With multiple depot paths (//depot/pathA, //depot/pathB) if there
are more changes than the changes-block-size limit, then some
of the changes will be skipped. This fixes this by correcting
the loop in p4ChangesForPaths() to reset the "start" point
for each depot.
Suggested-by: James Farwell
Sign
James Farwell reported a bug I introduced into git-p4 with
handling of multiple depot paths:
http://article.gmane.org/gmane.comp.version-control.git/282297
This patch series adds a failing test case, and a fix for this
problem.
Luke
Luke Diamand (2):
git-p4: failing test case for skipping cha
Having just fixed this, I've now just spotted that Sam Hocevar's fix
to reduce the number of P4 transactions also fixes it:
https://www.mail-archive.com/git%40vger.kernel.org/msg81880.html
That seems like a cleaner fix.
Luke
On 13 December 2015 at 20:07, Luke Diamand wrote:
> James Farwell re
On Sun, Dec 13, 2015 at 4:31 AM, Karthik Nayak wrote:
> On Sun, Dec 13, 2015 at 11:10 AM, Eric Sunshine
> wrote:
>> If the intention is to rid that inner loop of much of the expensive
>> processing, then wouldn't we want to introduce an enum of valid atoms
>> which is to be a member of 'struct u
On 13.12.15 18:27, brian m. carlson wrote:
> The format of the "From " header line is very specific to allow
> utilities to detect Git-style patches. Add a test that the patches
> created are in the expected format.
>
> Signed-off-by: brian m. carlson
> ---
> t/t4014-format-patch.sh | 6 ++
30 matches
Mail list logo
