Hello!
The command:
git fetch -p -v origin master:refs/heads/test
Deletes refs/heads/test every second time when run repeatedly:
$ git fetch -p -v origin master:refs/heads/test
>From https://github.com/git/git
* [new branch] master -> test
= [up to date] master -> orig
On Mon, Jan 16, 2017 at 2:00 PM, Jeff King wrote:
> On Mon, Jan 16, 2017 at 06:06:35PM +0100, Johannes Schindelin wrote:
>
>> > And I think that would apply to any input parameter we show via
>> > error(), etc, if it is connected to a newline (ideally we would
>> > show newlines as
On Sun, Jan 15, 2017 at 04:23:02PM -0800, Junio C Hamano wrote:
> Wolfram Sang writes:
>
> > request-pull uses OPTIONS_SPEC, so no need for (meanwhile incomplete)
> > USAGE and LONG_USAGE anymore.
> >
> > Signed-off-by: Wolfram Sang
> > ---
>
> Makes sense. These are not used anywhere after w
On Mon, Jan 16, 2017 at 01:41:02AM +0100, Stephan Beyer wrote:
> However, going further, the next feature to be requested could be "git
> stash --patch" ;D This leads me to think that the mentioned simulation
> of partial stashes might be something everyone might come up with who
> has basic under
On Mon, Jan 16, 2017 at 04:22:31PM -0500, Jeff King wrote:
> I came across a repository today that was missing an object, and for
> which "git fsck" reported the error but "git fsck --connectivity-check"
> did not. It turns out that the shortcut taken by --connectivity-check
> violates some assump
Hello,
I noticed that, after renaming the current branch, the corresponding
message in .git/logs/HEAD is empty.
For example, running
$ mkdir test-repo
$ cd test-repo
$ git init
$ echo abc >file.txt
$ git add file.txt
$ git commit -m"Add file.txt"
$ git branch -m maste
I'm looking into a user git-gui problem
(https://github.com/git-for-windows/git/issues/1014) that I'd seen in the
past - I'd started some patches back in Dec 2015
http://public-inbox.org/git/1450310287-4936-1-git-send-email-philipoak...@iee.org/
I'm trying to make sure I have covered the corner c
Hello.
Apparently various GIT_* environment variables (most
interesting is GIT_DIR but AFAIR there were more) leak to
shell session launched from Git Gui's "Git Bash" menu item.
Which can cause unexpected results if user navigates in that
shell to some other repository (in can also include startin
On 01/15, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > While working on a repository, it's often helpful to stash the changes
> > of a single or multiple files, and leave others alone. Unfortunately
> > git currently offers no such option. git stash -p can be used to work
> > around th
On Mon, Jan 16, 2017 at 05:00:14PM -0500, Jeff King wrote:
> > > Please don't. Obviously C treats the "if/else" as a single unit, but
> > > IMHO it's less error-prone to include the braces any time there are
> > > multiple visual lines. E.g., something like:
> > >
> > > while (foo)
> > > if (
On Mon, Jan 16, 2017 at 06:06:35PM +0100, Johannes Schindelin wrote:
> > And I think that would apply to any input parameter we show via
> > error(), etc, if it is connected to a newline (ideally we would
> > show newlines as "?", too, but we cannot tell the difference
> > betw
On Mon, Jan 16, 2017 at 09:33:07PM +0100, Johannes Sixt wrote:
> However, Jeff's patch is intended to catch exactly these cases (not for the
> cases where this happens accidentally, but when they happen with malicious
> intent).
>
> We are talking about user-provided data that is reproduced by di
On Mon, Jan 16, 2017 at 08:56:37PM +0100, Bernd Kuhls wrote:
> According to
> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Running-the-Compiler.html
> the parameter syntax of AC_COMPILE_IFELSE is
>
> (input, [action-if-true], [action-if-false])
>
> Displaying "no" when th
Instead of checking reachability from the refs, you can ask
fsck to check from a particular set of heads. However, the
error checking here is quite lax. In particular:
1. It claims lookup_object() will report an error, which
is not true. It only does a hash lookup, and the user
has no
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
fir
There are two spots that call lookup_object() and assume
that a non-NULL result means we have the object:
1. When we're checking the objects given to us by the user
on the command line.
2. When we're checking if a reflog entry is valid.
This generally follows fsck's mental model that we
Since fsck tries to continue as much as it can after seeing
an error, we still do the reachability check even if some
heads we were given on the command-line are bogus. But if
_none_ of the heads is is valid, we fallback to checking all
refs and the index, which is not what the user asked for at
al
After checking connectivity, fsck looks through the list of
any objects we've seen mentioned, and reports unreachable
and un-"used" ones as dangling. However, it skips any object
which is not marked as "parsed", as that is an object that
we _don't_ have (but that somebody mentioned).
Since 6e454b9
This test creates a multi-level set of trees, but its
cleanup routine only removes the top-level tree. After the
test finishes, the inner tree and the blob it points to
remain, making the inner tree dangling.
A later test ("cleaned up") verifies that we've removed any
cruft and "git fsck" output i
I came across a repository today that was missing an object, and for
which "git fsck" reported the error but "git fsck --connectivity-check"
did not. It turns out that the shortcut taken by --connectivity-check
violates some assumptions made by the rest of fsck (namely, that every
object in the rep
Am 16.01.2017 um 18:06 schrieb Johannes Schindelin:
On Mon, 16 Jan 2017, Jeff King wrote:
Hmm. I am not sure to what degree CRLFs are actually a problem here.
Keep in mind these are error messages generated via error(), and so not
processing arbitrary data. I can imagine that CRs might come fro
According to
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Running-the-Compiler.html
the parameter syntax of AC_COMPILE_IFELSE is
(input, [action-if-true], [action-if-false])
Displaying "no" when the test was positive and enabling support for old
iconv implementations by OL
GIT_PARSE_WITH(iconv)) sets NO_ICONV=YesPlease in
https://github.com/git/git/blob/maint/configure.ac#L327
But the command GIT_CONF_SUBST([NO_ICONV]) in
https://github.com/git/git/blob/maint/configure.ac#L618
is only executed when NO_ICONV is an empty variable
https://github.com/git/git/blob/maint
Hi Peff,
On Mon, 16 Jan 2017, Jeff King wrote:
> On Mon, Jan 16, 2017 at 01:52:39PM +0100, Johannes Schindelin wrote:
>
> > > > An error message with an ASCII control character like '\r' in it
> > > > can alter the message to hide its early part, which is problematic
> > > > when a remote sid
On Mon, Jan 16, 2017 at 01:52:39PM +0100, Johannes Schindelin wrote:
> > > An error message with an ASCII control character like '\r' in it
> > > can alter the message to hide its early part, which is problematic
> > > when a remote side gives such an error message that the local side
> > > wi
HELP ME PLEASE
Dear Friend
I am Mr. Abdoul Issouf ,I work for BOA bank Ouagadougou Burkina Faso.
I have a business proposal which concerns the transfer of $13.5
Million USD, into a foreign account. Everything about this
transaction shall be legally done without any problem. If you are
interest
Hi,
On Mon, 16 Jan 2017, Johannes Schindelin wrote:
> On Sun, 15 Jan 2017, Junio C Hamano wrote:
>
> > I haven't spent enough time to think if it even makes sense to
> > "stash" partially, leaving the working tree still dirty.
>
> Think no more! We already support that with --keep-index, and it
Hi Hannes,
On Mon, 16 Jan 2017, Johannes Sixt wrote:
> Am 16.01.2017 um 02:51 schrieb Junio C Hamano:
> > * jk/vreport-sanitize (2017-01-11) 2 commits
> > - vreport: sanitize ASCII control chars
> > - Revert "vreportf: avoid intermediate buffer"
> >
> > An error message with an ASCII control c
Sup git
kghwegiel.pl/sitesearch.php?pound=2f3va0rhzegvq60
bolaji
Hi Junio,
On Sun, 15 Jan 2017, Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'. The ones marked with '.' do not appear in any of
> the integration branches, but I
Hi Junio,
On Sun, 15 Jan 2017, Junio C Hamano wrote:
> * js/prepare-sequencer-more (2017-01-09) 38 commits
I think that it adds confusion rather than value to specifically use a
different branch name than I indicated in my submission, unless there is a
really good reason to do so (which I fail t
Hi Stephan,
On Mon, 16 Jan 2017, Stephan Beyer wrote:
> a git-newbie-ish co-worker uses git-stash sometimes. Last time he used
> "git stash pop", he got into a merge conflict. After he resolved the
> conflict, he did not know what to do to get the repository into the
> wanted state. In his case,
Hi Junio,
On Sun, 15 Jan 2017, Junio C Hamano wrote:
> I haven't spent enough time to think if it even makes sense to
> "stash" partially, leaving the working tree still dirty.
Think no more! We already support that with --keep-index, and it is a very
useful feature.
Ciao,
Johannes
Hi Junio,
On Sat, 14 Jan 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > You stated elsewhere that converting a script into a builtin should focus
> > on a faithful conversion.
> >
> > The original code is:
> >
> > . "$author_script"
>
> [...]
>
> If the code in the sequenc
Junio C Hamano writes:
> Christian Couder writes:
>
>> The following part of the description:
>>
>> git bisect (bad|new) []
>> git bisect (good|old) [...]
>>
>> may be a bit confusing, as a reader may wonder if instead it should be:
>>
>> git bisect (bad|good) []
>> git bisect (old|new) [...]
>>
On 16.01.2017 01:41, Stephan Beyer wrote:
Hi,
On 01/16/2017 01:21 AM, Junio C Hamano wrote:
I haven't spent enough time to think if it even makes sense to
"stash" partially, leaving the working tree still dirty. My initial
reaction was "then stashing away the dirty WIP state to get a spiffy
cl
On Sun, Jan 15, 2017 at 03:47:16PM -0800, Junio C Hamano wrote:
> This one unfortunately clashes with jk/nofollow-attr-ignore where
> Peff adds sanity to refuse following symbolic links when reading
> .gitignore and .gitattributes; I'll eject jk/nofollow-attr-ignore
> topic for now and see how wel
37 matches
Mail list logo
