Re: [RFC/PATCH] git-remote-mediawiki: reset private ref after non-dumb push

Felipe Contreras writes: > On Mon, Aug 26, 2013 at 4:16 AM, Matthieu Moy > wrote: >> Matthieu Moy writes: >> >>> Junio C Hamano writes: >>> Matthieu Moy writes: >>> >>> Ideally, it would be possible to ask for a non-update without a fatal >>> error on old Git versions, but this is not po

Re: [RFC/PATCH] git-remote-mediawiki: reset private ref after non-dumb push

Junio C Hamano writes: > Matthieu Moy writes: > >> git-remote-mediawiki is kind of a special case, as the remote side uses >> a very different data model, hence it can make sense to export+reimport >> to get locally what the remote side received. > > Hmm, I am not sure how export+reimport would

Eine große Überraschung für Sie

Heute, Ihre ganz heißen Deal nike Free Schuhe innen online zu speichern. Das Markenzeichen von Nike Free betriebenen Schuhen passiert zu sein unglaublich prominent ausschließlich ein gutes Angebot über mehrere Jahre, All erwägen daher, präsentiert das Nike Free Run 2 Turnschuhe in einem der im Grun

[PATCH] config: add _cb suffix to callback functions

Commit 4d8dd1494e9f3af2e9738edaca40ada096f7bf10 introduced a build regression on uClibc which defines fgetc as macro. To work around that we add a _cb suffix to the callback functions. Signed-off-by: Natanael Copa --- config.c | 32 1 file changed, 16 insertions(

Re: [PATCH] Add gui.displayuntracked option

Max Kirillov writes: >When git is used to track only a subset of a directory, or >there is no sure way to divide files to ignore from files to track, >git user have to live with large number of untracked files. These files >present in file list, and should always be scrolled through >to handle re

Re: [PATCH] git-gui: right half window is paned

Max Kirillov writes: >For long descriptions it would be nice to be able to resize >the comment text field. > >Signed-off-by: Max Kirillov >--- > git-gui/git-gui.sh | 16 +++- > 1 file changed, 11 insertions(+), 5 deletions(-) > >diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh >in

Donation Funds

My wife and i won £148.6 Million Pounds last year, and we have done lot of charity donation, so we decide to give 1.5Million Pounds each to 5 lucky people this June 2013, lucky for you, your email, was given to us by google managment as one of our lucky receipants. For verification process see

[PATCH] Document pack v4 format

Signed-off-by: Nguyễn Thái Ngọc Duy --- For my education but may help people who are interested in the format. Most is gathered from commit messages, except the delta tree entries. .idx is not documented yet, but it does not change much and not the focus right now anyway. Documentation/t

Re: [RFC/PATCH] Fix path prefixing in grep_object

On Tue, Aug 27, 2013 at 12:07 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Not necessarily. If the user is asking the question in a more >> natural way (I want to see where in 'next' branch's tip commit hits >> appear, by the way, I know I am only interested in builtin/ so I'd >> give

[PATCH] remote: filter out invalid remote configurations

In remote's configuration callback, anything that looks like 'remote..*' creates a remote ''. This remote may not end up having any configuration for a remote, but it's still in the list, so 'git remote' shows it, which means something like [remote "bogus"] hocus = pocus will show a r

Re: [PATCH/RFC] core.precomposeunicode is true by default

(Sorry for the somewhat late reply, thanks for review) >Torsten Bögershausen writes: > >> When core.precomposeunicode was introduced, it was set to false >> by default, to be compatible with older versions of Git. >> >> Whenever UTF-8 file names are used in a mixed environment, >> the Mac OS users

BUG: git subtree split - revert commit followed by a merge

Hello: I'm running into the problem described in this mailing list post: http://thread.gmane.org/gmane.comp.version-control.git/202645 'git subtree split' fails to reconstruct the history when a revert commit is followed by a merge commit. I have slightly adjusted the test script provid

[PATCH/RFC v2] Set core.precomposeunicode to true on e.g. HFS+

When core.precomposeunicode was introduced in 76759c7d, it was set to false on a unicode decomposing file system like HFS+ to be compatible with older versions of Git. The Mac OS users need to find out that this configuration exist and change it manually from false to true. A smoother workflow ca

[PATCH] documentation: clarify notes for clean.requireForce

Add "-i" (interactive clean option) to clarify the documentation for "clean.requireForce" config variable. Also replace the example in `gitcli.txt` with safer git clean command. Signed-off-by: Jiang Xin --- Documentation/config.txt | 4 ++-- Documentation/gitcli.txt | 2 +- 2 files changed, 3 in

Asymmetric default behavior of git stash

Hi, is there any reason why the default behavior of git stash is asymmetric? When I save my current state with 'git stash save' it saves the worktree changes and the index changes (and resets both). When I restore the state with 'git stash pop' it restores the worktree changes, but not the state

Re: [PATCH/RFC v2] Set core.precomposeunicode to true on e.g. HFS+

Torsten Bögershausen writes: > When core.precomposeunicode was introduced in 76759c7d, > it was set to false on a unicode decomposing file system like HFS+ > to be compatible with older versions of Git. > > The Mac OS users need to find out that this configuration exist > and change it manually f

PATCH/RFC man git remote, use of vs

I noticed that mostly refers to remotes as "", but in one case as "". "" is clearer than "", and also follows the pattern of "", "" and so on. Here follows a patch in which the usage is made consistent, as "" rather than "". I hope the format is OK. Thanks, Da

Re: [PATCH/RFC] core.precomposeunicode is true by default

Torsten Bögershausen writes: >>... see if that path can be seen under its alias. Why do we set it >>to "false"? Isn't this the true culprit? >> >>After all, this is not in the "reinit" codepath, so we know we are >>dealing with a repository that was created afresh. > > There is nothing wrong wi

Re: [PATCH] remote: filter out invalid remote configurations

Carlos Martín Nieto writes: > In remote's configuration callback, anything that looks like > 'remote..*' creates a remote ''. This remote may not end > up having any configuration for a remote, but it's still in the list, > so 'git remote' shows it, which means something like > > [remote "bog

Re: [PATCH] config: add _cb suffix to callback functions

Natanael Copa writes: > Commit 4d8dd1494e9f3af2e9738edaca40ada096f7bf10 introduced a build > regression on uClibc which defines fgetc as macro. To work around that > we add a _cb suffix to the callback functions. > > Signed-off-by: Natanael Copa > --- Thanks; I think Peff already fixed this yes

Re: [PATCH 00/23] Preliminary pack v4 support

Nicolas Pitre writes: > Subject says it all... at last ! > > This can also be fetched here: > > git://git.linaro.org/people/nico/git > > Demonstration of what it does at the moment: > > http://article.gmane.org/gmane.comp.version-control.git/233038 > > I'd like to preserve the author

Re: [PATCH/RFC] core.precomposeunicode is true by default

On 27.08.13 16:49, Junio C Hamano wrote: > Torsten Bögershausen writes: > >>> ... see if that path can be seen under its alias. Why do we set it >>> to "false"? Isn't this the true culprit? >>> >>> After all, this is not in the "reinit" codepath, so we know we are >>> dealing with a repository t

Re: [PATCH 01/23] pack v4: initial pack dictionary structure and code

Nicolas Pitre writes: > Signed-off-by: Nicolas Pitre > --- Was there a reason not to reuse the hash-table Linus did in hash.[ch]? It may not make much of a difference for something so small and isolated from the rest of the system, but if hash.[ch] can be easily fixed with a small tweak to sui

Eclipse

Does git work with Eclipse? Ron -- 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 http://vger.kernel.org/majordomo-info.html

Re: Eclipse

On 27.08.13 17:10, Ron Tregaskis - NOAA Federal wrote: > Does git work with Eclipse? No. If the question is "does Eclipse work with git": yes. For more information please feel free to spend some seconds using a seach engine. -- To unsubscribe from this list: send the line "unsubscribe git" in

Re: [PATCH 05/23] pack v4: add commit object parsing

Nicolas Pitre writes: > Let's create another dictionary table to hold the author and committer > entries. We use the same table format used for tree entries where the > 16 bit data prefix is conveniently used to store the timezone value. > > In order to copy straight from a commit object buffer,

Re: [PATCH 08/23] pack v4: basic references encoding

Nicolas Pitre writes: > Add variable length number encoding. Let's apply the same encoding > currently used for the offset to base of OBJ_OFS_DELTA objects which > is the most efficient way to do this, and apply it to everything with > pack version 4. > > Also add SHA1 reference encoding. This

Re: [PATCH 09/23] pack v4: commit object encoding

Nicolas Pitre writes: > This goes as follows: > > - Tree reference: either variable length encoding of the index > into the SHA1 table or the literal SHA1 prefixed by 0 (see > add_sha1_ref()). > > - Parent count: variable length encoding of the number of parents. > This is normally going to

Re: [PATCH 10/23] pack v4: tree object encoding

Nicolas Pitre writes: > This goes as follows: > > - Number of tree entries: variable length encoded. > > Then for each tree entry: > > - Path component reference: variable length encoded index into the path > string dictionary table which also covers the entry mode. To make the > overall enc

Re: [PATCH 12/23] pack v4: creation code

Nicolas Pitre writes: > Let's actually open the destination pack file and write the header and > the tables. > > The header isn't much different from pack v3, except for the pack version > number of course. > > The first table is the sorted SHA1 table normally found in the pack index > file. Wit

Re: [PATCH 08/23] pack v4: basic references encoding

On Tue, 27 Aug 2013, Junio C Hamano wrote: > Nicolas Pitre writes: > > > Add variable length number encoding. Let's apply the same encoding > > currently used for the offset to base of OBJ_OFS_DELTA objects which > > is the most efficient way to do this, and apply it to everything with > > pack

Re: [PATCH 14/23] pack v4: object data copy

Nicolas Pitre writes: > Blob and tag objects have no particular changes except for their object > header. > > Delta objects are also copied as is, except for their delta base reference > which is converted to the new way as used elsewhere in pack v4 encoding > i.e. an index into the SHA1 table or

Re: [PATCH 00/23] Preliminary pack v4 support

On Tue, 27 Aug 2013, Junio C Hamano wrote: > Nicolas Pitre writes: > > > Subject says it all... at last ! > > > > This can also be fetched here: > > > > git://git.linaro.org/people/nico/git > > > > Demonstration of what it does at the moment: > > > > http://article.gmane.org/gmane.comp.v

Re: [PATCH 01/23] pack v4: initial pack dictionary structure and code

On Tue, 27 Aug 2013, Junio C Hamano wrote: > Nicolas Pitre writes: > > > Signed-off-by: Nicolas Pitre > > --- > > Was there a reason not to reuse the hash-table Linus did in > hash.[ch]? Well... Most likely because when I started that code (which used to be quite different initially) it migh

Re: [PATCH/RFC] core.precomposeunicode is true by default

Torsten Bögershausen writes: >>> 2) >>> When we access a repo from Windows/Linux using SAMBA, >> You mean s/repo/repository that resides on HFS+/? > Sorry being unclear here, trying being clearer with an example: > I have a /data/Docs on my linux box, which is handled by git > > I export /data/Do

Re: [PATCH] documentation: clarify notes for clean.requireForce

Jiang Xin writes: > Add "-i" (interactive clean option) to clarify the documentation for > "clean.requireForce" config variable. Also replace the example in > `gitcli.txt` with safer git clean command. Hmm, the former change may make sense, but I am not sure about the latter. The section is abo

Re: [PATCH 00/23] Preliminary pack v4 support

Nicolas Pitre writes: > On Tue, 27 Aug 2013, Junio C Hamano wrote: > >> Nicolas Pitre writes: >> ... >> > I'd like to preserve the author time stamps as they relate to where in >> > the world I was when the corresponding code was written. You'll notice >> > I didn't work on the code in the sam

Re: [PATCH 05/23] pack v4: add commit object parsing

On Tue, 27 Aug 2013, Junio C Hamano wrote: > Nicolas Pitre writes: > > > Let's create another dictionary table to hold the author and committer > > entries. We use the same table format used for tree entries where the > > 16 bit data prefix is conveniently used to store the timezone value. > >

Re: [PATCH 10/23] pack v4: tree object encoding

On Tue, 27 Aug 2013, Junio C Hamano wrote: > Nicolas Pitre writes: > > > This goes as follows: > > > > - Number of tree entries: variable length encoded. > > > > Then for each tree entry: > > > > - Path component reference: variable length encoded index into the path > > string dictionary tabl

Re: Eclipse

Gee, sorry I asked. On 8/27/2013 11:15 AM, Torsten Bögershausen wrote: On 27.08.13 17:10, Ron Tregaskis - NOAA Federal wrote: Does git work with Eclipse? No. If the question is "does Eclipse work with git": yes. For more information please feel free to spend some seconds using a seach engin

Re: [PATCH 12/23] pack v4: creation code

On Tue, 27 Aug 2013, Junio C Hamano wrote: > Nicolas Pitre writes: > > > Let's actually open the destination pack file and write the header and > > the tables. > > > > The header isn't much different from pack v3, except for the pack version > > number of course. > > > > The first table is the s

Re: [PATCH 09/23] pack v4: commit object encoding

On Tue, 27 Aug 2013, Junio C Hamano wrote: > Nicolas Pitre writes: > > > This goes as follows: > > > > - Tree reference: either variable length encoding of the index > > into the SHA1 table or the literal SHA1 prefixed by 0 (see > > add_sha1_ref()). > > > > - Parent count: variable length en

Re: Eclipse

On 8/27/2013 10:10 AM, Ron Tregaskis - NOAA Federal wrote: Does git work with Eclipse? Ron -- 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 http://vger.kernel.org/majordomo-info.html I find that an

Re: [PATCH 05/23] pack v4: add commit object parsing

Nicolas Pitre writes: > Hmmm The problem I have with split_ident_line() right now is about > the fact that it is too liberal with whitespaces. Here I must be sure I > can deconstruct a commit object and be sure I still can regenerate it > byte for byte in order to match its SHA1 signatur

[PATCH v2 0/11] Modernize user-manual

Hi, this is v2 of my patches for user-manual.txt. Thanks to Junio, Jonathan, Martin and Philip for your comments! I think Philips remarks should be part of a separate patch series which then also should address the current differences in layout between user-manual.html and user-manual.pdf. Chan

[PATCH 01/11] Call it "Git User Manual" and remove reference to very old Git version

Reviewed-by: Jonathan Nieder Signed-off-by: Thomas Ackermann --- Documentation/user-manual.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index fe723e4..103ec9a 100644 --- a/Documentation/user-manual.txt

[PATCH 02/11] Use current "detached HEAD" message

Signed-off-by: Thomas Ackermann --- Documentation/user-manual.txt | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 103ec9a..bdefd9a 100644 --- a/Documentation/user-manual.txt +++ b/Documen

[PATCH 03/11] Use current output for "git repack"

Signed-off-by: Thomas Ackermann --- Documentation/user-manual.txt | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index bdefd9a..3f44ca0 100644 --- a/Documentation/user-manual.txt +++ b/Documentati

[PATCH 04/11] Use "git merge" instead of "git pull ."

"git pull ." works, but "git merge" is the recommended way for new users to do things. (The old description also should have read "The former is actually *not* very commonly used".) Signed-off-by: Thomas Ackermann --- Documentation/user-manual.txt | 8 1 file changed, 4 insertions(+),

[PATCH 05/11] Fix some typos and improve wording

Signed-off-by: Thomas Ackermann --- Documentation/user-manual.txt | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 6241a43..465d9cb 100644 --- a/Documentation/user-manual.txt +++ b/Docum

[PATCH 06/11] Simplify "How to make a commit"

Combine the two cases for "git add" into one. Add verb "use" to "git rm" case. Signed-off-by: Thomas Ackermann --- Documentation/user-manual.txt | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 465

[PATCH 07/11] Improve section "Manipulating branches"

Add some missing punctuation. Simplify description of "git branch -d/-D". Signed-off-by: Thomas Ackermann --- Documentation/user-manual.txt | 20 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt ind

[PATCH 10/11] Remove irrelevant reference from "Tying it all together"

Sorry Jon, but this might not be of any help to new Git users ;) Acked-by: Jon Loeliger Signed-off-by: Thomas Ackermann --- Documentation/user-manual.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 56

[PATCH 11/11] "git prune" is safe

"git prune" is safe in case of concurrent accesses to a repository but using it in such a case is not recommended. Signed-off-by: Thomas Ackermann --- Documentation/user-manual.txt | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/Documentation/user-manual.txt b/D

[PATCH 08/11] Improve section "Merging multiple trees"

Remove unnecessary quoting. Simplify description of three-way merge. Signed-off-by: Jonathan Nieder Signed-off-by: Thomas Ackermann --- Documentation/user-manual.txt | 27 +-- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/Documentation/user-manual.txt

[PATCH 09/11] Remove unnecessary historical note from "Object storage format"

Signed-off-by: Thomas Ackermann --- Documentation/user-manual.txt | 2 -- 1 file changed, 2 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index a7ca3e3..56bd088 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -4145,8 +4

Re: [PATCH] Document pack v4 format

Nguyễn Thái Ngọc Duy writes: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > For my education but may help people who are interested in the > format. Most is gathered from commit messages, except the delta tree > entries. Thanks. > diff --git a/Documentation/technical/pack-format-v4.txt > b

Re: [PATCH 14/23] pack v4: object data copy

On Tue, 27 Aug 2013, Junio C Hamano wrote: > Nicolas Pitre writes: > > > Blob and tag objects have no particular changes except for their object > > header. > > > > Delta objects are also copied as is, except for their delta base reference > > which is converted to the new way as used elsewhere

Re: [PATCH] Document pack v4 format

On Tue, 27 Aug 2013, Nguyễn Thái Ngọc Duy wrote: > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > For my education but may help people who are interested in the > format. Most is gathered from commit messages, except the delta tree > entries. Excellent! That's the kind of thing I need help w

Re: [PATCH 05/11] Fix some typos and improve wording

Thomas Ackermann writes: > Signed-off-by: Thomas Ackermann > --- > Documentation/user-manual.txt | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt > index 6241a43..465d9cb 100644 > --- a/

Re: [PATCH 06/11] Simplify "How to make a commit"

Sounds good. -- 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 http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/11] Call it "Git User Manual" and remove reference to very old Git version

Thomas Ackermann writes: > Reviewed-by: Jonathan Nieder > Signed-off-by: Thomas Ackermann > --- I tend to agree with Jonathan that this should be "User's Manual". I've tentatively queued uncontroversial bits from v1 series already on 'pu', by the way, and I do not think I have time to queue r

Re: [PATCH 04/11] Use "git merge" instead of "git pull ."

Thomas Ackermann writes: > "git pull ." works, but "git merge" is the recommended > way for new users to do things. (The old description > also should have read "The former is actually *not* very > commonly used".) It does not matter that you are unaware other people use it often. I'd suggest dr

Re: [PATCH 07/11] Improve section "Manipulating branches"

Thomas Ackermann writes: > `git branch -d `:: > - delete the branch ``; if the branch you are deleting > - points to a commit which is not reachable from the current > - branch, this command will fail with a warning. > + delete the branch ``; if the branch is not fully > + me

Re: [PATCH] Improve font rendering on retina macbooks

Mads Dørup writes: >Hi there > >I've created a very small change to git gui that considerably improves the >experience on my machine at least: > >diff --git a/git-gui/macosx/Info.plist b/git-gui/macosx/Info.plist >index b3bf15f..1ade121 100644 >--- a/git-gui/macosx/Info.plist >+++ b/git-gui/macos

What's cooking in git.git (Aug 2013, #06; Tue, 27)

What's cooking in git.git (Aug 2013, #06; Tue, 27) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Git 1.8.4 was tagged and released recentl

Re: [PATCH 08/11] Improve section "Merging multiple trees"

Thomas Ackermann writes: > Remove unnecessary quoting. > Simplify description of three-way merge. > > Signed-off-by: Jonathan Nieder > Signed-off-by: Thomas Ackermann > --- The update is good, but I wonder if this belongs to "User's manual" these days. Perhaps we should start thinking about r

Re: [PATCH 09/11] Remove unnecessary historical note from "Object storage format"

Good. Thanks. -- 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 http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/11] "git prune" is safe

Thomas Ackermann writes: > "git prune" is safe in case of concurrent accesses to a repository > but using it in such a case is not recommended. > > Signed-off-by: Thomas Ackermann > --- > Documentation/user-manual.txt | 12 +++- > 1 file changed, 3 insertions(+), 9 deletions(-) > > diff

Re: [PATCH/RFC] core.precomposeunicode is true by default

On 2013-08-27 18.27, Junio C Hamano wrote: > Torsten Bögershausen writes: > 2) When we access a repo from Windows/Linux using SAMBA, >>> You mean s/repo/repository that resides on HFS+/? >> Sorry being unclear here, trying being clearer with an example: >> I have a /data/Docs on my linu

Re: [PATCH 04/11] Use "git merge" instead of "git pull ."

On Tue, Aug 27, 2013 at 12:06:33PM -0700, Junio C Hamano wrote: > Thomas Ackermann writes: > > > "git pull ." works, but "git merge" is the recommended > > way for new users to do things. (The old description > > also should have read "The former is actually *not* very > > commonly used".) > > I

Re: [PATCH] config: add _cb suffix to callback functions

On Tue, Aug 27, 2013 at 10:54 AM, Junio C Hamano wrote: > Natanael Copa writes: > >> Commit 4d8dd1494e9f3af2e9738edaca40ada096f7bf10 introduced a build >> regression on uClibc which defines fgetc as macro. To work around that >> we add a _cb suffix to the callback functions. >> >> Signed-off-by:

[PATCH v2 1/5] replace: forbid replacing an object with one of a different type

Users replacing an object with one of a different type were not prevented to do so, even if it was obvious, and stated in the doc, that bad things would result from doing that. To avoid mistakes, it is better to just forbid that though. There is no case where one object can be replaced with one o

[PATCH v2 4/5] t6050-replace: add test to clean up all the replace refs

Signed-off-by: Christian Couder --- t/t6050-replace.sh | 6 ++ 1 file changed, 6 insertions(+) diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh index 5c352c4..05be228 100755 --- a/t/t6050-replace.sh +++ b/t/t6050-replace.sh @@ -276,4 +276,10 @@ test_expect_success 'replaced and replaceme

[PATCH v2 3/5] t6050-replace: test that objects are of the same type

Signed-off-by: Christian Couder --- t/t6050-replace.sh | 13 + 1 file changed, 13 insertions(+) diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh index decdc33..5c352c4 100755 --- a/t/t6050-replace.sh +++ b/t/t6050-replace.sh @@ -263,4 +263,17 @@ test_expect_success 'not just comm

[PATCH v2 5/5] Documentation/replace: add Creating Replacement Objects section

There were no hints in the documentation about how to create replacement objects. Signed-off-by: Christian Couder --- Documentation/git-replace.txt | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index aa66d27..7

[PATCH v2 2/5] Documentation/replace: state that objects must be of the same type

A previous patch ensures that both the replaced and the replacement objects passed to git replace must be of the same type. While at it state that there is no other restriction on both objects. Signed-off-by: Christian Couder --- Documentation/git-replace.txt | 7 --- 1 file changed, 4 inse

[PATCH v2 0/5] Check replacement object type and minor updates

The only changes compared to the previous version are those suggested by Johannes: - the error message is now: "Objects must be of the same type.\n" "'%s' points to a replaced object of type '%s'\n" "while '%s' points to a replacement object of type '%s'." - the test uses

Re: [PATCH 09/23] pack v4: commit object encoding

On Tue, 27 Aug 2013, Junio C Hamano wrote: > Nicolas Pitre writes: > > > + /* parse the "tree" line */ > > + if (in + 46 >= tail || memcmp(in, "tree ", 5) || in[45] != '\n') > > + goto bad_data; > > + if (get_sha1_hex(in + 5, sha1) < 0) > > + goto bad_data; > > Is this

Re: contrib/credential/netrc/git-credential-netrc: Use of uninitialized value in string

On Mon, Aug 26, 2013 at 08:56:23PM -0700, Junio C Hamano wrote: > Antoine Pelisse writes: > > > I've tried to use the netrc credential with git-send-email > > (v1.8.4-rc2), and I've had the following log (running with -d -v): > > Peff what do you think? From credential layer's point of view, I

Re: [PATCH 09/23] pack v4: commit object encoding

Nicolas Pitre writes: > On Tue, 27 Aug 2013, Junio C Hamano wrote: > >> Nicolas Pitre writes: >> >> > + /* parse the "tree" line */ >> > + if (in + 46 >= tail || memcmp(in, "tree ", 5) || in[45] != '\n') >> > + goto bad_data; >> > + if (get_sha1_hex(in + 5, sha1) < 0) >> > +

Re: [PATCH v2 1/5] replace: forbid replacing an object with one of a different type

Christian Couder writes: > Users replacing an object with one of a different type were not > prevented to do so, even if it was obvious, and stated in the doc, > that bad things would result from doing that. > > To avoid mistakes, it is better to just forbid that though. > > There is no case wher

[PATCHv3] write_index: optionally allow broken null sha1s

On Mon, Aug 26, 2013 at 05:20:53PM -0400, Jeff King wrote: > And by your rule above, the advice would be "each of these tests > should say "setup" in the description". That makes sense to me, and I > don't mind doing it here. > > [...] > > I totally missed your original point, then. I don't mind c

Re: [PATCH 04/11] Use "git merge" instead of "git pull ."

Jonathan Nieder writes: > On Tue, Aug 27, 2013 at 12:06:33PM -0700, Junio C Hamano wrote: >> Thomas Ackermann writes: >> >> > "git pull ." works, but "git merge" is the recommended >> > way for new users to do things. (The old description >> > also should have read "The former is actually *not*

Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)

On Tue, Aug 27, 2013 at 12:22:30PM -0700, Junio C Hamano wrote: > * jk/config-int-range-check (2013-08-21) 2 commits > (merged to 'next' on 2013-08-22 at 465efb3) > + teach git-config to output large integers > + config: properly range-check integer values > > Originally merged to 'next' on

Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)

Jeff King writes: > On Tue, Aug 27, 2013 at 12:22:30PM -0700, Junio C Hamano wrote: > >> * jk/config-int-range-check (2013-08-21) 2 commits >> (merged to 'next' on 2013-08-22 at 465efb3) >> + teach git-config to output large integers >> + config: properly range-check integer values >> >> Or

Re: [PATCH 01/11] Call it "Git User Manual" and remove reference to very old Git version

Junio C Hamano writes: | Thomas Ackermann writes: > >> Reviewed-by: Jonathan Nieder >> Signed-off-by: Thomas Ackermann >> --- > | I tend to agree with Jonathan that this should be "User's Manual". Not going into which one might be more correct, but a quick google search for "User's Manual" a

Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)

On Tue, Aug 27, 2013 at 9:22 PM, Junio C Hamano wrote: > * jh/remote-hg-fetch-fix (2013-07-25) 2 commits > (merged to 'next' on 2013-07-25 at 33161ad) > + Revert "remotes-hg: bugfix for fetching non local remotes" > (merged to 'next' on 2013-07-24 at 9c96641) > + remotes-hg: bugfix for fetch

Re: [PATCH 09/23] pack v4: commit object encoding

On Tue, 27 Aug 2013, Junio C Hamano wrote: > Nicolas Pitre writes: > > > On Tue, 27 Aug 2013, Junio C Hamano wrote: > > > >> Nicolas Pitre writes: > >> > >> > +/* parse the "tree" line */ > >> > +if (in + 46 >= tail || memcmp(in, "tree ", 5) || in[45] != '\n') > >> > +

Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)

[+cc Jonathan] On Tue, Aug 27, 2013 at 02:05:01PM -0700, Junio C Hamano wrote: > >> * jk/config-int-range-check (2013-08-21) 2 commits > [...] > > > > I think Jonathan had some concerns about the test in the first one, and > > there was an open question in the second of whether we wanted to add >

Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)

Junio C Hamano writes: > What's cooking in git.git (Aug 2013, #06; Tue, 27) > -- > > Here are the topics that have been cooking. Commits prefixed with > '-' are only in 'pu' (proposed updates) while commits prefixed with > '+' are in 'next'. > > Gi

Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)

Jeff King writes: > I don't feel too strongly either way. I mostly kept the range checks for > --int because that is how the code already worked, and I assumed that > was what was desired. But given what I know of the history of the config > code, it is probably a completely random side effect of

Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)

Antoine Pelisse writes: > On Tue, Aug 27, 2013 at 9:22 PM, Junio C Hamano wrote: >> * jh/remote-hg-fetch-fix (2013-07-25) 2 commits >> (merged to 'next' on 2013-07-25 at 33161ad) >> + Revert "remotes-hg: bugfix for fetching non local remotes" >> (merged to 'next' on 2013-07-24 at 9c96641) >

Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)

On Tue, Aug 27, 2013 at 12:22:30PM -0700, Junio C Hamano wrote: > * kk/tests-with-no-perl (2013-08-24) 4 commits > - reset test: modernize style > - t/t7106-reset-unborn-branch.sh: Add PERL prerequisite > - add -i test: use skip_all instead of repeated PERL prerequisite > - Make test "using inv

???????

Contact Me for a business Deal -- 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 http://vger.kernel.org/majordomo-info.html

[PATCH v2] documentation: clarify notes for clean.requireForce

Add "-i" (interactive clean option) to clarify the documentation for "clean.requireForce" config variable. Signed-off-by: Jiang Xin --- Documentation/config.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 83613

[PATCHv2] mailmap: handle mailmap blobs without trailing newlines

The read_mailmap_buf function reads each line of the mailmap using strchrnul, like: const char *end = strchrnul(buf, '\n'); unsigned long linelen = end - buf + 1; But that's off-by-one when we actually hit the NUL byte; our line does not have a terminator, and so is only "end - buf" bytes

Re: [PATCH 00/23] Preliminary pack v4 support

On Tue, Aug 27, 2013 at 11:44 PM, Junio C Hamano wrote: > As you have "0-index" escape hatch for SHA-1 table, but no similar > escape hatch for the people's name table, I can see why it may be > cumbersome to fix a thin pack by only appending to a received > packfile and updating a few header fiel

Re: [PATCH 00/23] Preliminary pack v4 support

On Wed, 28 Aug 2013, Duy Nguyen wrote: > On Tue, Aug 27, 2013 at 11:44 PM, Junio C Hamano wrote: > > As you have "0-index" escape hatch for SHA-1 table, but no similar > > escape hatch for the people's name table, I can see why it may be > > cumbersome to fix a thin pack by only appending to a re

Re: [PATCH 00/23] Preliminary pack v4 support

On Wed, Aug 28, 2013 at 9:58 AM, Nicolas Pitre wrote: >> But what if we store >> appended objects in OBJ_REF_DELTA format where base ref is empty >> tree/commit and cached by sha1_file.c? > > I don't follow you here. Missing objects need to be added to the pack, > they can't be cached anywhere.

  1   2   >