|
0c7f49dd
|
2017-06-30T13:39:01
|
|
Make sure to always include "common.h" first
Next to including several files, our "common.h" header also declares
various macros which are then used throughout the project. As such, we
have to make sure to always include this file first in all
implementation files. Otherwise, we might encounter problems or even
silent behavioural differences due to macros or defines not being
defined as they should be. So in fact, our header and implementation
files should make sure to always include "common.h" first.
This commit does so by establishing a common include pattern. Header
files inside of "src" will now always include "common.h" as its first
other file, separated by a newline from all the other includes to make
it stand out as special. There are two cases for the implementation
files. If they do have a matching header file, they will always include
this one first, leading to "common.h" being transitively included as
first file. If they do not have a matching header file, they instead
include "common.h" as first file themselves.
This fixes the outlined problems and will become our standard practice
for header and source files inside of the "src/" from now on.
|
|
62a617dc
|
2014-11-06T16:16:46
|
|
iterator: submodules are determined by an index or tree
We cannot know from looking at .gitmodules whether a directory is a
submodule or not. We need the index or tree we are comparing against to
tell us. Otherwise we have to assume the entry in .gitmodules is stale
or otherwise invalid.
Thus we pass the index of the repository into the workdir iterator, even
if we do not want to compare against it. This follows what git does,
which even for `git diff <tree>`, it will consider staged submodules as
such.
|
|
6affd71f
|
2014-01-03T17:38:34
|
|
git_checkout_opts -> git_checkout_options
|
|
7fa73de1
|
2013-09-23T17:52:40
|
|
Move functions in checkout_conflicts to checkout.c
It seemed exceptionally silly to have a split there
where no split needed to be.
|
|
216f97e4
|
2013-09-23T09:47:47
|
|
Two-step conflict checkout (load / perform)
Move conflict handling into two steps: load the conflicts and
then apply the conflicts. This is more compatible with the
existing checkout implementation and makes progress reporting
more sane.
|
|
cfae7f85
|
2013-08-09T20:23:36
|
|
Honor UPDATE_ONLY bit when checking out conflicts
|
|
629b661c
|
2013-07-17T09:49:56
|
|
checkout (from index) can write conflicts
|
|
eec1c1fe
|
2013-09-20T22:49:20
|
|
clone: const-ify checkout options
The removal of many options which lead to the direct usage of the
user's checkout options means we should make sure they remain const.
|
|
359fc2d2
|
2013-01-08T17:07:25
|
|
update copyrights
|
|
cf208031
|
2012-12-06T13:36:17
|
|
Rework checkout internals (again)
I've tried to map out the detailed behaviors of checkout and make
sure that we're handling the various cases correctly, along with
providing options to allow us to emulate "git checkout" and "git
checkout-index" with the various flags. I've thrown away flags
in the checkout API that seemed like clutter and added some new
ones. Also, I've converted the conflict callback to a general
notification callback so we can emulate "git checkout" output and
display "dirty" files.
As of this commit, the new behavior is not working 100% but some
of that is probably baked into tests that are not testing the
right thing. This is a decent snapshot point, I think, along the
way to getting the update done.
|
|
7e5c8a5b
|
2012-12-10T15:31:43
|
|
More checkout improvements
This flips checkout back to be driven off the changes between
the baseline and the target trees. This reinstates the complex
code for tracking the contents of the working directory, but
overall, I think the resulting logic is easier to follow.
|