Not answering questions does not help anyone.
My question was: What is the point in insisting that there is a *really*
new commit when the one commit that already existed has exactly the
content that you wanted?
-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bo
Hi PJ and Hannes,
try to run the last script that I posted, with and without a sleep 1
before the last commit:
git init
echo "aaa" >f1
git add f1
git commit -m A
git checkout --orphan sources
git commit -m A --allow-empty
and
git init
echo "aaa" >f1
git add f1
git commit -m A
git checkout --orp
Am 10/2/2012 23:56, schrieb Angelo Borsotti:
> The problem I am trying to solve is to push to a remote server the
> source files only,
> while keeping in the local repo both sources and binaries. To do it, I
> keep an orphan
> branch, [...]
>
> # this is the commit on the master branch
> git init
On Tue, Oct 2, 2012 at 2:56 PM, Angelo Borsotti
wrote:
> Hi Junio,
>
>> It does create one; it just is the same one you already happen to have,
>> when you record the same state on top of the same history as the
>> same person at the same time.
>>
>
> No, it does not create one: as you can see fro
Jeremy Morton writes:
> I've noticed that the p4merge shell script could do with some
> improvement when it comes to merging. Because p4merge throws up an
> error when one of the files it's given to diff is "/dev/null", git
> needs to create a temporary empty file and pass that to p4merge when
>
return-path: off...@motylek.com
Claudio.canovastudioclaudiocanova. Http://nimubuh.esugar.org/
--
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
Hi,
I've noticed that the p4merge shell script could do with some
improvement when it comes to merging. Because p4merge throws up an
error when one of the files it's given to diff is "/dev/null", git needs
to create a temporary empty file and pass that to p4merge when diffing a
file that has
Junio C Hamano :
> Seeing the above without a signed-off patch and then this on cia.vc
>
> We intend to have the CIA.VC Site running soon then bring the
> service back at a later date! We currently do not have an ETA for
> the Service but hope to have it functioning soon!
>
> I am no
e...@thyrsus.com (Eric S. Raymond) writes:
> The CIA notification server died about two days ago, done in by
> a screwup at the cloud service hosting is VM. For various technical
> reasons there cannot and will not be any effort to revive it. If you want
> the whole sordid tale, read "CIA and th
Junio C Hamano writes:
> The last piece to expect "error in tag.*broken links" in the output
> is wrong. Probably we should remove the misguided check and end
> it with "test_must_fail git fsck --tags".
I think this should suffice.
When we check tag T first, we make a mental note on X that is
Hi Junio,
> It does create one; it just is the same one you already happen to have,
> when you record the same state on top of the same history as the
> same person at the same time.
>
No, it does not create one: as you can see from the trace of the execution
of my script, the sha of the commit i
On Tue, Oct 02, 2012 at 09:32:11PM +0200, Carlos Martín Nieto wrote:
> >> @@ -101,8 +102,9 @@ static char *locate_in_PATH(const char *file)
> >>}
> >>strbuf_addstr(&buf, file);
> >>
> >> - if (!access(buf.buf, F_OK))
> >> + if (!stat(buf.buf, &st) && !S_
Torsten Bögershausen writes:
> With help of Junio's comments I probably found the reason why the test
> behaves differently:
>
> The objects are checked in a certain order, based on the inode number.
>
> Which seems to be the same on most machines: when files are created
> in a certain order, the
Simon Oosthoek writes:
> ... This is
> prevented (and quite the norm in static PS1 strings) by enclosing the
> terminal code for color inside \[ and \] so bash doesn't count these and
> what is in between them in the length of the prompt string.
Ah, OK, and these \[ things \] behave like other m
c...@elego.de (Carlos Martín Nieto) writes:
> How about something like this instead? We keep the access check and only
> do the stat call when we have found something we want to look at.
Sounds safer.
Looking at the way the stat call is indented twice, I suspect that
the variable can be defined
Angelo Borsotti writes:
> "Usually recording a commit that has the exact same tree as its sole
> parent commit is a mistake, and the command prevents you from making
> such a commit. This option bypasses the safety, and is primarily for
> use by foreign SCM interface scripts."
>
> I cannot find a
On 02/10/12 19:01, Junio C Hamano wrote:
> If your goal is to use PROMPT_COMMAND and not PS1, then yes between
> the two definitions of PROMPT_COMMAND above, the latter may look
> simpler. But that does not explain why you want to prefer it over
> PS1 in the first place, which was the central poin
Am 02.10.2012 18:51, schrieb Ramkumar Ramachandra:
> Introduce a diff.submoduleFormat configuration variable corresponding
> to the '--submodule' command-line option of 'git diff'.
Nice. Maybe a better name would be "diff.submodule", as this sets the
default for the "--submodule" option of diff?
Junio C Hamano writes:
> Carlos Martín Nieto writes:
>
>> When looking through $PATH to try to find an external command,
>> locate_in_PATH doesn't check that it's trying to execute a file. Add a
>> check to make sure we won't try to execute a directory.
>>
>> This also stops us from looking furt
Peter Krefting writes:
> a fix for the most embarrasing typo in the Swedish translation
> ("Receiveing" became "Deleting"). The fix is already in the big
> pull-request slated for the next feature release, but I would
> appreciate if a 1.17.12.3 did contain this...
Surely, and thanks.
I do no
Hi Junio,
if I put on my head the implementor's hat, I would agree with you: that command
after all behaves as implemented.
However, if I put the user's hat I would reason differently. What I
need are predictable
commands, and that by all means is not. This because the time at which a command
is e
Am 02.10.2012 18:51, schrieb Ramkumar Ramachandra:
> Currently, the diff code does not differentiate between an explicit
> '--submodule=short' being passed, and no submodule option being passed
> on the command line. Making this differentiation will be important
> when the command-line option can
Junio C Hamano writes:
> Brian Charles Gernhardt writes:
>
>> Another problem caused by BSD v GNU sed, I think.
>>
>> git cat-file blob HEAD:x |
>> sed "/preline/a\
>> ADDED" >x &&
>
> Actually, I think what is happening is that inside "", the backslash
> at the end of line is eat
David Glasser writes:
> Thanks Junio! Note that I think the word is usually spelled
> "controlled" not "controled".
Thanks; I cannot spelll...
--
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://vg
Thanks Junio! Note that I think the word is usually spelled
"controlled" not "controled".
On Tue, Oct 2, 2012 at 11:34 AM, Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> David Glasser wrote:
>>> Thanks Rankumar! There's also the reference in the "git push origin"
>>> example and the "
Brian Charles Gernhardt writes:
> Another problem caused by BSD v GNU sed, I think.
>
> git cat-file blob HEAD:x |
> sed "/preline/a\
> ADDED" >x &&
Actually, I think what is happening is that inside "", the backslash
at the end of line is eaten by the shell together with that
Junio C Hamano writes:
> Brian Charles Gernhardt writes:
>
>> Another problem caused by BSD v GNU sed, I think.
>
> Oh, that again X-<.
>
> Will patch up in a stupid-but-trivial way, unless somebody knows a
> reliable workaround.
I no longer have a BSD handy to test, so I'd appreciate it if
som
Brian Charles Gernhardt writes:
> Another problem caused by BSD v GNU sed, I think.
Oh, that again X-<.
Will patch up in a stupid-but-trivial way, unless somebody knows a
reliable workaround.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
Ramkumar Ramachandra writes:
> David Glasser wrote:
>> Thanks Rankumar! There's also the reference in the "git push origin"
>> example and the "This is the default operation mode if no explicit
>> refspec is found".
>
> Sorry; here's a revised patch.
>
> --8<--
FYI: the above is not a scissors
Wayne Davison writes:
> On Tue, Oct 2, 2012 at 7:07 AM, Ævar Arnfjörð Bjarmason
> wrote:
>
>> Perhaps Wayne Davison (added to CC) wouldn't mind giving us permission to
>> use the subsequent changes to these files under the GPLv2?
>
> There have been no changes in the wildmat files since the GPL
Ramkumar Ramachandra writes:
> Hi,
>
> Today I learnt that a gitlink is a commit object embedded in a tree.
> However, I can't seem to be able to cat it.
>
> $ git ls-tree HEAD
> 100644 blob 5a91f388f3648b98ae34a19ec42ba9acc7852ef4.gitmodules
> 16 commit 8daa12004db8862b22f6c7
Carlos Martín Nieto writes:
> When looking through $PATH to try to find an external command,
> locate_in_PATH doesn't check that it's trying to execute a file. Add a
> check to make sure we won't try to execute a directory.
>
> This also stops us from looking further and maybe finding that the
>
Johannes Sixt writes:
> Note that git commit -m A --allow-empty *DID* create a commit. Only, that
> it received the same name (SHA1) as the commit you created before it
> because it had the exact same contents (files, parents, author, committer,
> and timestamps). Obviously, your script was execu
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Ramkumar Ramachandra writes:
>>
>>> David Glasser wrote:
Thanks Rankumar! There's also the reference in the "git push origin"
example and the "This is the default operation mode if no explicit
refspec is found".
>>>
>>> Sorry; h
Matt McClellan writes:
> I've done this using git add --interactive then reverting a files
> changes, though the actual crime was done using egit staging tool. It
> seems the command line won't let you unstage changes but gui tools and
> interactive tools seem to allow it.
I think you could do
Matthieu Moy writes:
> Ramkumar Ramachandra writes:
>
>> David Glasser wrote:
>>> Thanks Rankumar! There's also the reference in the "git push origin"
>>> example and the "This is the default operation mode if no explicit
>>> refspec is found".
>>
>> Sorry; here's a revised patch.
>
> Sounds go
Michael J Gruber writes:
> Signed-off-by: Michael J Gruber
> ---
> Just trying to make it clearer, and threw in an article or two.
> Also, tried to make the use of tenses a bit more uniform.
Thanks.
> Documentation/RelNotes/1.8.0.txt | 48
>
> 1 file
Michael J Gruber writes:
> Junio C Hamano venit, vidit, dixit 01.10.2012 23:09:
>
>> Confused
>>
>
> The "problem" (as far as I see) is only: What user interface do we want
> to expose to the user, or rather, do we want to expose the user to ;)
>
> So far, we say:
>
> #1) Copy this file
Matthieu Moy wrote:
> Ramkumar Ramachandra writes:
>
>> David Glasser wrote:
>>> Thanks Rankumar! There's also the reference in the "git push origin"
>>> example and the "This is the default operation mode if no explicit
>>> refspec is found".
>>
>> Sorry; here's a revised patch.
>
> Sounds good,
Introduce a diff.submoduleFormat configuration variable corresponding
to the '--submodule' command-line option of 'git diff'.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/diff-config.txt|7 +++
Documentation/diff-options.txt |3 ++-
diff.c |
Currently, 'git diff --submodule' displays output with a bold diff
header for non-submodules. So this part is in bold:
diff --git a/file1 b/file1
index 30b2f6c..2638038 100644
--- a/file1
+++ b/file1
For submodules, the header looks like this:
Submodule submodule1 012b072..2
Currently, the diff code does not differentiate between an explicit
'--submodule=short' being passed, and no submodule option being passed
on the command line. Making this differentiation will be important
when the command-line option can be used to override a
"diff.submoduleFormat" configuration
df44483a (diff --stat: add config option to limit graph width,
2012-03-01) added the option diff.statGraphWidth, but did not place it
in its appropriate lexical place in diff-config.txt. Fix this.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/diff-config.txt |8
1 files cha
19299a8 (Documentation: Move diff..* from config.txt to
diff-config.txt, 2011-04-07) moved the diff configuration options to
diff-config.txt, but forgot about diff.wordRegex, which was left
behind in config.txt. Fix this.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/config.txt |
Hi,
The fourth patch is the crux of the series. The first two patches
clear up config.txt, diff-config.txt for the fourth patch. The third
patch turned out to be a prerequisite. And the fifth patch is a
bonus.
Thanks for reading.
Ram
Ramkumar Ramachandra (5):
Documentation: move diff.wordR
Ramkumar Ramachandra writes:
> David Glasser wrote:
>> Thanks Rankumar! There's also the reference in the "git push origin"
>> example and the "This is the default operation mode if no explicit
>> refspec is found".
>
> Sorry; here's a revised patch.
Sounds good, thanks (resend and Cc Junio if
When argument parsing fails to detect a file name, "git-gui" will try to
use the previously detected "head" as the file name. We should avoid
prepending the prefix if "head" looks like a full path.
Signed-off-by: Andrew Wong
---
git-gui.sh | 9 +++--
1 file changed, 7 insertions(+), 2 deleti
When running "git-gui blame" from a subfolder (which means prefix is
non-empty), if we pass a full path as argument, the argument parsing
will fail to recognize the argument as a file name, because prefix is
prepended to the argument.
This patch handles that scenario by adding an additional branch
I ran into a file name parsing issue in git-gui. If I'm in a subfolder and try
to pass a full path to "git-gui blame", then "git-gui" will fail to detect the
argument as a valid path. The first patch will handle this scenario.
The second patch just another issue that I noticed when "git-gui" fails
On 09/19/2012 08:30 PM, Junio C Hamano wrote:
Torsten Bögershausen writes:
"is a blob, not a commit" is likely to come from validating of the
tag 66f6581d that presumably point at 63499e4; it reads the tag,
learns the name of the object that is tagged and the type of it,
remembers that the obje
Am Dienstag, 2. Oktober 2012, 20:53:28 schrieben Sie:
> Hi,
>
> Today I learnt that a gitlink is a commit object embedded in a tree.
> However, I can't seem to be able to cat it.
>
> $ git ls-tree HEAD
> 100644 blob 5a91f388f3648b98ae34a19ec42ba9acc7852ef4.gitmodules
> 16 comm
Thanks Rankumar! There's also the reference in the "git push origin"
example and the "This is the default operation mode if no explicit
refspec is found".
(I would have sent my own patch but I can't figure out where the
syntax for the manpages is documented.)
--dave
On Tue, Oct 2, 2012 at 8:09 A
David Glasser wrote:
> Is the newish push.default documented in the "git push" manpage
> anywhere? I don't see it mentioned (and there are several references
> to the "default" behavior), but maybe I'm missing something. Is it
> left out on purpose (ie, config values aren't supposed to be mentioned
Signed-off-by: Andrew Wong
---
gitk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitk b/gitk
index f8f89a5..d53fdb2 100755
--- a/gitk
+++ b/gitk
@@ -2501,7 +2501,7 @@ proc makewindow {} {
bindkey ? {dofind -1 1}
bindkey f nextfile
bind . updatecommits
-b
The function includes a workaround for systems where F* keys are mapped
to XF86_Switch_VT_* when modifiers are used.
Signed-off-by: Andrew Wong
---
gitk | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index 379582a..f8f89a5 100755
--- a/gitk
+++ b/gitk
@@
Refactored the code for binding modified function keys as Junio suggested.
Andrew Wong (2):
gitk: Refactor code for binding modified function keys
gitk: Use bindshiftfunctionkey to bind Shift-F5
gitk | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--
1.7.12.1.382.gb0576a6
On Mon, Oct 1, 2012 at 5:48 AM, Nguyen Thai Ngoc Duy wrote:
> Probably off topic. Does saving a list of missing bases in the pack
> index help storing thin packs directly? I may be missing some points
> because I don't see why thin packs cannot be stored on disk in the
> first place.
Packs are su
When looking through $PATH to try to find an external command,
locate_in_PATH doesn't check that it's trying to execute a file. Add a
check to make sure we won't try to execute a directory.
This also stops us from looking further and maybe finding that the
user meant an alias, as in the case where
Signed-off-by: Michael J Gruber
---
Just trying to make it clearer, and threw in an article or two.
Also, tried to make the use of tenses a bit more uniform.
As always, best looked at with --color-words or such.
Documentation/RelNotes/1.8.0.txt | 48
1
On Wed, Sep 26, 2012 at 1:25 PM, Nguyễn Thái Ngọc Duy wrote:
> These files are from rsync.git commit
> f92f5b166e3019db42bc7fe1aa2f1a9178cd215d, which was the last commit
> before rsync turned GPL-3. All files are imported as-is and
> no-op. Adaptation is done in a separate patch.
Perhaps Wayne D
On Mon, Oct 1, 2012 at 10:38 PM, Shawn Pearce wrote:
> On Mon, Oct 1, 2012 at 3:18 PM, Jeff King wrote:
>> On Mon, Oct 01, 2012 at 02:23:06PM -0700, Shawn O. Pearce wrote:
>>>
>>> When libcurl fails to connect to an SSL server always retry the
>>> request once. Since the connection failed before
Another problem caused by BSD v GNU sed, I think.
$ ./t4055-diff-context.sh -i -v
Initialized empty Git repository in /Users/brian/dev/git/t/trash
directory.t4055-diff-context/.git/
expecting success:
cat >x <<-\EOF &&
firstline
b
c
d
e
f
Hi
having such a time-dependent behavior is not nice. It means that the user must
know it, and wait patiently before issuing the command, or in a script
add a sleep
before the command.
The choice is then between adding a warning in the man page ("please
wait at least
a second before executing the
Am 10/2/2012 9:51, schrieb Angelo Borsotti:
> This is the log of the second execution:
>
> $ emptycommit
> + rm -rf local
> + mkdir local
> + cd local
> + git init
> Initialized empty Git repository in d:/gtest/local/.git/
> + echo aaa
> + git add f1
> warning: LF will be replaced by CRLF in f1.
>
Stefano Lattarini wrote:
> On 10/02/2012 09:21 AM, Ramkumar Ramachandra wrote:
>> Hi,
>>
>> I've often found the '**' (extended) shell glob useful for matching
>> any string crossing directory boundaries: it's especially useful if
>> you only have a toplevel .gitignore, as opposed to a per-director
On 10/02/2012 09:38 AM, Michael J Gruber wrote:
The longer I read your explanation, the less useful the "PC mode"
sounds like, at least to me. So why does an user even want to use
such a mechanism, instead of PS1? And even if the user wants to use
it by doing \w, \u etc. himself, she can do tha
On 10/02/2012 09:21 AM, Ramkumar Ramachandra wrote:
> Hi,
>
> I've often found the '**' (extended) shell glob useful for matching
> any string crossing directory boundaries: it's especially useful if
> you only have a toplevel .gitignore, as opposed to a per-directory
> .gitignore. Unfortunately,
Junio C Hamano venit, vidit, dixit 01.10.2012 23:09:
> Simon Oosthoek writes:
>
>> It's possible to set PS1 to nothing and print a string from
>> PROMPT_COMMAND, but then you miss out on all the features of the PS1
>> interpretation by bash and compared to the use of __git_ps1 at the
>> moment, i
Fix bad translation of "Receiving objects".
Signed-off-by: Peter Krefting
---
po/sv.po | 4 ++--
1 fil ändrad, 2 tillägg(+), 2 borttagningar(-)
Dear Junio,
could you please apply this patch to the 1.7.12 maintenance branch, if
you intend to do more releases past 1.17.12.2 from there? It cont
Ok, thanks for clarifying this.
"Philip Oakley" writes:
>All of the above are expected and working as designed. Remote
>tracking branches are local _copies_ of what you have over there at
>the remote repository. The latter is the authoritative version, and
>you asked "ls-remote" to go over the
70 matches
Mail list logo
