1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-12 20:23:02 +01:00
Commit graph

225 commits

Author SHA1 Message Date
Junio C Hamano
a78fafe74a sha1_name.c: restructure disambiguation of short names
We try to find zero, one or more matches from loose objects and
packed objects independently and then decide if the given short
object name is unique across them.

Instead, introduce a "struct disambiguate_state" that keeps track of
what we have found so far, that can be one of:

 - We have seen one object that _could_ be what we are looking for;
 - We have also checked that object for additional constraints (if any),
   and found that the object satisfies it;
 - We have also checked that object for additional constraints (if any),
   and found that the object does not satisfy it; or
 - We have seen more than one objects that satisfy the constraints.

and pass it to the enumeration functions for loose and packed
objects.  The disambiguation state can optionally take a callback
function that takes a candidate object name and reports if the
object satisifies additional criteria (e.g. when the caller knows
that the short name must refer to a commit, this mechanism can be
used to check the type of the given object).

Compared to the earlier attempt, this round avoids the optional
check if there is only one candidate that matches the short name in
the first place.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03 10:24:15 -07:00
Junio C Hamano
1703f9aa0b sha1_name.c: correct misnamed "canonical" and "res"
These are hexadecimal and binary representation of the short object
name given to the callchain as its input.  Rename them with _pfx
suffix to make it clear they are prefixes, and call them hex and bin
respectively.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03 10:24:15 -07:00
Junio C Hamano
f703e6ea5e sha1_name.c: refactor find_short_packed_object()
Extract the logic to find object(s) that match a given prefix inside
a single pack into a separate helper function, and give it a bit more
comment.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03 10:24:15 -07:00
Junio C Hamano
1b27c2f01a sha1_name.c: rename "now" to "current"
This variable points at the element we are currently looking at, and
does not have anything to do with the current time which the name
"now" implies.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03 10:24:15 -07:00
Junio C Hamano
274ac009f4 sha1_name.c: clarify what "fake" is for in find_short_object_filename()
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03 10:24:15 -07:00
Junio C Hamano
249c8f4a16 sha1_name.c: get rid of get_sha1_with_mode()
There are only two callers, and they will benefit from being able to
pass disambiguation hints to underlying get_sha1_with_context() API
once it happens.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03 10:24:11 -07:00
Junio C Hamano
8c135ea260 sha1_name.c: get rid of get_sha1_with_mode_1()
The only external caller is setup.c that tries to give a nicer error
message when an object name is misspelt (e.g. "HEAD:cashe.h").
Retire it and give the caller a dedicated and more intuitive API
function maybe_die_on_misspelt_object_name().

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03 10:22:37 -07:00
Junio C Hamano
f01cc14c3c sha1_name.c: hide get_sha1_with_context_1() ugliness
There is no outside caller that cares about the "only-to-die" ugliness.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-02 11:22:57 -07:00
Junio C Hamano
08080894b7 Merge branch 'mm/verify-filename-fix'
"git diff COPYING HEAD:COPYING" gave a nonsense error message that
claimed that the treeish HEAD did not have COPYING in it.
2012-06-28 15:19:32 -07:00
Matthieu Moy
d7236c4395 sha1_name: do not trigger detailed diagnosis for file arguments
diagnose_invalid_sha1_path() is meant to be called to diagnose a
misspelt <treeish>:<pathname> when <pathname> does not exist in
<treeish>.  However, the code may call it if <treeish>:<pathname> is
invalid (which triggers another call with only_to_die == 1), but for
another reason. This happens when calling e.g.

  git log existing-file HEAD:existing-file

because existing-file is a path and not a revision, the code
verifies that the arguments that follow to be paths.  This leads to
an incorrect message like "existing-file does not exist in HEAD",
even though the path exists in HEAD.

Check that the search for <pathname> in <treeish> fails before
triggering the diagnosis.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-18 15:13:16 -07:00
Junio C Hamano
a1b475eeb4 sha1_name.c: indentation fix
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-18 14:59:56 -07:00
Zbigniew Jędrzejewski-Szmek
6472028893 i18n: mark @{upstream} error messages for translation
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15 14:26:08 -07:00
Zbigniew Jędrzejewski-Szmek
17c82211ec Be more specific if upstream branch is not tracked
If the branch configured as upstream didn't have a local tracking
branch, git said "Upstream branch not found". We can be more helpful,
and separate the cases when upstream is not configured, and when it is
configured, but the upstream branch is not tracked in a local branch.

The following configuration leads to the second scenario:

    [remote "origin"]
    	    url = ...
            fetch = refs/heads/master
    [branch "master"]
            remote = origin
            merge = refs/heads/master

'git pull' will work on master, but master@{upstream} is not defined.

Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15 14:25:34 -07:00
Zbigniew Jędrzejewski-Szmek
bb0dab5d61 Provide better message for barnhc_wiht_tpyo@{u}
Instead of just saying that no upstream exists for such branch,
which is true but not very helpful, check that there's no
refs/heads/barnhc_wiht_tpyo and tell it to the user.

Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15 14:25:19 -07:00
Zbigniew Jędrzejewski-Szmek
9884e67f9d Provide branch name in error message when using @{u}
When using @{u} or @{upstream} it is common to omit the branch name,
implying current branch. If the upstream is not configured, the error
message was "No upstream branch found for ''".

When resolving '@{u}', branch_get() is called, which almost always
returns a description of a branch. This allows us to use a branch name
in the error message, even if the user said something like '@{u}'.

The only case when branch_get() returns NULL is when HEAD points to so
something which is not a branch. Of course this also means that no
upstream is configured, but it is better to directly say that HEAD
does not point to a branch.

Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15 14:24:36 -07:00
Junio C Hamano
0445ba2457 Merge branch 'jc/broken-ref-dwim-fix'
* jc/broken-ref-dwim-fix:
  resolve_ref(): report breakage to the caller without warning
  resolve_ref(): expose REF_ISBROKEN flag
  refs.c: move dwim_ref()/dwim_log() from sha1_name.c
2011-10-21 16:04:36 -07:00
Junio C Hamano
ff74f7f118 refs.c: move dwim_ref()/dwim_log() from sha1_name.c
Both dwim_ref()/dwim_log() functions are intimately related to the ref
parsing rules defined in refs.c and better fits there. Move them together
with substitute_branch_name(), a file scope static helper function.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-12 10:35:38 -07:00
Junio C Hamano
9bd500048d Merge branch 'mh/check-ref-format-3'
* mh/check-ref-format-3: (23 commits)
  add_ref(): verify that the refname is formatted correctly
  resolve_ref(): expand documentation
  resolve_ref(): also treat a too-long SHA1 as invalid
  resolve_ref(): emit warnings for improperly-formatted references
  resolve_ref(): verify that the input refname has the right format
  remote: avoid passing NULL to read_ref()
  remote: use xstrdup() instead of strdup()
  resolve_ref(): do not follow incorrectly-formatted symbolic refs
  resolve_ref(): extract a function get_packed_ref()
  resolve_ref(): turn buffer into a proper string as soon as possible
  resolve_ref(): only follow a symlink that contains a valid, normalized refname
  resolve_ref(): use prefixcmp()
  resolve_ref(): explicitly fail if a symlink is not readable
  Change check_refname_format() to reject unnormalized refnames
  Inline function refname_format_print()
  Make collapse_slashes() allocate memory for its result
  Do not allow ".lock" at the end of any refname component
  Refactor check_refname_format()
  Change check_ref_format() to take a flags argument
  Change bad_ref_char() to return a boolean value
  ...
2011-10-10 15:56:18 -07:00
Michael Haggerty
8d9c50105f Change check_ref_format() to take a flags argument
Change check_ref_format() to take a flags argument that indicates what
is acceptable in the reference name (analogous to "git
check-ref-format"'s "--allow-onelevel" and "--refspec-pattern").  This
is more convenient for callers and also fixes a failure in the test
suite (and likely elsewhere in the code) by enabling "onelevel" and
"refspec-pattern" to be allowed independently of each other.

Also rename check_ref_format() to check_refname_format() to make it
obvious that it deals with refnames rather than references themselves.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05 13:45:29 -07:00
Junio C Hamano
6099835c19 Allow git merge ":/<pattern>"
It probably is not such a good idea to use ":/<pattern>" to specify which
commit to merge, as ":/<pattern>" can often hit unexpected commits, but
somebody tried it and got a nonsense error message:

	fatal: ':/Foo bar' does not point to a commit

So here is a for-the-sake-of-consistency update that is fairly useless
that allows users to carefully try not shooting in the foot.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-15 16:52:43 -07:00
Junio C Hamano
be5ab43566 Merge branch 'jc/magic-pathspec'
* jc/magic-pathspec:
  setup.c: Fix some "symbol not declared" sparse warnings
  t3703: Skip tests using directory name ":" on Windows
  revision.c: leave a note for "a lone :" enhancement
  t3703, t4208: add test cases for magic pathspec
  rev/path disambiguation: further restrict "misspelled index entry" diag
  fix overslow :/no-such-string-ever-existed diagnostics
  fix overstrict :<path> diagnosis
  grep: use get_pathspec() correctly
  pathspec: drop "lone : means no pathspec" from get_pathspec()
  Revert "magic pathspec: add ":(icase)path" to match case insensitively"
  magic pathspec: add ":(icase)path" to match case insensitively
  magic pathspec: futureproof shorthand form
  magic pathspec: add tentative ":/path/from/top/level" pathspec support
2011-05-23 09:58:35 -07:00
Junio C Hamano
2e83b66c32 fix overslow :/no-such-string-ever-existed diagnostics
"git cmd :/no-such-string-ever-existed" runs an extra round of get_sha1()
since 009fee4 (Detailed diagnosis when parsing an object name fails.,
2009-12-07).  Once without error diagnosis to see there is no commit with
such a string in the log message (hence "it cannot be a ref"), and after
seeing that :/no-such-string-ever-existed is not a filename (hence "it
cannot be a path, either"), another time to give "better diagnosis".

The thing is, the second time it runs, we already know that traversing the
history all the way down to the root will _not_ find any matching commit.

Rename misguided "gently" parameter, which is turned off _only_ when the
"detailed diagnosis" codepath knows that it cannot be a ref and making the
call only for the caller to die with a message.  Flip its meaning (and
adjust the callers) and call it "only_to_die", which is not a great name,
but it describes far more clearly what the codepaths that switches their
behaviour based on this variable do.

On my box, the command spends ~1.8 seconds without the patch to make the
report; with the patch it spends ~1.12 seconds.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-10 12:37:54 -07:00
Junio C Hamano
9619617d33 fix overstrict :<path> diagnosis
Given "git log :", we get a disambiguation message that tries to be
helpful and yet totally misses the point, i.e.

    $ git log :
    fatal: Path '' does not exist (neither on disk nor in the index).
    $ git log :/
    fatal: Path '/' exists on disk, but not in the index.

An empty path nor anything that begins with '/' cannot possibly in the
index, and it is wrong to guess that the user might have meant to access
such an index entry.

It should yield the same error message as "git log '*.c'", i.e.

    $ git log '*.c'
    fatal: ambiguous argument '*.c': unknown revision or path not in the working tree.
    Use '--' to separate paths from revisions

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-10 12:36:06 -07:00
Michael J Gruber
e41d718c7d sha1_name: Suggest commit:./file for path in subdir
Currently, the "Did you mean..." message suggests "commit:fullpath"
only. Extend this to show the more convenient "commit:./file" form also.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-03 12:24:27 -07:00
Junio C Hamano
ea2c69ed47 Revert "core.abbrevguard: Ensure short object names stay unique a bit longer"
This reverts commit 72a5b561fc, as adding
fixed number of hexdigits more than necessary to make one object name
locally unique does not help in futureproofing the uniqueness of names
we generate today.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-10 22:41:14 -08:00
Junio C Hamano
716958c9a2 Merge branch 'tf/commit-list-prefix'
* tf/commit-list-prefix:
  commit: Add commit_list prefix in two function names.

Conflicts:
	sha1_name.c
2010-12-22 14:40:17 -08:00
Junio C Hamano
41cd7974b0 Merge branch 'nd/oneline-sha1-name-from-specific-ref'
* nd/oneline-sha1-name-from-specific-ref:
  get_sha1: handle special case $commit^{/}
  get_sha1: support $commit^{/regex} syntax
  get_sha1_oneline: make callers prepare the commit list to traverse
  get_sha1_oneline: fix lifespan rule of temp_commit_buffer variable
2010-12-21 14:30:19 -08:00
Nguyễn Thái Ngọc Duy
4322842acf get_sha1: handle special case $commit^{/}
Empty regex pattern should always match. But the exact behavior of
regexec() may vary. Because it always matches anyway, we can just
return 'matched' without calling regex machinery.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-16 13:11:42 -08:00
Junio C Hamano
620b89cd98 Merge branch 'nd/extended-sha1-relpath'
* nd/extended-sha1-relpath:
  get_sha1: teach ":$n:<path>" the same relative path logic
  get_sha1: support relative path ":path" syntax
  Make prefix_path() return char* without const

Conflicts:
	sha1_name.c
2010-12-16 12:51:05 -08:00
Nguyễn Thái Ngọc Duy
32574b68c5 get_sha1: support $commit^{/regex} syntax
This works like ":/regex" syntax that finds a recently created commit
starting from all refs, but limits the discovery to those reachable from
the named commit.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-14 16:50:45 -08:00
Nguyễn Thái Ngọc Duy
84baa31bcb get_sha1_oneline: make callers prepare the commit list to traverse
This gives callers more control, i.e. which ref will be searched from.
They must prepare the list ordered by committer date.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-12 22:32:01 -08:00
Junio C Hamano
28042dbcd6 get_sha1_oneline: fix lifespan rule of temp_commit_buffer variable
This is trying to free only what we ourselves read (as opposed to what
we borrowed from commit->buffer) but do so lazily only to work around
the fact that the code has many irregular exit points, and doing it right
makes it necessary to call free() from many different places in the loop.

Rewrite the structure of the code inside the loop so that the variable
has to live within a single iteration, ever.  This should make the logic
easier to follow as well.

Also we didn't free a temporary commit list we kept to hold the original
set of commits.  Free it.

Noticed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-12 22:31:45 -08:00
Junio C Hamano
3d6e0f745e get_sha1: teach ":$n:<path>" the same relative path logic
We taught the object name parser to take ":./<path>", ":../<path>", etc.
and understand them to be relative to the current working directory.

Given that ":<path>" is just a short-hand for ":0:<path>" (i.e. "take
stage #0 of that path"), we should allow ":$n:<path>" to interpret them
the same way.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-09 13:38:05 -08:00
Nguyễn Thái Ngọc Duy
979f792951 get_sha1: support relative path ":path" syntax
Currently :path and ref:path can be used to refer to a specific object
in index or ref respectively. "path" component is absolute path. This
patch allows "path" to be written as "./path" or "../path", which is
relative to user's original cwd.

This does not work in commands for which startup_info is NULL
(i.e. non-builtin ones, it seems none of them needs this anyway).

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-07 14:25:46 -08:00
Junio C Hamano
39f04dbaac Merge branch 'jn/thinner-wrapper'
* jn/thinner-wrapper:
  Remove pack file handling dependency from wrapper.o
  pack-objects: mark file-local variable static
  wrapper: give zlib wrappers their own translation unit
  strbuf: move strbuf_branchname to sha1_name.c
  path helpers: move git_mkstemp* to wrapper.c
  wrapper: move odb_* to environment.c
  wrapper: move xmmap() to sha1_file.c
2010-12-03 16:13:06 -08:00
Junio C Hamano
63ae595c6d Merge branch 'jc/abbrev-guard'
* jc/abbrev-guard:
  core.abbrevguard: Ensure short object names stay unique a bit longer
2010-12-03 16:10:35 -08:00
Thiago Farina
47e44ed1dc commit: Add commit_list prefix in two function names.
Add commit_list prefix to insert_by_date function and to sort_by_date,
so it's clear that these functions refer to commit_list structure.

Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-29 14:01:52 -08:00
Junio C Hamano
dd9d290bc9 Merge branch 'ks/no-textconv-symlink'
* ks/no-textconv-symlink:
  blame,cat-file --textconv: Don't assume mode is ``S_IFREF | 0664''
  blame,cat-file: Demonstrate --textconv is wrongly running converter on symlinks
  blame,cat-file: Prepare --textconv tests for correctly-failing conversion program
2010-11-17 14:59:27 -08:00
Jonathan Nieder
6bab74e7fb strbuf: move strbuf_branchname to sha1_name.c
strbuf_branchname is a thin wrapper around interpret_branch_name
from sha1_name.o.  Most strbuf.o users do not need it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-10 11:07:04 -08:00
Junio C Hamano
72a5b561fc core.abbrevguard: Ensure short object names stay unique a bit longer
Even though git makes sure that it uses enough hexdigits to show an
abbreviated object name unambiguously, as more objects are added to the
repository over time, a short name that used to be unique will stop being
unique.  Git uses this many extra hexdigits that are more than necessary
to make the object name currently unique, in the hope that its output will
stay unique a bit longer.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-28 17:37:35 -07:00
Kirill Smelkov
900647104e blame,cat-file --textconv: Don't assume mode is ``S_IFREF | 0664''
We need to get the correct mode when blame reads the source from the
working tree, the index, or trees.  This allows us to omit running
textconv filters on symbolic links.

Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29 16:53:25 -07:00
Matthieu Moy
95ad6d2de1 update comment and documentation for :/foo syntax
The documentation in revisions.txt did not match the implementation, and
the comment in sha1_name.c was incomplete.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-27 10:54:52 -07:00
Junio C Hamano
306d7e5556 Merge branch 'js/maint-reflog-beyond-horizon'
* js/maint-reflog-beyond-horizon:
  t1503: fix broken test_must_fail calls
  rev-parse: tests git rev-parse --verify master@{n}, for various n
  sha1_name.c: use warning in preference to fprintf(stderr
  rev-parse: exit with non-zero status if ref@{n} is not valid.
2010-09-03 22:24:29 -07:00
Jon Seymour
eedce784a7 sha1_name.c: use warning in preference to fprintf(stderr
This commit changes sha1_name.c to use warning instead of
fprintf(stderr).

Trailing newlines from message formats have been removed
since warning adds one itself.

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-24 10:46:14 -07:00
Jon Seymour
e6eedc31d5 rev-parse: exit with non-zero status if ref@{n} is not valid.
"The current behaviour of ref@{...} syntax parser is suboptimal:

    $ git rev-parse --verify jch@{99999} && echo true
    warning: Log for 'jch' only has 1368 entries.
    cfb88e9a8d
    true

It even knows that it is running off the cut-off point; it should just
cause the caller to notice that fact.  I don't think changing it to error
out should cause any harm to existing callers."

With this change:

   $ git rev-parse --verify jch@{99999} || echo false
   fatal: Log for 'jch' only has 1368 entries.
   false

   $ git rev-parse jch@{99999} || echo false
   fatal: Log for 'jch' only has 1368 entries.
   false

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-24 10:46:11 -07:00
Junio C Hamano
6baa9bd882 Merge branch 'jc/sha1-name-find-fix' into maint
* jc/sha1-name-find-fix:
  sha1_name.c: fix parsing of ":/token" syntax

Conflicts:
	sha1_name.c
2010-08-19 15:49:24 -07:00
Junio C Hamano
3d04589758 Merge branch 'jc/sha1-name-find-fix'
* jc/sha1-name-find-fix:
  sha1_name.c: fix parsing of ":/token" syntax

Conflicts:
	sha1_name.c
2010-08-12 18:32:49 -07:00
Junio C Hamano
f7bff00314 sha1_name.c: fix parsing of ":/token" syntax
The parser tried to clean up the object flags it used while finding
commits with matching string, but was not doing a very good job at it.

This caused "checkout -b new ':/token'", which internally tries to parse
':/token' twice as an object name, to fail when the commit in question
was reachable from only one ref.

The mask bits given to pop_most_recent_commit(&list, MASK) means "I have
already been on the list to be processed, so please do not place me again
even if I am found to be a parent of some other commit on the list."  So
mark them when we add them to the list at the beginning.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-02 14:40:48 -07:00
Junio C Hamano
cf4403a010 Merge branch 'cp/textconv-cat-file'
* cp/textconv-cat-file:
  git-cat-file.txt: Document --textconv
  t/t8007: test textconv support for cat-file
  textconv: support for cat_file
  sha1_name: add get_sha1_with_context()
2010-06-27 12:07:55 -07:00
Clément Poulain
573285e552 sha1_name: add get_sha1_with_context()
Textconv is defined by the diff driver, which is associated with a pathname,
not a blob. This fonction permits to know the context for the sha1 you're
looking for, especially his pathname

Signed-off-by: Clément Poulain <clement.poulain@ensimag.imag.fr>
Signed-off-by: Diane Gasselin <diane.gasselin@ensimag.imag.fr>
Signed-off-by: Axel Bonnet <axel.bonnet@ensimag.imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-18 09:41:29 -07:00
Linus Torvalds
57895105c4 Make :/ accept a regex rather than a fixed pattern
This also makes it trigger anywhere in the commit message, rather than
just at the beginning. Which tends to be a lot more useful.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-14 10:31:11 -07:00
Markus Heidelberg
77e8466fb9 sha1_name: fix segfault caused by invalid index access
The code to see if user input "git show :path" makes sense tried to access
the index without properly checking the array bound.

Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-28 10:32:06 -08:00
Junio C Hamano
e7b3cea0f7 Merge branch 'maint-1.6.6' into maint
* maint-1.6.6:
  dwim_ref: fix dangling symref warning
  stash pop: remove 'apply' options during 'drop' invocation
  diff: make sure --output=/bad/path is caught
  Remove hyphen from "git-command" in two error messages
2010-02-16 15:05:02 -08:00
Junio C Hamano
eb0bcd0fbe Merge branch 'maint-1.6.5' into maint-1.6.6
* maint-1.6.5:
  dwim_ref: fix dangling symref warning
  stash pop: remove 'apply' options during 'drop' invocation
  diff: make sure --output=/bad/path is caught
2010-02-16 15:04:55 -08:00
Jeff King
003c6abdb2 dwim_ref: fix dangling symref warning
If we encounter a symref that is dangling, in most cases we will warn
about it. The one exception is a dangling HEAD, as that indicates a
branch yet to be born.

However, the check in dwim_ref was not quite right. If we were fed
something like "HEAD^0" we would try to resolve "HEAD", see that it is
dangling, and then check whether the _original_ string we got was
"HEAD" (which it wasn't in this case). And that makes no sense; the
dangling thing we found was not "HEAD^0" but rather "HEAD".

Fixing this squelches a scary warning from "submodule summary HEAD" (and
consequently "git status" with status.submodulesummary set) in an empty
repo, as the submodule script calls "git rev-parse -q --verify HEAD^0".

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-16 09:03:58 -08:00
Jeff King
12a258c078 reject @{-1} not at beginning of object name
Something like foo@{-1} is nonsensical, as the @{-N} syntax
is reserved for "the Nth last branch", and is not an actual
reflog selector. We should not feed such nonsense to
approxidate at all.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-28 12:12:50 -08:00
Jeff King
d46a830193 fix parsing of @{-1}@{u} combination
Previously interpret_branch_name would see @{-1} and stop
parsing, leaving the @{u} as cruft that provoked an error.
Instead, we should recurse if there is more to parse.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-28 12:12:42 -08:00
Junio C Hamano
103209c678 Merge branch 'jc/maint-reflog-bad-timestamp'
* jc/maint-reflog-bad-timestamp:
  t0101: use a fixed timestamp when searching in the reflog
  Update @{bogus.timestamp} fix not to die()
  approxidate_careful() reports errorneous date string
2010-01-27 14:57:37 -08:00
Junio C Hamano
a5e10acbb9 Update @{bogus.timestamp} fix not to die()
The caller will say "It is not a valid object name" if it wants to, and
some callers may even try to see if it names an object and otherwise try to
see if it is a path.

Pointed out by Jeff King.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-27 10:53:09 -08:00
Junio C Hamano
93cfa7c7a8 approxidate_careful() reports errorneous date string
For a long time, the time based reflog syntax (e.g. master@{yesterday})
didn't complain when the "human readable" timestamp was misspelled, as
the underlying mechanism tried to be as lenient as possible.  The funny
thing was that parsing of "@{now}" even relied on the fact that anything
not recognized by the machinery returned the current timestamp.

Introduce approxidate_careful() that takes an optional pointer to an
integer, that gets assigned 1 when the input does not make sense as a
timestamp.

As I am too lazy to fix all the callers that use approxidate(), most of
the callers do not take advantage of the error checking, but convert the
code to parse reflog to use it as a demonstration.

Tests are mostly from Jeff King.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-26 13:51:41 -08:00
Junio C Hamano
4ca1b62386 Merge branch 'js/refer-upstream'
* js/refer-upstream:
  Teach @{upstream} syntax to strbuf_branchanme()
  t1506: more test for @{upstream} syntax
  Introduce <branch>@{upstream} notation
2010-01-22 16:08:13 -08:00
Junio C Hamano
ae0ba8e20a Teach @{upstream} syntax to strbuf_branchanme()
This teaches @{upstream} syntax to interpret_branch_name(), instead
of dwim_ref() machinery.

There are places in git UI that behaves differently when you give a local
branch name and when you give an extended SHA-1 expression that evaluates
to the commit object name at the tip of the branch.  The intent is that
the special syntax such as @{-1} can stand in as if the user spelled the
name of the branch in such places.

The name of the branch "frotz" to switch to ("git checkout frotz"), and
the name of the branch "nitfol" to fork a new branch "frotz" from ("git
checkout -b frotz nitfol"), are examples of such places.  These places
take only the name of the branch (e.g. "frotz"), and they are supposed to
act differently to an equivalent refname (e.g. "refs/heads/frotz"), so
hooking the @{upstream} and @{-N} syntax to dwim_ref() is insufficient
when we want to deal with cases a local branch is forked from another
local branch and use "forked@{upstream}" to name the forkee branch.

The "upstream" syntax "forked@{u}" is to specify the ref that "forked" is
configured to merge with, and most often the forkee is a remote tracking
branch, not a local branch.  We cannot simply return a local branch name,
but that does not necessarily mean we have to returns the full refname
(e.g. refs/remotes/origin/frotz, when returning origin/frotz is enough).
This update calls shorten_unambiguous_ref() to do so.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20 01:21:47 -08:00
Junio C Hamano
1f73566af5 Merge branch 'jc/checkout-merge-base'
* jc/checkout-merge-base:
  rebase -i: teach --onto A...B syntax
  rebase: fix --onto A...B parsing and add tests
  "rebase --onto A...B" replays history on the merge base between A and B
  "checkout A...B" switches to the merge base between A and B
2010-01-13 12:31:13 -08:00
Johannes Schindelin
28fb84382b Introduce <branch>@{upstream} notation
A new notation '<branch>@{upstream}' refers to the branch <branch> is set
to build on top of.  Missing <branch> (i.e. '@{upstream}') defaults to the
current branch.

This allows you to run, for example,

	for l in list of local branches
	do
		git log --oneline --left-right $l...$l@{upstream}
	done

to inspect each of the local branches you are interested in for the
divergence from its upstream.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12 14:00:58 -08:00
Matthieu Moy
009fee4774 Detailed diagnosis when parsing an object name fails.
The previous error message was the same in many situations (unknown
revision or path not in the working tree). We try to help the user as
much as possible to understand the error, especially with the
sha1:filename notation. In this case, we say whether the sha1 or the
filename is problematic, and diagnose the confusion between
relative-to-root and relative-to-$PWD confusion precisely.

The 7 new error messages are tested.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-07 13:35:06 -08:00
Junio C Hamano
619a644d6d "checkout A...B" switches to the merge base between A and B
When flipping commits around on topic branches, I often end up doing
this sequence:

 * Run "log --oneline next..jc/frotz" to find out the first commit
   on 'jc/frotz' branch not yet merged to 'next';

 * Run "checkout $that_commit^" to detach HEAD to the parent of it;

 * Rebuild the series on top of that commit; and

 * "show-branch jc/frotz HEAD" and "diff jc/frotz HEAD" to verify.

Introduce a new syntax to "git checkout" to name the commit to switch to,
to make the first two steps easier.  When the branch to switch to is
specified as A...B (you can omit either A or B but not both, and HEAD
is used instead of the omitted side), the merge base between these two
commits are computed, and if there is one unique one, we detach the HEAD
at that commit.

With this, I can say "checkout next...jc/frotz".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-18 12:34:56 -07:00
Brandon Casey
b45a09c4b4 sha1_name.c: avoid unnecessary strbuf_release
When we fall back to a standard for_each_reflog_ent() after failing to find
the nth branch switch (or if we had a short reflog) with the call to
for_each_recent_reflog_ent(), we do not need to free the memory allocated
for our strbuf's since a strbuf_reset() will be performed in
grab_nth_branch_switch() before assigning to the entry.

Plus, the strbuf_release() negates the non-zero hint we initially gave to
strbuf_init() just above these lines.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-16 15:09:21 -07:00
Junio C Hamano
431b1969fc Rename interpret/substitute nth_last_branch functions
These allow you to say "git checkout @{-2}" to switch to the branch two
"branch switching" ago by pretending as if you typed the name of that
branch.  As it is likely that we will be introducing more short-hands to
write the name of a branch without writing it explicitly, rename the
functions from "nth_last_branch" to more generic "branch_name", to prepare
for different semantics.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22 23:36:47 -07:00
Junio C Hamano
9e5b80cd87 Squelch overzealous "ignoring dangling symref" in an empty repository
057e713 (Warn use of "origin" when remotes/origin/HEAD is dangling,
2009-02-08) tried to warn dangling refs/remotes/origin/HEAD only when
"origin" was used to refer to it.  There was one corner case a symref is
expected to be dangling and this warning is unwarranted: HEAD in an empty
repository.

This squelches the warning for this special case.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-11 09:22:16 -08:00
Junio C Hamano
057e71384a Warn use of "origin" when remotes/origin/HEAD is dangling
The previous one squelched the diagnositic message we used to issue every
time we enumerated the refs and noticed a dangling ref.  This adds the
warning back to the place where the user actually attempts to use it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-10 22:26:32 -08:00
Junio C Hamano
8712b3cdb0 Merge branch 'tr/previous-branch'
* tr/previous-branch:
  t1505: remove debugging cruft
  Simplify parsing branch switching events in reflog
  Introduce for_each_recent_reflog_ent().
  interpret_nth_last_branch(): plug small memleak
  Fix reflog parsing for a malformed branch switching entry
  Fix parsing of @{-1}@{1}
  interpret_nth_last_branch(): avoid traversing the reflog twice
  checkout: implement "-" abbreviation, add docs and tests
  sha1_name: support @{-N} syntax in get_sha1()
  sha1_name: tweak @{-N} lookup
  checkout: implement "@{-N}" shortcut name for N-th last branch

Conflicts:
	sha1_name.c
2009-01-28 15:00:27 -08:00
Junio C Hamano
899d8dc392 Merge branch 'maint-1.6.0' into maint
* maint-1.6.0:
  test-path-utils: Fix off by one, found by valgrind
  get_sha1_basic(): fix invalid memory access, found by valgrind
2009-01-27 15:23:46 -08:00
Johannes Schindelin
f265458f61 get_sha1_basic(): fix invalid memory access, found by valgrind
When get_sha1_basic() is passed a buffer of len 0, it should not
check if buf[len-1] is a curly bracket.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-27 15:16:31 -08:00
Junio C Hamano
d7c03c1ff9 Simplify parsing branch switching events in reflog
We only accept "checkout: moving from A to B" newer style reflog entries,
in order to pick up A.  There is no point computing where B begins at
after running strstr to locate " to ", nor adding 4 and then subtracting 4
from the same pointer.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-21 00:42:22 -08:00
Junio C Hamano
101d15e097 Introduce for_each_recent_reflog_ent().
This can be used to scan only the last few kilobytes of a reflog, as a
cheap optimization when the data you are looking for is likely to be
found near the end of it.  The caller is expected to fall back to the
full scan if that is not the case.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-19 22:18:29 -08:00
Junio C Hamano
39765e5941 interpret_nth_last_branch(): plug small memleak
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-19 21:58:31 -08:00
Junio C Hamano
c829774c30 Fix reflog parsing for a malformed branch switching entry
target can be NULL when we failed to parse the message.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-19 16:44:17 -08:00
Johannes Schindelin
aa9c55b667 Fix parsing of @{-1}@{1}
To do that, Git no longer looks forward for the '@{' corresponding to the
closing '}' but backward, and dwim_ref() as well as dwim_log() learnt
about the @{-<N>} notation.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-19 16:36:34 -08:00
Junio C Hamano
c2883e62f5 interpret_nth_last_branch(): avoid traversing the reflog twice
You can have quite a many reflog entries, but you typically won't recall
which branch you were on after switching branches for more than several
times.

Instead of reading the reflog twice, this reads the branch switching event
and keeps as many entries as the user asked from the latest such entries,
which is the minimum required to be able to switch back to the branch we
were recently on.

[jc: improvements from Dscho squashed in]

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-19 15:35:21 -08:00
Thomas Rast
d18ba22154 sha1_name: support @{-N} syntax in get_sha1()
Let get_sha1() parse the @{-N} syntax, with docs and tests.

Note that while @{-1}^2, @{-2}~5 and such are supported, @{-1}@{1} is
currently not allowed.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 18:37:19 -08:00
Thomas Rast
a884d0cb71 sha1_name: tweak @{-N} lookup
Have the lookup only look at "interesting" checkouts, meaning those
that tell you "Already on ..." don't count even though they also cause
a reflog entry.

Let interpret_nth_last_branch() return the number of characters
parsed, so that git-checkout can verify that the branch spec was
@{-N}, not @{-1}^2 or something like that.  (The latter will be added
later.)

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 18:37:02 -08:00
Junio C Hamano
ae5a6c3684 checkout: implement "@{-N}" shortcut name for N-th last branch
Implement a shortcut @{-N} for the N-th last branch checked out, that
works by parsing the reflog for the message added by previous
git-checkout invocations.  We expand the @{-N} to the branch name, so
that you end up on an attached HEAD on that branch.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 18:36:49 -08:00
Junio C Hamano
356af64d84 Merge branch 'ar/maint-mksnpath' into HEAD
* ar/maint-mksnpath:
  Fix potentially dangerous uses of mkpath and git_path
  Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
  Add mksnpath which allows you to specify the output buffer
2008-10-26 22:24:44 -07:00
Alex Riesen
94cc355287 Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
Otherwise the function sometimes fail to resolve obviously correct
refnames, because the string data pointed to by "str" argument were
reused.

The change in dwim_log does not fix anything, just optimizes away
strcpy code as the path can be created directly in the available
buffer.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-26 22:10:28 -07:00
Shawn O. Pearce
ea360dd053 Make reflog query '@{1219188291}' act as '@{2008.8.19.16:24:51.-0700}'
As we support seconds-since-epoch in $GIT_COMMITTER_TIME we should
also support it in a reflog @{...} style notation.  We can easily
tell this part from @{nth} style notation by looking to see if the
value is unreasonably large for an @{nth} style notation.

The value 100000000 was chosen as it is already used by date.c to
disambiguate yyyymmdd format from a seconds-since-epoch time value.

A reflog with 100,000,000 record entries is also simply not valid.
Such a reflog would require at least 7.7 GB to store just the old
and new SHA-1 values.  So our randomly chosen upper limit for @{nth}
notation is "big enough".

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-21 23:30:17 -07:00
Junio C Hamano
0c4cd7f4a7 ignore non-existent refs in dwim_log()
f2eba66 (Enable HEAD@{...} and make it independent from the current
branch, 2007-02-03) introduced dwim_log() to handle <refname>@{...}
syntax, and as part of its processing, it checks if the ref exists by
calling refsolve_ref().  It should call it as a reader to make sure the
call returns NULL for a nonexistent ref (not as a potential writer in
which case it does not return NULL).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-23 18:11:04 -07:00
Junio C Hamano
30c0312fd1 Merge branch 'maint-1.5.4' into maint
* maint-1.5.4:
  cvsimport: always pass user data to "system" as a list
  fix reflog approxidate parsing bug
2008-04-29 22:55:07 -07:00
Jeff King
861f00e349 fix reflog approxidate parsing bug
In get_sha1_basic, we parse a string like

  HEAD@{10 seconds ago}:path/to/file

into its constituent ref, reflog date, and path components.
We never actually munge the string itself, but instead keep
offsets into the string with their associated lengths.

When we call approxidate on the contents inside braces,
however, we pass just a string without a length. This means
that approxidate could sometimes look past the closing brace
and (erroneously) interpret the rest of the string as part
of the date.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-29 22:22:19 -07:00
Junio C Hamano
2a2ad0c000 Merge branch 'maint'
* maint:
  Make man page building quiet when DOCBOOK_XSL_172 is defined
  git-new-workdir: Share SVN meta data between work dirs and the repository
  rev-parse: fix meaning of rev~ vs rev~0.
  git-svn: don't blindly append '*' to branch/tags config
2008-03-15 00:05:40 -07:00
Linus Torvalds
621ff67594 rev-parse: fix meaning of rev~ vs rev~0.
I think it would make more sense for rev~ to have the same guarantees that
rev^ has, namely to always return a commit. I would also suggest that not
giving a number would have the same effect of defaulting to 1, not 0.

Right now it's a bit illogical, but at least it's an _undocumented_
illogical behaviour.

This patch makes '^' and '~' act the same for the default count (i.e. both
default to 1), and also have the same behaviour for a count of zero.

Before (no discernible pattern):

	[torvalds@woody git]$ git rev-parse v1.5.1 v1.5.1^0 v1.5.1~0 v1.5.1^ v1.5.1~
	45354a57ee
	89815cab95
	45354a57ee
	045f5759c9
	45354a57ee

After (fairly logical):

	[torvalds@woody git]$ git rev-parse v1.5.1 v1.5.1^0 v1.5.1~0 v1.5.1^ v1.5.1~
	45354a57ee
	89815cab95
	89815cab95
	045f5759c9
	045f5759c9

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-14 17:59:24 -07:00
Junio C Hamano
5d921e2931 Merge branch 'jc/cherry-pick' (early part)
* 'jc/cherry-pick' (early part):
  expose a helper function peel_to_type().
  merge-recursive: split low-level merge functions out.

Conflicts:

	Makefile
	builtin-merge-recursive.c
	sha1_name.c
2008-03-11 02:05:12 -07:00
Junio C Hamano
b66fde9a28 find_unique_abbrev(): redefine semantics
The function returned NULL when no object that matches the name
was found, but that made the callers more complicated, as nobody
used that NULL return as an indication that no object with such
a name exists.  They (at least the careful ones) instead took
the full 40-hexdigit and used in such a case, and the careless
ones segfaulted.

With this "git rev-parse --short 5555555555555555555555555555555555555555"
would stop segfaulting.

This is based on Jeff King's rewrite to my RFC patch, but "missing"
logic swapped to "exists".  The final logic reads:

    For existing objects, make sure the abbreviated string uniquely
    identifies it.  Otherwise, make sure the abbreviated string is
    long enough so that it would not name any existing object.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-01 23:52:13 -08:00
Jim Meyering
8e0f70033b Avoid unnecessary "if-before-free" tests.
This change removes all obvious useless if-before-free tests.
E.g., it replaces code like this:

        if (some_expression)
                free (some_expression);

with the now-equivalent:

        free (some_expression);

It is equivalent not just because POSIX has required free(NULL)
to work for a long time, but simply because it has worked for
so long that no reasonable porting target fails the test.
Here's some evidence from nearly 1.5 years ago:

    http://www.winehq.org/pipermail/wine-patches/2006-October/031544.html

FYI, the change below was prepared by running the following:

  git ls-files -z | xargs -0 \
  perl -0x3b -pi -e \
    's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*NULL)?\s*\)\s+(free\s*\(\s*\1\s*\))/$2/s'

Note however, that it doesn't handle brace-enclosed blocks like
"if (x) { free (x); }".  But that's ok, since there were none like
that in git sources.

Beware: if you do use the above snippet, note that it can
produce syntactically invalid C code.  That happens when the
affected "if"-statement has a matching "else".
E.g., it would transform this

  if (x)
    free (x);
  else
    foo ();

into this:

  free (x);
  else
    foo ();

There were none of those here, either.

If you're interested in automating detection of the useless
tests, you might like the useless-if-before-free script in gnulib:
[it *does* detect brace-enclosed free statements, and has a --name=S
 option to make it detect free-like functions with different names]

  http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/useless-if-before-free

Addendum:
  Remove one more (in imap-send.c), spotted by Jean-Luc Herren <jlh@gmx.ch>.

Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-22 14:14:40 -08:00
Junio C Hamano
ee4f06c0a6 Merge branch 'mk/maint-parse-careful'
* mk/maint-parse-careful:
  peel_onion: handle NULL
  check return value from parse_commit() in various functions
  parse_commit: don't fail, if object is NULL
  revision.c: handle tag->tagged == NULL
  reachable.c::process_tree/blob: check for NULL
  process_tag: handle tag->tagged == NULL
  check results of parse_commit in merge_bases
  list-objects.c::process_tree/blob: check for NULL
  reachable.c::add_one_tree: handle NULL from lookup_tree
  mark_blob/tree_uninteresting: check for NULL
  get_sha1_oneline: check return value of parse_object
  read_object_with_reference: don't read beyond the buffer
2008-02-18 20:56:01 -08:00
Martin Koegler
f73df331a4 peel_onion: handle NULL
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-18 20:49:18 -08:00
Martin Koegler
283cdbcf49 get_sha1_oneline: check return value of parse_object
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-18 19:20:18 -08:00
Junio C Hamano
8177631547 expose a helper function peel_to_type().
This helper function is the core of "$object^{type}" parser.
Now it is made available to callers outside sha1_name.c
2008-02-18 00:51:05 -08:00
Martin Koegler
affeef12fb deref_tag: handle return value NULL
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-17 23:46:55 -08:00
Linus Torvalds
7a51ed66f6 Make on-disk index representation separate from in-core one
This converts the index explicitly on read and write to its on-disk
format, allowing the in-core format to contain more flags, and be
simpler.

In particular, the in-core format is now host-endian (as opposed to the
on-disk one that is network endian in order to be able to be shared
across machines) and as a result we can dispense with all the
htonl/ntohl on accesses to the cache_entry fields.

This will make it easier to make use of various temporary flags that do
not exist in the on-disk format.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-21 12:44:31 -08:00
Junio C Hamano
9bbe6db85f Merge branch 'sp/refspec-match'
* sp/refspec-match:
  refactor fetch's ref matching to use refname_match()
  push: use same rules as git-rev-parse to resolve refspecs
  add refname_match()
  push: support pushing HEAD to real branch name
2007-12-04 17:07:10 -08:00