Good day, everyone.
I have some kind of a confusion here, explained it in details here:
http://stackoverflow.com/questions/11289124/git-commit-list but didn't get any
answers, maybe someone could give me a hint about that?--
To unsubscribe from this list: send the line "unsubscribe git" in
the
The default user-agent depends on the GIT_VERSION, which means that
anytime you switch versions, it causes a full rebuild. Instead, let's
split it out into its own file and restrict the dependency to
version.o.
To avoid noise during builds, unlike the GIT-CFLAGS rule which prints
"* new build flag
When a source file makes use of a makefile variable, there should be a
corresponding dependency on a file that changes when that variable
changes to ensure the build output is not left stale when the variable
changes.
Document this, even though we are not following the rule perfectly
yet. Based o
Just like MISC_H (see previous commit), there is no reason to track
xdiff and vcs-svn headers separately from the rest of the headers.
The only purpose of these variables is to keep track of recompilation
dependencies.
As a pleasant side effect, folding these into LIB_H lets us stop
tracking GIT_O
On Fri, Jul 6, 2012 at 4:01 PM, Junio C Hamano wrote:
> Phil Hord writes:
>
>>> Would an obvious alternative of running "git rerere" ourselves after
>>> running "git merge-recursive" in this script work?
>>>
>>> git-stash.sh | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/git-stas
Hi,
I finally found some moments to revisit this series, so I'm starting
here. I think the justification for this patch is something like
this:
Keeping track of what files include each header is an error-prone
chore. On top of that, for l10n, these days we have to keep a master
list of al
On 12-07-06 04:43 PM, Marc Branchaud wrote:
>
> So why change "git clone" to always set remote.default if the functionality
> remains the same either way?
>
> To me it makes a more consistent implementation. Since "git remote add" sets
> remote.default if it's adding the first remote to the repo
On Fri, 6 Jul 2012, Alex Riesen wrote:
> Hi list,
>
> when git-clone was built in, its treatment of umask has changed: the shell
> version respected umask for newly created directories by using plain mkdir(1),
> and the builtin version just uses mkdir(work_tree, 0755).
>
> Is it intentional?
I h
On 12-07-06 03:39 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> If remote.default isn't set, then if someone does
>> git remote rename origin foo
>> the default remote will still be "origin" (modulo the currently-checked-out
>> branch stuff).
>
> Why?
Erm, actually, my st
David Michael Barr writes:
> On Sat, Jul 7, 2012 at 3:10 AM, Jonathan Nieder wrote:
>> ...
>> Some of the patches had to change a little since v2 of db/vcs-svn, so
>> I'll be replying with a copy of the patches for reference.
>>
>> David has looked the branch over and acked and tested it.
>> ...
> AFAIK it makes no senes to translate terms like "commit" to "Abzeichen" like
> it is used
> in git gui. I don't know *anybody* here in my IT business environment who
> uses this word
> or even would guess what it means. Everyone is used to the Denglisch Version
> "committen"
> or "einchecken"
> "Junio" == Junio C Hamano writes:
Junio> mer...@stonehenge.com (Randal L. Schwartz) writes:
>>> "Neal" == Neal Kreitzinger writes:
>>
Neal> Does anyone use git with uucp to deploy software?
>>
>> Isn't there a gap of about two decades between those two things? :)
Junio> Are you sugg
mer...@stonehenge.com (Randal L. Schwartz) writes:
>> "Neal" == Neal Kreitzinger writes:
>
> Neal> Does anyone use git with uucp to deploy software?
>
> Isn't there a gap of about two decades between those two things? :)
Are you suggesting us to get rid of use of Perl from Git, or C for
that
Phil Hord writes:
>> Would an obvious alternative of running "git rerere" ourselves after
>> running "git merge-recursive" in this script work?
>>
>> git-stash.sh | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/git-stash.sh b/git-stash.sh
>> index 4e2c7f8..bbefdf6 100755
>> --- a/git
On 12-07-06 03:31 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> On 12-07-05 06:50 PM, Junio C Hamano wrote:
>>>
- effective_remote_name is the name of the remote tracked by the current
branch, or is default_remote_name if the current branch doesn't have a
remote.
>
On Sat, Jul 7, 2012 at 3:10 AM, Jonathan Nieder wrote:
> Hi Junio,
>
> The following changes since commit 58ebd9865d2bb9d42842fbac5a1c4eae49e92859:
>
> vcs-svn/svndiff.c: squelch false "unused" warning from gcc (2012-01-27
> 11:58:56 -0800)
>
> are available at:
>
> git://repo.or.cz/git/jrn.g
Marc Branchaud writes:
> If remote.default isn't set, then if someone does
> git remote rename origin foo
> the default remote will still be "origin" (modulo the currently-checked-out
> branch stuff).
Why? I thought the proposed semantics was "if remote.default is
unset, the defau
Marc Branchaud writes:
> On 12-07-05 06:50 PM, Junio C Hamano wrote:
>>
>>> - effective_remote_name is the name of the remote tracked by the current
>>>branch, or is default_remote_name if the current branch doesn't have a
>>>remote.
>>
>> The explanation of the latter belongs to the p
Hi list,
when git-clone was built in, its treatment of umask has changed: the shell
version respected umask for newly created directories by using plain mkdir(1),
and the builtin version just uses mkdir(work_tree, 0755).
Is it intentional?
This Stackoverflow question is what got me interested:
On Fri, Jul 06, 2012 at 08:58:21PM +0200, Ralf Thielow wrote:
> On Fri, Jul 6, 2012 at 8:20 PM, Michael J Gruber
> wrote:
> > Ralf Thielow venit, vidit, dixit 05.07.2012 20:16:
> > Is "rebase" = "Neuaufbau"? My last thought on this wording was "rebase"
> > =
> > "Umpflanzen".
> >>>
>
Max Horn writes:
>>> +'{caret}!', e.g. 'HEAD{caret}!'::
>>> + A suffix '{caret}' followed by an exclamation mark
>>> + means commit '' but forces all of its parents to be excluded. For
>>> + commands that deal with a single revision, this is the same as '".
>>
>> Is this sentence correct? "g
On Fri, Jul 6, 2012 at 8:20 PM, Michael J Gruber
wrote:
> Ralf Thielow venit, vidit, dixit 05.07.2012 20:16:
> Is "rebase" = "Neuaufbau"? My last thought on this wording was "rebase" =
> "Umpflanzen".
>>>
>>> "Basisumbau"?
>>>
>>
>> I have added both suggestions to the glossary that they d
Ralf Thielow venit, vidit, dixit 05.07.2012 20:16:
Is "rebase" = "Neuaufbau"? My last thought on this wording was "rebase" =
"Umpflanzen".
>>
>> "Basisumbau"?
>>
>
> I have added both suggestions to the glossary that they don't get lost when
> we discuss about non-optimal and/or missing
> "Neal" == Neal Kreitzinger writes:
Neal> Does anyone use git with uucp to deploy software?
Isn't there a gap of about two decades between those two things? :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
http://www.stonehenge.com/merlyn/>
Smalltalk/Perl
Date: Thu, 5 Jul 2012 22:47:47 -0500
Currently the vcs-svn/ library only pays attention to the presence of
the Prop-Content-Length field and doesn't care about its value, but
some day we might care about the value. Parse it as an off_t instead
of arbitrarily limiting to 32 bits for intuitiveness.
From: Jonathan Nieder
Date: Thu, 5 Jul 2012 22:21:09 -0500
All callers pass a nonnegative delta_len, so the code is already safe.
Add an assertion to ensure that remains so and add a cast to keep
clang and gcc -Wsign-compare from worrying.
Reported-by: David Barr
Signed-off-by: Jonathan Nieder
From: David Barr
Date: Fri, 1 Jun 2012 00:41:29 +1000
The preceding code checks that view->max_off is nonnegative and
(off + width) fits in an off_t, so this code is already safe.
Signed-off-by: David Barr
Signed-off-by: Jonathan Nieder
---
Another unobjectionable piece from v2's patch 5. The
From: David Barr
Date: Fri, 1 Jun 2012 00:41:29 +1000
These are already safe because both sides of the comparison are
nonnegative.
This would normally not be important because Git is not -Wsign-compare
clean anyway, but we like to keep the vcs-svn/ lib to a higher
standard for convenience using
From: David Barr
Date: Fri, 1 Jun 2012 00:41:28 +1000
memmem is a GNU extension.
Avoiding it makes the code clearer and makes it easier for projects
that don't share git's compat/ code, such as the standalone
svn-dump-fast-export project, to reuse the vcs-svn/ library.
Signed-off-by: David Barr
From: David Barr
Date: Fri, 1 Jun 2012 00:41:27 +1000
Since the length of t is already known, we can simplify a little by
using memcmp() instead of strncmp() to carry out a prefix comparison.
All nearby code already does this.
Noticed in the standalone svn-dump-fast-export project which has not
From: David Barr
Date: Fri, 1 Jun 2012 00:41:26 +1000
Currently the cleanup code looks like this:
free resources
return 0;
error_out:
free resources
return -1;
Avoid duplicating the "free resources" part by keeping the return
value in a variable and sharing code
From: David Barr
Date: Fri, 1 Jun 2012 00:41:25 +1000
Without this change, clang complains:
vcs-svn/svndiff.c:298:3: warning: Assigned value is garbage or undefined
off_t pre_off = pre_off; /* stupid GCC... */
^ ~~~
This code uses an old and
From: David Barr
Date: Fri, 1 Jun 2012 00:41:30 +1000
Since v1.7.5~42^2~6 (vcs-svn: remove buffer_read_string)
buffer_reset() does nothing thus fast_export_reset() also.
Signed-off-by: David Barr
Signed-off-by: Jonathan Nieder
---
Incorporates fixes from $gmane/198955. No other changes.
tes
Hi Junio,
The following changes since commit 58ebd9865d2bb9d42842fbac5a1c4eae49e92859:
vcs-svn/svndiff.c: squelch false "unused" warning from gcc (2012-01-27
11:58:56 -0800)
are available at:
git://repo.or.cz/git/jrn.git svn-fe
The first three commits duplicate changes that are already in
This patch series adds a failing test and then a fix for the condition
discussed in these threads:
http://article.gmane.org/gmane.comp.version-control.git/177224
http://article.gmane.org/gmane.comp.version-control.git/201045
http://article.gmane.org/gmane.comp.version-control.git/200178/match=merg
Add a failing test to confirm the leftover rerere
state files interfere with git-mergetool during a
conflicted stash apply.
Signed-off-by: Phil Hord
---
t/t7610-mergetool.sh | 28
1 file changed, 28 insertions(+)
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool
The presence of a GIT_DIR/MERGE_RR file indicates we
were resolving a merge which had rerere candidates for
recording. But the file does not get deleted after
all resolutions are completed. This is ok for most
cases because the file will get replaced when the
next merge happens. But stash apply
Replace strlen(ce->name) with ce_namelen() in a couple
of places which gives us some additional bits of
performance.
Signed-off-by: Thomas Gummerer
---
read-cache.c |4 ++--
unpack-trees.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/read-cache.c b/read-cache.c
Strip the name length from the ce_flags field and move it
into its own ce_namelen field in struct cache_entry. This
will both give us a tiny bit of a performance enhancement
when working with long pathnames and is part of the
refactoring for the index-v5 file format.
Index-v5 won't store the name
Thanks to the review of Junio, Duy and Thomas here is a reroll of the
patches, where the name length is separated from the flags in the
in-memory format and which includes a little bit of a performance
optimization by using the ce_namelen field instead of strlen() in
a couple of places thanks to th
On 7/6/2012 6:46 AM, Radu Manea wrote:
Thank you for the detailed presentation posted on git.or.cz site.
One question: is there any equivalent config spec file for GIT as is in
ClearCase today?
I don't know clearcase, but have you looked at git-config manpage?
http://git-htmldocs.googlecode.c
On Thu, Jul 5, 2012 at 1:15 PM, Junio C Hamano wrote:
> Phil Hord writes:
>
>> The presence of a GIT_DIR/MERGE_RR file indicates we
>> were resolving a merge which had rerere candidates for
>> recording. But the file does not get deleted after
>> all resolutions are completed. This is ok for mo
Hi Carlos,
Carlos MartÃn Nieto wrote:
> Add this shortcut just like git-push has it.
[...]
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -724,7 +724,7 @@ int cmd_branch(int argc, const char **argv, const char
> *prefix)
> OPT__QUIET(&quiet, "suppress informational messages
43 matches
Mail list logo
